常見開源OLAP技術架構對比

1.OLAP

On-line Analytical Processing，聯機分析處理是在基於數據倉庫多維模型的基礎上實現的面向分析的各類操作的集合。可以比較下其與傳統的OLTP（On-line Transaction Processing，聯機事務處理）的區別來看一下它的特點：

數據處理類型	OLTP	OLAP
面向對象	業務開發人員	分析決策人員
數據模型	關系模型	多維模型
操作數據量	幾條或者幾十條	百萬千萬條記錄
操作類型	增刪改查	查詢為主
主要衡量指標	事務吞吐量	查詢響應速度（QPS）

2.OLAP的基本操作

　　我們已經知道OLAP的操作是以查詢——也就是數據庫的SELECT操作為主，但是查詢可以很復雜，比如基於關系數據庫的查詢可以多表關聯，可以使用COUNT、SUM、AVG等聚合函數。OLAP正是基於多維模型定義了一些常見的面向分析的操作類型是這些操作顯得更加直觀。

　　OLAP的多維分析操作包括：鑽取（Drill-down）、上卷（Roll-up）、切片（Slice）、切塊（Dice）以及旋轉（Pivot），下面還是以上面的數據立方體為例來逐一解釋下：

 

3.OLAP分類

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

3.1 MOLAP

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

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

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

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

3.2 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 適用於對查詢模式不固定、查詢靈活性要求高的場景。如數據分析師常用的數據分析類產品，他們往往會對數據做各種預先不能確定的分析，所以需要更高的查詢靈活性。

3.3 HOLAP

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

順便提一下，國內外有一些閉源的商業OLAP引擎，沒有在這里歸類和介紹，主要是因為使用的公司不多並且源碼不可見、資料少，很難分析學習其中的源碼和技術點。

4.OLAP引擎的對比

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

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這些。

場景二：復雜查詢

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

4.2 執行模型對比

 

Scatter-Gather執行模型：單節點匯聚，無法完成大表join及高基數聚合，Elasticsearch是此模型。

MapReduce：任務之間需要等待中間數據落盤，有磁盤IO的消耗，Hive是此模型。

MPP：MPP學名是大規模並行計算（Massively Parallel Processing），流水線執行無需等待，數據內存傳輸，無磁盤IO消耗，Doris、Druid

5.OLAP引擎的主要特點

5.1 Hive

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 Presto

Presto 是由 Facebook 開源的大數據分布式 SQL 查詢引擎，基於內存的低延遲高並發並行計算（MPP）引擎，適用於交互式分析查詢，大部分場景比hive快一個數量級。Presto特點：

1. 本身並不存儲數據，但是可以接入多種數據源，包括 Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。
2. 完全支持ANSI SQL標准，用戶可以直接使用 ANSI SQL 進行數據查詢和計算。
3. 可以混合多個catalog進行join查詢和計算，支持跨數據源的級聯查詢。
4. 基於PipeLine進行設計的，流水管道式數據處理，支持數據規模GB~PB，計算中拿出一部分放在內存、計算、拋出、再拿。
5. SQL on Hadoop：彌補Hive的效率性能和靈活性的不足，Presto和Spark SQL、Impala有很多異曲同工之處。

5.4 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。

5.5 Kylin

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

適合Kylin的場景包括：

1. 用戶數據存在於Hadoop HDFS中，利用Hive將HDFS文件數據以關系數據方式存取，數據量巨大，在500G以上。
2. 每天有數G甚至數十G的數據增量導入。
3. 有10個以內較為固定的分析維度。

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

5.6 Elasticsearch

架構圖

提到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引擎，有幾項劣勢：

1. 多維度分組排序、分頁。
2. 不支持Join。
3. 在做aggregation后，由於返回的數據嵌套層次太多，數據量會過於膨脹。

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

5.7 Doris

架構圖

Doris是百度主導的，根據Google Mesa論文和Impala項目改寫的一個大數據分析引擎，在百度、美團團、京東的廣告分析等業務有廣泛的應用。Doris 的整體架構和 TiDB 類似，借助 MySQL 協議，用戶使用任意 MySQL 的 ODBC/JDBC以及MySQL 的客戶端，都可以直接訪問 Doris。

Doris數據模型在建表時就已經確定，且無法修改。所以，選擇一個合適的數據模型非常重要，主要有Aggregate、Uniq、Duplicate三種模型：

1. Aggregate 模型可以通過預聚合，極大地降低聚合查詢時所需掃描的數據量和查詢的計算量，非常適合有固定模式的報表類查詢場景。但是該模型對 count(*) 查詢很不友好。同時因為固定了 Value 列上的聚合方式，在進行其他類型的聚合查詢時，需要考慮語意正確性。
2. Uniq 模型針對需要唯一主鍵約束的場景，可以保證主鍵唯一性約束。但是無法利用 ROLLUP 等預聚合帶來的查詢優勢（因為本質是 REPLACE，沒有 SUM 這種聚合方式）。
3. Duplicate 適合任意維度的 Ad-hoc 查詢。雖然同樣無法利用預聚合的特性，但是不受聚合模型的約束，可以發揮列存模型的優勢（只讀取相關列，而不需要讀取所有 Key 列）。

Doris適用場景：

1、對數據分析、統計

數據分析大體上可以分為兩大類場景：一種偏向於報表類的，另一種偏向於多維分析的。

2、報表

報表類數據分析，數據分析以及查詢的模式相對比較固定，而且后台 SQL 的模式往往都是確定的。針對此類應用場景，選擇使用 MySQL 存結果數據，用戶可從界面選擇執行批處理以及發送郵件。在 Doris 平台中，報表類查詢時延一般在秒級以下。

3、多維分析

這里提到的多維分析，同樣要求數據是結構化的，適用於查詢相對靈活的場景，例如數據分析條件以及聚合維度等方面不是很確定，一般將此類數據分析定義為多維分析。相對於報表類分析，多維分析的查詢時延會稍慢，大約在會在 10s 的級別。

5.8 Druid

架構圖:

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

Druid的特點包括：

1. Druid實時的數據消費，真正做到數據攝入實時、查詢結果實時。
2. Druid支持 PB 級數據、千億級事件快速處理，支持每秒數千查詢並發。
3. Druid把數據列分為三類：時間戳（timestamp）、維度列（Dimension）、指標列（Metric）。
4. Druid的核心是時間序列，把數據按照時間序列分批存儲，十分適合用於對按時間進行統計分析的場景。
5. Druid不支持多表連接。
6. Druid不適合用於處理維度復雜多變的查詢場景。

5.9  Clickhouse

集群模式架構圖（基於ReplicatedMergeTree+Distributed）

 數據查詢過程：

 

ClickHouse是近年來備受關注的開源列式數據庫，主要用於數據分析（OLAP）領域。主要特性如下：

1. PB級數據處理能力
2. 列式數據存儲
3. 優秀的數據壓縮
4. 多核並行處理
5. 多服務器分布式處理
6. SQL支持（部分語句有點怪）
7. 向量化引擎
8. 支持實時數據更新
9. 高吞吐寫入
10. 近似計算
11. 少依賴，上手非常容易

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

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。

6. 總結

簡單對比下個人認為未來比較有前途的OLAP：Elasticsearch、Doris、Druid、ClickHouse

OLAP引擎	優點	缺點	運維復雜度	支持SQL	GitHub Star
Elasticsearch	搜索場景第一選擇 高並發、低延遲 支持特殊數據類型（如IP、經緯度等） 跨集群搜索 數據“冷熱分離” 跨集群復制（X-pack） 數據Roll up（X-pack） 完善的集群管理機制	多維度聚合性能一般 耗內存：索引信息、cache 寫放大問題：磁盤空間占用大	低	有限支持	56k
Doris	MPP架構 向量化執行引擎 高效的聚集表技術 預聚合Roll up 支持更新表Schema	開源版本還沒有從apache畢業 生態待完善	低	支持標准SQL，兼容MySQL協議	3.4k
Druid	MPP架構 實時/批量數據攝入 支持較高並發 數據預聚合	運維部署復雜，有6種進程服務 對高基數聚合和精確去重支持不好 不支持根據主鍵的單條記錄更新	高	有限支持	11k
ClickHouse	多核並行處理 向量化執行引擎 實時數據更新 數據壓縮比高 單表查詢性能高 數據“冷熱分離” 跨集群復制 豐富的表引擎 數據預聚合	並發不高（QPS小於100） 不適合通過其鍵檢索單行的點查詢 多副本之間的數據同步依賴zookeeper 分片與副本功能完全靠配置文件實現，無法自動管理，所以當集群規模較大時，集群運維成本較高	中	支持（接近標准SQL）	19k

 在這里所做的各個OLAP引擎的介紹和分析，並不一定100%合理准確，只是一種參考。只有真正有OLAP線上經驗的人，在特定業務場景、特定數據量的，有過深入優化以上介紹的一種或者幾種OLAP引擎經驗的專家，才有相應的發言權來給出技術選型的建議。

 

參考：

https://www.elastic.co/cn/elasticsearch/

https://clickhouse.tech/

https://druid.apache.org/

http://kylin.apache.org/

http://doris.apache.org/master/zh-CN/

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

https://www.jianshu.com/p/5f0d29ed3ff9

https://www.infoq.cn/article/rr1gd91futjwi1yzepvw

https://developer.aliyun.com/article/783804?utm_content=g_1000267492