編者按
談到大數據就會聯想到Hadoop、Spark整個生態的技術棧。大家都知道開源大數據組件種類衆多，其中開源OLAP引擎包含Hive、SparkSQL、Presto、HAWQ、ClickHouse、Impala、Kylin等。當前企業對大數據的研究與應用日趨理性，那麼，如何根據業務特點，選擇一個適合自身場景的查詢引擎呢？
百分點在某國家級項目中承擔了日增超5000億級的數據處理與分析任務，集羣的總數據量已接近百萬億。本報告結合百分點在項目中的業務場景，對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
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評估時，也需要將併發作爲一個重要的考慮因素。
本文轉載自公衆號百分點（ID：baifendian_com）。
原文鏈接：