Part 01傳統(tǒng)Hadoop生態(tài)方案介紹及其缺點(diǎn) 

從Hadoop生態(tài)出現(xiàn)以來，人們嘗到了大數(shù)據(jù)技術(shù)的甜頭，隨著Hadoop生態(tài)的不斷發(fā)展，它的大數(shù)據(jù)處理能力已經(jīng)被業(yè)界充分認(rèn)可。用戶可以根據(jù)自己的業(yè)務(wù)需要選擇合適的Hadoop生態(tài)組件組成自己的大數(shù)據(jù)處理框架，這里我們以大數(shù)據(jù)Lambda架構(gòu)為例對Hadoop生態(tài)方案進(jìn)行說明，其架構(gòu)圖如下所示。

大數(shù)據(jù)Lambda架構(gòu)分為三層，下面分別進(jìn)行描述。

批處理層（Batch Layer）：對不可變數(shù)據(jù)進(jìn)行批量處理。因?yàn)槿绻跇I(yè)務(wù)需要查詢時對全量數(shù)據(jù)集進(jìn)行在線查詢計(jì)算代價會很高，所以可以對查詢事先進(jìn)行預(yù)計(jì)算，生成對應(yīng)的Views，這樣查詢的速度會提高很多。批處理層采用不可變模型對所有數(shù)據(jù)進(jìn)行了存儲，并根據(jù)不同的業(yè)務(wù)需求對數(shù)據(jù)進(jìn)行了不同的預(yù)查詢，生成對應(yīng)的Batch Views，這些Batch Views提供給上層的Serving Layer進(jìn)行進(jìn)一步的查詢。

實(shí)時流處理層（Speed Layer）：因?yàn)榕幚韺邮菍θ繑?shù)據(jù)集進(jìn)行查詢，花費(fèi)的時間會比較長（通常以小時甚至是天為單位）。新進(jìn)入系統(tǒng)的數(shù)據(jù)就無法及時被用戶查詢，導(dǎo)致用戶得到的結(jié)果不正確。因此需要實(shí)時流處理層來處理增量的實(shí)時數(shù)據(jù)。

服務(wù)層（Serving Layer）：用于響應(yīng)用戶的查詢請求，它將批處理層和實(shí)時流處理層的結(jié)果進(jìn)行合并，把得到的最終結(jié)果返回給用戶。

大數(shù)據(jù)Lambda不同的層可以根據(jù)實(shí)際業(yè)務(wù)選擇合適的Hadoop生態(tài)組件，可能的選擇如下圖粗體文字所示：

圖2 Lambda架構(gòu)選擇組件

通過上面我們對傳統(tǒng)Hadoop生態(tài)方案的介紹我們可以看到，傳統(tǒng)方案使用的生態(tài)組件多，這就會導(dǎo)致所需硬件資源多、維護(hù)困難、使用門檻高等各種問題，而ClickHouse方案就沒有上述的各種問題，讓我們接著往下看。

Part 02ClickHouse介紹  

ClickHouse是俄羅斯的Yandex于2016年開源的用于在線分析處理查詢（OLAP :Online Analytical Processing）MPP架構(gòu)的列式存儲數(shù)據(jù)庫（DBMS：Database Management System），能夠使用 SQL 查詢實(shí)時生成分析數(shù)據(jù)報(bào)告。ClickHouse可以做用戶行為分析，流批一體。線性擴(kuò)展和可靠性保障能夠原生支持 shard + replication。ClickHouse沒有走Hadoop生態(tài)，采用Local attached storage作為存儲。

ClickHouse通過向量化執(zhí)行以及對CPU底層指令集（SIMD）的使用，它可以對海量數(shù)據(jù)進(jìn)行并行處理，從而加快數(shù)據(jù)的處理速度。

2.1 ClickHouse和其他常用數(shù)據(jù)庫性能對比

圖片

圖片來源https://benchmark.clickhouse.com/

上圖是ClickHouse官方發(fā)布的，ClickHouse和MongoDB、MySQL的部分性能評測對比圖。我們可以看到ClickHouse的性能在幾乎所有場景都優(yōu)于MongoDB和MySQL。

2.2 ClickHouse的特點(diǎn)

那么ClickHouse為什么這么快？這源于它的設(shè)計(jì)和特點(diǎn)。ClickHouse使用C++開發(fā)，可以利用硬件優(yōu)勢，摒棄了Hadoop生態(tài)，數(shù)據(jù)底層以列式存儲。它利用單節(jié)點(diǎn)的多核并行處理，為數(shù)據(jù)建立索引一級、二級、稀疏索引，使用大量的算法處理數(shù)據(jù)，并支持向量化處理，分布式處理數(shù)據(jù)。

2.2.1 ClickHouse為什么采用列式存儲？

行式存儲的好處：想查找某個人所有的屬性時，可以通過一次磁盤查找加順序讀取就可以；但是當(dāng)想查所有人的年齡時，需要不停的查找，或者全表掃描才行，遍歷的很多數(shù)據(jù)都是不需要的。

列式存儲的好處：對于列的聚合、計(jì)數(shù)、求和等統(tǒng)計(jì)操作優(yōu)于行式存儲。由于某一列的數(shù)據(jù)類型都是相同的，針對于數(shù)據(jù)存儲更容易進(jìn)行數(shù)據(jù)壓縮，每一列選擇更優(yōu)的數(shù)據(jù)壓縮算法，大大提高了數(shù)據(jù)的壓縮比重。數(shù)據(jù)壓縮比更好，一方面節(jié)省了磁盤空間，另一方面對于cache也有了更大的發(fā)揮空間。

2.2.2 DBMS功能

ClickHouse幾乎覆蓋了標(biāo)準(zhǔn) SQL 的大部分語法，包括 DDL 和 DML，以及配套的各種函數(shù)；用戶管理及權(quán)限管理、數(shù)據(jù)的備份與恢復(fù)。

2.2.3 多樣化引擎

ClickHouse目前提供包括合并樹、日志、接口和其他四大類20多種引擎。

2.2.4 高吞吐寫入能力

ClickHouse采用類LSM Tree的結(jié)構(gòu)，數(shù)據(jù)寫入后定期在后臺Compaction。通過類 LSM tree的結(jié)構(gòu)， ClickHouse在數(shù)據(jù)導(dǎo)入時全部是順序append寫，寫入后數(shù)據(jù)段不可更改，在后臺compaction時也是多個段merge sort后順序?qū)懟卮疟P。順序?qū)懙奶匦?，充分利用了磁盤的吞吐能力。

2.2.5 數(shù)據(jù)分區(qū)與線程及并行

ClickHouse將數(shù)據(jù)劃分為多個partition，每個partition再進(jìn)一步劃分為多個index granularity(索引粒度)，然后通過多個CPU核心分別處理其中的一部分來實(shí)現(xiàn)并行數(shù)據(jù)處理。在這種設(shè)計(jì)下，單條Query就能利用整機(jī)所有CPU。強(qiáng)大的并行處理能力，極大的降低了查詢延時。

所以，ClickHouse即使對于大量數(shù)據(jù)的查詢也能夠化整為零平行處理。但是有一個弊端就是對于單條查詢使用多CPU，就不利于同時并發(fā)多條查詢。所以對于高QPS的查詢業(yè)務(wù)并不是強(qiáng)項(xiàng)。

ClickHouse像很多OLAP數(shù)據(jù)庫一樣，單表查詢速度優(yōu)于關(guān)聯(lián)查詢，而且ClickHouse的兩者差距更為明顯。在執(zhí)行關(guān)聯(lián)查詢時，ClickHouse會將右表加載到內(nèi)存。

Part 03ClickHouse方案 

各種數(shù)據(jù)源通過Kafka接入到數(shù)據(jù)平臺層，數(shù)據(jù)平臺講明細(xì)數(shù)據(jù)存入數(shù)據(jù)存儲層的ClickHouse中，明細(xì)數(shù)據(jù)的存活時間可以根據(jù)業(yè)務(wù)需求設(shè)置。同時可以根據(jù)業(yè)務(wù)報(bào)表查詢的不同維度，利用ClickHouse的物化視圖形成預(yù)聚合數(shù)據(jù)，提高數(shù)據(jù)查詢效率。由數(shù)據(jù)服務(wù)層的定時任務(wù)周期性地從ClickHouse的預(yù)聚合數(shù)據(jù)中查詢業(yè)務(wù)所需的展示數(shù)據(jù)，把展示數(shù)據(jù)存入MySQL。由數(shù)據(jù)服務(wù)層的報(bào)表服務(wù)向數(shù)據(jù)展示層提供查詢服務(wù)，報(bào)表服務(wù)直接查詢MySQL中的結(jié)果數(shù)據(jù)，保證了查詢效率和并發(fā)性。

Part 04 總結(jié) 

傳統(tǒng)的Hadoop生態(tài)方案使用的生態(tài)組件多，這就會導(dǎo)致所需硬件資源多、維護(hù)困難、使用門檻高等各種問題。而ClickHouse方案不依賴Hadoop生態(tài)，根據(jù)業(yè)務(wù)需要使用簡單的幾種組件就可以完成數(shù)據(jù)接入、數(shù)據(jù)存儲和數(shù)據(jù)查詢等功能，節(jié)省了系統(tǒng)服務(wù)器資源，也降低了使用人員的門檻。