編者按

談到大資料就會聯想到Hadoop、Spark整個生態的技術棧。大家都知道開源大資料元件種類眾多，其中開源OLAP引擎包含Hive、SparkSQL、Presto、HAWQ、ClickHouse、Impala、Kylin等。當前企業對大資料的研究與應用日趨理性，那麼，如何根據業務特點，選擇一個適合自身場景的查詢引擎呢？

百分點在某國家級專案中承擔了日增超5000億級的資料處理與分析任務，叢集的總資料量已接近百萬億。本報告結合百分點在專案中的業務場景，對HAWQ、Presto、ClickHouse做了綜合評測，供大家參考。

本文作者：趙群鄒立民

百分點大資料評測報告：開源OLAP引擎綜評（HAWQ、Presto、ClickHouse）

一、測試整體方案

百分點面對的業務場景，主體是要解決超大規模資料集的Ad-Hoc查詢問題，並且大多是單表查詢場景。架構團隊在此過程中選取了HAWQ、Presto、ClickHouse進行評測。評測中選取的資料集與SQL來自專案實際業務，我們需要評測維度主要如下：

A．資料在不同壓縮格式下的壓縮能力。

B．不同格式下的資料查詢能力。

C．特定格式下的HAWQ、Presto、ClickHouse查詢能力橫向對比。

二、測試元件介紹

1.HAWQ

HAWQ是Hadoop原生SQL查詢引擎，結合了MPP資料庫的關鍵技術優勢和Hadoop的可擴充套件性、便捷性，以及ANSI SQL 標準的支援；具有 MPP（大規模並行處理系統）的效能，比Hadoop生態圈裡的其它SQL 引擎快數倍；具有非常成熟的並行最佳化器等。

2.Presto

Presto是一個分散式的查詢引擎，本身並不儲存資料，但是可以接入多種資料來源，並且支援跨資料來源的級聯查詢。Presto是一個OLAP的工具，擅長對海量資料進行復雜的分析。但是，對於OLTP場景，並不是Presto所擅長，所以不要把Presto當做資料庫來使用。

Presto需要從其他資料來源獲取資料來進行運算分析，它可以連線多種資料來源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。

3.ClickHouse

ClickHouse是“戰鬥民族”俄羅斯搜尋巨頭Yandex公司開源的一個極具"戰鬥力"的實時資料分析資料庫，是面向 OLAP 的分散式列式DBMS，圈內人戲稱為“喀秋莎資料庫”。ClickHouse有一個簡稱"CK"，與Hadoop、Spark這些巨無霸元件相比，ClickHouse很輕量級，其特點包括：分散式、列式儲存、非同步複製、線性擴充套件、支援資料壓縮和最終資料一致性，其資料量級在PB級別。

三、測試環境

1.伺服器硬體配置

大資料伺服器：大資料網路增強型 d1ne

百分點大資料評測報告：開源OLAP引擎綜評（HAWQ、Presto、ClickHouse）

2.OLAP引擎環境

HAWQ環境

Presto環境

ClickHouse環境

3.測試資料

資料存放路徑：/data1~12/iplog，一個盤20G，6臺伺服器每臺都是240G，一共1440GB；每臺伺服器12個盤裝載4個分割槽（小時）資料，每個盤裝載4個分割槽的1/12的資料，4個檔案，每個檔案大小5G，2500w條記錄，一條記錄200Byte。

4.測試SQL

測試挑選4個實際典型SQL，大致如下：

四、測試過程

1.HAWQ儲存格式與效能評測

經過對比測試後，考慮資料的壓縮比、資料的插入速度，以及查詢時間這三個維度綜合評估，我們的場景推薦HAWQ採用列式儲存+Gzip5的壓縮方式；如果大家對壓縮沒有非常高的要求，可以按照測試的詳細資料採用其它的組合方式。

HAWQ壓縮測試注意事項：只有當orientation=parquet的時候才能使用gzip進行壓縮，orientation=row的時候才能使用zlib進行壓縮，snappy不支援設定壓縮級別。

詳細的評測資料及圖片展現如下文所示。

行式儲存與壓縮：

HAWQ的插入方式是將資料寫入CSV檔案後，Load到HAWQ表中。本次評測的是資料Load的過程和最終壓縮比。可以發現，zlib壓縮級別到5以後，壓縮比的降低就不那麼明顯了。

測試明細：

結果圖形展示：

行式儲存查詢效能：

測試明細：

結果圖形展示：

列式儲存與壓縮：

測試明細：

結果圖形展示：

列式儲存查詢效能：

測試明細：

結果圖形展示：

2.Presto儲存格式與效能評測

經過對比測試後，考慮資料的壓縮比、資料的插入速度，以及查詢時間這三個維度綜合評估，我們的場景推薦Presto採用LZ4+ORC方式。這個結果也與各公司採用的格式一致。

儲存與壓縮：

測試方式，透過CSV檔案Load到Hive表，原始資料總量為1440GB。

查詢效能：

3.查詢對比測試：HAWQ vs Presto vs ClickHouse

透過對比測試結果可以發現，在相同的資料量查詢SQL情況下，ClickHouse對比HAWQ、Presto有數量級的效能優勢。由於我們的業務更多是單表的Ad-Hoc查詢和分析，因此本次評測最終採用ClickHouse作為我們的OLAP引擎。

同時，測試過程中我們也發現一些有意思的現象，如：

(1) HAWQ對查詢都是全表掃描，如類似Select * from where c1=xxx limit 10查詢，而Presto則對掃描的結果直接返回。

(2) HAWQ查詢會使用到系統快取，而Presto對這方面並沒有特別的最佳化。表現出的現象就是，在一定的併發度下，HAWQ反而會體現出快取的優勢，而Presto效能則呈現線性下降趨勢。

詳細見測試過程的詳細記錄及圖形化的直觀展現。

併發1查詢效能：

併發10查詢效能：

併發20查詢效能：

4.其它擴充套件測試

Presto單機多Worker：

我們透過新增單機的Worker數量驗證是否提高查詢效率，提高單機的查詢利用率。

單機增加Presto Worker，部署多Worker。測試結果：表現為CPU瓶頸，沒有效果。如下圖，可以發現每個Worker的吞吐也少了一半。

Presto擴容：

我們透過新增擴容機器並部署Worker，驗證查詢效能影響。

加入新的機器，部署Worker。測試結果：表現為效能基本線性增長，受限於資料節點的磁碟IO和網路。

ClickHouse 橫向擴充套件查詢測試：

測試橫向擴充套件對查詢效能的影響，每個節點的資料量是相同的，使用相同的SQL分別測試單節點、五節點、十節點的查詢效能。

根據測試結果可以看出，橫向擴充套件後，節點數和資料量等比增加，查詢時間幾乎保持不變。所以對於ClickHouse我們可以基於單節點的資料量和效能，推斷一定場景下整個叢集的情況。

測試明細：

結果圖形展示：

ClickHouse PageCache快取查詢測試:

測試PageCache對查詢效能的影響，首先清除所有快取分別查詢四個SQL，然後再重複執行一次，可以發現，PageCache對第二次查詢的效能提高是影響巨大的。

ClickHouse充分利用了系統快取（PageCache），對查詢有數量級的效能提升作用。

測試明細：

結果圖形展示：

五、各元件綜合分析

透過上述測試結果和分析圖表，結合我們查詢各元件的開源介紹進行綜合分析，如下：

HAWQ採用基於成本的SQL查詢最佳化器，生成執行計劃；同時在標準化SQL相容性這方面表現突出（基於TPC-DS進行SQL相容性測試）。資料儲存直接使用HDFS，與其它SQL on Hadoop引擎不一樣，HAWQ採用自己的資料模型及儲存方式。在本次對單表的查詢測試中，效能並不理想，並且我們發現對於表查詢類似limit 1語句。 HAWQ也會全表掃描，這個過程讓我們感覺有點詫異。

Presto的綜合能力對比其他SQLon Hadoop引擎還是比較突出的。我們在測試過程中發現，單節點的掃描速度達5000WRow/S。 Presto是完全基於記憶體的平行計算，對記憶體有一定的要求。只裝載資料到記憶體一次，其他都是透過記憶體、網路IO來處理，所以在慢速網路下是不適合的，所以它對網路要求也是很高。 Presto只是查詢引擎，不負責資料的底層持久化、裝載策略。 Presto支援豐富的多資料來源，可跨多個資料來源查詢。另外，在我們測試的版本上沒有本地資料讀取最佳化策略，開源社群裡在新版本上是支援的。

ClickHouse作為戰鬥民族的開源神器，是目前所有開源MPP計算框架中速度最快的。對比測試的結果表明，ClickHouse在單表的查詢中效能十分優異。對多表的關聯分析場景，查詢其他報告並不十分理想，本次測試並不涉及，不做評論。 ClickHouse效能很大程度上依賴於系統快取。對完全非快取，進行磁碟掃描的場景，效能也不是十分突出，二者也有數量級的效能差距。這也是我們在使用過程中的最佳化點。

最後，以上採用MPP架構的OLAP引擎，隨著併發的提高，查詢效能都出現了線性下降，Presto在這個問題上的尤為明顯。CK由於單次查詢速度快，所以一定程度上掩蓋了這個問題。因此，大家在未來的業務中進行OLAP評估時，也需要將併發作為一個重要的考慮因素。

百分點大資料評測報告：開源OLAP引擎綜評（HAWQ、Presto、ClickHouse）

2.OLAP引擎環境

HAWQ環境

Presto環境

相關文章