TUNANのBlogHomeArchivesTagsCategories
ClickHouse MergeTree原理
|ClickHouse
Word count: 2.1k|Reading time: 6 min

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

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

主要的功能点:

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

    这允许用户可以创建一个小型的稀疏索引, 有利于更快的在表中找到索要的数据.

  • 如果partitioning key被设置, 分片(partitions)可以被使用.

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

  • 数据副本机制支持(Replication)

    ReplicatedMergeTree并引擎提供了数据副本机制.

  • 支持数据采样

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

创建表

建表语句

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, ...]

参数说明

  • ENGINE: 指定该表所使用的的引擎. 如果引擎需要一些具体的参数, 需要进行相应的设置, MergeTree引擎不需要, 例如ReplicatedMergeTree:

    Copy ENGINE=ReplicatedMergeTree('/clickhouse/tables/#_tenant_id_#/#__appname__#/#_at_date_#/{shard}/hits', '{replica}')

  • ORDER BY: 按指定字段进行排序

    支持设置的值为元组(一个列名或任意多字段表达式), 例如:

    Copy 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类型的字段作为一个结果值, 例如:

    Copy 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格式的最小字节数/行数. 可以设置这些设置中的一个, 两个或全部.

样例说明

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是默认值.

数据存储

一个表由按主键排序的数据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. 在这种情况下, 颗粒的大小等于行的大小.

Author: Tunan
Link: http://yerias.github.io/2020/12/15/clickhouse/10/
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.
ClickHouse