二、測(cè)試組件介紹

1.HAWQ

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

2.Presto

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

3.ClickHouse

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

三 、測(cè)試環(huán)境

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

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

· HAWQ環(huán)境

· Presto環(huán)境

· ClickHouse環(huán)境 

搜圖編輯

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

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

4.測(cè)試SQL

測(cè)試挑選4個(gè)實(shí)際典型SQL，大致如下： 

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

HAWQ壓縮測(cè)試注意事項(xiàng)：只有當(dāng)orientation=parquet的時(shí)候才能使用gzip進(jìn)行壓縮，orientation=row的時(shí)候才能使用zlib進(jìn)行壓縮，snappy不支持設(shè)置壓縮級(jí)別。

詳細(xì)的評(píng)測(cè)數(shù)據(jù)及圖片展現(xiàn)如下文所示。 

· 行式存儲(chǔ)與壓縮：

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

測(cè)試明細(xì)： 

結(jié)果圖形展示： 

搜圖編輯

· 行式存儲(chǔ)查詢性能：

測(cè)試明細(xì)： 

結(jié)果圖形展示：

· 列式存儲(chǔ)與壓縮：

測(cè)試明細(xì)：

結(jié)果圖形展示：

搜圖編輯

· 列式存儲(chǔ)查詢性能：

測(cè)試明細(xì)：

結(jié)果圖形展示：

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

· 存儲(chǔ)與壓縮：

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

· 查詢性能：

搜圖編輯

3.查詢對(duì)比測(cè)試：HAWQ vs Presto vs ClickHouse

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

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

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

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

詳細(xì)見(jiàn)測(cè)試過(guò)程的詳細(xì)記錄及圖形化的直觀展現(xiàn)。

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

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

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

4.其它擴(kuò)展測(cè)試

· Presto單機(jī)多Worker：

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

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

· ClickHouse 橫向擴(kuò)展查詢測(cè)試：

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

測(cè)試明細(xì)： 

結(jié)果圖形展示：

· ClickHouse PageCache緩存查詢測(cè)試:

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

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

測(cè)試明細(xì)：

結(jié)果圖形展示：

五、各組件綜合分析通過(guò)上述測(cè)試結(jié)果和分析圖表，結(jié)合我們查詢各組件的開(kāi)源介紹進(jìn)行綜合分析，如下：

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

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

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

xiesc