ClickHouse深度解析 一般有用 看1 速

十一vs十一發表於2024-04-02

一、什麼是ClickHouse？

ClickHouse由俄羅斯第一大搜尋引擎Yandex於2016年6月釋出, 開發語言為C++,ClickHouse是一個面向聯機分析處理(OLAP)的開源的面向列式儲存的DBMS，簡稱CK, 與Hadoop、Spark這些巨無霸元件相比，ClickHouse很輕量級,查詢效能非常好，使用之後會被它的效能折服，非常值得安利。

二、適用場景

  1. 志資料行為分析

  2. 標籤畫像的分析

  3. 資料集市分層

  4. 廣告系統和實時競價廣告

  5. 電商和金融行業

  6. 實時監控和遙感測量

  7. 商業智慧

  8. 線上遊戲

  9. 資訊保安

  10. 所有的網際網路場景

三、特性

真正的面向列的DBMS（ClickHouse是一個DBMS,而不是一個單一的資料庫。它允許在執行時建立表和資料庫、載入資料和執行查詢，而無需重新配置和重新啟動伺服器）
資料壓縮（一些面向列的DBMS（INFINIDB CE 和 MonetDB）不使用資料壓縮。但是，資料壓縮確實是提高了效能）
磁碟儲存的資料（許多面向列的DBMS(SPA HANA和GooglePowerDrill)）只能在記憶體中工作。但即使在數千臺伺服器上，記憶體也太小了。）
多核並行處理(多核多節點並行化大型查詢)
在多個伺服器上分散式處理(在clickhouse中，資料可以駐留在不同的分片上。每個分片都可以用於容錯的一組副本，查詢會在所有分片上並行處理)
SQL支援(ClickHouse sql 跟真正的sql有不一樣的函式名稱。不過語法基本跟SQL語法相容，支援JOIN/FROM/IN 和JOIN子句及標量子查詢支援子查詢)

  1. 真正的列式資料庫

  2. 資料壓縮

  3. 資料的磁碟儲存

  4. 多核並行處理

  5. 多伺服器分散式處理（資料儲存在不同的shard上，每一個shard都由一組用於容錯的副本組成，可並行查詢所有shard）

  6. 向量引擎（按列的一部分進行處理，高效實用CPU）

  7. 實時的資料更新（支援在表中定義主鍵,資料增量有序儲存在mergeTree中）

  8. 索引（按照主鍵對資料進行排序，毫秒內完成對資料的查詢）

  9. 適合線上查詢

  10. 支援近似計算（允許犧牲精度的情況下低延遲查詢）

  11. 支援資料複製和資料完整性（非同步多主複製技術）

四、 缺陷

  1. 沒有完整的事務支援

  2. 缺少高頻率低延遲的修改或刪除資料的能力

  3. 不適合透過其檢索單行的點查詢

  4. 聯機事物處理

  5. 二進位制資料或檔案儲存

  6. 鍵值對資料高效率訪問請求

五、核心概念

5.1.表引擎（Engine）

表引擎決定了資料在檔案系統中的儲存方式，常用的也是官方推薦的儲存引擎是MergeTree系列，如果需要資料副本的話可以使用ReplicatedMergeTree系列，相當於MergeTree的副本版本。讀取叢集資料需要使用分散式表引擎Distribute。

5.2.表分割槽（Partition）

表中的資料可以按照指定的欄位分割槽儲存，每個分割槽在檔案系統中都是都以目錄的形式存在。常用時間欄位作為分割槽欄位，資料量大的表可以按照小時分割槽，資料量小的表可以在按照天分割槽或者月分割槽，查詢時，使用分割槽欄位作為Where條件，可以有效的過濾掉大量非結果集資料。

5.3.分片（Shard）

一個分片本身就是ClickHouse一個例項節點，分片的本質就是為了提高查詢效率，將一份全量的資料分成多份（片），從而降低單節點的資料掃描數量，提高查詢效能。

5.4. 複製集（Replication）

簡單理解就是相同的資料備份，在CK中透過複製集，我們實現保障了資料可靠性外，也透過多副本的方式，增加了CK查詢的併發能力。這裡一般有2種方式： （1）基於ZooKeeper的表複製方式； （2）基於Cluster的複製方式。由於我們推薦的資料寫入方式本地表寫入，禁止分散式表寫入，所以我們的複製表只考慮ZooKeeper的表複製方案。

5.5.叢集（Cluster）

可以使用多個ClickHouse例項組成一個叢集，並統一對外提供服務。

六、主要表引擎深入解析

6.1.TinyLog

最簡單的表引擎，用於將資料儲存在磁碟上，每列都儲存在單獨的壓縮檔案中，寫入時，資料附加到檔案末尾. 缺點：（1）沒有併發控制（沒有做最佳化，同時寫會資料會損壞，報錯） （2）不支援索引 （3）資料儲存在磁碟上 優點：（1）小表節省空間 （2）資料寫入，只查詢，不做增刪改操作 建立表：

create table stu1(id Int8, name String)ENGINE=TinyLog

6.2. Memory

記憶體引擎，資料以未壓縮的原始形式直接儲存在記憶體中，伺服器重啟，資料會消失，讀寫操作不會相互阻塞，不支援索引。 建議上限1億行的場景。 優點：簡單查詢下有非常高的效能表現（超過10G/s） 建立表:

create table stu1(id Int8, name String)ENGINE=Merge(db_name, 'regex_tablename')

6.3.Merge

本身不儲存資料，但可用於同時從任意多個其他的表中讀取資料，讀是自動並行的，不支援寫入，讀取時，那些真正被讀取到資料的表的索引（如果有的話）會被佔用,預設是本地表，不能跨機器。 引數：一個資料庫名和一個用於匹配表名的正規表示式 建立表：

create table t1(id Int8, name String)ENGINE=TinyLog
create table t2(id Int8, name String)ENGINE=TinyLog
create table t3(id Int8, name String)ENGINE=TinyLog
create table t (id UInt16, name String)ENGINE=Merge(currentDatabase(), ‘^t’)

6.4.MergeTree

ck中最強大的表引擎MergeTree(合併樹)和該系列（*MergeTree）中的其他引擎。 使用場景：有巨量資料要插入到表中，高效一批批寫入資料片段，並希望這些資料片段在後臺按照一定規則合併。相比在插入時不斷修改（重寫）資料進行儲存，會高效很多。 優點：（1）資料按主鍵排序 （2）可以使用分割槽（如果指定了主鍵）（3）支援資料副本 （4）支援資料取樣 建立表：

ENGINE MergeTree() PARTITION BY toYYYYMM(EventDate) ORDER BY (CounterID, EventDate, intHash32(UserID)) SAMPLE BY intHash32(UserID) SETTINGS index_granularity=8192

ClickHouse深度解析 一般有用 看1 速

插入資料：

ClickHouse深度解析 一般有用 看1 速

6.5.ReplacingMergeTree

在MergeTree的基礎上，增加了“處理重複資料”的功能，和MergeTree的不同之處在於他會刪除具有相同主鍵的重複項，資料的去重只會在合併的過程中出現，合併會在未知的時間在後臺進行，所以你無法預先做出計劃，有一些資料可能仍未被處理，適用於在後臺清除重複的資料以節省空間，但是不保證沒有重複的資料出現。 建立表：

ClickHouse深度解析 一般有用 看1 速

6.6.SummingMergeTree

繼承自MergeTree,區別在於，當合並SummingMergeTree表的資料片段時，ck會把具有相同主鍵的行合併為一行，該行包含了被合併的行中具有數值資料型別的列的彙總值，如果主鍵的組合方式使得單個鍵值對應於大量的行，則可以顯著的減少儲存空間並加快資料查詢的速度，對於不可加的列，會取一個最先出現的值。

ClickHouse深度解析 一般有用 看1 速

6.7.Distributed(重點)

分散式引擎，本身不儲存資料，但可以在多個伺服器上進行分散式查詢，讀是自動並行的，讀取時，遠端伺服器的索引（如果有的話）會被使用。

ClickHouse深度解析 一般有用 看1 速

七、最佳實踐

7.1.HDFS資料匯入Clickhouse

建立hdfs_engine

CREATE TABLE hdfs_engine_table (name String, value UInt32) ENGINE=HDFS('hdfs://hdfs1:9000/other_storage', 'TSV')

File file

INSERT INTO hdfs_engine_table VALUES ('one', 1), ('two', 2), ('three', 3)

資料查詢

SELECT * FROM hdfs_engine_table LIMIT 2
┌─name─┬─value─┐
│ one  │     1 │
│ two  │     2 │
└──────┴───────┘

7.2.每分鐘億級別海量使用者行為日誌實時自助查詢

資料鏈路

ClickHouse深度解析 一般有用 看1 速

系統實現 在flink端動態設定schema資訊，ETL處理資料，動態生成寬表，資料存入Clickhouse，按天分割槽，Clickhouse使用Distributed表引擎，資料保留7天，避免資料過度膨脹，導致查詢效能降低，使用Redash報表工具，分析人員可以寫SQL自助查詢，結果自定義圖表展示。

系統成果 每分鐘乙級的資料量，整個資料鏈路資料延遲在毫秒，資料查詢響應在秒級別，動態設定schema生成寬表，做到整個系統的複用性，避免重複開發，查詢效能比Hive快幾百倍，滿足了實時性的要求。

八、大廠使用場景

1. 頭條：使用者行為分析系統，上報日誌 大寬表，減少join，增加map資料型別，展平模型，支援動態scheam

ClickHouse深度解析 一般有用 看1 速

2. 騰訊：遊戲資料分析

3. 攜程：內部從18年7月份開始接入試用，目前80%的業務都跑在ClickHouse上。每天資料增量十多億，近百萬次查詢請求 4.快手：內部也在使用ClickHouse，儲存總量大約10PB， 每天新增200TB， 90%查詢小於3S 5.國外：Yandex內部有數百節點用於做使用者點選行為分析，CloudFlare、Spotify等頭部公司也在使用

相關文章