二、測試組件介紹

1.HAWQ

HAWQ是Hadoop原生SQL查詢引擎，結合了MPP數(shù)據(jù)庫的關鍵技術優(yōu)勢和Hadoop的可擴展性、便捷性，以及ANSI SQL 標準的支持；具有 MPP（大規(guī)模并行處理系統(tǒng)）的性能，比Hadoop生態(tài)圈里的其它SQL 引擎快數(shù)倍；具有非常成熟的并行優(yōu)化器等。 

2.Presto

Presto是一個分布式的查詢引擎，本身并不存儲數(shù)據(jù)，但是可以接入多種數(shù)據(jù)源，并且支持跨數(shù)據(jù)源的級聯(lián)查詢。Presto是一個OLAP的工具，擅長對海量數(shù)據(jù)進行復雜的分析。但是，對于OLTP場景，并不是Presto所擅長，所以不要把Presto當做數(shù)據(jù)庫來使用。Presto需要從其他數(shù)據(jù)源獲取數(shù)據(jù)來進行運算分析，它可以連接多種數(shù)據(jù)源，包括Hive、RDBMS（Mysql、Oracle、Tidb等）、Kafka、MongoDB、Redis等。 

3.ClickHouse

ClickHouse是”戰(zhàn)斗民族”俄羅斯搜索巨頭Yandex公司開源的一個極具”戰(zhàn)斗力”的實時數(shù)據(jù)分析數(shù)據(jù)庫，是面向 OLAP 的分布式列式DBMS，圈內(nèi)人戲稱為”喀秋莎數(shù)據(jù)庫”。ClickHouse有一個簡稱”CK”，與Hadoop、Spark這些巨無霸組件相比，ClickHouse很輕量級，其特點包括：分布式、列式存儲、異步復制、線性擴展、支持數(shù)據(jù)壓縮和最終數(shù)據(jù)一致性，其數(shù)據(jù)量級在PB級別。

三 、測試環(huán)境

1.服務器硬件配置大數(shù)據(jù)服務器：大數(shù)據(jù)網(wǎng)絡增強型 d1ne 

2.OLAP引擎環(huán)境

· HAWQ環(huán)境

· Presto環(huán)境

· ClickHouse環(huán)境 

搜圖編輯

3.測試數(shù)據(jù) 

數(shù)據(jù)存放路徑：/data1~12/iplog，一個盤20G，6臺服務器每臺都是240G，一共1440GB；每臺服務器12個盤裝載4個分區(qū)（小時）數(shù)據(jù)，每個盤裝載4個分區(qū)的1/12的數(shù)據(jù)，4個文件，每個文件大小5G，2500w條記錄，一條記錄200Byte。

4.測試SQL

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

四、測試過程 1.HAWQ存儲格式與性能評測經(jīng)過對比測試后，考慮數(shù)據(jù)的壓縮比、數(shù)據(jù)的插入速度，以及查詢時間這三個維度綜合評估，我們的場景推薦HAWQ采用列式存儲+Gzip5的壓縮方式；如果大家對壓縮沒有非常高的要求，可以按照測試的詳細數(shù)據(jù)采用其它的組合方式。 

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

詳細的評測數(shù)據(jù)及圖片展現(xiàn)如下文所示。 

· 行式存儲與壓縮：

HAWQ的插入方式是將數(shù)據(jù)寫入CSV文件后，Load到HAWQ表中。本次評測的是數(shù)據(jù)Load的過程和最終壓縮比?？梢园l(fā)現(xiàn)，zlib壓縮級別到5以后，壓縮比的降低就不那么明顯了。 

測試明細： 

結果圖形展示： 

搜圖編輯

· 行式存儲查詢性能：

測試明細： 

結果圖形展示：

· 列式存儲與壓縮：

測試明細：

結果圖形展示：

搜圖編輯

· 列式存儲查詢性能：

測試明細：

結果圖形展示：

2.Presto存儲格式與性能評測 經(jīng)過對比測試后，考慮數(shù)據(jù)的壓縮比、數(shù)據(jù)的插入速度，以及查詢時間這三個維度綜合評估，我們的場景推薦Presto采用LZ4+ORC方式。這個結果也與各公司采用的格式一致。

· 存儲與壓縮：

測試方式，通過CSV文件Load到Hive表，原始數(shù)據(jù)總量為1440GB。 

· 查詢性能：

搜圖編輯

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

通過對比測試結果可以發(fā)現(xiàn)，在相同的數(shù)據(jù)量查詢SQL情況下，ClickHouse對比HAWQ、Presto有數(shù)量級的性能優(yōu)勢。由于我們的業(yè)務更多是單表的Ad-Hoc查詢和分析，因此本次評測最終采用ClickHouse作為我們的OLAP引擎。 

同時，測試過程中我們也發(fā)現(xiàn)一些有意思的現(xiàn)象，如：

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

(2)  HAWQ查詢會使用到系統(tǒng)緩存，而Presto對這方面并沒有特別的優(yōu)化。表現(xiàn)出的現(xiàn)象就是，在一定的并發(fā)度下，HAWQ反而會體現(xiàn)出緩存的優(yōu)勢，而Presto性能則呈現(xiàn)線性下降趨勢。 

詳細見測試過程的詳細記錄及圖形化的直觀展現(xiàn)。

· 并發(fā)1查詢性能：

· 并發(fā)10查詢性能：

· 并發(fā)20查詢性能：

4.其它擴展測試

· Presto單機多Worker：

我們通過添加單機的Worker數(shù)量驗證是否提高查詢效率，提高單機的查詢利用率。 單機增加Presto Worker，部署多Worker。測試結果：表現(xiàn)為CPU瓶頸，沒有效果。如下圖，可以發(fā)現(xiàn)每個Worker的吞吐也少了一半。 

· Presto擴容：我們通過添加擴容機器并部署Worker，驗證查詢性能影響。加入新的機器，部署Worker。測試結果：表現(xiàn)為性能基本線性增長，受限于數(shù)據(jù)節(jié)點的磁盤IO和網(wǎng)絡。 

· ClickHouse 橫向擴展查詢測試：

測試橫向擴展對查詢性能的影響，每個節(jié)點的數(shù)據(jù)量是相同的，使用相同的SQL分別測試單節(jié)點、五節(jié)點、十節(jié)點的查詢性能。根據(jù)測試結果可以看出，橫向擴展后，節(jié)點數(shù)和數(shù)據(jù)量等比增加，查詢時間幾乎保持不變。所以對于ClickHouse我們可以基于單節(jié)點的數(shù)據(jù)量和性能，推斷一定場景下整個集群的情況。

測試明細： 

結果圖形展示：

· ClickHouse PageCache緩存查詢測試:

測試PageCache對查詢性能的影響，首先清除所有緩存分別查詢四個SQL，然后再重復執(zhí)行一次，可以發(fā)現(xiàn)，PageCache對第二次查詢的性能提高是影響巨大的。

ClickHouse充分利用了系統(tǒng)緩存（PageCache），對查詢有數(shù)量級的性能提升作用。

測試明細：

結果圖形展示：

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

HAWQ采用基于成本的SQL查詢優(yōu)化器，生成執(zhí)行計劃；同時在標準化SQL兼容性這方面表現(xiàn)突出（基于TPC-DS進行SQL兼容性測試）。數(shù)據(jù)存儲直接使用HDFS，與其它SQL on Hadoop引擎不一樣，HAWQ采用自己的數(shù)據(jù)模型及存儲方式。在本次對單表的查詢測試中，性能并不理想，并且我們發(fā)現(xiàn)對于表查詢類似limit 1語句。HAWQ也會全表掃描，這個過程讓我們感覺有點詫異。 

Presto的綜合能力對比其他SQLon Hadoop引擎還是比較突出的。我們在測試過程中發(fā)現(xiàn)，單節(jié)點的掃描速度達5000WRow/S。Presto是完全基于內(nèi)存的并行計算，對內(nèi)存有一定的要求。只裝載數(shù)據(jù)到內(nèi)存一次，其他都是通過內(nèi)存、網(wǎng)絡IO來處理，所以在慢速網(wǎng)絡下是不適合的，所以它對網(wǎng)絡要求也是很高。Presto只是查詢引擎，不負責數(shù)據(jù)的底層持久化、裝載策略。Presto支持豐富的多數(shù)據(jù)源，可跨多個數(shù)據(jù)源查詢。另外，在我們測試的版本上沒有本地數(shù)據(jù)讀取優(yōu)化策略，開源社區(qū)里在新版本上是支持的。 

ClickHouse作為戰(zhàn)斗民族的開源神器，是目前所有開源MPP計算框架中速度最快的。對比測試的結果表明，ClickHouse在單表的查詢中性能十分優(yōu)異。對多表的關聯(lián)分析場景，查詢其他報告并不十分理想，本次測試并不涉及，不做評論。ClickHouse性能很大程度上依賴于系統(tǒng)緩存。對完全非緩存，進行磁盤掃描的場景，性能也不是十分突出，二者也有數(shù)量級的性能差距。這也是我們在使用過程中的優(yōu)化點。?最后，以上采用MPP架構的OLAP引擎，隨著并發(fā)的提高，查詢性能都出現(xiàn)了線性下降，Presto在這個問題上的尤為明顯。CK由于單次查詢速度快，所以一定程度上掩蓋了這個問題。因此，大家在未來的業(yè)務中進行OLAP評估時，也需要將并發(fā)作為一個重要的考慮因素。

xiesc