ClickHouse是近年來備受關(guān)注的開源列式數(shù)據(jù)庫验庙，主要用于數(shù)據(jù)分析（OLAP）領(lǐng)域。目前國內(nèi)社區(qū)火熱壶谒，各個大廠紛紛跟進大規(guī)模使用：
- 今日頭條 內(nèi)部用ClickHouse來做用戶行為分析，內(nèi)部一共幾千個ClickHouse節(jié)點汗菜，單集群最大1200節(jié)點让禀，總數(shù)據(jù)量幾十PB，日增原始數(shù)據(jù)300TB左右陨界。
- 騰訊內(nèi)部用ClickHouse做游戲數(shù)據(jù)分析巡揍，并且為之建立了一整套監(jiān)控運維體系。
- 攜程內(nèi)部從18年7月份開始接入試用菌瘪，目前80%的業(yè)務(wù)都跑在ClickHouse上腮敌。每天數(shù)據(jù)增量十多億阱当，近百萬次查詢請求。
- 快手內(nèi)部也在使用ClickHouse糜工，存儲總量大約10PB弊添， 每天新增200TB， 90%查詢小于3S捌木。
在國外油坝，Yandex內(nèi)部有數(shù)百節(jié)點用于做用戶點擊行為分析，CloudFlare刨裆、Spotify等頭部公司也在使用澈圈。
特別值得一提的是：國內(nèi)云計算的領(lǐng)導(dǎo)廠商阿里云率先推出了自己的ClickHouse托管產(chǎn)品，產(chǎn)品首頁地址為云數(shù)據(jù)庫ClickHouse帆啃，可以點擊鏈接申請參加免費公測瞬女，一睹為快！
在社區(qū)方面努潘，github star數(shù)目增速驚人诽偷。
在DB-engines排名上，如下圖中紅色曲線所示疯坤。ClickHouse開源時間雖短渤刃，但是增勢迅猛。
為何ClickHouse獲得了如此廣泛的關(guān)注贴膘，得到了社區(qū)的青睞卖子，也得到了諸多大廠的應(yīng)用呢？本文嘗試從技術(shù)視角進行回答刑峡。
1洋闽、OLAP場景的特點
讀多于寫
不同于事務(wù)處理（OLTP）的場景突梦，比如電商場景中加購物車宫患、下單娃闲、支付等需要在原地進行大量insert、update卷哩、delete操作将谊，數(shù)據(jù)分析（OLAP）場景通常是將數(shù)據(jù)批量導(dǎo)入后尊浓，進行任意維度的靈活探索、BI工具洞察虏劲、報表制作等。
數(shù)據(jù)一次性寫入后谷丸，分析師需要嘗試從各個角度對數(shù)據(jù)做挖掘刨疼、分析揩慕，直到發(fā)現(xiàn)其中的商業(yè)價值迎卤、業(yè)務(wù)變化趨勢等信息玷坠。這是一個需要反復(fù)試錯八堡、不斷調(diào)整兄渺、持續(xù)優(yōu)化的過程挂谍，其中數(shù)據(jù)的讀取次數(shù)遠(yuǎn)多于寫入次數(shù)口叙。這就要求底層數(shù)據(jù)庫為這個特點做專門設(shè)計，而不是盲目采用傳統(tǒng)數(shù)據(jù)庫的技術(shù)架構(gòu)饭望。
大寬表铅辞，讀大量行但是少量列斟珊，結(jié)果集較小
在OLAP場景中卢佣，通常存在一張或是幾張多列的大寬表助币，列數(shù)高達(dá)數(shù)百甚至數(shù)千列夜牡。對數(shù)據(jù)分析處理時勤庐，選擇其中的少數(shù)幾列作為維度列、其他少數(shù)幾列作為指標(biāo)列米罚，然后對全表或某一個較大范圍內(nèi)的數(shù)據(jù)做聚合計算录择。這個過程會掃描大量的行數(shù)據(jù)糊肠，但是只用到了其中的少數(shù)列货裹。而聚合計算的結(jié)果集相比于動輒數(shù)十億的原始數(shù)據(jù)弧圆，也明顯小得多搔预。
數(shù)據(jù)批量寫入拯田，且數(shù)據(jù)不更新或少更新
OLTP類業(yè)務(wù)對于延時（Latency）要求更高船庇，要避免讓客戶等待造成業(yè)務(wù)損失；而OLAP類業(yè)務(wù)臣淤，由于數(shù)據(jù)量非常大邑蒋，通常更加關(guān)注寫入吞吐（Throughput）医吊，要求海量數(shù)據(jù)能夠盡快導(dǎo)入完成逮京。一旦導(dǎo)入完成造虏，歷史數(shù)據(jù)往往作為存檔漓藕，不會再做更新享钞、刪除操作栗竖。
無需事務(wù)狐肢，數(shù)據(jù)一致性要求低
OLAP類業(yè)務(wù)對于事務(wù)需求較少份名，通常是導(dǎo)入歷史日志數(shù)據(jù)僵腺，或搭配一款事務(wù)型數(shù)據(jù)庫并實時從事務(wù)型數(shù)據(jù)庫中進行數(shù)據(jù)同步辰如。多數(shù)OLAP系統(tǒng)都支持最終一致性琉兜。
靈活多變，不適合預(yù)先建模
分析場景下漆际，隨著業(yè)務(wù)變化要及時調(diào)整分析維度奸汇、挖掘方法擂找，以盡快發(fā)現(xiàn)數(shù)據(jù)價值贯涎、更新業(yè)務(wù)指標(biāo)塘雳。而數(shù)據(jù)倉庫中通常存儲著海量的歷史數(shù)據(jù)普筹，調(diào)整代價十分高昂太防。預(yù)先建模技術(shù)雖然可以在特定場景中加速計算蜒车，但是無法滿足業(yè)務(wù)靈活多變的發(fā)展需求酿愧，維護成本過高嬉挡。
2棘伴、ClickHouse存儲層
ClickHouse從OLAP場景需求出發(fā)焊夸，定制開發(fā)了一套全新的高效列式存儲引擎，并且實現(xiàn)了數(shù)據(jù)有序存儲使鹅、主鍵索引患朱、稀疏索引裁厅、數(shù)據(jù)Sharding执虹、數(shù)據(jù)Partitioning唠梨、TTL当叭、主備復(fù)制等豐富功能蚁鳖。以上功能共同為ClickHouse極速的分析性能奠定了基礎(chǔ)才睹。
列式存儲
與行存將每一行的數(shù)據(jù)連續(xù)存儲不同琅攘，列存將每一列的數(shù)據(jù)連續(xù)存儲坞琴。示例圖如下：
相比于行式存儲剧辐，列式存儲在分析場景下有著許多優(yōu)良的特性荧关。
- 如前所述忍啤，分析場景中往往需要讀大量行但是少數(shù)幾個列同波。在行存模式下，數(shù)據(jù)按行連續(xù)存儲戴尸，所有列的數(shù)據(jù)都存儲在一個block中孙蒙，不參與計算的列在IO時也要全部讀出马篮，讀取操作被嚴(yán)重放大浑测。而列存模式下迁央，只需要讀取參與計算的列即可岖圈，極大的減低了IO cost蜂科，加速了查詢短条。
- 同一列中的數(shù)據(jù)屬于同一類型茸时，壓縮效果顯著可都。列存往往有著高達(dá)十倍甚至更高的壓縮比渠牲，節(jié)省了大量的存儲空間签杈，降低了存儲成本。
- 更高的壓縮比意味著更小的data size接奈，從磁盤中讀取相應(yīng)數(shù)據(jù)耗時更短通孽。
- 自由的壓縮算法選擇背苦。不同列的數(shù)據(jù)具有不同的數(shù)據(jù)類型行剂，適用的壓縮算法也就不盡相同‰缃恚可以針對不同列類型澈蝙，選擇最合適的壓縮算法撵幽。
- 高壓縮比盐杂，意味著同等大小的內(nèi)存能夠存放更多數(shù)據(jù)链烈，系統(tǒng)cache效果更好测垛。
官方數(shù)據(jù)顯示秧均，通過使用列存目胡，在某些分析場景下誉己，能夠獲得100倍甚至更高的加速效應(yīng)。
數(shù)據(jù)有序存儲
ClickHouse支持在建表時霉祸，指定將數(shù)據(jù)按照某些列進行sort by丝蹭。
排序后坪蚁，保證了相同sort key的數(shù)據(jù)在磁盤上連續(xù)存儲敏晤，且有序擺放嘴脾。在進行等值、范圍查詢時彩倚，where條件命中的數(shù)據(jù)都緊密存儲在一個或若干個連續(xù)的Block中帆离，而不是分散的存儲在任意多個Block哥谷， 大幅減少需要IO的block數(shù)量们妥。另外监婶，連續(xù)IO也能夠充分利用操作系統(tǒng)page cache的預(yù)取能力惑惶，減少page fault短纵。
主鍵索引
ClickHouse支持主鍵索引鱼冀，它將每列數(shù)據(jù)按照index granularity（默認(rèn)8192行）進行劃分，每個index granularity的開頭第一行被稱為一個mark行千绪。主鍵索引存儲該mark行對應(yīng)的primary key的值荸型。
對于where條件中含有primary key的查詢，通過對主鍵索引進行二分查找鹉究，能夠直接定位到對應(yīng)的index granularity自赔，避免了全表掃描從而加速查詢绍妨。
但是值得注意的是：ClickHouse的主鍵索引與MySQL等數(shù)據(jù)庫不同他去，它并不用于去重灾测，即便primary key相同的行媳搪，也可以同時存在于數(shù)據(jù)庫中秦爆。要想實現(xiàn)去重效果等限，需要結(jié)合具體的表引擎ReplacingMergeTree望门、CollapsingMergeTree怒允、VersionedCollapsingMergeTree實現(xiàn)纫事，我們會在未來的文章系列中再進行詳細(xì)解讀丽惶。
稀疏索引
ClickHouse支持對任意列創(chuàng)建任意數(shù)量的稀疏索引钾唬。其中被索引的value可以是任意的合法SQL Expression抡秆，并不僅僅局限于對column value本身進行索引儒士。之所以叫稀疏索引檩坚，是因為它本質(zhì)上是對一個完整index granularity（默認(rèn)8192行）的統(tǒng)計信息匾委，并不會具體記錄每一行在文件中的位置薯鳍。目前支持的稀疏索引類型包括：
- minmax: 以index granularity為單位辐啄，存儲指定表達(dá)式計算后的min壶辜、max值砸民；在等值和范圍查詢中能夠幫助快速跳過不滿足要求的塊岭参，減少IO演侯。
- set(max_rows)：以index granularity為單位悬赏，存儲指定表達(dá)式的distinct value集合娄徊，用于快速判斷等值查詢是否命中該塊兵多，減少IO橄仆。
- ngrambf_v1(n, size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)：將string進行ngram分詞后剩膘，構(gòu)建bloom filter，能夠優(yōu)化等值盆顾、like援雇、in等查詢條件。
- tokenbf_v1(size_of_bloom_filter_in_bytes, number_of_hash_functions, random_seed)：與ngrambf_v1類似椎扬，區(qū)別是不使用ngram進行分詞惫搏，而是通過標(biāo)點符號進行詞語分割。
- bloom_filter([false_positive])：對指定列構(gòu)建bloom filter蚕涤，用于加速等值筐赔、like、in等查詢條件的執(zhí)行。
數(shù)據(jù)Sharding
ClickHouse支持單機模式，也支持分布式集群模式。在分布式模式下，ClickHouse會將數(shù)據(jù)分為多個分片，并且分布到不同節(jié)點上道批。不同的分片策略在應(yīng)對不同的SQL Pattern時衅金，各有優(yōu)勢姨伟。
ClickHouse提供了豐富的sharding策略，讓業(yè)務(wù)可以根據(jù)實際需求選用。
1） random隨機分片：寫入數(shù)據(jù)會被隨機分發(fā)到分布式集群中的某個節(jié)點上。
2） constant固定分片：寫入數(shù)據(jù)會被分發(fā)到固定一個節(jié)點上榄笙。
3）column value分片：按照某一列的值進行hash分片。
4）自定義表達(dá)式分片：指定任意合法表達(dá)式，根據(jù)表達(dá)式被計算后的值進行hash分片。
數(shù)據(jù)分片，讓ClickHouse可以充分利用整個集群的大規(guī)模并行計算能力睛挚，快速返回查詢結(jié)果勃教。
更重要的是绳军，多樣化的分片功能猎唁，為業(yè)務(wù)優(yōu)化打開了想象空間蛔屹。比如在hash sharding的情況下育叁，JOIN計算能夠避免數(shù)據(jù)shuffle龟梦，直接在本地進行l(wèi)ocal join躁倒；支持自定義sharding福贞，可以為不同業(yè)務(wù)和SQL Pattern定制最適合的分片策略；利用自定義sharding功能薄辅，通過設(shè)置合理的sharding expression可以解決分片間數(shù)據(jù)傾斜問題等拉一。
另外，sharding機制使得ClickHouse可以橫向線性拓展，構(gòu)建大規(guī)模分布式集群锌杀，從而具備處理海量數(shù)據(jù)的能力究抓。
數(shù)據(jù)Partitioning
ClickHouse支持PARTITION BY子句畅卓，在建表時可以指定按照任意合法表達(dá)式進行數(shù)據(jù)分區(qū)操作，比如通過toYYYYMM()將數(shù)據(jù)按月進行分區(qū)价淌、toMonday()將數(shù)據(jù)按照周幾進行分區(qū)啦膜、對Enum類型的列直接每種取值作為一個分區(qū)等乘粒。
數(shù)據(jù)Partition在ClickHouse中主要有兩方面應(yīng)用：
- 在partition key上進行分區(qū)裁剪绑洛，只查詢必要的數(shù)據(jù)配深。靈活的partition expression設(shè)置母谎，使得可以根據(jù)SQL Pattern進行分區(qū)設(shè)置懈贺，最大化的貼合業(yè)務(wù)特點
- 對partition進行TTL管理皮迟，淘汰過期的分區(qū)數(shù)據(jù)。
數(shù)據(jù)TTL
在分析場景中忧勿，數(shù)據(jù)的價值隨著時間流逝而不斷降低哼勇，多數(shù)業(yè)務(wù)出于成本考慮只會保留最近幾個月的數(shù)據(jù)的烁，ClickHouse通過TTL提供了數(shù)據(jù)生命周期管理的能力注盈。
ClickHouse支持幾種不同粒度的TTL：
1） 列級別TTL：當(dāng)一列中的部分?jǐn)?shù)據(jù)過期后击罪，會被替換成默認(rèn)值；當(dāng)全列數(shù)據(jù)都過期后，會刪除該列本鸣。
2）行級別TTL：當(dāng)某一行過期后涮瞻，會直接刪除該行。
3）分區(qū)級別TTL：當(dāng)分區(qū)過期后，會直接刪除該分區(qū)台谊。
高吞吐寫入能力
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ū)懙奶匦裕浞掷昧舜疟P的吞吐能力硬猫，即便在HDD上也有著優(yōu)異的寫入性能补箍。
官方公開benchmark測試顯示能夠達(dá)到50MB-200MB/s的寫入吞吐能力，按照每行100Byte估算啸蜜，大約相當(dāng)于50W-200W條/s的寫入速度。
有限支持delete辈挂、update
在分析場景中衬横，刪除、更新操作并不是核心需求终蒂。ClickHouse沒有直接支持delete蜂林、update操作遥诉，而是變相支持了mutation操作，語法為alter table delete where filter_expr, alter table update col=val where filter_expr噪叙。
目前主要限制為刪除矮锈、更新操作為異步操作，需要后臺compation之后才能生效睁蕾。
主備同步
ClickHouse通過主備復(fù)制提供了高可用能力苞笨，主備架構(gòu)下支持無縫升級等運維操作。而且相比于其他系統(tǒng)它的實現(xiàn)有著自己的特色：
1）默認(rèn)配置下子眶，任何副本都處于active模式瀑凝，可以對外提供查詢服務(wù)；
2）可以任意配置副本個數(shù)臭杰，副本數(shù)量可以從0個到任意多個粤咪；
3）不同shard可以配置不提供副本個數(shù)，用于解決單個shard的查詢熱點問題
渴杆；
3寥枝、ClickHouse計算層
ClickHouse在計算層做了非常細(xì)致的工作，竭盡所能榨干硬件能力磁奖，提升查詢速度囊拜。它實現(xiàn)了單機多核并行、分布式計算点寥、向量化執(zhí)行與SIMD指令艾疟、代碼生成等多種重要技術(shù)。
多核并行
ClickHouse將數(shù)據(jù)劃分為多個partition敢辩，每個partition再進一步劃分為多個index granularity蔽莱，然后通過多個CPU核心分別處理其中的一部分來實現(xiàn)并行數(shù)據(jù)處理。
在這種設(shè)計下戚长，單條Query就能利用整機所有CPU盗冷。極致的并行處理能力，極大的降低了查詢延時同廉。
分布式計算
除了優(yōu)秀的單機并行處理能力仪糖，ClickHouse還提供了可線性拓展的分布式計算能力。ClickHouse會自動將查詢拆解為多個task下發(fā)到集群中迫肖，然后進行多機并行處理锅劝，最后把結(jié)果匯聚到一起。
在存在多副本的情況下蟆湖，ClickHouse提供了多種query下發(fā)策略
隨機下發(fā)：在多個replica中隨機選擇一個故爵；
- 最近hostname原則：選擇與當(dāng)前下發(fā)機器最相近的hostname節(jié)點，進行query下發(fā)隅津。在特定的網(wǎng)絡(luò)拓?fù)湎挛艽梗梢越档途W(wǎng)絡(luò)延時劲室。而且能夠確保query下發(fā)到固定的replica機器，充分利用系統(tǒng)cache结窘。
- in order：按照特定順序逐個嘗試下發(fā)很洋，當(dāng)前一個replica不可用時，順延到下一個replica隧枫。
- first or random：在In Order模式下喉磁，當(dāng)?shù)谝粋€replica不可用時，所有workload都會積壓到第二個Replica悠垛，導(dǎo)致負(fù)載不均衡线定。first or random解決了這個問題：當(dāng)?shù)谝粋€replica不可用時，隨機選擇一個其他replica确买，從而保證其余replica間負(fù)載均衡斤讥。另外在跨region復(fù)制場景下，通過設(shè)置第一個replica為本region內(nèi)的副本湾趾，可以顯著降低網(wǎng)絡(luò)延時芭商。
向量化執(zhí)行與SIMD
ClickHouse不僅將數(shù)據(jù)按列存儲，而且按列進行計算搀缠。傳統(tǒng)OLTP數(shù)據(jù)庫通常采用按行計算铛楣，原因是事務(wù)處理中以點查為主，SQL計算量小艺普，實現(xiàn)這些技術(shù)的收益不夠明顯簸州。但是在分析場景下，單個SQL所涉及計算量可能極大歧譬，將每行作為一個基本單元進行處理會帶來嚴(yán)重的性能損耗：
1）對每一行數(shù)據(jù)都要調(diào)用相應(yīng)的函數(shù)岸浑，函數(shù)調(diào)用開銷占比高；
2）存儲層按列存儲數(shù)據(jù)瑰步，在內(nèi)存中也按列組織矢洲，但是計算層按行處理，無法充分利用CPU cache的預(yù)讀能力缩焦，造成CPU Cache miss嚴(yán)重读虏；
3）按行處理，無法利用高效的SIMD指令袁滥；
ClickHouse實現(xiàn)了向量執(zhí)行引擎（Vectorized execution engine）盖桥，對內(nèi)存中的列式數(shù)據(jù)，一個batch調(diào)用一次SIMD指令（而非每一行調(diào)用一次）题翻，不僅減少了函數(shù)調(diào)用次數(shù)葱轩、降低了cache miss，而且可以充分發(fā)揮SIMD指令的并行能力藐握，大幅縮短了計算耗時靴拱。向量執(zhí)行引擎，通常能夠帶來數(shù)倍的性能提升猾普。
動態(tài)代碼生成Runtime Codegen
在經(jīng)典的數(shù)據(jù)庫實現(xiàn)中袜炕，通常對表達(dá)式計算采用火山模型，也即將查詢轉(zhuǎn)換成一個個operator初家，比如HashJoin偎窘、Scan、IndexScan溜在、Aggregation等陌知。為了連接不同算子，operator之間采用統(tǒng)一的接口掖肋，比如open/next/close仆葡。在每個算子內(nèi)部都實現(xiàn)了父類的這些虛函數(shù)，在分析場景中單條SQL要處理數(shù)據(jù)通常高達(dá)數(shù)億行志笼，虛函數(shù)的調(diào)用開銷不再可以忽略不計沿盅。
另外，在每個算子內(nèi)部都要考慮多種變量纫溃，比如列類型腰涧、列的size、列的個數(shù)等紊浩，存在著大量的if-else分支判斷導(dǎo)致CPU分支預(yù)測失效窖铡。
ClickHouse實現(xiàn)了Expression級別的runtime codegen，動態(tài)地根據(jù)當(dāng)前SQL直接生成代碼坊谁，然后編譯執(zhí)行费彼。如下圖例子所示，對于Expression直接生成代碼呜袁，不僅消除了大量的虛函數(shù)調(diào)用（即圖中多個function pointer的調(diào)用）敌买，而且由于在運行時表達(dá)式的參數(shù)類型、個數(shù)等都是已知的阶界，也消除了不必要的if-else分支判斷虹钮。
[圖片上傳中...(image-4a9712-1578294892480-0)]
近似計算
近似計算以損失一定結(jié)果精度為代價，極大地提升查詢性能膘融。在海量數(shù)據(jù)處理中芙粱，近似計算價值更加明顯。
ClickHouse實現(xiàn)了多種近似計算功能：
近似估算distinct values氧映、中位數(shù)春畔，分位數(shù)等多種聚合函數(shù)；
建表DDL支持SAMPLE BY子句，支持對于數(shù)據(jù)進行抽樣處理律姨；
復(fù)雜數(shù)據(jù)類型支持
ClickHouse還提供了array振峻、json、tuple择份、set等復(fù)合數(shù)據(jù)類型扣孟，支持業(yè)務(wù)schema的靈活變更。
5荣赶、結(jié)語
近年來ClickHouse發(fā)展趨勢迅猛凤价，社區(qū)和大廠都紛紛跟進使用。本文嘗試從OLAP場景的需求出發(fā)拔创，介紹了ClickHouse存儲層利诺、計算層的主要設(shè)計。ClickHouse實現(xiàn)了大多數(shù)當(dāng)前主流的數(shù)據(jù)分析技術(shù)剩燥，具有明顯的技術(shù)優(yōu)勢：
- 提供了極致的查詢性能：開源公開benchmark顯示比傳統(tǒng)方法快1001000倍慢逾，提供50MB200MB/s的高吞吐實時導(dǎo)入能力）
- 以極低的成本存儲海量數(shù)據(jù)：借助于精心設(shè)計的列存、高效的數(shù)據(jù)壓縮算法躏吊，提供高達(dá)10倍的壓縮比氛改，大幅提升單機數(shù)據(jù)存儲和計算能力，大幅降低使用成本比伏，是構(gòu)建海量數(shù)據(jù)倉庫的絕佳方案胜卤。
- 簡單靈活又不失強大：提供完善SQL支持，上手十分簡單赁项；提供json葛躏、map、array等靈活數(shù)據(jù)類型適配業(yè)務(wù)快速變化悠菜；同時支持近似計算舰攒、概率數(shù)據(jù)結(jié)構(gòu)等應(yīng)對海量數(shù)據(jù)處理。
相比于開源社區(qū)的其他幾項分析型技術(shù)悔醋，如Druid摩窃、Presto、Impala芬骄、Kylin猾愿、ElasticSearch等，ClickHouse更是一整套完善的解決方案账阻，它自包含了存儲和計算能力（無需額外依賴其他存儲組件）蒂秘，完全自主實現(xiàn)了高可用，而且支持完整的SQL語法包括JOIN等淘太，技術(shù)上有著明顯優(yōu)勢姻僧。
相比于hadoop體系规丽，以數(shù)據(jù)庫的方式來做大數(shù)據(jù)處理更加簡單易用，學(xué)習(xí)成本低且靈活度高撇贺。當(dāng)前社區(qū)仍舊在迅猛發(fā)展中赌莺，相信后續(xù)會有越來越多好用的功能出現(xiàn)。
