1. Clickhouse的簡介

ClickHouse是俄羅斯的Yandex于2016年開源的列式存儲(chǔ)數(shù)據(jù)庫（DBMS），使用 C++語言編寫，主要用于在線分析處理查詢（OLAP），能夠使用SQL查詢實(shí)時(shí)生成分析數(shù)據(jù)報(bào)告。

(資料圖)

2. Clickhouse的列式存儲(chǔ)

ClickHouse是一個(gè)用于聯(lián)機(jī)分析(OLAP)的列式數(shù)據(jù)庫管理系統(tǒng)(DBMS)。

在傳統(tǒng)的行式數(shù)據(jù)庫系統(tǒng)中，數(shù)據(jù)按如下順序存儲(chǔ)：

RowWatchIDJavaEnableTitleGoodEventEventTime

#0893543506621Investor Relations12016/5/18 5:19

#1903295099580Contact us12016/5/18 8:10

#2899537060541Mission12016/5/18 7:38

#N……………

處于同一行中的數(shù)據(jù)總是被物理的存儲(chǔ)在一起。常見的行式數(shù)據(jù)庫系統(tǒng)有： MySQL、Postgres、oracle和MS SQL Server。

在列式數(shù)據(jù)庫系統(tǒng)中，數(shù)據(jù)按如下的順序存儲(chǔ)：

Row:#0#1#2#N

WatchID:893543506629032950995889953706054…

JavaEnable:101…

Title:Investor RelationsContact usMission…

GoodEvent:111…

EventTime:2016-05-18 05:19:202016-05-18 08:10:202016-05-18 07:38:00…

該示例中只展示了數(shù)據(jù)在列式數(shù)據(jù)庫中數(shù)據(jù)的排列順序。對于存儲(chǔ)而言，列式數(shù)據(jù)庫總是將同一列的數(shù)據(jù)存儲(chǔ)在一起，不同列的數(shù)據(jù)也總是分開存儲(chǔ)。

常見的列式數(shù)據(jù)庫有： Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise， Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+。

不同的存儲(chǔ)方式適合不同的場景，這里的查詢場景包括： 進(jìn)行了哪些查詢，多久查詢一次以及各類查詢的比例； 每種查詢讀取多少數(shù)據(jù)————行、列和字節(jié)；讀取數(shù)據(jù)和寫入數(shù)據(jù)之間的關(guān)系；使用的數(shù)據(jù)集大小以及如何使用本地的數(shù)據(jù)集；是否使用事務(wù),以及它們是如何進(jìn)行隔離的；數(shù)據(jù)的復(fù)制機(jī)制與數(shù)據(jù)的完整性要求；每種類型的查詢要求的延遲與吞吐量等等。

系統(tǒng)負(fù)載越高，根據(jù)使用場景進(jìn)行定制化就越重要，并且定制將會(huì)變的越精細(xì)。沒有一個(gè)系統(tǒng)同樣適用于明顯不同的場景。如果系統(tǒng)適用于廣泛的場景，在負(fù)載高的情況下，所有的場景可以會(huì)被公平但低效處理，或者高效處理一小部分場景。

列式儲(chǔ)存的好處：

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

3. Clickhouse的SQL引擎和向量化

支持SQLClickHouse支持基于SQL的聲明式查詢語言，該語言大部分情況下是與SQL標(biāo)準(zhǔn)兼容的。 支持的查詢包括 GROUP BY，ORDER BY，IN，JOIN以及非相關(guān)子查詢。 不支持窗口函數(shù)和相關(guān)子查詢。

向量引擎為了高效的使用CPU，數(shù)據(jù)不僅僅按列存儲(chǔ)，同時(shí)還按向量(列的一部分)進(jìn)行處理，這樣可以更加高效地使用CPU。

4. Clickhouse的吞吐能力

ClickHouse 采用類LSM Tree的結(jié)構(gòu)，數(shù)據(jù)寫入后定期在后臺(tái)Compaction。通過類 LSM tree的結(jié)構(gòu)，ClickHouse 在數(shù)據(jù)導(dǎo)入時(shí)全部是順序 append 寫，寫入后數(shù)據(jù)段不可更改，在后臺(tái)compaction 時(shí)也是多個(gè)段 merge sort 后順序?qū)懟卮疟P。順序?qū)懙奶匦裕浞掷昧舜疟P的吞吐能力，即便在 HDD 上也有著優(yōu)異的寫入性能。 ??官方公開 benchmark 測試顯示能夠達(dá)到 50MB-200MB/s 的寫入吞吐能力，按照每行100Byte 估算，大約相當(dāng)于 50W-200W 條/s 的寫入速度。

5. 數(shù)據(jù)分區(qū)和線程級并行

ClickHouse 將數(shù)據(jù)劃分為多個(gè) partition，每個(gè) partition 再進(jìn)一步劃分為多個(gè) index granularity(索引粒度)，然后通過多個(gè)CPU核心分別處理其中的一部分來實(shí)現(xiàn)并行數(shù)據(jù)處理。在這種設(shè)計(jì)下，單條Query就能利用整機(jī)所有CPU。極致的并行處理能力，極大的降低了查詢延時(shí)。 ??所以，ClickHouse即使對于大量數(shù)據(jù)的查詢也能夠化整為零平行處理。但是有一個(gè)弊端就是對于單條查詢使用多cpu，就不利于同時(shí)并發(fā)多條查詢。所以對于高 qps 的查詢業(yè)務(wù)，ClickHouse 并不是強(qiáng)項(xiàng)。

6. 性能數(shù)據(jù)

數(shù)據(jù)壓縮數(shù)據(jù)壓縮方面，Sparkql、Impala、Presto均采用的是hive元數(shù)據(jù)，hive數(shù)據(jù)100G上傳之后顯示為96.3G(.dat數(shù)據(jù)格式)，壓縮比0.963；hawq壓縮后數(shù)據(jù)大小為68.2G(.dat格式)，壓縮比：0.682；clickhouse采用自己默認(rèn)格式42G；greenplum未使用壓縮，數(shù)據(jù)存儲(chǔ)大小為98G。性能測試

多表關(guān)聯(lián)查詢

單表查詢性能

ClickHouse 作為目前所有開源MPP計(jì)算框架中計(jì)算速度最快的，它在做多列的表，同時(shí)行數(shù)很多的表的查詢時(shí)，性能是很讓人興奮的，但是在做多表的join時(shí)，它的性能是不如單寬表查詢的。性能測試結(jié)果表明ClickHouse在單表查詢方面表現(xiàn)出很大的性能優(yōu)勢，但是在多表查詢中性能卻比較差，不如presto和impala、hawq的效果好。

更多內(nèi)容關(guān)注公眾號