到底為什麼我們需要 Clickhouse?

Clickhouse 是現在最流行的 OLAP 資料庫之一，雖然名聲如雷貫耳，但在我們心目中總有一個疑問，到底為什麼我們需要 Clickhouse，是哪些優點讓位元組、騰訊這些大公司都選擇它作為最推薦的 OLAP 資料庫，這篇文章將試圖帶我們找到答案。

一、什麼是 Clickhouse?

Clickhouse 是一個開源使用列式儲存的 OLAP 資料庫，最初由 Yandex 公司開發，現在從 Yandex 拆分出來併成立了獨立的 Clickhouse Inc，其功能類似於 Google Analytics。它的目標是處理數萬億行和數 PB 的資料，並快速執行分析查詢。

Clickhouse 等 OLAP 資料庫通常用於回答諸如 "昨天有多少人訪問掘金?昨天有多少人訪問 CSDN" 之類的業務問題。如果使用傳統的 OLTP 資料庫來處理，可能需要幾分鐘甚至幾個小時。而如果使用 OLAP 資料庫，我們幾毫秒就得到結果。OLTP 和 OLAP 之間的巨大速度差異是因為使用的底層儲存結構不同，OLTP 資料庫通常使用行式儲存，OLAP 則通常使用列式儲存。

什麼是列式儲存?

假設我們有如下資料：

時間戳

域名

訪問

2022-10-26 12:00  20

2022-10-26 12:00  300

2022-10-26 12:01  15

2022-10-26 12:02 blog.fflow.link 21

如果我們使用 PostgreSQL 和 MySQL 等的 OLTP 資料庫，資料將按如下結構進行儲存：

第 1 行 -> 2022-10-26 12:00，，20;第 2 行 -> 2022-10-26 12:00，，300;第 3 行-> 2022-10-26 12:01，，15;第 4 行-> 2022-10-26 12:02，blog.fflow.link，21;

一行中的每一列的資料會在磁碟中相鄰寫入，這樣的儲存結構會讓單行的資料查詢、更新和刪除操作很快。但是當我們需要進行聚合的時候，比如統計  的訪問次數，資料庫則需要逐行讀取資料並統計求和。這樣不僅帶來了大量的 IO 操作，而且處理的時候也會比較長。

但是如果我們使用列式儲存的資料庫，資料將按如下結構進行儲存：

時間戳列 -> 2022-10-26 12:00:001,2022-10-26 12:00:002,2022-10-26 12:01:003,2022-10-26 12:02:004;

訪問域名列-> :001,:002,:003,blog.fflow.link:004;

訪問次數列 -> 20:001,300:002,15:003,21:004;

列式儲存中的每一行資料都是分開儲存的。如果需要統計  的訪問次數，資料庫首先需要從訪問域名列中找到  對應的 id，然後再對 id 的訪問次數列求和。這樣資料庫就不需要再跨很多磁碟頁來檢索資料，因為它只需要先獲取滿足條件的列資料。這就是為什麼使用列式儲存的資料庫進行分析查詢，比使用行式儲存的資料庫快很多。

二、為什麼 Clickhouse 改變了遊戲規則

Clickhouse 或 OLAP 資料庫的主要用途包括但不限於：

資料分析

資料探勘

商業智慧

日誌分析

Clickhouse 是一個支援多種資料儲存引擎的資料庫，幾乎支援將任何資料來源匯入到 Clickhouse 資料庫中，並支援快速靈活的下鑽分析。比如，現在微信就使用 Clickhouse 來儲存日誌資料，因為日誌裡面通常有非常多的重複值，使用 Clickhouse 可以得到非常高的壓縮率，減少日誌佔用的儲存空間;Cloudflare、Mux、Plausible、GraphCDN 和 Panelbear 等公司則使用 Clickhouse 儲存流量資料，並在其儀表板中向使用者呈現相關報告;而 Percona 正在使用 Clickhouse 來儲存和分析資料庫效能指標。

三、什麼場景不適合 Clickhouse

Clickhouse 並不能取代關係型資料，也不是為了處理事務性資料而開發的，Clickhouse 更多的是作為 OLTP 補充，方便用來進行資料分析。如果需要對資料進行更新和刪除，或者需要進行多表關聯，那麼我們通常不推薦使用 Clickhouse。

另外也要避免把 Clickhouse 用作 OLTP 資料庫的副本。當然從技術上講，我們可以把 OLTP 資料庫的資料透過事件的方式同步到 Clickhouse，但最好的做法是使用 Clickhouse 作為資料的唯一真實來源，而不是作為 OLTP 資料庫的映象。

四、為什麼 MySQL 不使用列式儲存?

分頁友好，且可以將資料都放到葉子節點，可以兼顧 Scan 與 Lookup

資料更新方便 (這對列式儲存是硬傷，所以很多 OLAP 資料庫不支援更新，或者用複雜的方式支援更新)

事務型資料庫的主要效能瓶頸是 I/O，更新一行資料，列式儲存需要進行多次 I/O，但是行式少數幾次就夠了。

五、Clickhouse 的優點

開源社群很活躍

在評估開源軟體的時候，我們必須考慮它的社群是否活躍，如果我們使用了一個開源軟體，但是這個開源軟體突然就不維護了就會讓人很尷尬，比如之前阿里的 Dubbo。當然這種情況在開源的世界裡面並不少見，我們需要儘可能的使用有大公司 / 組織背書的開源軟體。如果我們選擇使用 Clickhouse，我們就不需要擔心這些。不管是國內的位元組、騰訊、阿里，還是國外的 Cloudflare、eBay、Spotify，這些業界知名的公司都在使用 Clickhouse。

飛快的查詢速度

根據 Marko Medojevic 的報告，如果對 11M 的資料集進行分析查詢，Clickhouse 的查詢速度會比 MySQL 快約 260 倍。然而，也許這種比較並不公平，因為 MySQL 畢竟是 OLTP 資料庫，但這也從側面反應了 OLAP 資料庫的優勢所在。

Clickhouse 實現的極致效能來自其獨特的資料庫引擎 MergeTree，而且 Clickhouse 也比較趨向於使用通用的硬體來做查詢效能最佳化。

小索引(稀疏索引)

大家都知道在資料庫中快速查詢資料的關鍵是索引。索引最好儲存在記憶體中以便快速訪問。在 OLTP 資料庫中，索引通常使用 B+ 樹來進行儲存，比如下圖。

這適用於 OLTP 資料庫，因為主鍵本質上是必不可少的。在 OLTP 資料庫中，通常是透過主鍵 ID 查詢資料庫，例如 SELECT username, email FROM user WHERE id = 10086 或類似 UPDATE user SET email = "hunterzhang86@gmail.com" WHERE id = 10086 等查詢。但是，一旦資料增長到數十億行並且索引在記憶體中放不下的時候，這種型別的索引侷限性就非常明顯。

而在 Clickhouse 中，索引的構造如下圖所示。

Clickhouse 使用的索引 和 Kafka 類似，其僅儲存索引資料的子集。這樣的好處是索引相對較小，就算是很大的資料量，其索引在記憶體裡面也放得下。我們想象一下如果要使用 SELECT SUM (visit) FROM visit WHERE date BETWEEN '2022-10-01' AND '2022-10-31' 進行查詢，資料庫使用稀疏索引的方式就很合適，因為我們的查詢條件是日期範圍，而不是主鍵 ID。這就是為什麼稀疏索引在 OLAP 資料庫中經常使用的原因。

資料壓縮

由於 Clickhouse 的資料是按列而不是按行儲存的，所以它能夠比行式資料庫能更好地壓縮資料。 有資料表明，同樣的資料放在 Clickhouse，相比於放在 PostgreSQL 所需的磁碟空間減少了 70%。另外在 Clickhouse 中，可以和方便的指定列的資料壓縮演算法和壓縮級別。

資料 TTL

通常我們不建議無限制的儲存資料，這樣會浪費非常多的磁碟空間。一般情況下，設定一個合適的資料保留時間是比較好的選擇。在 Clickhouse 中，可以透過在建立表時設定資料的 TTL 輕鬆做到這一點。

適配多種語言

Clickhouse 的社群非常活躍，現在就已經支援 Java、Go、Python 等流行語言的 SDK，如果使用 Perl 小眾語言，Clickhouse 也支援透過 HTTP 介面操作訪問資料。

水平可擴充套件和高可用

Clickhouse 在構建時就考慮了水平可擴充套件性和高可用性。我們可以將資料分片到多個節點並將資料複製到另一組伺服器中。當然水平可擴充套件性和高可用性功能會帶來額外的複雜度，如果我們使用 Kubernetes 部署 Clickhouse，可以使用 Clickhouse Kubernetes Operator 進行配置。

六、小結

實話說，現在如果有資料分析的場景，我第一個想到的方案就是使用 Clickhouse，如果再結合一下 Superset 等開源 BI 工具，我們就可以非常快速的搭建起來輕量的資料分析系統，這樣對於大多數中小公司來說就已經完全夠用了。最後，如果想快速試用一下，推薦試用 docker 進行安裝。