「ClickHouse系列」ClickHouse之MergeTree原理
Hi，我是王知無，一個大數(shù)據(jù)領(lǐng)域的原創(chuàng)作者。? 放心關(guān)注我，獲取更多行業(yè)的一手消息。
在閱讀本文之前你一定要先看看這個：
Clickhouse - MergeTree原理
MergeTree引擎以及隸屬于MergeTree引擎族的所有引擎是Clickhouse表引擎中最重要, 最強大的引擎.
MergeTree引擎族中的引擎被設(shè)計用于將大量數(shù)據(jù)寫入表中. 這些數(shù)據(jù)被快速的寫入每個表的每個part, 然后在Clickhouse底層會進行多個parts的合并(merge). 這種形式的處理比在插入過程中不斷重寫存儲中的數(shù)據(jù)要高效得多.
主要的功能點:
存儲按主鍵(primary key)排序的數(shù)據(jù).
這允許用戶可以創(chuàng)建一個小型的稀疏索引, 有利于更快的在表中找到索要的數(shù)據(jù).如果partitioning key被設(shè)置, 分片(partitions)可以被使用.
Clickhouse支持某些帶分區(qū)的操作, 對于同一份數(shù)據(jù)進行處理, 帶有分區(qū)的操作會比一般操作更有效. 當(dāng)在查詢語句中指定了分區(qū)后, Clickhouse會根據(jù)分區(qū)信息來進行數(shù)據(jù)的切分, 這樣極大程度上提升了查詢的性能.數(shù)據(jù)副本機制支持(Replication)
ReplicatedMergeTree并引擎提供了數(shù)據(jù)副本機制.支持數(shù)據(jù)采樣
如果必要, 可以在表中設(shè)置數(shù)據(jù)采樣方式.
1. 創(chuàng)建表
1.1. 建表語句
CREATE?TABLE?[IF?NOT?EXISTS]?[db.]table_name?[ON?CLUSTER?cluster]
(
????name1?[type1]?[DEFAULT|MATERIALIZED|ALIAS?expr1]?[TTL?expr1],
????name2?[type2]?[DEFAULT|MATERIALIZED|ALIAS?expr2]?[TTL?expr2],
????...
????INDEX?index_name1?expr1?TYPE?type1(...)?GRANULARITY?value1,
????INDEX?index_name2?expr2?TYPE?type2(...)?GRANULARITY?value2
)?ENGINE?=?MergeTree()
ORDER?BY?expr
[PARTITION?BY?expr]
[PRIMARY?KEY?expr]
[SAMPLE?BY?expr]
[TTL?expr?[DELETE|TO?DISK?'xxx'|TO?VOLUME?'xxx'],?...]
[SETTINGS?name=value,?...]
1.2. 參數(shù)說明
ENGINE: 指定該表所使用的的引擎. 如果引擎需要一些具體的參數(shù), 需要進行相應(yīng)的設(shè)置,MergeTree引擎不需要, 例如ReplicatedMergeTree:ENGINE=ReplicatedMergeTree('/clickhouse/tables/#_tenant_id_#/#__appname__#/#_at_date_#/{shard}/hits', '{replica}')ORDER BY: 按指定字段進行排序
支持設(shè)置的值為元組(一個列名或任意多字段表達式), 例如:ORDER BY (CounterID, EventDate)
如果創(chuàng)建表的時候, 沒有使用PRIMARY KEY修飾詞來顯式指定主鍵, 那么Clickhouse會將ORDER BY指定的字段作為主鍵處理.
如果該表不需要排序, 可以使用ORDER BY tuple()語法.PARTITION BY: 指定分區(qū)字段, 可選
分區(qū)字段一般是一個Date類型或者DateTime類型的字段. 如果想按照月進行分區(qū), 可以使用toYYYYMM(date_column)表達式, 那么分區(qū)字段的格式就是YYYYMM.PAIMARY KEY: 主鍵, 可選
默認情況下, 在Clickhouse中主鍵都是和排序字段(ORDER BY子句指定字段)是一致的, 所以在大多數(shù)情況下, 不需要單獨指定主鍵. 如果需要兩者不一致, 詳情可見differs from the sorting key.SAMPLE BY: 取樣表達式, 可選
如果使用了SAMPLE BY子句, 那么SAMPLE BY指定的字段必須是主鍵(或排序字段)所包含的字段. 例如:SAMPLE BY intHash32(USERID) ORDER BY (CounterID, EventDate, intHash32(UserID))TTL: 一些被指定的規(guī)則, 涉及存儲數(shù)據(jù)行的存儲時長, 以及確定數(shù)據(jù)parts的自動移除邏輯. 可選
TTL表達式必須包含一個Date類型或者DateTime類型的字段作為一個結(jié)果值, 例如:TTL date + INTERVAL 1 DAY
這種類型的規(guī)則DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'指定了當(dāng)表達式條件被滿足時對數(shù)據(jù)parts處理的操作: 刪除過期的行, 移除數(shù)據(jù)parts(如果該數(shù)據(jù)parts中所有的行都滿足條件)到指定的位置TO DISK 'XXX'.規(guī)則的默認類型是DELETE. 可以指定多個規(guī)則組成一條表達式, 但是DELETE規(guī)則不成超過一條.
查看更多細節(jié): TTL for columns and tables.SETTINGS: 設(shè)置MergeTree引擎的附加的參數(shù), 可選index_graularity
索引標記之間的最大數(shù)據(jù)行數(shù). 默認值: 8192.index_graularity_bytes
數(shù)據(jù)顆粒的最大大小, 單位bytes, 默認值: 10MB. 若要僅按行數(shù)限制顆粒大小, 請設(shè)置為0(不推薦).min_index_granularity_bytes
數(shù)據(jù)顆粒的最小大小, 單位bytes, 默認值: 1024b. 該值是為了防止意外創(chuàng)建``index_graularity_bytes`值很低的表.enable_mixed_granularity_parts
同樣是設(shè)置數(shù)據(jù)顆粒的最大大小, 該參數(shù)用于過渡取代index_graularity_bytes. 在v19.11版本前, 只有index_granularity用于控制顆粒大小.當(dāng)查詢數(shù)據(jù)涉及到大量的行(幾十或幾百兆)時,index_granularity_bytes參數(shù)提高了Clickhouse的性能. 如果你的表擁有大量的行時, 可以為表啟用這個參數(shù)來提高查詢的性能.use_minimalistic_part_header_in_zookeeper
在Zookeeper中數(shù)據(jù)parts_headers存儲的方式. 如果設(shè)置為1, 則Zookeeper中存儲的數(shù)據(jù)較少, 具體可以參考setting description.min_merge_bytes_to_use_direct_io
使用直接I/O訪問存儲磁盤所需的merge操作的最小數(shù)據(jù)量. merge數(shù)據(jù)parts時, Clickhouse會計算所有要合并的數(shù)據(jù)的總存儲空間, 如果超過min_merge_bytes_to_use_direct_io設(shè)定的值, Clickhouse會使用直接I/O接口(O_DIRECT選項)讀取和寫入數(shù)據(jù)到磁盤. 如果設(shè)置為0, 則直接I/O被禁用, 默認值: 10M.merge_with_ttl_timeout
重復(fù)合并TTL的最小延遲時間, 單位秒, 默認值: 1 day.write_final_mark
啟用或禁用在數(shù)據(jù)部分的末尾(最后一個字節(jié)之后)寫入最后的索引標記. 默認值: 1, 不要關(guān)閉.merge_max_block_size
合并操作時, 每個塊的最大行數(shù), 默認值: 8192.storage_policy
存儲策略, 詳見Using Multiple Block Devices for Data Storage.vmin_bytes_for_wide_part, min_rows_for_wide_part
數(shù)據(jù)部分中可存儲為Wide格式的最小字節(jié)數(shù)/行數(shù). 可以設(shè)置這些設(shè)置中的一個, 兩個或全部.
1.3. 樣例說明
ENGINE?MergeTree()?
PARTITION?BY?toYYYYMM(EventDate)?
ORDER?BY?(CounterID,?EventDate,?intHash32(UserID))?
SAMPLE?BY?intHash32(UserID)?
SETTINGS?index_granularity=8192
在這個樣例中, 設(shè)置了按月份進行分區(qū).
同時設(shè)置了一個表達式 -> 按用戶ID進行Hash采樣. 這樣就可以為每個CounterID和EventDate偽隨機化(pseudorandomize)表中的數(shù)據(jù). 如果你在選擇數(shù)據(jù)時定義了一個SAMPLE子句, Clickhouse將會為用戶的子集返回一個均勻的偽隨機化的數(shù)據(jù)樣本.
index_granularity設(shè)置可以省略, 因為8192是默認值.
2. 數(shù)據(jù)存儲
一個表由按主鍵排序的數(shù)據(jù)parts組成.
當(dāng)在表中插入數(shù)據(jù)時, 會創(chuàng)建單獨的數(shù)據(jù)parts, 并對每個數(shù)據(jù)parts按主鍵進行字典排序. 例如, 如果主鍵是(CounterID, Date), 則該部分的數(shù)據(jù)會按照CounterID排序, 在每個CounterID內(nèi), 再按照Date排序.
屬于不同分片的數(shù)據(jù)會被分隔成不同的part. 在Clickhouse底層, ck合并數(shù)據(jù)parts成為更有效的存儲結(jié)構(gòu). 屬于不同分片的parts不會被merge. Merge機制并不能保證所有具有相同主鍵的行都在同一個數(shù)據(jù)parts.
數(shù)據(jù)parts可以用寬(Wide)或者緊湊(Compact)格式來存儲. 在Wide格式中, 每一列都會被存儲在磁盤的一個單獨的文件中, 在Compact格式中, 所有的列都會被存在在同一個文件中. Compact格式可以用來提高小規(guī)模和頻繁插入的性能(涉及到寫入到更少的文件中).
數(shù)據(jù)存儲格式有表引擎的min_bytes_for_wide_part和min_rows_for_wide_part參數(shù)控制. 如果數(shù)據(jù)parts的字節(jié)數(shù)小于相應(yīng)的設(shè)置項, 則該部分以Compact格式存儲, 反之以Wide格式存儲. 如果這兩個參數(shù)未被設(shè)置, 將會默認以Wide格式存儲.
每個數(shù)據(jù)part在邏輯上被劃分成顆粒(granule). 一個顆粒是Clickhouse在讀取選中數(shù)據(jù)時, 最小的不可分割的數(shù)據(jù)集單位. Clickhouse不會拆分行或者字段值, 所以每個顆?？偸前麛?shù)單位的行. 顆粒的第一行是用該行的主鍵值進行標記的. 對于每個數(shù)據(jù)part來說, Clickhouse都會創(chuàng)建一個索引文件來存儲這些標記(mark). 對于每一列而言, 無論它是否是主鍵, Clickhouse都會存儲相同的標記. 這些標記可以幫助查詢的時候直接在列文件中找到數(shù)據(jù).
顆粒的大小收到表引擎index_granularity和index_granularity_bytes參數(shù)的限制. 根據(jù)行的大小, 一個顆粒中的行數(shù)在[1, index_granularity]范圍內(nèi). 如果單行的大小大于設(shè)置值, 那么顆粒的大小可以超過index_granularity_bytes. 在這種情況下, 顆粒的大小等于行的大小.
