从 Elastic 到 ClickHouse：日志系统性能与成本优化之路

文章目录

• • 需求背景
  • 需求目的
  • 计划完成时间
  • 阶段
  • 调研内容
  • • 日志写入链路
    • 方案设计
    • • 表结构设计
      • • 落地表（ReplicatedMergeTree）
        • 分布式表
        • Kafka 引擎表
        • 物化视图
      • 保留策略
      • 前端选型
      • • 配置ClickHouse连接信息与索引白名单
        • 配置需要切换到ClickHouse的index
    • 常见问题与解决方案
    • • 1. `offset out of range`
      • 2. 消费延迟过高
    • 成果展示
    • 实际插入情况
  • 亮点
  • 不足

需求背景

当前系统日志主要存 ElasticSearch，存在以下问题：

• 查询效率较低，尤其在高并发场景下性能瓶颈明显；
• 存储成本较高，部分日志存储冗余，压缩效果不佳；
• 查询维度较弱，难以支持多维分析与快速聚合。

ClickHouse 作为高性能列式 OLAP 引擎，在日志存储和分析方面具备显著优势，能够支持大吞吐量、高压缩比及亚秒级查询延迟。因此，计划将关键日志数据接入 ClickHouse 进行统一分析、降本增效。

需求目的

• 实现日志写入 ClickHouse，提升查询性能与响应速度；
• 支持常见的日志检索、聚合分析；
• 兼容现有日志收集流程；
• 降本增效；

计划完成时间

2025-07-31

阶段

1. Clickhouse结合日志存储调研，是否自建表？补充字段如何处理？
2. 分布式集群搭建
3. 性能优化
4. 结合监控数据展示及告警
5. 前端组件调研使用
6. 自动清理旧数据

调研内容

日志写入链路

Filebeat / Logstash ↓ Kafka ↓ ClickHouse（Kafka 引擎表 → MergeTree 表）

• Kafka 消费：ClickHouse 原生支持 Kafka 引擎，无需额外消费者；
• 数据转换：通过 Materialized View 进行字段映射与结构清洗；
• 落盘存储：使用 MergeTree 表优化查询性能与数据保留策略。

方案设计

表结构设计

落地表（ReplicatedMergeTree）

CREATE TABLE IF NOT EXISTS default.ycloud_log_local( `message` String, `host` String, `@timestamp` UInt64, `port` Int64, `secondFacility` String, `traceId` String, `logtime` String, `linenum` String,`procedure` String,`peerAddr` String, `level` String, `ck_assembly_extension` String, `orderId` String,`username` String,`spanId` String,`version` String, INDEX timestamp_index `@timestamp` TYPE minmax GRANULARITY 8192)ENGINE = ReplicatedMergeTree(\'/clickhouse/tables/{shard}/ycloud_log_local\', \'{replica}\')PARTITION BY (toYYYYMMDD(toDateTime(`@timestamp` / 1000, \'Asia/Shanghai\')), toHour(toDateTime(`@timestamp` / 1000, \'Asia/Shanghai\')))ORDER BY (intHash64(`@timestamp`))SAMPLE BY intHash64(`@timestamp`)TTL toDateTime(`@timestamp` / 1000) + INTERVAL 120 DAY DELETESETTINGS in_memory_parts_enable_wal = 0, index_granularity = 8192;

分布式表

CREATE TABLE IF NOT EXISTS default.ycloud_log_all AS default.ycloud_log_localENGINE = Distributed(\'gs_clickhouse_cluster\', default, ycloud_log_local, rand());

Kafka 引擎表

CREATE TABLE default.ycloud_log_kafka( `raw_json` String)ENGINE = KafkaSETTINGS kafka_broker_list = \'192.168.100.10:9092,192.168.100.20:9092,192.168.100.30:9092\', kafka_topic_list = \'ycloud\', kafka_group_name = \'ycloud_test_group\', kafka_format = \'JSONAsString\', kafka_num_consumers = 10, kafka_max_block_size = 1048576;

物化视图

CREATE MATERIALIZED VIEW IF NOT EXISTS default.ycloud_log_mvTO default.ycloud_log_localASSELECT JSONExtractString(raw_json, \'message\') AS message, JSONExtractString(raw_json, \'host\') AS host, toUnixTimestamp64Milli(parseDateTime64BestEffort(JSONExtractString(raw_json, \'logtime\'))) AS `@timestamp`, toInt64OrNull(JSONExtractString(raw_json, \'port\'))  AS port, JSONExtractString(raw_json, \'secondFacility\') AS secondFacility, JSONExtractString(raw_json, \'traceId\') AS traceId, JSONExtractString(raw_json, \'logtime\') AS logtime, JSONExtractString(raw_json, \'linenum\') AS linenum, JSONExtractString(raw_json, \'procedure\') AS procedure, JSONExtractString(raw_json, \'peerAddr\') AS peerAddr, JSONExtractString(raw_json, \'level\') AS level, raw_json  AS ck_assembly_extension, JSONExtractString(raw_json, \'orderId\')  AS orderId, JSONExtractString(raw_json, \'username\')  AS username, JSONExtractString(raw_json, \'spanId\')  AS spanId, JSONExtractString(raw_json, \'version\')  AS versionFROM default.ycloud_log_kafka;

保留策略

• 热数据：120 天内的日志使用主表存储；
• 清理机制：定期使用 TTL 策略清理过期分区。

前端选型

Ckibana + kibana

踩坑 Ckibana不支持8.0以上版本，官方文档写着支持Ckibana。使用时获取不到正确的时间戳字段。

部署方式采用自定义 Helm Charts，kibana 依赖Ckibana

spring: application: name: ckibanaserver: port: 8080logging: config: classpath:logback-spring.xml file: path: logsmetadata-config: hosts: 192.168.100.10:9200 headers: Authorization: ApiKey TzQ4N0VaZ0JjQWg3YWgzdw==

配置ClickHouse连接信息与索引白名单

设置ClickHouse连接信息:

curl --location --request POST \'localhost:8080/config/updateCk?url=ckUrl&user=default&pass=default&defaultCkDatabase=ops\'

配置需要切换到ClickHouse的index

curl --location --request POST \'localhost:8080/config/updateWhiteIndexList?list=index1,index2\'

⚡️: 实际使用 ES + Kibana 方式一致

常见问题与解决方案

1. offset out of range

日志：

offset reset to offset BEGINNING: fetch failed due to requested offset not available on the broker

原因：Kafka 中记录的 offset 已被删除，ClickHouse 自动回退到 earliest；

处理建议：

• 设置 kafka_auto_offset_reset = \'latest\' 避免历史 offset 回退；
• 定期清理消费组；
• 设置合理的 Kafka 数据保留时间。

2. 消费延迟过高

原因：Kafka TPS 高时 ClickHouse 消费不及时；主要出现在更添加INDEX时，TOPIC存储周期长，数据量大导致。

方案：

• 增加消费者副本（表配置 kafka_num_consumers）；
• 将大表进行拆分；
• 提前清洗复杂字段，避免落地时频繁 JSON 解析。

3.常用操作

toUnixTimestamp64Milli(now64(3)) 用于获取当前时间的 Unix 毫秒级时间戳。

## 添加字段ALTER TABLE default.gsnormal_log_local ADD COLUMN facility String AFTER level;## 删除字段ALTER TABLE default.gsnormal_log_local DROP COLUMN port;

成果展示

目标项 目标值 实际达成值 差值分析 查询效率 P95 ≤ 3s p95 1 s 性能超出预期，ClickHouse 列式存储和分区裁剪发挥了优势，查询明显更快 写入性能 QPS ≥ 10 万 QPS 实测峰值约 15 万 写入性能超额完成，Kafka 消费 + 批量 insert 提升了写入能力 存储成本 降低 ≥ 50% 实际约降低 60% 替换 ELK，去除副本冗余和冷热分层后，存储成本进一步下降

实际插入情况

亮点

• 提前规划固定字段（如 traceId、logtime、level 等）与原始 JSON 扩展字段（ck_assembly_extension）分开存储，保留日志灵活性，后期可快速应对字段变动需求，无需频繁修改表结构。
• 引入 ClickHouse TTL 自动清理策略，保障长期稳定运行。
• 使用 ReplicatedMergeTree 实现多副本同步，自动 failover 提升可用性，保证日志数据持久可靠。

不足

性能还需进一步加强，对极端写入压力的承载验证不足

七大队汽车俱乐部