Clickhouse 的緣起

Clickhouse 最初是為 Yandex.Metrica 這個(gè)世界上第二大的Web分析平臺開發(fā)的，并且一直是這個(gè)系統(tǒng)的核心組件。ClickHouse在Yandex.Metrica中的主要任務(wù)是使用非聚合數(shù)據(jù)在在線模式下構(gòu)建報(bào)告，使用374臺服務(wù)器組成的集群，在數(shù)據(jù)庫中存儲的數(shù)據(jù)超過20.3萬億行，壓縮后的數(shù)據(jù)量約為2PB，未壓縮的數(shù)據(jù)量(TSV格式)大約17PB。

Clickhouse 是一款面向數(shù)據(jù)倉庫提供實(shí)時(shí)計(jì)算的產(chǎn)品，傳統(tǒng)數(shù)倉普遍存在計(jì)算效率低、查詢和寫入延時(shí)高、投資和運(yùn)維成本高等缺陷。Clickhouse 放棄了很多傳統(tǒng)數(shù)據(jù)倉庫習(xí)以為常的設(shè)計(jì)，致力于充分發(fā)揮單機(jī)性能優(yōu)勢，提供低成本、高效率的實(shí)時(shí)數(shù)據(jù)倉庫環(huán)境。今天我們就來分析，Clickhouse 是如何通過精妙的存儲引擎和計(jì)算引擎來實(shí)現(xiàn)這些目標(biāo)的。

Clickhouse 為什么這么快

向量化的存儲引擎

Clickhouse 是一款列式存儲數(shù)據(jù)庫。數(shù)據(jù)庫表通常包含數(shù)十甚至數(shù)百的列，而分析計(jì)算只會使用其中的幾個(gè)列。行存讀取時(shí)將整行數(shù)據(jù)讀取到內(nèi)存中，然后再選擇相關(guān)的列進(jìn)行計(jì)算，而列式存儲僅讀取需要參與計(jì)算的列，因此列存能夠極大的降低數(shù)據(jù)分析過程中需要讀取的數(shù)據(jù)量。

而在計(jì)算引擎設(shè)計(jì)上，Clickhouse 首次使用了向量化計(jì)算引擎，借助于CPU提供的SIMD(Single Instruction Multiple Data，單指令多數(shù)據(jù)流)技術(shù)，可以充分發(fā)揮現(xiàn)代計(jì)算機(jī)體系架構(gòu)的優(yōu)勢，最大限度的壓榨單機(jī)性能。在實(shí)際使用中，百億以下的單表基本上使用單機(jī)就可以處理，這種處理能力已經(jīng)可以滿足絕大多數(shù)企業(yè)的需求，也在很大程度上解決了傳統(tǒng)數(shù)據(jù)倉庫系統(tǒng)效率低和成本高的問題。

高比例的數(shù)據(jù)壓縮

列存為Clickhouse 帶來另一個(gè)非常明顯的優(yōu)勢是大幅提高了數(shù)據(jù)壓縮空間。列存是將同一列數(shù)據(jù)存儲在連續(xù)的空間上，字段類型都是相同的，數(shù)據(jù)相似度更高，相比于行存數(shù)據(jù)，能夠提供更高的數(shù)據(jù)壓縮比，從而大幅減少壓縮后的數(shù)據(jù)大小，降低磁盤的I/O時(shí)間。

實(shí)際項(xiàng)目中，Clickhouse 的數(shù)據(jù)壓縮比能夠達(dá)到8:1，即8T數(shù)據(jù)壓縮后只需要1T的存儲空間。Yandex.Metrica 未壓縮數(shù)據(jù)17PB，壓縮后2PB，壓縮比也接近8:1。

高效的I/O優(yōu)化

超高的壓縮比例為Clickhouse 帶來了更低的數(shù)據(jù)存儲成本和I/O訪問開銷，同時(shí)也帶來了額外的計(jì)算開銷 – 數(shù)據(jù)解壓縮。數(shù)據(jù)壓縮后存儲到磁盤上，訪問時(shí)需要進(jìn)行解壓還原數(shù)據(jù)，之后才能參與分析和計(jì)算。如何最大程度減少解壓時(shí)間，甚至在數(shù)據(jù)被程序讀取前就過濾掉不相干的數(shù)據(jù)，成為具備壓縮能力引擎的一大挑戰(zhàn)。

Clickhouse 底層存儲引擎使用MergeTree，為了應(yīng)對海量數(shù)據(jù)查詢和管理需求，Clickhouse 使用了一種和B樹索引完全不同的索引結(jié)構(gòu) – 稀疏索引。

Clickhouse 批量數(shù)據(jù)插入形成一個(gè)最小的存儲單元，稱為Part，每個(gè)Part中的數(shù)據(jù)按照主鍵排序，表是由多個(gè)Part組成的。

ClickHouse 的表通常都比較大，因此表中的數(shù)據(jù)通常都是先按照分區(qū)鍵被劃分為多個(gè)分區(qū)，分區(qū)鍵常采用日期的方式，比如下圖中按照月份分區(qū)。分區(qū)表的Part歸屬于某一個(gè)分區(qū)，為了實(shí)現(xiàn)高效的數(shù)據(jù)存儲，ClickHouse會在后臺定期對歸屬于同一個(gè)分區(qū)的Part進(jìn)行合并。

每個(gè)數(shù)據(jù)Part被邏輯上拆分為多個(gè)顆粒(granules)，granules是Clickhouse訪問時(shí)讀取的最小數(shù)據(jù)集，不可分割。granules中的第一行用該行的主鍵值來標(biāo)記，這個(gè)標(biāo)記保存在 Part 的索引文件中，Clickhouse 會為每個(gè)granules創(chuàng)建獨(dú)立的索引文件。不僅僅是主鍵，每一列都會存儲類似的標(biāo)記，可以通過這些標(biāo)記直接在列文件中查找數(shù)據(jù)。

和B樹索引主鍵和數(shù)據(jù)一一對應(yīng)的結(jié)構(gòu)不同，稀疏索引的數(shù)據(jù)并沒有精確到行，而是通過索引文件中的Mark快速定位到數(shù)據(jù)所在的granules；然后將定位到的候選granules以并行流的方式加載到ClickHouse引擎，找到最終匹配的數(shù)據(jù)。這種索引最大的好處是主鍵索引占用的存儲空間很小，掃描的效率也很高，非常適合海量數(shù)據(jù)分析中的范圍查詢。

簡單舉例

以下是一個(gè)簡單的數(shù)據(jù)查詢過程，通過這個(gè)過程我們可以了解到如何從Clickhouse中獲取到最終數(shù)據(jù)。

select count(distinct action) where date=toDate(2020-01-01) and city=’bj’

1. 查找primary.idx并找到對應(yīng)的Mark集合（即數(shù)據(jù)block集合）;
2. 對于要讀取的每個(gè)列根據(jù).mrk文件定位到Mark對應(yīng)在數(shù)據(jù)文件.bin中的數(shù)據(jù)offset；
3. 讀取到對應(yīng)的數(shù)據(jù)，供后續(xù)計(jì)算。

Clickhouse 的不足

天下沒有免費(fèi)的午餐，ClickHouse在提供超強(qiáng)查詢性能的同時(shí)，也會在其他方面做一些取舍。

• 沒有完全成熟的事務(wù)能力；
• 對于已存在的數(shù)據(jù)，缺乏高效的數(shù)據(jù)修改和刪除能力；
• 稀疏索引使得ClickHouse在按鍵值檢索單行的點(diǎn)查詢時(shí)效率不高。

寫在最后

任何架構(gòu)都不是萬能的，都有其自身的優(yōu)點(diǎn)，在獲取這些優(yōu)點(diǎn)的同時(shí)也存在局限。盡管ClickHouse還存在著些許的不足，使得其并不適合作為OLTP型的數(shù)據(jù)庫，但并不妨礙其成為優(yōu)秀的MPP架構(gòu)數(shù)據(jù)倉庫。

國內(nèi)諸如字節(jié)跳動、騰訊、攜程、滴滴出行等眾多頭部互聯(lián)網(wǎng)公司，都在使用ClickHouse作為分析查詢引擎，提供業(yè)務(wù)決策、用戶畫像等場景。在當(dāng)前基礎(chǔ)架構(gòu)國產(chǎn)化的背景下，還有一眾公司基于ClickHouse推出了自己的數(shù)據(jù)倉庫產(chǎn)品，將ClickHouse的產(chǎn)品和理念推廣到更廣闊的領(lǐng)域。