常見開源OLAP技術架構對比

常見開源OLAP技術架構對比

文章目錄

常見開源OLAP技術架構對比

1. 什么是OLAP

2. OLAP引擎的常見操作

3. OLAP分類

4. OLAP引擎的對比

5. OLAP引擎的主要特點

6. 總結

1. 什么是OLAP

**OLAP（On-line Analytical Processing，聯機分析處理）**是在基于數據倉庫多維模型的基礎上實現的面向分析的各類操作的集合?？梢员容^下其與傳統的OLTP（On-line Transaction Processing，聯機事務處理）的區別來看一下它的特點：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-PI6tQsd7-1630662318879)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/2.jpg)]

OLAP的優勢是基于數據倉庫面向***主題、集成的、保留歷史及不可變更的數據存儲，以及多維模型多視角多層次的數據組織形式，如果脫離的這兩點，OLAP將不復存在，也就沒有優勢可言。***

Tips：相關概念 DW/DWH：數據倉庫 data warehouse MPP:大規模并行處理 Massively Parallel Processing 結構化數據：關系型數據庫中的數據 半結構化數據：日志、xml、json數據 非結構化數據：富文本文檔、網頁、多媒體 ROLAP：關系模型存放 MOLAP：多維模型存放 HOLAP：MOLAP 和 ROLAP 的一種融合

1

2

3

4

5

6

7

8

9

參考：http://webdataanalysis.net/web-data-warehouse/data-cube-and-olap/

2. OLAP引擎的常見操作

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-4QeVUeRb-1630662318881)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/5.jpg)]

下面所述幾種OLAP操作，是針對Kimball的星型模型（Star Schema）和雪花模型（Snowflake Schema）來說的。在Kimball模型中，定義了事實和維度。可以參考:http://webdataanalysis.net/web-data-warehouse/multidimensional-data-model/

上卷（Roll Up）/聚合：選定某些維度，根據這些維度來聚合事實，如果用SQL來表達就是select dim_a, aggs_func(fact_b) from fact_table group by dim_a.

下鉆（Drill Down）：上卷和下鉆是相反的操作。它是選定某些維度，將這些維度拆解出小的維度（如年拆解為月，省份拆解為城市），之后聚合事實。

切片（Slicing、Dicing）：選定某些維度，并根據特定值過濾這些維度的值，將原來的大Cube切成小cube。如dim_a in (‘CN’, ‘USA’)

旋轉（Pivot/Rotate）：維度位置的互換。

下圖舉了一個具體的例子：

圖片來自：http://webdataanalysis.net/web-data-warehouse/data-cube-and-olap/

3. OLAP分類

OLAP 是一種讓用戶可以用從不同視角方便快捷的分析數據的計算方法。主流的 OLAP 可以分為3類：多維 OLAP ( Multi-dimensional OLAP )、關系型 OLAP ( Relational OLAP ) 和混合 OLAP ( Hybrid OLAP ) 三大類。

MOLAP 的優點和缺點

MOLAP的典型代表是：Druid，Kylin，Doris，MOLAP一般會根據用戶定義的數據維度、度量（也可以叫指標）在數據寫入時生成預聚合數據；Query查詢到來時，實際上查詢的是預聚合的數據而不是原始明細數據，在查詢模式相對固定的場景中，這種優化提速很明顯。

MOLAP 的優點和缺點都來自于其數據預處理 ( pre-processing ) 環節。數據預處理，將原始數據按照指定的計算規則預先做聚合計算，這樣避免了查詢過程中出現大量的即使計算，提升了查詢性能。

但是這樣的預聚合處理，需要預先定義維度，會限制后期數據查詢的靈活性；如果查詢工作涉及新的指標，需要重新增加預處理流程，損失了靈活度，存儲成本也很高；同時，這種方式不支持明細數據的查詢，僅適用于聚合型查詢（如：sum，avg，count）。

因此，MOLAP 適用于查詢場景相對固定并且對查詢性能要求非常高的場景。如廣告主經常使用的廣告投放報表分析。

ROLAP 的優點和缺點

ROLAP的典型代表是：Presto，Impala，GreenPlum，Clickhouse，Elasticsearch，Hive，Spark SQL，Flink SQL

數據寫入時，ROLAP并未使用像MOLAP那樣的預聚合技術；ROLAP收到Query請求時，會先解析Query，生成執行計劃，掃描數據，執行關系型算子，在原始數據上做過濾(Where)、聚合(Sum, Avg, Count)、關聯(Join)，分組（Group By)、排序（Order By）等，最后將結算結果返回給用戶，整個過程都是即時計算，沒有預先聚合好的數據可供優化查詢速度，拼的都是資源和算力的大小。

ROLAP 不需要進行數據預處理 ( pre-processing )，因此查詢靈活，可擴展性好。這類引擎使用 MPP 架構 ( 與Hadoop相似的大型并行處理架構，可以通過擴大并發來增加計算資源 )，可以高效處理大量數據。

但是當數據量較大或 query 較為復雜時，查詢性能也無法像 MOLAP 那樣穩定。所有計算都是即時觸發 ( 沒有預處理 )，因此會耗費更多的計算資源，帶來潛在的重復計算。

因此，ROLAP 適用于對查詢模式不固定、查詢靈活性要求高的場景。如數據分析師常用的數據分析類產品，他們往往會對數據做各種預先不能確定的分析，所以需要更高的查詢靈活性。

混合 OLAP ( HOLAP )

混合 OLAP，是 MOLAP 和 ROLAP 的一種融合。當查詢聚合性數據的時候，使用MOLAP 技術；當查詢明細數據時，使用 ROLAP 技術。在給定使用場景的前提下，以達到查詢性能的最優化。

順便提一下，國內外有一些閉源的商業OLAP引擎，沒有在這里歸類和介紹，主要是因為使用的公司不多并且源碼不可見、資料少，很難分析學習其中的源碼和技術點。在一二線的互聯網公司中，應用較為廣泛的還是上面提到的各種OLAP引擎，如果你希望能夠通過掌握一種OLAP技術，學習這些就夠了。

4. OLAP引擎的對比

我們花一些篇幅來介紹和對比一下目前大數據業內非常流行的幾個OLAP引擎，它們是Hive、SparkSQL、FlinkSQL、Clickhouse、Elasticsearch、Druid、Kylin、Presto、Impala、Doris?？梢哉f目前沒有一個引擎能在數據量，靈活程度和性能上做到完美，用戶需要根據自己的需求進行選型。

4.1 并發能力與查詢延遲對比

這里可能有朋友有疑問：Hive，SparkSQL，FlinkSQL這些它們要么查詢速度慢，要么QPS上不去，怎么能算是OLAP引擎呢？其實OLAP的定義中并沒有關于查詢執行速度和QPS的限定。進一步來說，這里引出了衡量OLAP特定業務場景的兩個重要的指標：

查詢速度：Search Latency（常用Search Latency Pct99來衡量）

查詢并發能力：QPS

如果根據不同的查詢場景、再按照查詢速度與查詢并發能力這兩個指標來劃分以上所列的OLAP引擎，這些OLAP引擎的能力劃分如下：

場景一：簡單查詢

簡單查詢指的是點查、簡單聚合查詢或者數據查詢能夠命中索引或物化視圖（物化視圖指的是物化的查詢中間結果，如預聚合數據）。這樣的查詢經常出現在【在線數據服務】的企業應用中，如阿里生意參謀、騰訊的廣點通、京東的廣告業務等，它們共同的特點是對外服務、面向B端商業客戶（通常是幾十萬的級別）；并發查詢量(QPS)大；對響應時間要求高，一般是ms級別（可以想象一下，如果廣告主查詢頁面投放數據，如果10s還沒有結果，很傷害體驗）；查詢模式相對固定且簡單。從下圖可知，這種場景最合適的是Elasticsearch、Doris、Druid、Kylin這些。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-E0o4sEsq-1630662318891)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/7.jpg)]

場景二：復雜查詢

復雜查詢指的是復雜聚合查詢、大批量數據SCAN、復雜的查詢（如JOIN）。在ad-hoc場景中，經常會有這樣的查詢，往往用戶不能預先知道要查詢什么，更多的是探索式的。這里也根據QPS和查詢耗時分幾種情況，如下圖所示，根據業務的需求來選擇對應的引擎即可。有一點要提的是FlinkSQL和SparkSQL雖然也能完成類似需求，但是它們目前還不是開箱即用，需要做周邊生態建設，這兩種技術目前更多的應用場景還是在通過操作靈活的編程API來完成流式或離線的計算上。

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-GGHUw5XW-1630662318892)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/8.jpg)]

4.2 執行模型對比

【原圖來自Apache Doris官方介紹PPT】

Scatter-Gather執行模型：相當于MapReduce中的一趟Map和Reduce，沒有多輪的迭代，而且中間計算結果往往存儲在內存中，通過網絡直接交換。Elasticsearch、Druid、Kylin都是此模型。

MapReduce：Hive是此模型

MPP：MPP學名是大規模并行計算，其實很難給它一個準確的定義。如果說的寬泛一點，Presto、Impala、Doris、Clickhouse、Spark SQL、Flink SQL這些都算。有人說Spark SQL和Flink SQL屬于DAG模型，我們思考后認為，DAG并不算一種單獨的模型，它只是生成執行計劃的一種方式。

5. OLAP引擎的主要特點

5.1 Hive

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-ah7A1BCF-1630662318894)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/11.jpg)]

Hive是一個分布式SQL on Hadoop方案，底層依賴MapReduce計算模型執行分布式計算。Hive擅長執行長時間運行的離線批處理，數據量越大，優勢越明顯。Hive在數據量大、數據驅動需求強烈的互聯網大廠比較流行。近2年，隨著clickhouse的逐漸流行，對于一些總數據量不超過百PB級別的互聯網數據倉庫需求，已經有多家公司改為了clickhouse的方案。clickhouse的優勢是單個查詢執行速度更快，不依賴hadoop，架構和運維更簡單。

5.2 Spark SQL、Flink SQL

在大部分場景下，Hive計算還是太慢了，別說不能滿足那些要求高QPS、低查詢延遲的的對外在線服務的需求，就連企業內部的產品、運營、數據分析師也會經常抱怨Hive執行ad-hoc查詢太慢。這些痛點，推動了MPP內存迭代和DAG計算模型的誕生和發展，諸如Spark SQL、Flink SQL、Presto這些技術，目前在企業中也非常流行。Spark SQL、Flink SQL的執行速度更快，編程API豐富，同時支持流式計算與批處理，并且有流批統一的趨勢，使大數據應用更簡單。

注：上面說的在線服務，指的是如阿里對幾百萬淘寶店主開放的數據應用生意參謀，騰訊對幾十萬廣告主開發的廣點通廣告投放分析等。

5.3 Clickhouse

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-D6ssWHUO-1630662318896)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/31.jpg)]

ClickHouse是近年來備受關注的開源列式數據庫，主要用于數據分析（OLAP）領域。目前國內社區火熱，各個大廠紛紛跟進大規模使用：

今日頭條 內部用ClickHouse來做用戶行為分析，內部一共幾千個ClickHouse節點，單集群最大1200節點，總數據量幾十PB，日增原始數據300TB左右。

騰訊內部用ClickHouse做游戲數據分析，并且為之建立了一整套監控運維體系。

攜程內部從18年7月份開始接入試用，目前80%的業務都跑在ClickHouse上。每天數據增量十多億，近百萬次查詢請求。

快手內部也在使用ClickHouse，存儲總量大約10PB， 每天新增200TB， 90%查詢小于3S。

在國外，Yandex內部有數百節點用于做用戶點擊行為分析，CloudFlare、Spotify等頭部公司也在使用。

ClickHouse從OLAP場景需求出發，定制開發了一套全新的高效列式存儲引擎，并且實現了數據有序存儲、主鍵索引、稀疏索引、數據Sharding、數據Partitioning、TTL、主備復制等豐富功能。以上功能共同為ClickHouse極速的分析性能奠定了基礎。

注：內容來自https://zhuanlan.zhihu.com/p/98135840

ClickHouse部署架構簡單，易用，不依賴Hadoop體系（HDFS+YARN）。它比較擅長的地方是對一個大數據量的單表進行聚合查詢。Clickhouse用C++實現，底層實現具備向量化執行（Vectorized Execution）、減枝等優化能力，具備強勁的查詢性能。目前在互聯網企業均有廣泛使用，比較適合內部BI報表型應用，可以提供低延遲（ms級別）的響應速度，也就是說單個查詢非?？?。但是Clickhouse也有它的局限性，在OLAP技術選型的時候，應該避免把它作為多表關聯查詢(JOIN)的引擎，也應該避免把它用在期望支撐高并發數據查詢的場景，OLAP分析場景中，一般認為QPS達到1000+就算高并發，而不是像電商、搶紅包等業務場景中，10W以上才算高并發，畢竟數據分析場景，數據海量，計算復雜，QPS能夠達到1000已經非常不容易。例如Clickhouse，如果如數據量是TB級別，聚合計算稍復雜一點，單集群QPS一般達到100已經很困難了，所以它更適合企業內部BI報表應用，而不適合如數十萬的廣告主報表或者數百萬的淘寶店主相關報表應用。Clickhouse的執行模型決定了它會盡全力來執行一個Query，而不是同時執行很多Query。

5.4 Elasticsearch

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-IwNw6nOO-1630662318897)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/51.jpg)]

提到Elasticsearch，很多人的印象是這是一個開源的分布式搜索引擎，底層依托Lucene倒排索引結構，并且支持文本分詞，非常適合作為搜索服務。這些印象都對，并且用Elasticsearch作為搜索引擎，一個三節點的集群，支撐1000+的查詢QPS也不是什么難事，這是搜索場景。

但是，我們這里要講的內容是Elasticsearch的另一個功能，即作為聚合（aggregation）場景的OLAP引擎，它與搜索型場景區別很大。聚合場景，可以等同于select c1, c2, sum(c3), count(c4) from table where c1 in (‘china’, ‘usa’) and c2 < 100 這樣的SQL，也就是做多維度分組聚合。雖然Elasticsearch DSL是一個復雜的JSON而不是SQL，但是意思相同，可以互相轉換。

用Elasticsearch作為OLAP引擎，有幾項優勢：（1）擅長高QPS（QPS > 1K）、低延遲、過濾條件多、查詢模式簡單（如點查、簡單聚合）的查詢場景。（2）集群自動化管理能力（shard allocation，recovery）能力非常強。集群、索引管理和查看的API非常豐富。

ES的執行引擎是最簡單的Scatter-Gather模型，相當于MapReduce計算模型的一趟Map和Reduce。Scatter和Gather之間的節點數據交換也是基于內存的不會像MapReduce那樣每次Shuffle要先落盤。ES底層依賴的Lucene文件格式，我們可以把Lucene理解為一種行列混存的模式，并且在查詢時通過FST，跳表等加快數據查詢。這種Scatter-Gather模型的問題是，如果Gather/Reduce的數據量比較大，由于ES時單節點執行，可能會非常慢。整體來講，ES是通過犧牲靈活性，提高了簡單OLAP查詢的QPS、降低了延遲。

用Elasticsearch作為OLAP引擎，有幾項劣勢：多維度分組排序、分頁**。不支持Join**。在做aggregation后，由于返回的數據嵌套層次太多，數據量會過于膨脹。

ElasticSearch和Solar也可以歸為寬表模型。但其系統設計架構有較大不同，這兩個一般稱為搜索引擎，通過倒排索引，應用Scatter-Gather計算模型提高查詢性能。對于搜索類的查詢效果較好，但當數據量較大或進行掃描聚合類查詢時，查詢性能會有較大影響。

5.5 Presto

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-rjzwqq0o-1630662318898)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/4.jpg)]

Presto、Impala、GreenPlum均基于MPP架構，相比Elasticsearch、Druid、Kylin這樣的簡單Scatter-Gather模型，在支持的SQL計算上更加通用，更適合ad-hoc查詢場景，然而這些通用系統往往比專用系統更難做性能優化，所以不太適合做對查詢QPS(參考值QPS > 1000)、延遲要求比較高(參考值search latency < 500ms)的在線服務，更適合做公司內部的查詢服務和加速Hive查詢的服務。Presto還有一個優秀的特性是使用了ANSI標準SQL，并且支持超過30+的數據源Connector。這里我們給讀者留下一個思考題：以Presto為代表的MPP模型與Hive為代表的MapReduce模型的性能差異比較大的原因是什么？

5.6 Impala

Impala 是 Cloudera 在受到 Google 的 Dremel 啟發下開發的實時交互SQL大數據查詢工具，是CDH 平臺首選的 PB 級大數據實時查詢分析引擎。它擁有和Hadoop一樣的可擴展性、它提供了類SQL（類Hsql）語法，在多用戶場景下也能擁有較高的響應速度和吞吐量。它是由Java和C++實現的，Java提供的查詢交互的接口和實現，C++實現了查詢引擎部分，除此之外，Impala還能夠共享Hive Metastore，甚至可以直接使用Hive的JDBC jar和beeline等直接對Impala進行查詢、支持豐富的數據存儲格式（Parquet、Avro等）。此外，Impala 沒有再使用緩慢的 Hive+MapReduce 批處理，而是通過使用與商用并行關系數據庫中類似的分布式查詢引擎（由 Query Planner、Query Coordinator 和 Query Exec Engine 三部分組成），可以直接從 HDFS 或 HBase 中用 SELECT、JOIN 和統計函數查詢數據，從而大大降低了延遲。Impala經常搭配存儲引擎Kudu一起提供服務，這么做最大的優勢是點查比較快，并且支持數據的Update和Delete。

注：部分內容來自https://zhuanlan.zhihu.com/p/55197560

5.7 Doris

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-VN4GZzyo-1630662318900)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/71.jpg)]

Doris是百度主導的，根據Google Mesa論文和Impala項目改寫的一個大數據分析引擎，在百度、美團團、京東的廣告分析等業務有廣泛的應用。Doris的主要功能特性如下圖所示：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-tNJvEObN-1630662318901)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/81.jpg)]

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-SU8txeJ3-1630662318903)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/91.jpg)]

【原圖來自Apache Doris官方介紹PPT】

5.8 Druid

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-zGAnHvUc-1630662318904)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/0.jpg)]

Druid 是一種能對歷史和實時數據提供亞秒級別的查詢的數據存儲。Druid 支持低延時的數據攝取，靈活的數據探索分析，高性能的數據聚合，簡便的水平擴展。Druid支持更大的數據規模，具備一定的預聚合能力，通過倒排索引和位圖索引進一步優化查詢性能，在廣告分析場景、監控報警等時序類應用均有廣泛使用；

Druid的特點包括：

Druid實時的數據消費，真正做到數據攝入實時、查詢結果實時

Druid支持 PB 級數據、千億級事件快速處理，支持每秒數千查詢并發

Druid的核心是時間序列，把數據按照時間序列分批存儲，十分適合用于對按時間進行統計分析的場景

Druid把數據列分為三類：時間戳、維度列、指標列

Druid不支持多表連接

Druid中的數據一般是使用其他計算框架(Spark等)預計算好的低層次統計數據

Druid不適合用于處理透視維度復雜多變的查詢場景

Druid擅長的查詢類型比較單一，一些常用的SQL(groupby 等)語句在druid里運行速度一般

Druid支持低延時的數據插入、更新，但是比hbase、傳統數據庫要慢很多

與其他的時序數據庫類似，Druid在查詢條件命中大量數據情況下可能會有性能問題，而且排序、聚合等能力普遍不太好，靈活性和擴展性不夠，比如缺乏Join、子查詢等。

注：以上介紹Druid的內容來自：https://segmentfault.com/a/1190000020385389

5.9 Kylin

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-72cN52Rz-1630662318905)(http://www.hangdaowangluo.com/wp-content/uploads/2021/03/01.jpg)]

Kylin自身就是一個MOLAP系統，多維立方體（MOLAP Cube）的設計使得用戶能夠在Kylin里為百億以上數據集定義數據模型并構建立方體進行數據的預聚合。

適合Kylin的場景包括：

用戶數據存在于Hadoop HDFS中，利用Hive將HDFS文件數據以關系數據方式存取，數據量巨大，在500G以上

每天有數G甚至數十G的數據增量導入

有10個以內較為固定的分析維度

簡單來說，Kylin中數據立方的思想就是以空間換時間，通過定義一系列的緯度，對每個緯度的組合進行預先計算并存儲。有N個緯度，就會有2的N次種組合。所以最好控制好緯度的數量，因為存儲量會隨著緯度的增加爆炸式的增長，產生災難性后果。

注：以上介紹Kylin的內容來自：https://segmentfault.com/a/1190000020385389

6. 總結

我以為，我們在這里所做的各個OLAP引擎的介紹和分析，并不一定100%合理準確，只是一種參考。只有真正有OLAP線上經驗的人，在特定業務場景、特定數據量的，有過深入優化以上介紹的一種或者幾種OLAP引擎經驗的專家，才有相應的發言權來給出技術選型的建議。但是由于這些OLAP引擎技術方案太多，不可能有哪個專家全都精通。以我個人為例，過往的工作經驗使我在Hive、SparkSQL、FlinkSQL、Presto、Elasticsearch這幾個方面更了解，其他的引擎不敢瞎說自己懂，不構成技術選型的建議。所以大概每個專家說的都不準確、不全面，我們在這里鼓勵大家多討論和評論，多提問題，成為各個OLAP引擎方面的專家。

Hive SQL

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。