世界熱點！行式數(shù)據(jù)庫系統(tǒng)中的列式存儲——Clickhouse

1. Clickhouse的簡介

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

(資料圖)

2. Clickhouse的列式存儲

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

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

RowWatchIDJavaEnableTitleGoodEventEventTime

#0893543506621Investor Relations12016/5/18 5:19

#1903295099580Contact us12016/5/18 8:10

#2899537060541Mission12016/5/18 7:38

#N……………

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

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

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ù)的排列順序。對于存儲而言，列式數(shù)據(jù)庫總是將同一列的數(shù)據(jù)存儲在一起，不同列的數(shù)據(jù)也總是分開存儲。

常見的列式數(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+。

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

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

列式儲存的好處：

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

3. Clickhouse的SQL引擎和向量化

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

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

4. Clickhouse的吞吐能力

ClickHouse 采用類LSM Tree的結構，數(shù)據(jù)寫入后定期在后臺Compaction。通過類 LSM tree的結構，ClickHouse 在數(shù)據(jù)導入時全部是順序 append 寫，寫入后數(shù)據(jù)段不可更改，在后臺compaction 時也是多個段 merge sort 后順序寫回磁盤。順序寫的特性，充分利用了磁盤的吞吐能力，即便在 HDD 上也有著優(yōu)異的寫入性能。 ??官方公開 benchmark 測試顯示能夠達到 50MB-200MB/s 的寫入吞吐能力，按照每行100Byte 估算，大約相當于 50W-200W 條/s 的寫入速度。

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

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

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采用自己默認格式42G；greenplum未使用壓縮，數(shù)據(jù)存儲大小為98G。性能測試

多表關聯(lián)查詢

單表查詢性能

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

更多內容關注公眾號