Clickhouse - MergeTree原理

MergeTree引擎以及隶属于MergeTree引擎族的所有引擎是Clickhouse表引擎中最重要, 最强大的引擎.

MergeTree引擎族中的引擎被设计用于将大量数据写入表中. 这些数据被快速的写入每个表的每个part, 然后在Clickhouse底层会进行多个parts的合并(merge). 这种形式的处理比在插入过程中不断重写存储中的数据要高效得多.

主要的功能点:

存储按主键(primary key)排序的数据.

这允许用户可以创建一个小型的稀疏索引, 有利于更快的在表中找到索要的数据.
如果partitioning key被设置, 分片(partitions)可以被使用.

Clickhouse支持某些带分区的操作, 对于同一份数据进行处理, 带有分区的操作会比一般操作更有效. 当在查询语句中指定了分区后, Clickhouse会根据分区信息来进行数据的切分, 这样极大程度上提升了查询的性能.
数据副本机制支持(Replication)

ReplicatedMergeTree并引擎提供了数据副本机制.
支持数据采样

如果必要, 可以在表中设置数据采样方式.

1. 创建表

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. 参数说明

ENGINE: 指定该表所使用的的引擎. 如果引擎需要一些具体的参数, 需要进行相应的设置, MergeTree引擎不需要, 例如ReplicatedMergeTree:
```
ENGINE=ReplicatedMergeTree('/clickhouse/tables/#_tenant_id_#/#__appname__#/#_at_date_#/{shard}/hits', '{replica}')
```
ORDER BY : 按指定字段进行排序

支持设置的值为元组(一个列名或任意多字段表达式), 例如:
```
ORDER BY (CounterID, EventDate)
```
如果创建表的时候, 没有使用PRIMARY KEY修饰词来显式指定主键, 那么Clickhouse会将ORDER BY指定的字段作为主键处理.

如果该表不需要排序, 可以使用ORDER BY tuple()语法.
PARTITION BY: 指定分区字段, 可选

分区字段一般是一个Date类型或者DateTime类型的字段. 如果想按照月进行分区, 可以使用toYYYYMM(date_column)表达式, 那么分区字段的格式就是YYYYMM.
PAIMARY KEY: 主键, 可选

默认情况下, 在Clickhouse中主键都是和排序字段(ORDER BY 子句指定字段)是一致的, 所以在大多数情况下, 不需要单独指定主键. 如果需要两者不一致, 详情可见differs from the sorting key.
SAMPLE BY: 取样表达式, 可选

如果使用了SAMPLE BY子句, 那么SAMPLE BY指定的字段必须是主键(或排序字段)所包含的字段. 例如:
```
SAMPLE BY intHash32(USERID)

ORDER BY (CounterID, EventDate, intHash32(UserID))
```
TTL: 一些被指定的规则, 涉及存储数据行的存储时长, 以及确定数据parts的自动移除逻辑. 可选

TTL表达式必须包含一个Date类型或者DateTime类型的字段作为一个结果值, 例如:
```
TTL date + INTERVAL 1 DAY
```
这种类型的规则DELETE|TO DISK 'xxx'|TO VOLUME 'xxx'指定了当表达式条件被满足时对数据parts处理的操作: 删除过期的行, 移除数据parts(如果该数据parts中所有的行都满足条件)到指定的位置TO DISK 'XXX'.规则的默认类型是DELETE. 可以指定多个规则组成一条表达式, 但是DELETE规则不成超过一条.

查看更多细节: TTL for columns and tables.
SETTINGS: 设置MergeTree引擎的附加的参数, 可选
- index_graularity
  
  索引标记之间的最大数据行数. 默认值: 8192.
- index_graularity_bytes
  
  数据颗粒的最大大小, 单位bytes, 默认值: 10MB. 若要仅按行数限制颗粒大小, 请设置为0(不推荐).
- min_index_granularity_bytes
  
  数据颗粒的最小大小, 单位bytes, 默认值: 1024b. 该值是为了防止意外创建index_graularity_bytes值很低的表.
- enable_mixed_granularity_parts
  
  同样是设置数据颗粒的最大大小, 该参数用于过渡取代index_graularity_bytes. 在v19.11版本前, 只有index_granularity用于控制颗粒大小.当查询数据涉及到大量的行(几十或几百兆)时, index_granularity_bytes参数提高了Clickhouse的性能. 如果你的表拥有大量的行时, 可以为表启用这个参数来提高查询的性能.
- use_minimalistic_part_header_in_zookeeper
  
  在Zookeeper中数据parts_headers存储的方式. 如果设置为1, 则Zookeeper中存储的数据较少, 具体可以参考setting description.
- min_merge_bytes_to_use_direct_io
  
  使用直接I/O访问存储磁盘所需的merge操作的最小数据量. merge数据parts时, Clickhouse会计算所有要合并的数据的总存储空间, 如果超过min_merge_bytes_to_use_direct_io设定的值, Clickhouse会使用直接I/O接口(O_DIRECT选项)读取和写入数据到磁盘. 如果设置为0, 则直接I/O被禁用, 默认值: 10M.
- merge_with_ttl_timeout
  
  重复合并TTL的最小延迟时间, 单位秒, 默认值: 1 day.
- write_final_mark
  
  启用或禁用在数据部分的末尾(最后一个字节之后)写入最后的索引标记. 默认值: 1, 不要关闭.
- merge_max_block_size
  
  合并操作时, 每个块的最大行数, 默认值: 8192.
- storage_policy
  
  存储策略, 详见Using Multiple Block Devices for Data Storage.
- min_bytes_for_wide_part, min_rows_for_wide_part
  
  数据部分中可存储为Wide格式的最小字节数/行数. 可以设置这些设置中的一个, 两个或全部.

1.3. 样例说明

ENGINE MergeTree()

PARTITION BY toYYYYMM(EventDate)

ORDER BY (CounterID, EventDate, intHash32(UserID))

SAMPLE BY intHash32(UserID)

SETTINGS index_granularity=8192

在这个样例中, 设置了按月份进行分区.

同时设置了一个表达式 -> 按用户ID进行Hash采样. 这样就可以为每个CounterID和EventDate伪随机化(pseudorandomize)表中的数据. 如果你在选择数据时定义了一个SAMPLE子句, Clickhouse将会为用户的子集返回一个均匀的伪随机化的数据样本.

index_granularity设置可以省略, 因为8192是默认值.

2. 数据存储

一个表由按主键排序的数据parts组成.

当在表中插入数据时, 会创建单独的数据parts, 并对每个数据parts按主键进行字典排序. 例如, 如果主键是(CounterID, Date), 则该部分的数据会按照CounterID排序, 在每个CounterID内, 再按照Date排序.

属于不同分片的数据会被分隔成不同的part. 在Clickhouse底层, ck合并数据parts成为更有效的存储结构. 属于不同分片的parts不会被merge. Merge机制并不能保证所有具有相同主键的行都在同一个数据parts.

数据parts可以用宽(Wide)或者紧凑(Compact)格式来存储. 在Wide格式中, 每一列都会被存储在磁盘的一个单独的文件中, 在Compact格式中, 所有的列都会被存在在同一个文件中. Compact格式可以用来提高小规模和频繁插入的性能(涉及到写入到更少的文件中).

数据存储格式有表引擎的min_bytes_for_wide_part和min_rows_for_wide_part参数控制. 如果数据parts的字节数小于相应的设置项, 则该部分以Compact格式存储, 反之以Wide格式存储. 如果这两个参数未被设置, 将会默认以Wide格式存储.

每个数据part在逻辑上被划分成颗粒(granule). 一个颗粒是Clickhouse在读取选中数据时, 最小的不可分割的数据集单位. Clickhouse不会拆分行或者字段值, 所以每个颗粒总是包含整数单位的行. 颗粒的第一行是用该行的主键值进行标记的. 对于每个数据part来说, Clickhouse都会创建一个索引文件来存储这些标记(mark). 对于每一列而言, 无论它是否是主键, Clickhouse都会存储相同的标记. 这些标记可以帮助查询的时候直接在列文件中找到数据.

颗粒的大小收到表引擎index_granularity和index_granularity_bytes参数的限制. 根据行的大小, 一个颗粒中的行数在[1, index_granularity]范围内. 如果单行的大小大于设置值, 那么颗粒的大小可以超过index_granularity_bytes. 在这种情况下, 颗粒的大小等于行的大小.