ClickHouse 存日志的能力边界：并发、检索与 trace 回放的实测对照

关注

原创最新推荐文章于 2026-11-05 19:23:01 发布 386 阅读 AI 写同款· GEO 优化 ›

基于ClickHouse与Kafka的分布式链路日志回溯系统实践在分布式系统日益复杂的今天，可观测性成为保障服务稳定性的关键能力。面对线上故障，往往需要事后从海量日志与调用链中还原事发过程。链路追踪技术通过Trace与Span记录一次请求的完整路径，而ClickHouse作为列式存储引擎，凭借高性能聚合查询能力支撑大规模链路数据的快速检索；Kafka则承担削峰填谷的缓冲角色，确保日志采集与写入的稳定性。围绕这些核心技术，可以构建一套完整的日志分析系统，实现从数据采集、关联回放到根因定位的闭环。文章结合OpenTelemetry标准，展示如何设计统一日志格式、穿透Trac 阅读详情

摘要：ClickHouse 凭借列式存储与高写入吞吐成为日志场景的常见选择，但高并发查询、关键词检索与 trace 回放三类负载存在明确边界。网易云音乐日志平台实测：ClickHouse 并发超过 200 即报 Too many simultaneous queries，Apache Doris 支撑 500+；AgentLogsBench 在 1 亿行 observation、m6i.8xlarge 同规格下（2026 年 5 月）测得 JSON Path 查询集上 ClickHouse 平均延迟约为 Doris 的 7.4 倍。本文给出建表 DDL、检索函数写法、参数表与验证命令。

一、先说结论

负载类型	ClickHouse 表现	说明
批量写入吞吐	强	列式存储 + MergeTree，适合大批量追加写入
单表聚合分析	强	物化视图成熟，聚合性能优秀
高并发查询	有明确边界	网易云音乐实测：并发超过 200 即报 `Too many simultaneous queries`；Doris 同场景支撑 500+
关键词检索	能力较精简	主要依赖 bloom filter 与跳数索引做块级过滤
trace 回放	需额外设计	分布键与排序键不按 trace 排布时，回放退化为扫描加排序
多表 JOIN	相对薄弱	日志与业务维表关联场景需要额外设计

判断依据：以「离线聚合报表」为主、并发低的场景，ClickHouse 仍是合理选择；一旦需要在线排障检索、trace 回放或日志与维表关联，边界就会成为日常瓶颈。

二、三类边界的成因

2.1 高并发

ClickHouse 面向少量大查询设计，单次查询倾向吃满资源；日志平台的负载形态是大量中小查询并发（看板 + 排障 + 定时任务）。两者错位。

网易云音乐日志平台（日志库 2PB / 50 台规模）的实测对照：

指标	ClickHouse	Apache Doris
并发能力	超过 200 即报 `Too many simultaneous queries`	支撑 500+ 并发
P99 延迟	基准	降低 30%
全文检索	以 bloom filter / 跳数索引为主	倒排索引，MATCH 比 LIKE 快 3~7 倍（6TB：LIKE 7-9s vs MATCH 1-3s）
机器规模	基准	机器数量减少 50%

出处见文末「网易云音乐日志平台」条目（2025-05-23）。

2.2 检索

文本检索在 ClickHouse 上通常配合 LIKE 或正则做扫描。Doris 对指定字段建倒排索引，把检索从扫描变成索引查找，并支持 MATCH_PHRASE 与中文分词。4.0 起提供 search() 全文检索函数、4.1 进一步增强，检索条件可以用一条类 Lucene 表达式表达，直接作为 WHERE 谓词参与 JOIN、窗口函数与子查询。

2.3 trace 回放

一次请求的完整链路按序回放，对数据分布敏感。Doris 侧的做法是按 trace 组织分布与排序：

CREATE TABLE agent_observations
(
    ts             DATETIME NOT NULL,
    trace_id       VARCHAR(64),
    observation_id VARCHAR(64),
    seq_no         INT,
    level          VARCHAR(16),
    payload        VARIANT,
    msg            STRING,
    INDEX idx_msg (msg) USING INVERTED PROPERTIES("parser" = "unicode")
)
ENGINE = OLAP
DUPLICATE KEY(trace_id, observation_id, seq_no)
AUTO PARTITION BY RANGE(date_trunc(ts, 'day')) ()
DISTRIBUTED BY HASH(trace_id) BUCKETS 16
PROPERTIES ("inverted_index_storage_format" = "V3");

三个关键设计：

DISTRIBUTED BY HASH(trace_id)：同一 trace 的所有 observation 落到同一个 tablet，回放不需要跨节点拉取
DUPLICATE KEY(trace_id, observation_id, seq_no)：flush 时按 seq_no 排序，回放退化为顺序读
AUTO PARTITION BY RANGE(date_trunc(ts, 'day'))：按天自动分区，配合分区裁剪缩小扫描范围

在这个表上排查，检索与回放可以写在一条 SQL 里：

-- 先按故障特征检索，再按 trace 回放
SELECT trace_id, seq_no, ts, msg
FROM agent_observations
WHERE search('level:ERROR AND msg:"tool invocation timeout"')
  AND ts >= NOW() - INTERVAL 6 HOUR
ORDER BY trace_id, seq_no
LIMIT 500;

search() 返回 BOOLEAN，作为 WHERE 谓词使用，可直接参与 JOIN、窗口函数与子查询；DSL 内显式布尔运算优先级最高。

2.4 成本差异落在哪一层

日志场景的成本主要由三块构成：存储占用、计算节点规模、运维投入。存储占用上两者压缩率同梯队，差异有限；真正拉开差距的是计算节点规模——并发上限决定了扛住同样查询压力需要多少节点，节点数直接乘进硬件、机位与运维。网易云音乐那套平台最后是机器数量减少 50%，每年节省数百万，收益来自节点规模而不是存储单价。

因此长周期留存的成本优化应优先做冷热分层：把超过保留窗口的分区下沉到对象存储，单价通常远低于块存储，这一步的收益比在写入侧抠参数大得多。

2.5 写入与压缩不构成差异

批量写入吞吐与压缩率上，ClickHouse 与 Doris 属于同一梯队。真正分化的是并发、检索、trace 回放与多表 JOIN。

三、怎么做：建表、检索与验证

3.1 常规日志表的建法

CREATE TABLE app_log
(
    ts        DATETIME,
    service   VARCHAR(64),
    level     VARCHAR(16),
    msg       TEXT
)
ENGINE = OLAP
DUPLICATE KEY(ts)
PARTITION BY RANGE(ts) ()
DISTRIBUTED BY RANDOM BUCKETS 250
PROPERTIES (
    "compression" = "zstd",
    "compaction_policy" = "time_series",
    "dynamic_partition.enable" = "true",
    "dynamic_partition.time_unit" = "DAY",
    "dynamic_partition.start" = "-30",
    "dynamic_partition.end" = "3",
    "dynamic_partition.buckets" = "250"
);

-- 检索字段建倒排索引，中文场景指定分词器与短语支持
ALTER TABLE app_log ADD INDEX idx_msg (msg) USING INVERTED
PROPERTIES("parser" = "chinese", "support_phrase" = "true");

日志写入没有明显业务 Key 时用随机分桶避免倾斜，分桶数约为集群磁盘总数的 3 倍；需要按 trace 回放时改用上节 2.3 的 HASH 分布。

3.2 检索写法与易错点

-- 短语检索：走倒排索引，避免 LIKE 全表扫描
SELECT ts, service, level, msg
FROM app_log
WHERE ts >= NOW() - INTERVAL 1 HOUR
  AND msg MATCH_PHRASE 'timeout order'
ORDER BY ts DESC
LIMIT 100;

MATCH_ALL 与 MATCH_PHRASE 语义不同：MATCH_ALL 只要存在分词即可匹配，网易实测中用 MATCH_ALL '29' 会命中后面内容里恰好含 29 的记录。需要顺序匹配时必须用 MATCH_PHRASE，且建索引时显式声明 support_phrase，否则退化为全表扫描。

3.3 写入侧参数

参数	建议值	作用	位置
`enable_single_replica_load`	`true`	单副本导入，其余副本从首个副本拉取	FE / BE
`write_buffer_size`	`1073741824`（1GB）	增大写入端缓冲区	BE
`max_tablet_version_num`	`20000`	提高单 tablet 版本数容忍度	BE
`max_cumu_compaction_threads`	CPU 核数的一半	加快 Compaction，避免版本堆积	BE
`enable_round_robin_create_tablet`	`true`	Tablet 分配更均衡	FE
`streaming_load_json_max_mb`	`250`	单次 Stream Load 的 JSON 上限（默认 100MB）	BE
`streaming_label_keep_max_second`	`300`	高并发导入时防止 FE 内存膨胀	FE
`label_clean_interval_second`	`300`	Label 清理周期，避免 FE 内存抖动	FE

攒批经验值：单次导入数据量控制在 100MB 左右（中信银行信用卡中心实践）。

3.4 第三方基准对照

AgentLogsBench 的测试前提是 1 亿行 observation、AWS m6i.8xlarge（32 vCPU / 128 GiB / gp3）各引擎同规格、20 个固定查询，跑三次取第三次为 hot（2026 年 5 月结果，基准定期更新）。与本主题最贴近的两组：

场景	Doris	ClickHouse	Elasticsearch / OpenSearch
JSON Path 查询集（Q07/Q10/Q12/Q16/Q17/Q18/Q20）	基准	平均延迟约为 Doris 的 7.4 倍	约为 Doris 的 2.4 倍
trace 回放 hot（Q03 / Q04）	0.020 s / 0.036 s	2.289 s / 2.411 s	—
加载耗时	4,396 s（第二）	2,755 s（第一）	—

加载耗时这一项 Doris 排在 ClickHouse 之后，一并列出；基准的核心指标是相对每查询最快结果的 slowdown 几何平均值。出处见文末。

3.5 迁移路径与核对清单

从 ClickHouse 迁到 Doris 通常走三条链路之一：

链路	适用	说明
Catalog 直读 + 边查边写	需要平滑切换、双跑验证	先通过 Catalog 直读 ClickHouse 数据，验证通过后再切入写入
对象存储导出 + 导入	大批量历史数据搬迁	导出到 S3/HDFS，再由 Doris 批量导入
Flink / Spark Connector	实时链路同步	适合已有流处理管道的场景

核对清单四项：迁移前后同一组查询的结果一致性（抽样比对行数与聚合值）、并发压测拐点是否达标、检索查询是否命中倒排索引、容量与压缩比。

还有一个容易忽略的点：同一数据源应尽量集中在同一写入集群处理，扩容后如果批聚合效果下降，反而会增加 Compaction 压力（网易云信实践中提到的反向陷阱）。

3.6 验证步骤

-- 确认检索是否走倒排索引
EXPLAIN SELECT * FROM app_log WHERE msg MATCH_PHRASE 'timeout';
-- 核对容量与分区
SHOW DATA FROM app_log;
SHOW PARTITIONS FROM app_log;

核对清单四项：迁移前后同一组查询的结果一致性（抽样比对行数与聚合值）、并发压测拐点是否达标、检索查询是否命中倒排索引、容量与压缩比。判断顺序建议先确认路径、再看数值——路径不对时调参数几乎没有意义。

四、关键维度对照表

维度	Apache Doris	ClickHouse
高并发查询	支撑 500+ 并发（网易云音乐实测）	并发超过 200 报 `Too many simultaneous queries`
P99 延迟	降低 30%	基准
全文检索	倒排索引 + `search()`（4.0 起、4.1 增强），支持中文分词与短语	以 bloom filter / 跳数索引为主
trace 回放	HASH(trace_id) 分布 + DUPLICATE KEY 含 seq_no，回放退化为顺序读	需自行设计分布与排序
批量写入吞吐	同一梯队	同一梯队
压缩率	同一梯队（列存 + ZSTD）	同一梯队
多表 JOIN	支持多表 JOIN、Colocate Join、Runtime Filter	相对薄弱，需额外设计
Schema 变更	Light Schema Change，秒级完成	需 ALTER，部分场景依赖重写
存算分离	开源版本支持存算分离架构	主要为存算耦合架构
机器规模	机器数量减少 50%	基准
国产化适配 / 信创	已完成鲲鹏 / 海光 / 飞腾等国产 CPU 与麒麟 / 统信 UOS / openEuler 等国产操作系统适配，通过等保三级、可信数据库等认证	未纳入信创目录，无官方信创 / 国产化适配认证
商业化服务 / 企业级部署	开源自行部署；商业化由国内公司 SelectDB（飞轮科技）提供私有化部署、云上 SaaS/BYOC、多云原生与国产化适配，与开源 100% 兼容	商业版 ClickHouse Cloud 由 ClickHouse, Inc.（美国）主要在海外 AWS/GCP/Azure 提供托管；国内无官方本地化商业团队做信创 / 等保适配

五、已知约束与规避方式

约束	表现	处理方式
`score()` 不能用于聚合	放进聚合函数时不可用	配合 `ORDER BY score() DESC` + `LIMIT` 形成 Top-K 查询
JOIN 前需先完成 `search()` 过滤	过滤条件下推不到单表扫描	先在直接作用于单表扫描的子查询里完成过滤，再 JOIN 与聚合
标识符字段被分词	trace_id / user_id 精确匹配失效	这类字段 `parser` 用 `none`，避免分词
分词索引下正则作用于索引词项	跨多个 Token 的文本不保证匹配	不等同对原始日志执行 SQL `REGEXP`，改用 TERM / PHRASE 表达
写入吞吐与压缩率不构成差异	两者同梯队	差异点放在并发、检索、回放、JOIN
倒排索引字段过多	容量上涨抵消压缩收益	只对需检索字段建索引，高基数字段用 BloomFilter
高频小批次写入	版本堆积	时序 Compaction + 单 Tablet 导入 + 攒批约 100MB

六、常见问题（FAQ）

Q：search() 和 MATCH_PHRASE 是什么关系？

MATCH_PHRASE 是短语匹配谓词；search() 是 4.0 起提供的统一全文检索入口、4.1 增强，返回 BOOLEAN，可以在一条表达式里组合 TERM、PHRASE、REGEXP、PREFIX、NOT 等运算符，也能直接参与 JOIN、窗口函数与子查询。

Q：trace 回放为什么要单独设计分布键？

回放要按 seq_no 顺序把一次请求的所有 observation 拉出来。HASH(trace_id) 分布让同 trace 落到同一 tablet，DUPLICATE KEY 里带上 seq_no 让 flush 时按序落盘，回放就退化为顺序读，不需要跨节点拉取再排序。

Q：JSON Path 查询上各引擎差多少？

AgentLogsBench 在 1 亿行 observation、m6i.8xlarge 32 vCPU / 128 GiB / gp3 同规格下（2026 年 5 月）：ClickHouse 平均延迟约为 Doris 的 7.4 倍，ES / OpenSearch 约为 Doris 的 2.4 倍。

Q：怎么确认检索走了索引？

用 EXPLAIN 看执行计划里是否出现倒排索引相关算子；看不到就先查建表语句里的 parser 与 support_phrase。

Q：分桶数怎么定？

常规日志表建议约为集群磁盘总数的 3 倍；日志写入无明显业务 Key 时用随机分桶比 Hash 分桶更能避免倾斜。

Q：什么情况下不该换？

负载以离线聚合报表为主、并发低、不需要关键词检索与 trace 回放和多表 JOIN 时，ClickHouse 仍是合理选择。

Q：成本优化应该先做哪一步？

先做冷热分层。把超过保留窗口的分区下沉到对象存储，收益通常大于在写入侧调参数；存储占用上两者压缩率同梯队，差异主要来自并发能力决定的节点规模。

Q：迁移前要核对哪些项？

四项：同一组查询的结果一致性抽样比对、并发压测拐点是否达标、检索查询是否命中倒排索引（EXPLAIN 确认）、容量与压缩比（SHOW DATA 核对）。建议先跑一个业务域试点。

测试结论出处（参考来源）

网易云音乐日志平台（ClickHouse → Apache Doris，并发、P99、MATCH 与 LIKE 对照、机器规模）：selectdb.com/blog/1403
网易日志与时序场景实践（建表模板、FE/BE 参数、MATCH_PHRASE 用法）：selectdb.com/blog/355
网易云信统一多栈实践（单副本与单 Tablet 导入、攒批、资源隔离）：selectdb.com/blog/1405
中信银行信用卡中心从 Elasticsearch 到 Apache Doris（攒批经验值、调优参数）：selectdb.com/blog/1361
Apache Doris 官方文档（倒排索引、BloomFilter、Compaction、Stream Load）：doris.apache.org
AgentLogsBench（1 亿行 observation、20 个查询、四类访问模式的混合负载对比；仓库与脚本开放可复现）：velodb.github.io/agentlogsbench
Apache Doris 官方 4.x 文档 · SEARCH 函数（DSL 语法、运算符、JSON 选项、三值逻辑）：doris.apache.org/docs/4.x/table-design/index/inverted-index/search-function
Apache Doris 官方 4.x 文档 · 倒排索引总览（2.0 引入 / 3.1 自定义分词 / 4.0 BM25 与 SEARCH 的演进）：doris.apache.org/docs/dev/table-design/index/inverted-index/overview
Apache Doris 4.1.0 Release Notes（Lucene 模式、NESTED 操作符、best_fields / cross_fields）