「从ES到CK 04」Clickhouse表引擎选择和表结构设计

  导航

        在完成将公司日志数据从Elasticsearch(下称ES)转战到Clickhouse后，个人认为有必要将过程记录分享。限于篇幅及便于分类组织，我会以一个系列文章的形式记录：

• 01 《Elasticsearch vs Clickhouse》
• 02 《Clickhouse的基础知识扫盲》
• 03 《​Clickhouse多分片多副本集群部署​》
• 04 《​​Clickhouse表引擎选择和表结构设计​》
• 05 《​clickhouse高效数据处理工具vector​》
• 06 《​​​​​​​​​clickhouse的数据可视化工具clickvisual​》
• 07 《kibana自定义插件跳转clickvisual》
• 08 《妙用clickvisual api实现用户自动管理》（敬请期待）

一、表引擎选择

        在系列文章《​​Clickhouse的基础知识扫盲​​》也有提到过，合并树(MergeTree)系列的表引擎被誉为Clickhouse 中最强大的表引擎，其中MergeTree引擎作为其系列内其他表引擎的基础，具有如下特性：

        √ 存储的数据按主键排序

        √ 支持分区

        √ 支持数据副本

        √ 支持数据采样

        在继承MergeTree引擎特性的基础上，衍生出如下各有特色的表引擎，满足不同场景的需求：

表引擎	说明
SummingMergeTree	该引擎继承自 MergeTree。区别在于，当合并SummingMergeTree表的数据片段时，ClickHouse会把所有具有相同主键的行合并为一行，该行包含了被合并的行中具有数值数据类型的列的汇总值。如果主键的组合方式使得单个键值对应于大量的行，则可以显著的减少存储空间并加快数据查询的速度。
ReplacingMergeTree	会删除排序键值相同的重复项以节省空间，但是它不保证没有重复的数据出现
AggregatingMergeTree	一般用来做增量数据的聚合统计，包括物化视图的数据聚合。
CollapsingMergeTree	引擎继承于 MergeTree，并在数据块合并算法中添加了折叠行的逻辑
VersionedCollapsingMergeTree	擎继承自 MergeTree 并将折叠行的逻辑添加到合并数据部分的算法中
GraphiteMergeTree	该引擎用来对 Graphite数据进行瘦身及汇总
Replicated*	数据副本，支持： ReplicatedMergeTree ReplicatedSummingMergeTree ReplicatedReplacingMergeTree ReplicatedAggregatingMergeTree ReplicatedCollapsingMergeTree ReplicatedVersionedCollapsingMergeTree ReplicatedGraphiteMergeTree

在结合我司日志平台的实际场景后，选用了ReplicatedMergeTree引擎存储完整的日志数据~

二、表结构设计

        在系列文章《​​Clickhouse的基础知识扫盲​​》也有提到过表结构的相关概念，话不多说直接上DDL，以java日志的表结构为例：

CREATE TABLE elk.java_log_local
(
    `service_name` String CODEC(ZSTD(1)),
    `server_ip` String CODEC(ZSTD(1)),
    `sys_code` String CODEC(ZSTD(1)),
    `env_type` String CODEC(ZSTD(1)),
    `class_name` String CODEC(ZSTD(1)),
    `log_level` String CODEC(ZSTD(1)),
    `thread` String CODEC(ZSTD(1)),
    `_time_nanosecond_` DateTime64(3, 'Asia/Shanghai'),
    `msg` String CODEC(ZSTD(1)),
    `exception` String CODEC(ZSTD(1)),
    `traceId` String CODEC(ZSTD(1)),
    `spanId` String CODEC(ZSTD(1)),
    INDEX idx_msg msg TYPE tokenbf_v1(30720, 2, 0) GRANULARITY 1
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/java_log', '{replica}')
PARTITION BY toYYYYMMDD(_time_nanosecond_)
ORDER BY (_time_nanosecond_, sys_code, env_type, service_name)
-- TTL toDateTime(_time_nanosecond_) + toIntervalDay(14)
SETTINGS storage_policy = '51cto', index_granularity = 8192;

表结构设计说明：

属性	语句	说明
索引	INDEX idx_msg msg TYPE tokenbf_v1(30720, 2, 0) GRANULARITY 1	msg字段为日志详情，涉及长文本模糊匹配的场景，故针对该字段建立跳数索引
主键	-	无
排序(必填)	ORDER BY (time_nanosecond, sys_code, env_type, service_name)	结合业务场景，根据字段使用频率、优先级，由高至低组合
压缩方式	CODEC(ZSTD(1))	此处选用字符串字段常用的ZSTD压缩算法，压缩级别为1
分区	PARTITION BY toYYYYMMDD(time_nanosecond)	此处选用日期作为分区依据，注意避免过于精细的分区方案，以免影响整体性能
数据生命周期	TTL toDateTime(time_nanosecond) + toIntervalDay(14)	考虑到生命周期可能会根据实际情况而变动，在生产环境中我选用move/delete partition的方式来控制数据生命周期。因为ttl值设定后修改，会引发全表扫描，故设计表结构时需考虑清楚是否引入ttl设置
存储策略	storage_policy = '51cto'	此处采用多级存储，将数据按策略分别存在ssd、hdd和oss，具体可参考《​​Clickhouse多分片多副本集群部署​​》

三、参考资料

• Clickhouse

        ​​https://clickhouse.com/docs/zh​​

下回预告

        由于logstash消耗的资源较高，在日志平台转战clickhouse后，引入了高效数据处理工具vector，欢迎关注后续更新的系列文章~