開源OLAP引擎選型

在做資料分析之前，少不了要和各種開源引擎打交道，那麼，不同引擎之間是什麼關係，實時數倉是如何一步步跨越技術障礙，推動企業業務走向現代化資料架構的。在引擎選型之前，我們先看下OLAP與OLTP的區別。

OLAP與OLTP的區別

OLTP(OnlineTransactionProcessing聯機事務處理)，是傳統關係型資料庫的應用技術，提供日常的、基本的事務處理，比如線上交易之類。OLAP(OnlineAnalyticalProcessing聯機分析處理)，是大資料分析的應用技術，提供複雜的分析操作、側重決策支援。目前主流的OLAP引擎包括Hive、Presto、Druid、Clickhouse、Kylin、Sparksql、Greeplum，每個引擎都有它各自的特點

OLAP(On-line Analytical Processing，聯機分析處理)是在基於資料倉儲多維模型的基礎上實現的面向分析的各類操作的集合。可以比較下其與傳統的OLTP(On-line Transaction Processing，聯機事務處理)的區別來看一下它的特點：說起 OLAP 要追溯到 1993 年。

OLAP 準則

準則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 分類

OLAP 是一種讓使用者可以用從不同視角方便快捷的分析資料的計算方法。主流的 OLAP 可以分為：

多維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 架構

概念說明

Serde：序列化反序列化,serialize/deSerialize

MPP：大規模並行處理技術 (Massively Parallel Processor)

按照查詢型別劃分，OLAP 一般分為即席查詢和固化查詢，

即席查詢:透過手寫 sql 完成一些臨時的資料分析需求，這類 sql 形式多變、邏輯複雜，對查詢時間沒有嚴格要求

固化查詢：指的是一些固化下來的取數、看數需求，透過資料產品的形式提供給使用者，從而提高資料分析和運營的效率。這類的 sql 固定模式，對響應時間有較高要求。

按照架構實現劃分，主流的 OLAP 引擎主要有下面三類：

MPP 架構系統(Presto/Impala/SparkSQL/Drill 等)。這種架構主要還是從查詢引擎入手，使用分散式查詢引擎，而不是使用 hive+mapreduce 架構，提高查詢效率。

搜尋引擎架構的系統(es，solr 等)，在入庫時將資料轉換為倒排索引，採用 Scatter-Gather 計算模型，犧牲了靈活性換取很好的效能，在搜尋類查詢上能做到亞秒級響應。但是對於掃描聚合為主的查詢，隨著處理資料量的增加，響應時間也會退化到分鐘級。

預計算系統(Druid/Kylin 等)則在入庫時對資料進行預聚合，進一步犧牲靈活性換取效能，以實現對超大資料集的秒級響應。

資料軌跡現有的實現方式，從業務訴求看為:每賬期按照指定的查詢列取資料，進行分析未結算原因，偏向固化查詢的方式。但現有的實現方式為先按照查詢列值查詢出主表資料，再根據主表附屬表的關聯欄位，獲取查詢附屬表的 sql，sql 為動態拼接出來，這種方式更偏向於即席查詢的實現。

需要從以下三個方面考慮框架選型：資料儲存和構建、安裝搭建、開發成本。

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引擎：Hive、SparkSQL、FlinkSQL、Clickhouse、Elasticsearch、Druid、Kylin、Presto、Impala分別挑選了一些場景進行了對比，可以說目前沒有一個引擎能在資料量，靈活程度和效能上做到完美，使用者需要根據自己的需求進行選型。

簡介

impala

impala 是 Cloudera 開發開源的，Impala 是 Cloudera 開發並開源的，能查詢儲存在 HDFS 和 HBase 中的資料。同 Hive 一樣，也是一種 SQL on Hadoop 解決方案。但 Impala 拋棄了 MapReduce,使用更類似於傳統的 MPP 資料庫技術來提高查詢速度。

impala 可以直接查詢 hdfs 或 hbase 上的資料，可以與現有的儲存無縫對接。

impala 需要單獨安裝，公司內 paas 主推。需要與現場確認。

impala 提供 jdbc 介面和 sql 執行引擎，可以與現有系統整合

Presto

presto 是 Facebook 開源的大資料查詢引擎，為了解決 hive 查詢慢產生。使用 java 編寫，資料全部在記憶體中處理。

原生整合了 Hive、Hbase 和關係型資料庫。

需要與現場確認是否能提供

提供 jdbc 介面和 sql 執行引擎，可以與現有系統整合

druid

druid 同 kylin 一樣，是採用預計算的方式。主要解決的是對於大量的基於時序的資料進行聚合查詢。資料可以實時攝入，進入到 Druid 後立即可查，同時資料是幾乎是不可變。通常是基於時序的事實事件，事實發生後進入 Druid，外部系統就可以對該事實進行查詢。

需要預計算，將資料儲存在 druid 的 Segment 檔案中，佔用一部分儲存資源

需要與現場確認是否能提供

對 sql 支援不友好，需要用他自己的方言書寫

kylin

kylin 是一種 OLAP 資料引擎，支援大資料生態圈的資料分析業務，主要是透過預計算的方式將使用者設定的多維度資料立方體 (cube) 快取起來，達到快速查詢的目的。應用場景應該是針對複雜 sql join 後的資料快取。

這種 OLAP 引擎，一般包括以下幾部分：

1.資料構建儲存：cube 構建，後設資料資訊

2.sql 解析執行：Query 引擎 (sql 直譯器)，routing 模組 (sql 執行)

3.上層介面服務;jdbc/odbc 介面，rest 服務

應用思路：將 hive 中的資料按照查詢列 構建成 cube，儲存到 hbase 中，資料軌跡連線 kylin 的 jdbc 介面實現快速查詢。

需要預計算，將資料構建成 cube 儲存到 hbase

需要與現場確認是否能提供

提供 jdbc 介面和 rest 服務

redis

將要分析的資料同步到 redis，在 redis 中快速查詢資料。可以在分析前將本月資料同步到 redis。

對比

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的分類，從而對目前主流的 OLAP 引擎進行了介紹和對比，但是關於最終在技術選型上如何選擇合適的大資料引擎，還是需要使用者根據實際情況進行選擇。只憑借本篇文章，還無法作為選型的建議。