摘要：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 组织分布与排序：
CREATETABLEagent_observations(tsDATETIMENOTNULL,trace_idVARCHAR(64),observation_idVARCHAR(64),seq_noINT,levelVARCHAR(16),payload VARIANT,msg STRING,INDEXidx_msg(msg)USINGINVERTED PROPERTIES("parser"="unicode"))ENGINE=OLAPDUPLICATEKEY(trace_id,observation_id,seq_no)AUTOPARTITIONBYRANGE(date_trunc(ts,'day'))()DISTRIBUTEDBYHASH(trace_id)BUCKETS16PROPERTIES("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 回放SELECTtrace_id,seq_no,ts,msgFROMagent_observationsWHEREsearch('level:ERROR AND msg:"tool invocation timeout"')ANDts>=NOW()-INTERVAL6HOURORDERBYtrace_id,seq_noLIMIT500;search()返回 BOOLEAN，作为 WHERE 谓词使用，可直接参与 JOIN、窗口函数与子查询；DSL 内显式布尔运算优先级最高。
2.4 成本差异落在哪一层
日志场景的成本主要由三块构成：存储占用、计算节点规模、运维投入。存储占用上两者压缩率同梯队，差异有限；真正拉开差距的是计算节点规模——并发上限决定了扛住同样查询压力需要多少节点，节点数直接乘进硬件、机位与运维。网易云音乐那套平台最后是机器数量减少 50%，每年节省数百万，收益来自节点规模而不是存储单价。
因此长周期留存的成本优化应优先做冷热分层：把超过保留窗口的分区下沉到对象存储，单价通常远低于块存储，这一步的收益比在写入侧抠参数大得多。
2.5 写入与压缩不构成差异
批量写入吞吐与压缩率上，ClickHouse 与 Doris 属于同一梯队。真正分化的是并发、检索、trace 回放与多表 JOIN。
三、怎么做：建表、检索与验证
3.1 常规日志表的建法
CREATETABLEapp_log(tsDATETIME,serviceVARCHAR(64),levelVARCHAR(16),msgTEXT)ENGINE=OLAPDUPLICATEKEY(ts)PARTITIONBYRANGE(ts)()DISTRIBUTEDBYRANDOM BUCKETS250PROPERTIES("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");-- 检索字段建倒排索引，中文场景指定分词器与短语支持ALTERTABLEapp_logADDINDEXidx_msg(msg)USINGINVERTED PROPERTIES("parser"="chinese","support_phrase"="true");日志写入没有明显业务 Key 时用随机分桶避免倾斜，分桶数约为集群磁盘总数的 3 倍；需要按 trace 回放时改用上节 2.3 的 HASH 分布。
3.2 检索写法与易错点
-- 短语检索：走倒排索引，避免 LIKE 全表扫描SELECTts,service,level,msgFROMapp_logWHEREts>=NOW()-INTERVAL1HOURANDmsg MATCH_PHRASE'timeout order'ORDERBYtsDESCLIMIT100;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 验证步骤
-- 确认检索是否走倒排索引EXPLAINSELECT*FROMapp_logWHEREmsg MATCH_PHRASE'timeout';-- 核对容量与分区SHOWDATAFROMapp_log;SHOWPARTITIONSFROMapp_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 的文本不保证匹配 | 不等同对原始日志执行 SQLREGEXP，改用 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）
