ClickHouse核心架構設計是怎麼樣的?ClickHouse核心架構模塊分為兩個部分:ClickHouse執行過程架構和ClickHouse數據存儲架構,下麵分別詳細介紹。 ClickHouse執行過程架構 總的來說,結合目前搜集到的一些資料,可以看到目前ClickHouse核心架構由下圖構成, ...
ClickHouse核心架構設計是怎麼樣的?ClickHouse核心架構模塊分為兩個部分:ClickHouse執行過程架構和ClickHouse數據存儲架構,下麵分別詳細介紹。
ClickHouse執行過程架構
總的來說,結合目前搜集到的一些資料,可以看到目前ClickHouse核心架構由下圖構成,主要的抽象模塊是Column、DataType、Block、Functions、Storage、Parser與Interpreter。
簡單來說,就是一條sql,會經由Parser與Interpreter,解析和執行,通過調用Column、DataType、Block、Functions、Storage等模塊,最終返回數據,下麵是各個模塊具體的介紹。
Columns
表示記憶體中的列(實際上是列塊),需使用 IColumn 介面。該介面提供了用於實現各種關係操作符的輔助方法。幾乎所有的操作都是不可變的:這些操作不會更改原始列,但是會創建一個新的修改後的列。
Column對象分為介面和實現兩個部分,在IColumn介面對象中,定義了對數據進行各種關係運算的方法,例如插入數據的insertRangeFrom和insertFrom方法、用於分頁的cut,以及用於過濾的filter方法等。而這些方法的具體實現對象則根據數據類型的不同,由相應的對象實現,例如ColumnString、ColumnArray和ColumnTuple等。
Field
表示單個值,有時候也可能需要處理單個值,可以使用Field。Field 是 UInt64、Int64、Float64、String 和 Array 組成的聯合。與Column對象的泛化設計思路不同,Field對象使用了聚合的設計模式。在Field對象內部聚合了Null、UInt64、String和Array等13種數據類型及相應的處理邏輯。
DataType
IDataType 負責序列化和反序列化:讀寫二進位或文本形式的列或單個值構成的塊。IDataType直接與表的數據類型相對應。比如,有 DataTypeUInt32、DataTypeDateTime、DataTypeString等數據類型。
IDataType與IColumn之間的關聯並不大。不同的數據類型在記憶體中能夠用相同的IColumn實現來表示。比如,DataTypeUInt32和DataTypeDateTime都是用ColumnUInt32或ColumnConstUInt32來表示的。另外,相同的數據類型也可以用不同的IColumn實現來表示。比如,DataTypeUInt8既可以使用ColumnUInt8 來表示,也可以使用過ColumnConstUInt8 來表示。
IDataType僅存儲元數據。比如,DataTypeUInt8不存儲任何東西(除了vptr);DataTypeFixedString僅存儲N(固定長度字元串的串長度)。
IDataType具有針對各種數據格式的輔助函數。比如如下一些輔助函數:序列化一個值並加上可能的引號;序列化一個值用於 JSON 格式;序列化一個值作為 XML 格式的一部分。輔助函數與數據格式並沒有直接的對應。比如,兩種不同的數據格式 Pretty 和 TabSeparated 均可以使用 IDataType 介面提供的 serializeTextEscaped 這一輔助函數。
Block
Block是表示記憶體中表的子集(chunk)的容器,是由三元組:(IColumn,IDataType,列名)構成的集合。在查詢執行期間,數據是按 Block進行處理的。如果我們有一個Block,那麼就有了數據(在IColumn對象中),有了數據的類型信息告訴我們如何處理該列,同時也有了列名(來自表的原始列名,或人為指定的用於臨時計算結果的名字)。
當我們遍歷一個塊中的列進行某些函數計算時,會把結果列加入到塊中,但不會更改函數參數中的列,因為操作是不可變的。之後,不需要的列可以從塊中刪除,但不是修改。這對於消除公共子表達式非常方便。
Block用於處理數據塊。註意,對於相同類型的計算,列名和類型對不同的塊保持相同,僅列數據不同。最好把塊數據(block data)和塊頭(block header)分離開來,因為小塊大小會因複製共用指針和列名而帶來很高的臨時字元串開銷。
Block Streams
塊流用於處理數據。我們可以使用塊流從某個地方讀取數據,執行數據轉換,或將數據寫到某個地方。IBlockInputStream 具有 read 方法,其能夠在數據可用時獲取下一個塊。IBlockOutputStream 具有 write 方法,其能夠將塊寫到某處。
塊流負責:
- 讀或寫一個表。表僅返回一個流用於讀寫塊。
- 完成數據格式化。比如,如果你打算將數據以Pretty格式輸出到終端,你可以創建一個塊輸出流,將塊寫入該流中,然後進行格式化。
- 執行數據轉換。假設你現在有IBlockInputStream並且打算創建一個過濾流,那麼你可以創建一個FilterBlockInputStream並用IBlockInputStream 進行初始化。之後,當你從FilterBlockInputStream中拉取塊時,會從你的流中提取一個塊,對其進行過濾,然後將過濾後的塊返回給你。查詢執行流水線就是以這種方式表示的。
Storage
IStorage介面表示一張表。該介面的不同實現對應不同的表引擎。比如 StorageMergeTree、StorageMemory等。這些類的實例就是表。
IStorage 中最重要的方法是read和write,除此之外還有alter、rename和drop等方法。read方法接受如下參數:需要從表中讀取的列集,需要執行的AST查詢,以及所需返回的流的數量。read方法的返回值是一個或多個IBlockInputStream對象,以及在查詢執行期間在一個表引擎內完成的關於數據處理階段的信息。
在大多數情況下,read方法僅負責從表中讀取指定的列,而不會進行進一步的數據處理。進一步的數據處理均由查詢解釋器完成,不由 IStorage 負責。
但是也有值得註意的例外:AST查詢被傳遞給read方法,表引擎可以使用它來判斷是否能夠使用索引,從而從表中讀取更少的數據。有時候,表引擎能夠將數據處理到一個特定階段。比如,StorageDistributed 可以向遠程伺服器發送查詢,要求它們將來自不同的遠程伺服器能夠合併的數據處理到某個階段,並返回預處理後的數據,然後查詢解釋器完成後續的數據處理。
Parser與Interpreter
Parser和Interpreter是非常重要的兩組介面:Parser分析器負責創建AST對象;而Interpreter解釋器則負責解釋AST,併進一步創建查詢的執行管道。它們與IStorage一起,串聯起了整個數據查詢的過程。Parser分析器可以將一條SQL語句以遞歸下降的方法解析成AST語法樹的形式。不同的SQL語句,會經由不同的Parser實現類解析。例如,有負責解析DDL查詢語句的ParserRenameQuery、ParserDropQuery和ParserAlterQuery解析器,也有負責解析INSERT語句的ParserInsertQuery解析器,還有負責SELECT語句的ParserSelectQuery等。
Interpreter解釋器的作用就像Service服務層一樣,起到串聯整個查詢過程的作用,它會根據解釋器的類型,聚合它所需要的資源。首先它會解析AST對象;然後執行“業務邏輯”(例如分支判斷、設置參數、調用介面等);最終返回IBlock對象,以線程的形式建立起一個查詢執行管道。
Functions
函數既有普通函數,也有聚合函數。
普通函數不會改變行數-它們的執行看起來就像是獨立地處理每一行數據。實際上,函數不會作用於一個單獨的行上,而是作用在以Block 為單位的數據上,以實現向量查詢執行。
還有一些雜項函數,比如塊大小、rowNumberInBlock,以及跑累積,它們對塊進行處理,並且不遵從行的獨立性。
ClickHouse 具有強類型,因此隱式類型轉換不會發生。如果函數不支持某個特定的類型組合,則會拋出異常。但函數可以通過重載以支持許多不同的類型組合。比如,plus 函數(用於實現+運算符)支持任意數字類型的組合:UInt8+Float32,UInt16+Int8等。同時,一些可變參數的函數能夠級接收任意數目的參數,比如concat函數。
實現函數可能有些不方便,因為函數的實現需要包含所有支持該操作的數據類型和IColumn類型。比如,plus函數能夠利用C++模板針對不同的數字類型組合、常量以及非常量的左值和右值進行代碼生成。
這是一個實現動態代碼生成的好地方,從而能夠避免模板代碼膨脹。同樣,運行時代碼生成也使得實現融合函數成為可能,比如融合«乘-加»,或者在單層迴圈迭代中進行多重比較。
由於向量查詢執行,函數不會«短路»。比如,如果你寫 WHERE f(x) AND g(y),兩邊都會進行計算,即使是對於 f(x) 為 0 的行(除非f(x)是零常量表達式)。但是如果 f(x) 的選擇條件很高,並且計算 f(x) 比計算 g(y) 要划算得多,那麼最好進行多遍計算:首先計算 f(x),根據計算結果對列數據進行過濾,然後計算 g(y),之後只需對較小數量的數據進行過濾。
ClickHouse數據存儲架構
ClickHouse數據存儲架構由分片(Shard)組成,而每個分片又通過副本(Replica)組成。ClickHouse分片有限免兩個特點。
- ClickHouse的1個節點只能擁有1個分片,也就是說如果要實現1分片、1副本,則至少需要部署2個服務節點。
- 分片只是一個邏輯概念,其物理承載還是由副本承擔的。
下麵是cluster擁有1個shard(分片)和2個replica(副本),且副本由192.37.129.6服務節點和192.37.129.7服務節承載。從本質上看,這個配置是是一個分片一個副本,因為分片最終還是由副本來實現,所以這個其中一個副本是屬於分片,分片是一個邏輯概念,它指的是其中的一個副本,這個和Elasticsearch中的分片和副本的概念有所不同。
<ch_cluster>
<shard>
<replica>
<host>192.37.129.6</host>
<port>9000</port>
</replica>
<replica>
<host>192.37.129.7</host>
<port>9000</port>
</replica>
</shard>
</ch_cluster>
ClickHouse相關資料分享
資料參考:ClickHouse(02)ClickHouse架構設計介紹概述與ClickHouse數據分片設計
本文來自博客園,作者:張飛的豬,轉載請註明原文鏈接:https://www.cnblogs.com/the-pig-of-zf/p/16394605.html
作者公眾號:張飛的豬大數據分享,不定期分享大數據學習的總結和相關資料,歡迎關註。