导航
在完成将公司日志数据从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引擎存储完整的日志数据~
二、表结构设计
在系列文章《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文章来源:https://www.toymoban.com/news/detail-774899.html
下回预告
由于logstash消耗的资源较高,在日志平台转战clickhouse后,引入了高效数据处理工具vector,欢迎关注后续更新的系列文章~文章来源地址https://www.toymoban.com/news/detail-774899.html
到了这里,关于「从ES到CK 04」Clickhouse表引擎选择和表结构设计的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!