點擊上方藍色字體,選擇“設爲星標”
回覆”資源“獲取更多資源
引言
MergeTree存儲
MergeTree思想
MergeTree存儲結構
CREATE TABLE user_action_log (
`time` DateTime DEFAULT CAST('1970-01-01 08:00:00', 'DateTime') COMMENT '日誌時間',
`action_id` UInt16 DEFAULT CAST(0, 'UInt16') COMMENT '日誌行爲類型id',
`action_name` String DEFAULT '' COMMENT '日誌行爲類型名',
`region_name` String DEFAULT '' COMMENT '區服名稱',
`uid` UInt64 DEFAULT CAST(0, 'UInt64') COMMENT '用戶id',
`level` UInt32 DEFAULT CAST(0, 'UInt32') COMMENT '當前等級',
`trans_no` String DEFAULT '' COMMENT '事務流水號',
`ext_head` String DEFAULT '' COMMENT '擴展日誌head',
`avatar_id` UInt32 DEFAULT CAST(0, 'UInt32') COMMENT '角色id',
`scene_id` UInt32 DEFAULT CAST(0, 'UInt32') COMMENT '場景id',
`time_ts` UInt64 DEFAULT CAST(0, 'UInt64') COMMENT '秒單位時間戳',
index avatar_id_minmax (avatar_id) type minmax granularity 3
) ENGINE = MergeTree()
PARTITION BY (toYYYYMMDD(time), toHour(time), region_name)
ORDER BY (action_id, scene_id, time_ts, level, uid)
PRIMARY KEY (action_id, scene_id, time_ts, level);
MergeTree表的存儲結構中,每個數據分區相互獨立,邏輯上沒有關聯。單個數據分區內部存在着多個MergeTree Data Part。這些Data Part一旦生成就是Immutable的狀態,Data Part的生成和銷燬主要與寫入和異步Merge有關。MergeTree表的寫入鏈路是一個極端的batch load過程,Data Part不支持單條的append insert。每次batch insert都會生成一個新的MergeTree Data Part。如果用戶單次insert一條記錄,那就會爲那一條記錄生成一個獨立的Data Part,這必然是無法接受的。一般我們使用MergeTree表引擎的時候,需要在客戶端做聚合進行batch寫入或者在MergeTree表的基礎上創建Distributed表來代理MergeTree表的寫入和查詢,Distributed表默認會緩存用戶的寫入數據,超過一定時間或者數據量再異步轉發給MergeTree表。MergeTree存儲引擎對數據實時可見要求非常高的場景是不太友好的。
上圖展示了單個MergeTree Data Part裏最核心的一部分磁盤文件(只畫了action_id和avatar_id列其關的存儲文件),從功能上分主要有三個類:
Granule是數據按行劃分時用到的邏輯概念。關於多少行是一個Granule這個問題,在老版本中這是用參數index_granularity設定的一個常量,也就是每隔確定行就是一個Granule。在當前版本中有另一個參數index_granularity_bytes會影響Granule的行數,它的意義是讓每個Granule中所有列的sum size儘量不要超過設定值。老版本中的定長Granule設定主要的問題是MergeTree中的數據是按Granule粒度進行索引的,這種粗糙的索引粒度在分析超級大寬表的場景中,從存儲讀取的data size會膨脹得非常厲害,需要用戶非常謹慎得設定參數。
Block是列存文件中的壓縮單元。每個列存文件的Block都會包含若干個Granule,具體多少個Granule是由參數min_compress_block_size控制,每次列的Block中寫完一個Granule的數據時,它會檢查當前Block Size有沒有達到設定值,如果達到則會把當前Block進行壓縮然後寫磁盤。
從以上兩點可以看出MergeTree的Block既不是定data size也不是定行數的,Granule也不是一個定長的邏輯概念。所以我們需要額外信息快速找到某一個Granule。這就是Mark標識文件的作用,它記錄了每個Granule的行數,以及它所在的Block在列存壓縮文件中的偏移,同時還有Granule在解壓後的Block中的偏移位置。
MergeTree查詢
索引檢索
/// Whether the condition is feasible in the key range.
/// left_key and right_key must contain all fields in the sort_descr in the appropriate order.
/// data_types - the types of the key columns.
bool mayBeTrueInRange(size_t used_key_size, const Field * left_key, const Field * right_key, const DataTypes & data_types) const;
/// Whether the condition is feasible in the direct product of single column ranges specified by `parallelogram`.
bool mayBeTrueInParallelogram(const std::vector<Range> & parallelogram, const DataTypes & data_types) const;
/// Is the condition valid in a semi-infinite (not limited to the right) key range.
/// left_key must contain all the fields in the sort_descr in the appropriate order.
bool mayBeTrueAfter(size_t used_key_size, const Field * left_key, const DataTypes & data_types) const;
數據Sampling
數據掃描
Final模式:該模式對CollapsingMergeTree、SummingMergeTree等表引擎提供一個最終Merge後的數據視圖。前文已經提到過MergeTree基礎上的高級MergeTree表引擎都是對MergeTree Data Part採用了特定的Merge邏輯。它帶來的問題是由於MergeTree Data Part是異步Merge的過程,在沒有最終Merge成一個Data Part的情況下,用戶無法看到最終的數據結果。所以ClickHouse在查詢是提供了一個final模式,它會在各個Data Part的多條BlockInputStream基礎上套上一些高級的Merge Stream,例如DistinctSortedBlockInputStream、SummingSortedBlockInputStream等,這部分邏輯和異步Merge時的邏輯保持一致,這樣用戶就可以提前看到“最終”的數據結果了。
Sorted模式:sort模式可以認爲是一種order by下推存儲的查詢加速優化手段。因爲每個MergeTree Data Part內部的數據是有序的,所以當用戶查詢中包括排序鍵order by條件時只需要在各個Data Part的BlockInputStream上套一個做數據有序歸併的InputStream就可以實現全局有序的能力。
Normal模式:這是基礎MergeTree表最常用的數據掃描模式,多個Data Part之間進行並行數據掃描,對於單查詢可以達到非常高吞吐的數據讀取。
並行掃描:傳統的計算引擎在數據掃描部分的併發度大多和存儲文件數綁定在一起,所以MergeTree Data Part並行掃描是一個基礎能力。但是MergeTree的存儲結構要求數據不斷mege,最終合併成一個Data Part,這樣對索引和數據壓縮纔是最高效的。所以ClickHouse在MergeTree Data Part並行的基礎上還增加了Mark Range並行。用戶可以任意設定數據掃描過程中的並行度,每個掃描線程分配到的是Mark Range In Data Part粒度的任務,同時多個掃描線程之間還共享了Mark Range Task Pool,這樣可以避免在存儲掃描中的長尾問題。
數據Cache:MergeTree的查詢鏈路中涉及到的數據有不同級別的緩存設計。主鍵索引和分區鍵索引在load Data Part的過程中被加載到內存,Mark文件和列存文件有對應的MarkCache和UncompressedCache,MarkCache直接緩存了Mark文件中的binary內容,而UncompressedCache中緩存的是解壓後的Block數據。
SIMD反序列化:部分列類型的反序列化過程中採用了手寫的sse指令加速,在數據命中UncompressedCache的情況下會有一些效果。
PreWhere過濾:ClickHouse的語法支持了額外的PreWhere過濾條件,它會先於Where條件進行判斷。當用戶在sql的filter條件中加上PreWhere過濾條件時,存儲掃描會分兩階段進行,先讀取PreWhere條件中依賴的列值,然後計算每一行是否符合條件。相當於在Mark Range的基礎上進一步縮小掃描範圍,PreWhere列掃描計算過後,ClickHouse會調整每個Mark對應的Granule中具體要掃描的行數,相當於可以丟棄Granule頭尾的一部分行。
結語
本文分享自微信公衆號 - 大數據技術與架構(import_bigdata)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。