開源大資料OLAP元件，可以分為MOLAP和ROLAP兩類。ROLAP中又可細分為MPP資料庫和SQL引擎兩類。對於SQL引擎又可以再細分為基於MPP架構的SQL引擎和基於通用計算框架的SQL引擎：

1. MOLAP一般對資料儲存有優化，並且進行部分預計算，因此查詢效能最高。但通常對查詢靈活性有限制。

2. MPP資料庫是個完整的資料庫，通常資料需要匯入其中才能完成OLAP功能。MPP資料庫在資料入庫時對資料分佈可以做優化，雖然入庫效率有一定下降，但是對後期查詢效能的提高有很大幫助。MPP資料庫可以提供靈活的即席查詢能力，但一般對查詢資料量有一定限制，無法支撐特別大的資料量的查詢。

3. SQL引擎只提供SQL執行的能力，本身一般不負責資料儲存，通常可以對接多種資料儲存，如HDFS、HBase、MySQL等。有的還支援聯邦查詢能力，可以對多個異構資料來源進行聯合分析。SQL引擎中，基於MPP架構的SQL引擎，一般對線上查詢場景有特殊優化，所以端到端查詢效能一般要高於基於通用計算框架的SQL引擎；但是在容錯性和資料量方面又會遜於基於通用計算框架的SQL引擎。

總之，可以說沒有一個OLAP系統能同時在處理規模，靈活性和效能這三個方面做到完美，使用者需要基於自己的需求進行取捨和選型。

2.1 開源MOLAP系統分析

2.1.1 Kylin

Apache Kylin 是一個開源的分散式分析引擎，提供 Hadoop/Spark 之上的 SQL 查詢介面及多維分析（OLAP）能力以支援超大規模資料，它能在亞秒內查詢巨大的 Hive 表。Kylin的核心思想是預計算，理論基礎是：以空間換時間。即將多維分析可能用到的度量進行預計算，將計算好的結果儲存成Cube並存儲到HBase中，供查詢時直接訪問。把高複雜度的聚合運算，多表連線等操作轉換成對預計算結果的查詢。

Kylin的核心模組：

1. REST Server：提供 Restful 介面，例如建立、構建、重新整理、合併等 Cube 相關操作，Kylin 的 Projects、Tables 等元資料管理，使用者訪問許可權控制，SQL 的查詢等；

2. Query Engine：使用開源的 Apache Calcite 框架來實現 SQL 解析，可以理解為 SQL 引擎層；

3. Routing：負責將解析 SQL 生成的執行計劃轉換成 Cube 快取的查詢，這部分查詢是可以在秒級甚至毫秒級完成；

4. Metadata：Kylin 中有大量的元資料資訊，包括 Cube 的定義、星型模型的定義、Job 和執行 Job 的輸出資訊、模型的維度資訊等等，Kylin 的元資料和 Cube 都儲存在 HBase 中，儲存的格式是 json 字串；

5. Cube Build Engine：所有模組的基礎，它主要負責 Kylin 預計算中建立 Cube，建立的過程是首先通過 Hive 讀取原始資料，然後通過一些 MapReduce 或 Spark 計算生成 Htable，最後將資料 load 到 HBase 表中。

整個系統分為兩部分：

1. 離線構建：

   • 資料來源在左側，目前主要是 Hadoop Hive，儲存著待分析的使用者資料；

   • 根據元資料的定義，下方構建引擎從資料來源抽取資料，並構建 Cube；

   • 資料以關係表的形式輸入，支援星形模型和雪花模型；

   • 2.5 開始 Spark 是主要的構建技術（以前是MapReduce）；

   • 構建後的 Cube 儲存在右側的儲存引擎中，一般選用 HBase 作為儲存。

2. 線上查詢

   • 使用者可以從上方查詢系統（Rest API、JDBC/ODBC）傳送 SQL 進行查詢分析；

   • 無論從哪個介面進入，SQL 最終都會來到 Rest 服務層，再轉交給查詢引擎進行處理；

   • 查詢引擎解析 SQL，生成基於關係表的邏輯執行計劃；

   • 然後將其轉譯為基於 Cube 的物理執行計劃；

   • 最後查詢預計算生成的 Cube 併產生結果。

• 優點：

1. 亞秒級查詢響應；

2. 支援百億、千億甚至萬億級別互動式分析；

3. 無縫與 BI 工具整合；

4. 支援增量重新整理；

• 缺點：

1. 由於 Kylin 是一個分析引擎，只讀，不支援 insert, update, delete 等 SQL 操作，使用者修改資料的話需要重新批量匯入（構建）；

2. 需要預先建立模型後加載資料到 Cube 後才可進行查詢

3. 使用 Kylin 的建模人員需要了解一定的資料倉庫知識。

2.1.2 Druid

Apache Druid是高效能的實時分析資料庫，主要提供對大量的基於時序的資料進行OLAP查詢能力。支援毫秒級的快速的互動式查詢。

Druid有幾種程序型別，簡要描述如下：

1. Coordinators協調器程序：負責監控資料伺服器上的Historicals程序，將Segments分配給特定的伺服器，並負責確保Segments在多個Historicals之間保持平衡。

2. Overlords程序：負責監控資料伺服器上的MiddleManager程序，並控制資料獲取任務的分配。

3. Broker代理程序：處理來自外部客戶端的查詢，將查詢轉發給資料伺服器去執行，併合並來自多個數據伺服器的結果，返回給終端使用者。

4. Routers程序：是個可選程序，提供統一的API Gateway，可以將請求路由到Brokers、Overlords和Coordinators。

5. Historicals程序：負責處理“歷史資料”的查詢。 它會從Deep Storage下載查詢需要的Segments以加速查詢。它不負責寫入。

6. MiddleManager程序：負責處理獲取到新資料，從外部資料來源讀取資料並轉換成Segments進行儲存。

Druid程序可以按照任何方式進行部署，但是為了易於部署，一般建議將它們組織為三種伺服器型別：

1. 主伺服器：執行Coordinatos和Overlords程序，負責管理資料獲取和資料可用性。

2. 查詢伺服器：執行Brokers和可選的Routers程序，處理來自外部客戶端的查詢。

3. 資料伺服器：執行Historicals和MiddleManagers程序，負責執行資料獲取任務並存儲所有可查詢的資料。

Druid之所以查詢如此之快，與它針對多維資料優化的組織和儲存方式有很大關係。它將資料索引儲存在Segments檔案中，Segment檔案按列來儲存，並通過時間分割槽來進行橫向分割。Druid將資料列分為了三種不同的型別：

1. 對於時間列和指標列處理比較簡單，直接用lz4壓縮儲存。一旦查詢知道去找哪幾行，只需要將它們解壓，然後用相應的操作符來操作它們就可以了。

2. 對於維度列就沒那麼簡單了，因為它們需要支援過濾和聚合操作，因此每個維度需要下面三個資料結構：

   (1) 一個map，Key是維度的值，值是一個整型的id

   (2) 一個儲存列的值得列表，用(1)中的map編碼的list

   (3) 對於列中的每個值對應一個bitmap，這個bitmap用來指示哪些行包含這個個值。

1: 字典
{
    "Justin BIeber": 0,
    "Ke$ha":         1
}

2. 值的列表
[0,
 0,
 1,
 1]

3. bitMap
value="Justin Bieber": [1, 1, 0, 0]
value="Ke$ha":         [0, 0, 1, 1]

為什麼要使用這三個資料結構？ map將字串值對映為整數id，以便可以緊湊地表示（2）和（3）中的值。 （3）中的bitmap（也被稱為倒排索引）允許快速過濾操作（特別地，bitmap便於快速進行AND和OR運算），這樣，對於過濾再聚合的場景，無需訪問（2）中的維度值列表。最後，（2）中的值可以被用來支援group by和TopN查詢。

• 優點：

1. 為分析而設計：為OLAP工作流的探索性分析而構建。它支援各種filter、aggregator和查詢型別。

2. 互動式查詢：低延遲資料攝取架構允許事件在它們建立後毫秒內查詢。

3. 高可用：你的資料在系統更新時依然可用、可查詢。規模的擴大和縮小不會造成資料丟失。

4. 可伸縮：每天處理數十億事件和TB級資料。

• 缺點：

1. 不支援更新操作，資料不可更改

2. 不支援事實表之間的關聯

2.2 開源MPP資料庫分析

2.2.1 Greenplum

GreenPlum是基於PostgreSQL的開源MPP資料庫，具有良好的線性擴充套件能力，具有高效的並行運算和並行儲存特性。

Greenplum的系統架構實際上是多臺PostgreSQL資料庫伺服器組成的矩陣，採用無共享(no shareing)的MPP架構：

1. Master節點：作為資料庫的入口，負責客服端連線；對客服端的請求生成查詢計劃，分發給某個或者所有的Segment節點。

2. Standby節點 : 作為master節點的備庫，提供高可用性。

3. Interconnect：是GreenPlum的網路層；負責每個節點之間的通訊。

4. Segment節點：為資料節點；接收master分發下來的查詢計劃；執行返回結果給master節點。

5. Mirror Segment節點： 作為Segment節點的備庫，提供高可用性；通常跟對應的segment節點不在同一臺機器上。

• 優點：

1. 支援多型資料儲存，允許使用者根據應用定義資料分佈方式，可提高查詢效能。

2. 具有高效的SQL優化器，針對OLAP查詢進行優化。

• 缺點：

1. 存在“木桶效應”，單機故障會導致效能嚴重下降，因此叢集規模不能太大。

2. 併發效能不高，通常無法支援超過30個併發。

2.2.2 ClickHouse

ClickHouse是Yandex（號稱俄羅斯的‘百度’）開源的MPP架構的列式儲存資料庫。

目前ClickHouse公開的資料相對匱乏，比如在架構設計層面就很難找到完整的資料，甚至連一張整體的架構圖都沒有。

• ClickHouse為什麼效能這麼好？

1. 著眼硬體。基於將硬體功效最大化的目的，ClickHouse會在記憶體中進行GROUP BY；與此同時，他們非常在意CPU L3級別的快取，因為一次L3的快取失效會帶來70～100ns的延遲，意味著在單核CPU上，它會浪費4000萬次/秒的運算。正因為注意了這些細節，所以ClickHouse在基準查詢中能做到1.75億次/秒的資料掃描效能。

2. 注重演算法。例如，在字串搜尋方面，針對不同的場景，ClickHouse選擇了多種演算法：對於常量，使用Volnitsky演算法；對於非常量，使用CPU的向量化執行SIMD，暴力優化；正則匹配使用re2和hyperscan演算法。除了字串之外，其餘的場景也與它類似，ClickHouse會使用最合適、最快的演算法。如果世面上出現了號稱效能強大的新演算法，ClickHouse團隊會立即將其納入並進行驗證。

3. 特定場景，特殊優化。針對同一個場景的不同狀況，選擇使用不同的實現方式，儘可能將效能最大化。對於資料結構比較清晰的場景，會通過程式碼生成技術實現迴圈展開，以減少迴圈次數。

4. 向量化執行。SIMD被廣泛地應用於文字轉換、資料過濾、資料解壓和JSON轉換等場景。相較於單純地使用CPU，利用暫存器暴力優化也算是一種降維打擊了。

• 優點：

1. 速度快

• 缺點：

1. 不支援事務，不支援真正的刪除/更新；

2. 不支援高併發，Clickhouse快是因為採用了並行處理機制，即使一個查詢，也會用伺服器一半的CPU去執行。

3. join效能不高

4. 開源社群主要是俄語為主.

2.3 基於MPP架構的SQL引擎分析

2.3.1 Presto

Presto是Facebook推出分散式SQL互動式查詢引擎，完全基於記憶體的平行計算，支援任意資料來源，資料規模GB~PB。

Presto採用典型的Master-Slave架構：

1. coordinator：是presto叢集的master節點。負責解析SQL語句，生成執行計劃，分發執行任務給Worker節點執行。

2. worker：是執行任務的節點。負責實際查詢任務的計算和讀寫。

3. discovery service：是將coordinator和worker結合在一起服務。worker節點啟動後向discovery service服務註冊，coordinator通過discovery service獲取註冊的worker節點。

4. connector：presto以外掛形式對資料儲存層進行了抽象，即connector。可通過connector連線多種資料來源，提取資料。

   discovery service 將coordinator和worker結合在一起服務； worker節點啟動後向discovery service服務註冊 coordinator通過discovery service獲取註冊的worker節點

既然Presto是一個互動式的查詢引擎，我們最關心的就是Presto實現低延時查詢的原理，我認為主要是下面幾個關鍵點：

1. 完全基於記憶體的平行計算

2. 流水線式計算作業

3. 本地化計算

4. 動態編譯執行計劃

5. 小心使用記憶體和資料結構

6. 類BlinkDB的近似查詢

7. GC控制

• 與Hive的比較：

上圖顯示了MapReduce與Presto的執行過程的不同點，MR每個操作要麼需要寫磁碟，要麼需要等待前一個stage全部完成才開始執行，而Presto將SQL轉換為多個stage，每個stage又由多個tasks執行，每個tasks又將分為多個split。所有的task是並行的方式進行允許，stage之間資料是以pipeline形式流式的執行，資料之間的傳輸也是通過網路以Memory-to-Memory的形式進行，沒有磁碟io操作。這也是Presto效能比Hive快很多倍的決定性原因。

• 與Spark的比較：

  1. 目標：Presto強調查詢，但Spark重點強調計算。

  2. 架構：Presto的體系結構與MPP SQL引擎非常相似。這意味著僅針對SQL查詢執行進行了高度優化，而Spark是一個通用執行框架，能夠執行多個不同的工作負載，如ETL，機器學習等。

  3. 任務啟動：Presto的查詢沒有太多開銷。Presto協調器始終處於啟動狀態並等待查詢。而Spark驅動程式啟動需要時間與叢集管理器協商資源，複製jar，才開始處理。

  4. 任務提交：Spark提交任務並在每個階段實時應用資源（與presto相比，這種策略可能導致處理速度稍慢）; Presto一次申請所需資源，並且一次提交所有任務。

  5. 資料處理：在spark中，資料需要在進入下一階段之前完全處理。 Presto是流水線式處理模式。只要一個page完成處理，就可以將其傳送到下一個task（這種方法大大減少了各種查詢的端到端響應時間）。

  6. 記憶體：兩者都是記憶體儲存和計算，當它無法獲得足夠的記憶體時，spark會將資料寫入磁碟，但presto會導致OOM。

  7. 容錯：如果Spark任務失敗或資料丟失，它將重新計算。但是presto會導致查詢失敗。

• 優點：

1. 基於記憶體運算，減少沒必要的硬碟IO，所以快。

2. 都能夠處理PB級別的海量資料分析。（雖然能夠處理PB級別的海量資料分析，但不是代表Presto把PB級別都放在記憶體中計算的。而是根據場景，如count，avg等聚合運算，是邊讀資料邊計算，再清記憶體，再讀資料再計算，這種耗的記憶體並不高。）

3. 能夠連線多個數據源，跨資料來源關聯查詢。

4. 清晰的架構，是一個能夠獨立執行的系統，不依賴於任何其他外部系統。部署簡單。

• 缺點：

1. 不適合多個大表的join操作，因為presto是基於記憶體的，太多資料記憶體放不下的。

2. Presto的一個權衡是不關心中間查詢容錯。如果其中一個Presto工作節點出現故障（例如，關閉），則大多數情況下正在進行的查詢將中止並需要重新啟動。

2.3.2 HAWQ

HAWQ是Pivotal公司開源的一個Hadoop原生大規模並行SQL分析引擎，針對的是分析型應用。Apache HAWQ 採用主從（Master-Slave）的改進MPP架構，通過將MPP與批處理系統有效的結合，克服了MPP的一些關鍵的限制問題，如短板效應、併發限制、擴充套件性等。其整體架構與Pivotal另一開源MPP資料庫Greenplum比較相似：

HAWQ Master節點內部有以下幾個重要元件：

1. 查詢解析器（Parser/Analyzer），負責解析查詢，並檢查語法及語義。最終生成查詢樹傳遞給優化器。

2. 優化器（Optimizer），負責接受查詢樹，生成查詢計劃。針對一個查詢，可能有數億個可能的等價的查詢計劃，但執行效能差異很大。優化器的做用是找出優化的查詢計劃。

3. 資源管理器（Resource Manager），資源管理器經過資源代理向全域性資源管理器（好比YARN）動態申請資源。並快取資源。在不須要的時候返回資源。

4. HDFS元資料快取（HDFS Catalog Cache），用於HAWQ確定哪些Segment掃描表的哪些部分。HAWQ是把計算派發到資料所在的地方。因此要匹配計算和資料的區域性性。如果每一個查詢都訪問HDFS NameNode會形成NameNode的瓶頸。因此在HAWQ Master節點上建立了HDFS元資料快取。

5. 容錯服務（Fault Tolerance Service），負責檢測哪些節點可用，哪些節點不可用。不可用的機器會被排除出資源池。

6. 查詢派遣器（Dispatcher），優化器優化完查詢之後，查詢派遣器派遣計劃到各個節點上執行，並協調查詢執行的整個過程。查詢派遣器是整個並行系統的粘合劑。

7. 元資料服務（Catalog Service），負責儲存HAWQ的各類元資料，包括資料庫和表資訊，以及訪問許可權資訊等。另外，元資料服務也是實現分散式事務的關鍵。

其餘節點為Slave節點。每一個Slave節點上部署有HDFS DataNode，YARN NodeManager以及一個HAWQ Segment。HAWQ Segment在執行查詢的時候會啟動多個QE (Query Executor, 查詢執行器)。查詢執行器執行在資源容器裡面。節點間資料交換經過Interconnect（高速網際網路絡）進行。

• 優點：

1. 對SQL標準的完善支援：ANSI SQL標準，OLAP擴充套件，標準JDBC/ODBC支援。

2. 支援ACID事務特性：這是很多現有基於Hadoop的SQL引擎做不到的，對保證資料一致性很重要。

3. 動態資料流引擎：基於UDP的高速網際網路絡。

4. 多種UDF（使用者自定義函式）語言支援：java, python, c/c++, perl, R等。

5. 動態擴容：動態按需擴容，按照儲存大小或者計算需求，秒級新增節點。

6. 支援MADlib機器學習。

• 缺點：

1. 基於GreenPlum實現，技術實現複雜，包含多個元件。比如對於外部資料來源，需要通過PXF單獨進行處理；

2. C++實現，對記憶體的控制比較複雜，如果出現segmentfault直接導致當前node掛掉。

3. 安裝配置複雜；

2.3.3 Impala

Impala是Cloudera在受到Google的Dremel啟發下開發的實時互動SQL大資料查詢工具。

Impala採用MPP架構，與儲存引擎解耦：

1. impalad（例項*N）: 接收client、hue、jdbc或者odbc請求。每當將查詢提交到特定節點上的impalad時，該節點充當該查詢的“協調器節點”，負責將Query分發到其他impalad節點來並行化查詢，所有查詢結果返回給中心協調節點。

2. StateStore（例項*1）: 負責收集分佈在各個Impalad程序的資源資訊、各節點健康狀況，同步節點資訊；

3. Catalog Service（例項*1）: 分發表的元資料資訊到各個Impalad中，每個Impala節點在本地快取所有元資料。

• 與Hive的比較：

  Impala 與Hive都是構建在Hadoop之上的資料查詢工具，各有不同的側重點， Hive適合於長時間的批處理查詢分析，而Impala適合於實時互動式SQL查詢。

  1. 資料儲存：使用相同的儲存資料池都支援把資料儲存於HDFS, HBase。

  2. 元資料：兩者使用相同的元資料。

  3. SQL解釋處理：比較相似都是通過詞法分析生成執行計劃。

  4. 執行計劃：

     • Hive: 依賴於MapReduce執行框架，執行計劃分成 map->shuffle->reduce->map->shuffle->reduce…的模型。如果一個Query會 被編譯成多輪MapReduce，則會有更多的寫中間結果。由於MapReduce執行框架本身的特點，過多的中間過程會增加整個Query的執行時間。

     • Impala: 把執行計劃表現為一棵完整的執行計劃樹，可以更自然地分發執行計劃到各個Impalad執行查詢，而不用像Hive那樣把它組合成管道型的 map->reduce模式，以此保證Impala有更好的併發性和避免不必要的中間sort與shuffle。

  5. 資料流：

     • Hive: 採用推的方式，每一個計算節點計算完成後將資料主動推給後續節點。

     • Impala: 採用拉的方式，後續節點通過getNext主動向前面節點要資料，以此方式資料可以流式的返回給客戶端，且只要有1條資料被處理完，就可以立即展現出來，而不用等到全部處理完成，更符合SQL互動式查詢使用。

  6. 記憶體使用：

     • Hive: 在執行過程中如果記憶體放不下所有資料，則會使用外存，以保證Query能順序執行完。每一輪MapReduce結束，中間結果也會寫入HDFS中，同樣由於MapReduce執行架構的特性，shuffle過程也會有寫本地磁碟的操作。

     • Impala: 在遇到記憶體放不下資料時，當前版本1.0.1是直接返回錯誤，而不會利用外存。這使用得Impala目前處理Query會受到一 定的限制。Impala在多個階段之間利用網路傳輸資料，在執行過程不會有寫磁碟的操作（insert除外）。

  7. 排程：

     • Hive: 任務排程依賴於Hadoop的排程策略。

     • Impala: 排程由自己完成，目前只有一種排程器simple-schedule，它會盡量滿足資料的區域性性，掃描資料的程序儘量靠近資料本身所在的物理機器。排程器目前還比較簡單，還沒有考慮負載，網路IO狀況等因素進行排程。但目前 Impala已經有對執行過程的效能統計分析，應該以後版本會利用這些統計資訊進行排程吧。

  8. 容錯：

     • Hive: 依賴於Hadoop的容錯能力。

     • Impala: 在查詢過程中，沒有容錯邏輯，如果在執行過程中發生故障，則直接返回錯誤（這與Impala的設計有關，因為Impala定位於實時查詢，一次查詢失敗， 再查一次就好了，再查一次的成本很低）。

  9. 適用面：

     • Hive: 複雜的批處理查詢任務，資料轉換任務。

     • Impala：實時資料分析，因為不支援UDF，能處理的問題域有一定的限制。

• 優點：

  1. 支援SQL查詢，快速查詢大資料。

  2. 可以對已有資料進行查詢，減少資料的載入，轉換。

  3. 多種儲存格式可以選擇（Parquet, Text, Avro, RCFile, SequeenceFile）。

  4. 可以與Hive配合使用。

• 缺點：

  1. 不支援使用者定義函式UDF。

  2. 不支援text域的全文搜尋。

  3. 不支援Transforms。

  4. 不支援查詢期的容錯。

  5. 對記憶體要求高。

2.3.4 Drill

Drill是MapR開源的一個低延遲的大資料集的分散式SQL查詢引擎，是谷歌Dremel的開源實現。它支援對本地檔案、HDFS、HBASE等資料進行資料查詢，也支援對如JSON等schema-free的資料進行查詢。

從架構上看，與同是源自Dremel的Impala比較類似。Drill的核心是DrillBit，它主要負責接收客戶端的請求，處理查詢，並將結果返回給客戶端。 Drill的查詢流程包括以下步驟：

1. Drill客戶端發起查詢，任意DrilBit都可以接受來自客戶端的查詢

2. 收到請求的DrillBit成為驅動節點（Foreman），對查詢進行分析優化生成執行計劃，之後將執行計劃劃分成各個片段（Fragment），並確定合適的節點來執行。

3. 各個節點執行查詢片段（Fragment），並將結果返回給驅動節點

4. 驅動節點將結果返回給客戶端

• 優點：

1. 能夠自動解析資料（json，text，parquet）的結構。

2. 支援自定義的巢狀資料集，資料靈活,，支援查詢複雜的半結構化資料。

3. 與Hive一體化（Hive表和檢視的查詢，支援所有的Hive檔案格式和HiveUDFS）。

4. 支援多資料來源，包括NoSQL資料庫。

5. 可以方便的與第三方BI工具對接。

• 缺點：

1. SQL語法和常規SQL有區別,一般是如“select * from 外掛名.表名”的形式。

2. 安裝部署比較複雜。

3. GC機制還有待提高。

2.4 基於通用計算框架的SQL引擎分析

2.4.1 SparkSQL

Spark SQL與傳統 DBMS 的查詢優化器 + 執行器的架構較為類似，只不過其執行器是在分散式環境中實現，並採用的 Spark 作為執行引擎：

Spark SQL 的查詢優化是Catalyst，Catalyst 將 SQL 語言翻譯成最終的執行計劃，並在這個過程中進行查詢優化。這裡和傳統不太一樣的地方就在於， SQL 經過查詢優化器最終轉換為可執行的查詢計劃是一個查詢樹，傳統 DB 就可以執行這個查詢計劃了。而 Spark SQL 最後執行還是會在 Spark 內將這棵執行計劃樹轉換為 Spark 的有向無環圖DAG 再執行。

• 優點：

1. 將sql查詢與spar無縫融合

2. 相容HiveQL

• 缺點：

1. 查詢效能不高

2. 以thrift server方式提供的SparkSQL服務不支援多種資料來源，必須使用DataFrame API。

2.4.2 Hive

Hive是一個構建於Hadoop頂層的資料倉庫工具。定義了簡單的類似SQL 的查詢語言——HiveQL，可以將HiveQL查詢轉換為MapReduce 的任務在Hadoop叢集上執行。

image-20200803091119996.png

• 優點：

1. 高可靠、高容錯：HiveServer採用叢集模式。雙MetaStor。超時重試機制。

2. 類SQL：類似SQL語法，內建大量函式。

3. 可擴充套件：自定義儲存格式，自定義函式。

4. 多介面：Beeline，JDBC，ODBC，Python，Thrift。

• 缺點：

1. 延遲較高：預設MR為執行引擎，MR延遲較高。

2. 不支援物化檢視：Hive支援普通檢視，不支援物化檢視。Hive不能再檢視上更新、插入、刪除資料。

3. 不適用OLTP：暫不支援列級別的資料新增、更新、刪除操作。

2.5 各元件效能對比

測試資料來源於：開源OLAP引擎測評報告。通過測試以及相關調研編寫了各元件各個方面的綜合對比分析表，這裡採用5分為滿分來比較，如下表：

1. SparkSQL是Hadoop中另一個著名的SQL引擎，它以Spark作為底層計算框架，Spark使用RDD作為分散式程式的工作集合，它提供一種分散式共享記憶體的受限形式。在分散式共享記憶體系統中，應用可以向全域性地址空間的任意位置進行讀寫作，而RDD是隻讀的，對其只能進行建立、轉化和求值等作。這種記憶體操作大大提高了計算速度。SparkSql的效能相對其他的元件要差一些，多表單表查詢效能都不突出。

2. Impala官方宣傳其計算速度是一大優點，在實際測試中我們也發現它的多表查詢效能和presto差不多，但是單表查詢方面卻不如presto好。而且Impala有很多不支援的地方，例如：不支援update、delete操作，不支援Date資料型別，不支援ORC檔案格式等等，所以我們查詢時採用parquet格式進行查詢，而且Impala在查詢時佔用的記憶體很大。

3. Presto綜合性能比起來要比其餘元件好一些，無論是查詢效能還是支援的資料來源和資料格式方面都要突出一些，在單表查詢時效能靠前，多表查詢方面效能也很突出。由於Presto是完全基於記憶體的平行計算，所以presto在查詢時佔用的記憶體也不少，但是發現要比Impala少一些，比如多表join需要很大的記憶體，Impala佔用的記憶體比presto要多。

4. HAWQ 吸收了先進的基於成本的 SQL 查詢優化器，自動生成執行計劃，可優化使用hadoop 叢集資源。HAWQ 採用 Dynamic pipelining 技術解決這一關鍵問題。Dynamic pipelining 是一種並行資料流框架，利用線性可擴充套件加速Hadoop查詢，資料直接儲存在HDFS上，並且其SQL查詢優化器已經為基於HDFS的檔案系統性能特徵進行過細緻的優化。但是我們發現HAWQ在多表查詢時比Presto、Impala差一些；而且不適合單表的複雜聚合操作，單表測試效能方面要比其餘四種元件差很多，hawq環境搭建也遇到了諸多問題。

5. ClickHouse 作為目前所有開源MPP計算框架中計算速度最快的，它在做多列的表，同時行數很多的表的查詢時，效能是很讓人興奮的，但是在做多表的join時，它的效能是不如單寬表查詢的。效能測試結果表明ClickHouse在單表查詢方面表現出很大的效能優勢，但是在多表查詢中效能卻比較差，不如presto、impala、hawq的效果好。

6. GreenPlum作為關係型資料庫產品，它的特點主要就是查詢速度快，資料裝載速度快，批量DML處理快。而且效能可以隨著硬體的新增，呈線性增加，擁有非常良好的可擴充套件性。因此，它主要適用於面向分析的應用。比如構建企業級ODS/EDW，或者資料集市等，GREENPLUM都是不錯的選擇。

轉載連結：https://www.jianshu.com/p/4b3bcbabad77
來源：簡書