Categories
程式開發

選擇適合自己的 OLAP 引擎


摘要:本文主要介紹了主流開源的OLAP引擎:Hive、Sparksql、Presto、Kylin、Impala、Druid、Clickhouse 等,逐一介紹了每一款開源OLAP 引擎,包含架構、優缺點、使用場景等,希望可以給大家有所啟發。 PS: 文章較長,建議收藏慢慢看。

說起 OLAP 要追溯到 1993 年。

準則1 OLAP模型必須提供多維概念視圖準則2 透明性準則準則3 存取能力準則準則4 穩定的報表能力準則5 客戶/服務器體系結構準則6 維的等同性準則準則7 動態的稀疏矩陣處理準則準則8多用戶支持能力準則準則9 非受限的跨維操作準則10 直觀的數據操縱準則11 靈活的報表生成準則12 不受限的維與聚集層次

OLAP場景的關鍵特徵

大多數是讀請求數據總是以相當大的批(> 1000 rows)進行寫入不修改已添加的數據每次查詢都從數據庫中讀取大量的行,但是同時又僅需要少量的列寬表,即每個表包含著大量的列較少的查詢(通常每台服務器每秒數百個查詢或更少)對於簡單查詢,允許延遲大約50毫秒列中的數據相對較小:數字和短字符串(例如,每個URL 60個字節)處理單個查詢時需要高吞吐量(每個服務器每秒高達數十億行)事務不是必須的對數據一致性要求低每一個查詢除了一個大表外都很小查詢結果明顯小於源數據,換句話說,數據被過濾或聚合後能夠被盛放在單台服務器的內存中

與OLAP 不同的是,OLTP系統強調數據庫內存效率,強調內存各種指標的命令率,強調綁定變量,強調並發操作,強調事務性。

OLAP系統則強調數據分析,強調SQL執行時長,強調磁盤I/O,強調分區。

選擇適合自己的 OLAP 引擎 1

OLAP開源引擎

目前市面上主流的開源OLAP引擎包含不限於:Hive、Spark SQL、Presto、Kylin、Impala、Druid、Clickhouse、Greeplum等,可以說目前沒有一個引擎能在數據量,靈活程度和性能上做到完美,用戶需要根據自己的需求進行選型。

從事數據開發工作的小伙伴,大概率用過以上的幾種甚至全部。所以下面就開門見山了,默認大家熟悉大數據的專業名詞和生態環境。

Hive hive.apache.org

Hive 是基於 Hadoop 的一個數據倉庫工具,可以將結構化的數據文件映射為一張數據庫表,並提供完整的 sql 查詢功能,可以將 sql 語句轉換為 MapReduce 任務進行運行。其優點是學習成本低,可以通過類SQL語句快速實現簡單的MapReduce統計,不必開發專門的MapReduce應用,十分適合數據倉庫的統計分析。

Spark SQL spark.apache.org/sql

SparkSQL的前身是Shark,它將 SQL 查詢與 Spark 程序無縫集成,可以將結構化數據作為 Spark 的 RDD 進行查詢。 SparkSQL作為Spark生態的一員繼續發展,而不再受限於Hive,只是兼容Hive。

幾點說明:

1)Spark SQL的應用並不局限於SQL;

2)訪問hive、json、parquet等文件的數據;

3)SQL只是Spark SQL的一個功能而已;

4)Spark SQL這個名字起的並不恰當;

Spark SQL在整個Spark體系中的位置如下

選擇適合自己的 OLAP 引擎 2

選擇適合自己的 OLAP 引擎 3

看圖說話,分成三個部分,第一部分是前端的,第二部分是後端的,對三個部分是中間的Catalyst,這個Catalyst是整個架構的核心。

關於架構的流程總結,下面引用知乎@ysiwgtus 的內容

1、首先我们看前端。前端有不同种的访问方式。

1)典型的我们可以使用hive,你hive过来就是一个SQL语句,SQL语句就是一个字符串,那么这个字符串如何才能够被Catalyst进行解析呢,或者说如何将一个SQL语句翻译成spark的作业呢,他要经过解析的,有一个抽象语法树,这是第一种访问方式。

2)第二种访问方式,我们可以通过spark的应用程序,编程的方式来操作,编程的时候我们可以使用SQL,也可以使用dataframe或者是dataset api。

3)第三种是Streaming SQL,也就是说流和SQL综合起来使用。

2、我们看Catalyst

1)前端三个访问方式,当前端过来以后他首先会生成一个Unresolved Logical Plan,也就是一个没有彻底解析完的一个执行计划,这个执行计划会和我们的元数据,也就是metastore里面的schema一个表信息进行整合然后生成一个Logical Plan(逻辑执行计划)。

2)那么这个逻辑执行计划是最原始的,中间还会做各种优化也很多规则作用上去,也就是图中的Optimization Rules,然后进行优化以后生成优化过后的逻辑执行计划,就是图中的Optimized Logical Plan。

3)那么逻辑执行计划生成完了以后,才会生成物理执行计划,也就是我们spark的一个作业。

那么从你的SQL语句解析成抽象语法树之后后续的部分全部交给Catalyst来完成,包括你逻辑执行计划的生成,逻辑执行计划的优化都是由Catalyst完成的,我们再回顾一下shark,他的解析然后逻辑执行计划的生成和优化全部都是依赖于hive的,那么这就是sparkSQL和hive典型的一个区别从抽象语法树之后,也就是图上AST之后完全由sparkSQL里的Catalyst接管以后,由他来生成物理执行计划,并最终提交到生产上面去运行就行了。

3、以上就是sparkSQL架构的整体的流程,这个流程当中主要有几个部分,语法树、逻辑执行计划、优化之后的逻辑执行计划、物理执行计划。如果熟悉SQL的执行流程或者了解hive的SQL语句是怎么样从SQL翻译成mapreduce作业的话,那么其实你会看出来整个流程都是非常相似的,那么在SQL on hadoop框架里面的那么多框架,只要是基于SQL的,他的大概流程都是这样子的,从SQL解析过后成为一个抽象语法树,然后再到了逻辑执行计划,然后逻辑执行计划优化,再到物理执行计划,再到物理执行计划的优化,最终生成你对应框架的作业,有可能是mapreduce作业,可能是spark作业,提交到对应的集群上运行就可以了。

Presto  prestodb.io

選擇適合自己的 OLAP 引擎 4

Presto支持標準的ANSI SQL,包括複雜查詢、聚合(aggregation)、連接(join)和窗口函數(window functions)。作為Hive和Pig(Hive和Pig都是通過MapReduce的管道流來完成HDFS數據的查詢)的替代者,Presto 本身並不存儲數據,但是可以接入多種數據源,並且支持跨數據源的級聯查詢。

Presto沒有使用MapReduce,它是通過一個定制的查詢和執行引擎來完成的。它的所有的查詢處理是在內存中,這也是它的性能很高的一個主要原因。 Presto和Spark SQL有很大的相似性,這是它區別於Hive的最根本的區別。

Presto由於是基於內存的,而 Hive 是在磁盤上讀寫的,因此 presto 比hive快很多,但是由於是基於內存的計算當多張大表關聯操作時易引起內存溢出錯誤。

Apache Kylin™ kylin.apache.org/cn

Apache Kylin™是一個開源的、分佈式的分析型數據倉庫,提供Hadoop/Spark 之上的 SQL 查詢接口及多維分析(OLAP)能力以支持超大規模數據,最初由 eBay 開發並貢獻至開源社區。它能在亞秒內查詢巨大的表。

Kylin 提供與多種數據可視化工具的整合能力,如 Tableau,PowerBI 等,令用戶可以使用 BI 工具對 Hadoop 數據進行分析。

選擇適合自己的 OLAP 引擎 5

簡單的講解一下上面的架構圖,以Hive或者Kafka作為數據源,裡面保存著真實表,而Kylin做的就是將數據進行抽象,通過引擎實現Cube的構建。將Hbase作為數據的倉庫,存放Cube。因為Hbase的直接讀取比較複雜,所以Kylin提供了近似SQL和HQL的形式,滿足了數據讀取的基本需求。對外提供了RestApi和JDBC/ODBC方便操作。

選擇適合自己的 OLAP 引擎 6

Kylin自身就是一個MOLAP系統,多維立方體(MOLAP Cube)的設計使得用戶能夠在Kylin里為百億以上數據集定義數據模型並構建立方體進行數據的預聚合。立方體的設計,我的理解是就是以空間換時間,通過定義一系列的緯度,對每個緯度的組合進行預先計算並存儲。有N個緯度,就會有2的N次種組合。所以最好事先控制好緯度的數量,因為存儲量會隨著緯度的增加爆炸式的增長,產生災難性後果。

Impala  impala.apache.org

Impala 是 Cloudera 公司推出,提供對 HDFS、Hbase 數據的高性能、低延遲的交互式 SQL 查詢功能。 Impala 使用 Hive的元數據, 完全在內存中計算。是CDH 平台首選的 PB 級大數據實時查詢分析引擎。

選擇適合自己的 OLAP 引擎 7

選擇適合自己的 OLAP 引擎 8

執行流程

1、基於內存進行計算,能夠對PB級數據進行交互式實時查詢、分析

2、無需轉換為MR,直接讀取HDFS及Hbase數據  ,從而大大降低了延遲。

Impala沒有MapReduce批處理,而是通過使用與商用並行關係數據庫中類似的分佈式查詢引擎(由Query Planner、Query Coordinator和Query Exec Engine三部分組成

3、C++編寫,LLVM統一編譯運行

在底層對硬件進行優化, LLVM:編譯器,比較穩定,效率高

4、兼容HiveSQL

支持hive基本的一些查詢等,hive中的一些複雜結構是不支持的

5、具有數據倉庫的特性,可對hive數據直接做數據分析

6、支持Data Local

數據本地化:無需數據移動,減少數據的傳輸

7、支持列式存儲

可以和Hbase整合:因為Hive可以和Hbasez整合

8、支持JDBC/ODBC遠程訪問

Impala劣勢

1、對內存依賴大

只在內存中計算,官方建議128G(一般64G基本滿足),可優化:  各個節點匯總的節點(服務器)內存選用大的,不匯總節點可小點

2、C++編寫 開源    ?

對於java, C++可能不是很了解

3、完全依賴hive

4、實踐過程中分區超過1w 性能嚴重下下降

定期刪除沒有必要的分區,保證分區的個數不要太大

5、穩定性不如hive

因完全在內存中計算,內存不夠,會出現問題, hive內存不夠,可使用外存

Impala不提供任何對序列化和反序列化的支持。 Impala只能讀取文本文件,而不能讀取自定義二進製文件。每當新的記錄/文件被添加到HDFS中的數據目錄時,該表需要被刷新。

Druid  druid.apache.org

說起Druid,大家首先想到的是阿里的Druid 數據庫連接池,而本文介紹的Druid 是一個在大數據場景下的解決方案,是需要在復雜的海量數據下進行交互式實時數據展現的BI/OLAP工具。

選擇適合自己的 OLAP 引擎 9

Druid 的架構是 Lambda 架構,分成實時層( Overlord、 MiddleManager )和批處理層( Broker 和 Historical )。

更多關於架構的描述,可以看官方文檔或者 《Druid在有讚的實踐》

目前 Druid 廣泛應用在國內外各個公司,比如阿里,滴滴,知乎,360,eBay,Hulu 等。 Druid 之所以能夠在 OLAP 家族中佔據一席之地,主要依賴其強大的 MPP 架構設計。初次之外,它還運用到了四點重要的技術,分別是:預聚合、列式存儲、字典編碼、位圖索引。

常見的應用場景:(https://druid.apache.org/use-cases)

點擊流分析(網絡和移動分析)風險/欺詐分析網絡遙測分析(網絡性能監控)服務器指標存儲供應鏈分析(製造指標)應用程序性能指標商業智能/ OLAP

Druid的核心設計結合了數據倉庫,時間序列數據庫和搜索系統的思想,以創建一個統一的系統,用於針對各種用例的實時分析。 Druid將這三個系統中每個系統的關鍵特徵合併到其接收層,存儲格式,查詢層和核心體系結構中。

(https://druid.apache.org/technology)

什麼樣的業務適合用 Druid?

建議如下:

時序化數據:Druid 可以理解為時序數據庫,所有的數據必須有時間字段。實時數據接入可容忍丟數據(tranquility):目前 tranquility 有丟數據的風險,所以建議實時和離線一起用,實時接當天數據,離線第二天把今天的數據全部覆蓋,保證數據完備性。 OLAP 查詢而不是 OLTP 查詢:Druid 查詢並發有限,不適合 OLTP 查詢。非精確的去重計算:目前 Druid 的去重都是非精確的。無 Join 操作:Druid 適合處理星型模型的數據,不支持關聯操作。數據沒有 update 更新操作,只對 segment 粒度進行覆蓋:由於時序化數據的特點,Druid 不支持數據的更新。

Clickhouse clickhouse.tech

Clickhouse 由俄羅斯 yandex 公司開發。專為在線數據分析而設計。 Yandex是俄羅斯搜索引擎公司。官方提供的文檔表名,ClickHouse 日處理記錄數”十億級”。

這個列式存儲數據庫的跑分要超過很多流行的商業MPP數據庫軟件,例如Vertica。

特性:

1.真正的面向列的DBMS

2.數據壓縮

3.磁盤存儲的數據

覽量和會話。

4.多核並行處理

5.在多個服務器上分佈式處理

6.SQL支持

7.向量化引擎

8.實時數據更新

9.索引

10.支持在線查詢

11.支持近似計算

12.數據複製和對數據完整性的支持。

使用ClickHouse也有其本身的限制,包括:

缺少高頻率,低延遲的修改或刪除已存在數據的能力。僅能用於批量刪除或修改數據。沒有完整的事務支持不支持二級索引有限的SQL支持,join實現與眾不同不支持窗口功能元數據管理需要人工干預維護

目前還沒有一個OLAP系統能夠滿足各種場景的查詢需求。其本質原因是,沒有一個系統能同時在數據量、性能、和靈活性三個方面做到完美,每個系統在設計時都需要在這三者間做出取捨。

參考

https://xie.infoq.cn/article/77ec0d231d36c963a8e6d1630

https://www.jianshu.com/p/26c18e6a30c3

https://www.jianshu.com/p/4d0e0b42a3b0

https://www.jianshu.com/p/257ff24db397

https://www.cnblogs.com/tgzhu/p/6033373.html

https://zhuanlan.zhihu.com/p/29385628

https://blog.csdn.net/yongshenghuang/article/details/84925941https://www.jianshu.com/p/b5c85cadb362

https://clickhouse.yandex/docs/zh/development/architecture/

http://www.clickhouse.com.cn

https://www.jianshu.com/p/a5bf490247ea

https://blog.csdn.net/weixin_34273481/article/details/89238947

https://blog.csdn.net/warren288/article/details/80629909

往期推薦

2020 年 Flink 最佳學習路線,學習的路上,你,並不孤單

Apache Flink OLAP引擎性能優化及應用【乾貨】趣頭條基於 Flink+ClickHouse 構建實時數據分析平台

來了來了,2020 首場 Meetup ,可!

本地Spark連接遠程集群Hive(Scala/Python)Spark 性能優化指南(官網文檔)

關注我,帶你不同角度看數據架構

選擇適合自己的 OLAP 引擎 10