本文為博主公司原創文章，仿冒必究，轉載請回復留言**

開源OLAP引擎測評報告(SparkSql、Presto、Impala、HAWQ、ClickHouse、GreenPlum)

易觀CTO 郭煒 序
現在大資料元件非常多，眾說不一，在每個企業不同的使用場景裡究竟應該使用哪個引擎呢？這是易觀Spark實戰營出品的開源Olap引擎測評報告，團隊選取了Hive、Sparksql、Presto、Impala、Hawq、Clickhouse、Greenplum大資料查詢引擎，在原生推薦配置情況下，在不同場景下做一次橫向對比，供大家參考。
每年易觀都會發布一次這樣的大資料開源測評報告，歡迎大家給出更好的測評意見以及想要測試的元件。易觀Spark實戰營是易觀大資料技術團隊組織的針對大資料初學者的實戰訓練營，歡迎搜尋訪問“易觀資料極客社群”，在文章後留言，交流最新最全的大資料技術。

目錄

開源OLAP框架基線測試報告
一、測試方案
1.1 測試整體方案
1.2 TPC-DS測試與單表測試方案及資料準備
1.3 環境準備
二、測試元件介紹
2.1 SparkSql
2.2 Presto
2.3 Impala
2.4 HAWQ
2.5 ClickHouse
2.6 Hive
2.7 Greenplum
三、效能測試分析
3.1 資料壓縮
3.2 效能測試
3.2.1 多表關聯查詢對比測試
3.2.2 單表查詢對比測試
3.3 效能測試結果分析
四、各元件綜合分析比較

一、測試方案

1.1測試整體方案

本次測試針對現有Olap的7大Sql引擎Hadoop(2.7)、Hive(2.1)、Hawq(3.1.2.0)、Presto(0.211)、Impala(2.6.0)、Sparksql(2.2.0)、Clickhouse(18.1.0-1.El7)、Greenplum(5.7.0) 基礎效能測試。我們採用多表關聯和單大表效能分別對比不同元件在查詢效能、系統負載等方面的情況，測試方案如下：

1. 1，多表關聯採用Tpc-Ds基準測試工具生成相應測試語句和資料進行測試，
2. 2，單大表測試同樣選用Tpc-Ds基準測試工具生成的最大資料量的表，並採用我們選用的一些常規性聚合語句進行測試。

1.2 TPC-DS測試與單表測試方案及資料準備

   TPC-DS採用星型、雪花型等多維資料模式。它包含7張事實表，17張維度表平均每張表含有18列。其工作負載包含99個SQL查詢，覆蓋SQL99和2003的核心部分以及OLAP。這個測試集包含對大資料集的統計、報表生成、聯機查詢、資料探勘等複雜應用，測試用的資料和值是有傾斜的，與真實資料一致。可以說TPC-DS是與真實場景非常接近的一個測試集，也是難度較大的一個測試集。

   TPC-DS的這個特點跟大資料的分析挖掘應用非常類似。Hadoop等大資料分析技術也是對海量資料進行大規模的資料分析和深度挖掘，也包含互動式聯機查詢和統計報表類應用，同時大資料的資料質量也較低，資料分佈是真實而不均勻的。因此TPC-DS成為客觀衡量多個不同Hadoop版本以及SQL on Hadoop技術的最佳測試集。

   本次測試採用TPC-DS提供的dsdgen命令工具生成指定量級的測試資料，我們指定資料量級為100G。

生成的各個表的資料量如下：

   通過使用dsqgen命令根據TPC-DS提供的模板生成不同型別的SQL語句，TPC-DS預設支援以下模板：db2.tpl、netezza.tpl、oracle.tpl、sqlserver.tpl。我們通過命令生成sqlserver.tpl模板的SQL語句，分別對其進行細微的修改使其符合不同的olap引擎支援的語法規則。

   對於多表關聯測試，我們從中選取了15條有代表性的sql語句（見附件二），幾乎所有的測試案例都有很高的IO負載和CPU計算需求，涵蓋了幾乎所有的業務場景。

   對於單大表測試，我們選擇TPC-DS生成的測試資料集中資料量最大的表store_sales，並選用了9條使用頻率高的常規性聚合sql語句進行測試（見附件三）。

1.3環境準備

本次測試方案的硬體環境使用三臺物理機，作業系統為centos7，基礎配置資訊如下表：

伺服器	cpu核數	cpu執行緒數	記憶體大小	磁碟空間
server1	4	16	64g	2T
server2	4	16	64g	2T
server3	4	16	64g	2T

   本次測試各元件搭建的版本資訊如下：Hadoop(2.7)、Hive(2.1)、HAWQ(3.1.2.0)、Presto(0.211)、Impala(2.6.0)、sparksql(2.2.0)、clickhouse(18.1.0-1.el7)、greenplum(5.7.0)，所有元件都採用分散式搭建於三臺伺服器，並配置每臺伺服器上查詢最大使用記憶體20g，cpu 8線。

   各個Olap引擎通過各自的方式建立表結構，匯入資料。Hive使用Orc格式的內部表；Impala使用Hive上的Parquet格式資料；Presto使用Hive上的Orc格式資料；Hawq建立內部表使用預設Txt格式；Clickhouse使用Log表引擎分散式建表。

二、測試元件介紹

2.1 SparkSql

   Spark SQL 是 Spark 處理結構化資料的程式模組。它將 SQL 查詢與 Spark 程式無縫整合,可以將結構化資料作為 Spark 的 RDD 進行查詢。RDD 的全稱為 Resilient Distributed Datasets，即彈性分散式資料集，是 Spark 基本的資料結構。Spark 使用 RDD 作為分散式程式的工作集合，提供一種分散式共享記憶體的受限形式。RDD 是隻讀的，對其只能進行建立、轉化和求值等操作。SparkSQL作為Spark生態的一員繼續發展，而不再受限於Hive，只是相容Hive。我們利用hive作為資料來源，spark作為計算引擎，通過SQL解析引擎，實現基於hive資料來源，spark作為計算引擎的SQL測試方案。

2.2 Presto

   Presto是一個分散式SQL查詢引擎， 它被設計為用來專門進行高速、實時的資料分析。它支援標準的ANSI SQL，包括複雜查詢、聚合（aggregation）、連線（join）和視窗函式（window functions)。作為Hive和Pig（Hive和Pig都是通過MapReduce的管道流來完成HDFS資料的查詢）的替代者，Presto 本身並不儲存資料，但是可以接入多種資料來源，並且支援跨資料來源的級聯查詢。Presto是一個OLAP的工具，擅長對海量資料進行復雜的分析；但是對於OLTP場景，並不是Presto所擅長，所以不要把Presto當做資料庫來使用。

2.3 Impala

   Impala 是 Cloudera 在受到 Google 的 Dremel 啟發下開發的實時互動SQL大資料查詢工具，它擁有和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 和統計函式查詢資料，從而大大降低了延遲。

2.4 HAWQ

   HAWQ 是一個 Hadoop 上的 SQL 引擎，是以 Greenplum Database 為程式碼基礎逐漸發展起來的。HAWQ 採用 MPP 架構，改進了針對 Hadoop 的基於成本的查詢優化器。除了能高效處理本身的內部資料，還可通過 PXF 訪問 HDFS、Hive、HBase、JSON 等外部資料來源。HAWQ全面相容 SQL 標準，能編寫 SQL UDF，還可用 SQL 完成簡單的資料探勘和機器學習。無論是功能特性，還是效能表現，HAWQ 都比較適用於構建 Hadoop 分析型資料倉儲應用。

2.5 ClickHouse

   Clickhouse由俄羅斯yandex公司開發。專為線上資料分析而設計。Yandex是俄羅斯搜尋引擎公司。官方提供的文件表名，ClickHouse 日處理記錄數”十億級”。

   特性:採用列式儲存；資料壓縮；基於磁碟的儲存，大部分列式儲存資料庫為了追求速度，會將資料直接寫入記憶體，按時記憶體的空間往往很小；CPU 利用率高，在計算時會使用機器上的所有 CPU 資源；支援分片，並且同一個計算任務會在不同分片上並行執行，計算完成後會將結果彙總；支援SQL，SQL 幾乎成了大資料的標準工具，使用門檻較低；支援聯表查詢；支援實時更新；自動多副本同步；支援索引；分散式儲存查詢。

2.6 Hive

   Hive是基於Hadoop的一個資料倉儲工具，可以將結構化的資料檔案對映為一張資料庫表，並提供完整的sql查詢功能，可以將sql語句轉換為MapReduce任務進行執行。其優點是學習成本低，可以通過類SQL語句快速實現簡單的MapReduce統計，不必開發專門的MapReduce應用，十分適合資料倉儲的統計分析。

  Hive是建立在 Hadoop 上的資料倉儲基礎構架。它提供了一系列的工具，可以用來進行資料提取轉化載入（ETL），這是一種可以儲存、查詢和分析儲存在 Hadoop 中的大規模資料的機制。Hive 定義了簡單的類 SQL 查詢語言，稱為 HQL，它允許熟悉 SQL 的使用者查詢資料。同時，這個語言也允許熟悉 MapReduce 開發者的開發自定義的 mapper 和 reducer 來處理內建的 mapper 和 reducer 無法完成的複雜的分析工作。

2.7 GreenPlum

   Greenplum是一個開源的大規模並行資料分析引擎。藉助MPP架構，在大型資料集上執行復雜SQL分析的速度比很多解決方案都要快。

   GPDB完全支援ANSI SQL 2008標準和SQL OLAP 2003 擴充套件；從應用程式設計介面上講，它支援ODBC和JDBC。完善的標準支援使得系統開發、維護和管理都大為方便。支援分散式事務，支援ACID。保證資料的強一致性。做為分散式資料庫，擁有良好的線性擴充套件能力。GPDB有完善的生態系統，可以與很多企業級產品整合，譬如SAS，Cognos，Informatic，Tableau等；也可以很多種開源軟體整合，譬如Pentaho,Talend 等。

三、效能測試分析

3.1 資料壓縮

   資料壓縮方面，Sparkql、Impala、Presto均採用的是hive後設資料，hive資料100G上傳之後顯示為96.3G(.dat資料格式)，壓縮比0.963；hawq壓縮後資料大小為68.2G(.dat格式)，壓縮比：0.682；clickhouse採用自己預設格式42G；greenplum未使用壓縮，資料儲存大小為98G。

3.2 效能測試

  本節通過查詢語句對比SparkSql、Presto、Impala、HAWQ、ClickHouse、Hive、GreenPlum七種元件的查詢效能，測試結果均採用連續三次查詢結果的平均值，通過圖表展示對比結果。

   效能分析部分我們分為兩部分，第一部分是多表關聯查詢對比測試，第二部分是單大表查詢對比測試。

3.2.1 多表關聯查詢對比測試

以下是多表關聯測試結果，資料如下（sql檔案見附件二）：

   通過我們選取的15條sql語句查詢測試，從表中可以看出，presto、impala和hawq查詢時間快於SparkSql和ClickHouse，效能約是SparkSql的2-3倍，其中尤其以Presto和Impala效能要好一些。greenplum在多表查詢上也有不錯的表現；ClickHouse對於多表join效果相比較於Presto、Impala、HAWQ不是很好，並且很多複雜語法支援的不夠好，可見並不是為關聯分析而設定；而hive無疑是所有元件中耗時最多的，其中部分語句查詢時間超出1h的總時間按1h計算。

   下面是通過圖形展示來更加直觀比較各元件效能。由於hive與其他相差太大，在圖中不作比較。

       

                                      

3.2.2 單表查詢對比測試

以下是9條單表測試語句對六種元件進行測試，測試結果圖表分析如下(查詢sql見附件三)：

  從結果中我們發現，對於單表測試ClickHouse要比其餘幾種元件查詢速度表現突出，測試效能約是其餘四種的3-6倍。而Presto相比於HAWQ、Impala、SparkSql、GreenPlum在單表操作方面效能也稍好些。

  下面通過圖來直觀比較：

                                                                

                                                                  

  從影像上更加清楚地顯示出五種元件在單表測試方面效能的差距，Clickhouse在效能方面體現出了足夠的優勢，在單大表查詢方面比其餘元件效能都要好；Impala和Presto相比較，在sql_01-sql_05這5條語句是簡單的一些求和求平均的單表操作方面，Presto的效能要比Impala好很多，而sql_06-sql_09一些複雜點的多個列的單表操作，Impala的效能要比Presto好一些，這也反映出Presto更加適合一些簡單的資料量大的聚合操作，而Impala適合一些複雜的聚合操作。

   最後我們發現HAWQ、GreenPlum在單表聚合操作方面效能不如其餘四種元件，測試時間要大大超過它們，當然也不排除測試環境的影響，但是測試結果表明，HAWQ、GreenPlum不適合單表的複雜聚合操作，更適合多表的聚合操作。

3.3 效能測試結果分析

  從上面的分析結果可以看出，presto、Impala以及hawq在多表查詢方面體現出了優勢，雖說presto和Impala在多表查詢方面的效能差別不大，但是在查詢過程中卻發現Impala的一些侷限性，並儘量避開這些侷限問題進行測試。Impala不支援的地方，例如：不支援update、delete操作，不支援Date資料型別，不支援ORC檔案格式等等，而presto則基本沒有這些侷限問題（本次測試中基本沒有發現）。

  在單表測試方面clickhouse體現出了比其餘元件的優勢，效能比其他元件要好一大截，而presto相比於hawq和impala以及sparksql在單大表聚合操作方面的表現也相對優秀。

四、各元件綜合分析比較

  通過以上圖表查詢效能分析以及我們查詢相關資料對各元件總結如下：

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都是不錯的選擇。
7. 此外我們還對flink進行了調研發現，flink 核心是個流式的計算引擎，通過流來模擬批處理，flink sql還處於早期開發階段，未來社群計劃通過提供基於REST的SQL客戶端，目前sql客戶端不能直接訪問hive，通過YAML file檔案定義外部資料來源，可以連線檔案系統和kafka，目前短時間我們的sql測試不太好模擬。所以沒有對flink進行測試分析。

    我們通過測試以及以上的相關調研編寫了各元件各個方面的綜合對比分析表，這裡採用5分為滿分來比較，如下表：

附件資訊：

附件一：表結構資訊

附件二：TPC-DS查詢測試語句

附件三：單表查詢測試語句

附件四：效能對比表（Sheet1:TPC-DS語句，Sheet2:單表語句，Sheet5：改變格式優化之後的測試結果）

本文為博主公司原創文章，仿冒必究，轉載請回復留言**