隨着大數據技術在各行各業的深入應用，對於海量數據的分析需求也愈加凸顯，OLAP技術也逐漸走入人們的視野。本文將圍繞常見的開源OLAP引擎展開，介紹什麼是OLAP以及OLAP的常見操作和分類，並對目前主流的開源OLAP引擎進行對比和特點的總結。
一、什麼是OLAP
OLAP（On-line Analytical Processing，聯機分析處理）是在基於數據倉庫多維模型的基礎上實現的面向分析的各類操作的集合。可以比較下其與傳統的OLTP（On-line Transaction Processing，聯機事務處理）的區別來看一下它的特點：
OLAP的優勢是基於數據倉庫面向主題、集成的、保留歷史及不可變更的數據存儲，以及多維模型多視角多層次的數據組織形式，如果脫離了這兩點，OLAP將不復存在，也就沒有優勢可言。
二、OLAP引擎的常見操作
下面所述幾種OLAP操作，是針對Kimball的星型模型（Star Schema）和雪花模型（Snowflake Schema）來說的。在Kimball模型中，定義了事實和維度。
上卷（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）：維度位置的互換。
下圖舉了一個具體的例子：
三、OLAP分類
OLAP 是一種讓用戶可以用從不同視角方便快捷的分析數據的計算方法。主流的 OLAP 可以分爲3類：多維OLAP ( Multi-dimensional OLAP )、關係型OLAP ( Relational OLAP ) 和混合OLAP ( Hybrid OLAP ) 三大類。
1.多維OLAP ( Multi-dimensional OLAP )
MOLAP基於直接支持多維數據和操作的本機邏輯模型。數據物理上存儲在多維數組中, 並且使用定位技術來訪問它們。
MOLAP架構包含了數據庫服務器、MOLAP服務器和前端工具三個組件。
MOLAP的典型代表是：Druid 和 Kylin。MOLAP一般會根據用戶定義的數據維度、度量（也可以叫指標）在數據寫入時生成預聚合數據；Query查詢到來時，實際上查詢的是預聚合的數據而不是原始明細數據，在查詢模式相對固定的場景中，這種優化提速很明顯。
MOLAP 的優點和缺點都來自於其數據預處理 ( pre-processing ) 環節。數據預處理，將原始數據按照指定的計算規則預先做聚合計算，這樣避免了查詢過程中出現大量的即使計算，提升了查詢性能。
但是這樣的預聚合處理，需要預先定義維度，會限制後期數據查詢的靈活性；如果查詢工作涉及新的指標，需要重新增加預處理流程，損失了靈活度，存儲成本也很高；同時，這種方式不支持明細數據的查詢，僅適用於聚合型查詢（如：sum，avg，count）。
因此，MOLAP 適用於查詢場景相對固定並且對查詢性能要求非常高的場景。如廣告主經常使用的廣告投放報表分析。
2.關係型OLAP ( Relational OLAP )
關係OLAP（ROLAP）是中間服務器, 它們位於關係後端服務器和用戶前端工具之間，其使用關係或擴展關係DBMS來保存和處理倉庫數據, 並使用OLAP中間件來提供丟失的數據。
ROLAP的體系結構如下圖，其中包含了數據庫服務器、ROLAP服務器和前端工具。
ROLAP的典型代表是：Presto，Impala，GreenPlum，Clickhouse，Elasticsearch，Hive，Spark SQL，Flink SQL。
ROLAP的優勢在於以下兩個方面：
第一，在數據寫入時，ROLAP並未使用像MOLAP那樣的預聚合技術。ROLAP收到Query請求時，會先解析Query，生成執行計劃，掃描數據，執行關係型算子，在原始數據上做過濾(Where)、聚合(Sum, Avg, Count)、關聯(Join)，分組（Group By)、排序（Order By）等，最後將結算結果返回給用戶，整個過程都是即時計算，沒有預先聚合好的數據可供優化查詢速度，拼的都是資源和算力的大小。
第二，ROLAP 不需要進行數據預處理 ( pre-processing )，因此查詢靈活，可擴展性好。這類引擎使用 MPP 架構 ( 與Hadoop相似的大型並行處理架構，可以通過擴大併發來增加計算資源 )，可以高效處理大量數據。
但是ROLAP也存在着劣勢，那就是當數據量較大或 query 較爲複雜時，查詢性能也無法像 MOLAP 那樣穩定。所有計算都是即時觸發 ( 沒有預處理 )，因此會耗費更多的計算資源，帶來潛在的重複計算。
因此，ROLAP 適用於對查詢模式不固定、查詢靈活性要求高的場景。如數據分析師常用的數據分析類產品，他們往往會對數據做各種預先不能確定的分析，所以需要更高的查詢靈活性。
3.混合OLAP ( Hybrid OLAP )
混合 OLAP，是 MOLAP 和 ROLAP 的一種融合。當查詢聚合性數據的時候，使用MOLAP 技術；當查詢明細數據時，使用 ROLAP 技術。在給定使用場景的前提下，以達到查詢性能的最優化。混合OLAP的技術體系架構如下圖：
混合 OLAP的優勢在於其很好的結合了MOLAP和ROLAP的優勢之處，並且提供了所有聚合級別的快速訪問。同時因爲它僅將聚合信息存儲在OLAP服務器上, 而詳細記錄保留在關係數據庫中。因此, 不會保留詳細記錄的重複副本，平衡了磁盤空間需求。
混合 OLAP的劣勢恰恰在於其由於集成了MOLAP和ROLAP，因此需要同時支持MOLAP和ROLAP，並且本身的體系結構也非常複雜。
4.Others
除此之外，還包含一些其他分類，包括啓用Web的OLAP（WOLAP），桌面OLAP（DOLAP），移動OLAP（MOLAP）和空間OLAP（SOLAP）。但總體上不太流行，故此不再進行介紹。
四、開源OLAP引擎對比
針對於目前大數據業內非常流行的數個開源OLAP引擎：Hive、SparkSQL、FlinkSQL、Clickhouse、Elasticsearch、Druid、Kylin、Presto、Impala分別挑選了一些場景進行了對比，可以說目前沒有一個引擎能在數據量，靈活程度和性能上做到完美，用戶需要根據自己的需求進行選型。
1.併發能力與查詢延遲對比
看到這裏可能有人會提出疑問：Hive，SparkSQL，FlinkSQL這些它們要麼查詢速度慢，要麼QPS上不去，怎麼能算是OLAP引擎呢？其實OLAP的定義中並沒有關於查詢執行速度和QPS的限定。進一步來說，這裏引出了衡量OLAP特定業務場景的兩個重要的指標：
查詢速度：Search Latency
查詢併發能力：QPS
如果根據不同的查詢場景、再按照查詢速度與查詢併發能力這兩個指標來劃分以上所列的OLAP引擎，這些OLAP引擎的能力劃分如下：
場景一：簡單查詢
簡單查詢指的是點查、簡單聚合查詢或者數據查詢能夠命中索引或物化視圖（物化視圖指的是物化的查詢中間結果，如預聚合數據）。這樣的查詢經常出現在【在線數據服務】的企業應用中，如阿里生意參謀、騰訊的廣點通、京東的廣告業務等，它們共同的特點是對外服務、面向B端商業客戶（通常是幾十萬的級別）；併發查詢量(QPS)大；對響應時間要求高，一般是ms級別（可以想象一下，如果廣告主查詢頁面投放數據，如果10s還沒有結果，很傷害體驗）；查詢模式相對固定且簡單。從下圖可知，這種場景最合適的是Elasticsearch、Druid、Kylin。
場景二：複雜查詢
複雜查詢指的是複雜聚合查詢、大批量數據SCAN、複雜的查詢（如JOIN）。在ad-hoc場景中，經常會有這樣的查詢，往往用戶不能預先知道要查詢什麼，更多的是探索式的。這裏也根據QPS和查詢耗時分幾種情況，如下圖所示，根據業務的需求來選擇對應的引擎即可。有一點要提的是FlinkSQL和SparkSQL雖然也能完成類似需求，但是它們目前還不是開箱即用，需要做周邊生態建設，這兩種技術目前更多的應用場景還是在通過操作靈活的編程API來完成流式或離線的計算上。
2.執行模型對比
Scatter-Gather執行模型：相當於MapReduce中的一趟Map和Reduce，沒有多輪的迭代，而且中間計算結果往往存儲在內存中，通過網絡直接交換。Elasticsearch、Druid、Kylin都是此模型。
MapReduce：Hive採用的正是這個模型。
MPP：MPP學名是大規模並行計算，其實很難給它一個準確的定義。如果說的寬泛一點，Presto、Impala、Clickhouse、Spark SQL、Flink SQL這些都算。有人說Spark SQL和Flink SQL屬於DAG模型，我們思考後認爲，DAG並不算一種單獨的模型，它只是生成執行計劃的一種方式。
五、主流開源OLAP引擎的主要特點
1.Hive
Hive是一個分佈式SQL on Hadoop方案，底層依賴MapReduce計算模型執行分佈式計算。Hive擅長執行長時間運行的離線批處理，數據量越大，優勢越明顯。Hive在數據量大、數據驅動需求強烈的互聯網大廠比較流行。近2年，隨着Clickhouse的逐漸流行，對於一些總數據量不超過百PB級別的互聯網數據倉庫需求，已經有多家公司改爲了Clickhouse的方案。Clickhouse的優勢是單個查詢執行速度更快，不依賴Hadoop，架構和運維更簡單。
2.Spark SQL、Flink SQL
在大部分場景下，Hive計算速度過慢，別說不能滿足那些要求高QPS、低查詢延遲的的對外在線服務的需求，就連企業內部的產品、運營、數據分析師也會經常抱怨Hive執行ad-hoc查詢太慢。這些痛點，推動了MPP內存迭代和DAG計算模型的誕生和發展，諸如Spark SQL、Flink SQL、Presto這些技術，目前在企業中也非常流行。Spark SQL、Flink SQL的執行速度更快，編程API豐富，同時支持流式計算與批處理，並且有流批統一的趨勢，使大數據應用更簡單。
3.Clickhouse
ClickHouse是近年來備受關注的開源列式數據庫，主要用於數據分析（OLAP）領域。目前國內社區火熱，各個大廠紛紛跟進大規模使用。
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。
4.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引擎，有幾項劣勢：多維度分組排序、分頁。不支持Join。在做aggregation後，由於返回的數據嵌套層次太多，數據量會過於膨脹。
ElasticSearch和Solar也可以歸爲寬表模型。但其系統設計架構有較大不同，這兩個一般稱爲搜索引擎，通過倒排索引，應用Scatter-Gather計算模型提高查詢性能。對於搜索類的查詢效果較好，但當數據量較大或進行掃描聚合類查詢時，查詢性能會有較大影響。
5.Presto
Presto、Impala、GreenPlum均基於MPP架構，相比Elasticsearch、Druid、Kylin這樣的簡單Scatter-Gather模型，在支持的SQL計算上更加通用，更適合ad-hoc查詢場景，然而這些通用系統往往比專用系統更難做性能優化，所以不太適合做對查詢QPS(參考值QPS > 1000)、延遲要求比較高(參考值search latency < 500ms)的在線服務，更適合做公司內部的查詢服務和加速Hive查詢的服務。Presto還有一個優秀的特性是使用了ANSI標準SQL，並且支持超過30+的數據源Connector。
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。
7.Druid
Druid 是一種能對歷史和實時數據提供亞秒級別的查詢的數據存儲。Druid 支持低延時的數據攝取，靈活的數據探索分析，高性能的數據聚合，簡便的水平擴展。Druid支持更大的數據規模，具備一定的預聚合能力，通過倒排索引和位圖索引進一步優化查詢性能，在廣告分析場景、監控報警等時序類應用均有廣泛使用；
Druid的特點包括：
Druid實時的數據消費，真正做到數據攝入實時、查詢結果實時
Druid支持 PB 級數據、千億級事件快速處理，支持每秒數千查詢併發
Druid的核心是時間序列，把數據按照時間序列分批存儲，十分適合用於對按時間進行統計分析的場景
Druid把數據列分爲三類：時間戳、維度列、指標列
Druid不支持多表連接
Druid中的數據一般是使用其他計算框架(Spark等)預計算好的低層次統計數據
Druid不適合用於處理透視維度複雜多變的查詢場景
Druid擅長的查詢類型比較單一，一些常用的SQL(groupby 等)語句在druid裏運行速度一般
Druid支持低延時的數據插入、更新，但是比hbase、傳統數據庫要慢很多
與其他的時序數據庫類似，Druid在查詢條件命中大量數據情況下可能會有性能問題，而且排序、聚合等能力普遍不太好，靈活性和擴展性不夠，比如缺乏Join、子查詢等。
8.Kylin
Kylin自身就是一個MOLAP系統，多維立方體（MOLAP Cube）的設計使得用戶能夠在Kylin裏爲百億以上數據集定義數據模型並構建立方體進行數據的預聚合。
適合Kylin的場景包括：
用戶數據存在於Hadoop HDFS中，利用Hive將HDFS文件數據以關係數據方式存取，數據量巨大，在500G以上
每天有數G甚至數十G的數據增量導入
有10個以內較爲固定的分析維度
簡單來說，Kylin中數據立方的思想就是以空間換時間，通過定義一系列的緯度，對每個緯度的組合進行預先計算並存儲。有N個緯度，就會有2的N次種組合。所以最好控制好緯度的數量，因爲存儲量會隨着緯度的增加爆炸式的增長，產生災難性後果。
六、總結
本文通過介紹了什麼是OLAP以及OLAP的分類，從而對目前主流的8款OLAP引擎進行了介紹和對比，但是關於最終在技術選型上如何選擇合適的大數據引擎，還是需要用戶根據實際情況進行選擇。只憑借本篇文章，還無法作爲選型的建議。
————————————————
、