ClickHouse 会放任你在大规模场景下犯错

ClickHouse Will Let You Be Wrong at Scale — matduggan.com · 9 小时前 · ⚙️ 工程

作者基于一次真实的生产级压测项目，复盘了 ClickHouse 在超出常规使用模式时的表现。背景设定相当严苛：目标是网络防火墙遥测数据，每天约 20 亿行来自多家厂商混合的 syslog 日志，在写入时解析成宽类型表，并设置 14 天的 TTL 自动过期。可视化层则要求在 Grafana 中同时完成两类任务——快速检索单条日志记录，以及在所有面板上叠加任意临时过滤条件后仍能保持流畅的即席分析。作者先给出了分层结论：走 OpenTelemetry 的标准路径时，几百个指标、每天几百万条日志和几千条链路追踪对 ClickHouse 来说毫无压力；但一旦进入自定义的复杂场景，引擎虽然极其强大，使用难度也陡然上升。整个项目的主旋律是「静默失败」：ClickHouse 像一个从不说你有错的同事，它不会报错，只会让你错得非常彻底——一条看起来正常的查询可能实际扫描了 84 倍于必要的行数；一个配置错误的过滤条件直接不生效；一个从未被路由命中的 projection 依然返回正确的结果，只是慢得多。作者坦承自己犯了大量错误，包括对难度的误判，写这篇复盘是为了给后来者踩坑警示，并且逐条认领这些错误。转折点出现在他真正理解了这个引擎的设计哲学之后：ClickHouse 永远不会主动告诉你做错了什么，你必须自己去发现错误，因此在使用任何功能之前，首先要建立验证习惯，而 system.query_log 表是最核心的排查工具。文章的核心结论是：工具的强大与易用是两回事，在非典型规模下，围绕工具建立自查和验证的工程纪律，比工具本身的性能参数更决定项目成败。

核心信息

这次压测的目标规模是每天约 20 亿行混合厂商的 syslog 防火墙日志，写入时解析为宽类型表并设置 14 天 TTL，同时要求 Grafana 仪表盘既能快速查询单条日志，又能在全部面板上叠加即席过滤器并保持响应速度，这是一个远超常规可观测性场景的严苛组合。
标准 OpenTelemetry 路径下的 ClickHouse 表现轻松：几百个指标、每天几百万条日志、几千条追踪都不构成压力；但在自定义接入路径上，引擎的强大与易用性出现了严重脱节，复杂的写法和配置问题不会以报错形式出现，而是以性能劣化的形式潜伏下来。
静默失败是整篇文章的核心教训：一条看似正常的查询可能比应有的扫描量多出 84 倍；配置错的过滤器会直接静默失效；从未被路由到的 projection 照样返回正确数值，只是查询速度大幅变慢——三种问题的共同点是没有报错，只有悄悄变差的结果。
作者给出的方法论是把验证习惯放在一切工作之前：system.query_log 是排查查询行为的核心工具，被形容为你的朋友、酒保和恐怖片里那条可爱的狗；只有在理解了 ClickHouse 从不主动纠错这一前提后，他与这个系统的磨合才真正走上正轨。

💡 为什么值得读: 一次每日 20 亿行日志的真实压测复盘，把「强大但静默失败」这个选型盲区讲得足够具体，能给所有准备上 ClickHouse 的团队省下真金白银的踩坑成本。

✍️ 小编看法: 小编看法：小编看法：这篇复盘的价值远超一篇 ClickHouse 踩坑记，它其实戳中了整个数据库选型文化里的一个盲区。我们习惯用官方基准测试和标准工作负载来评估引擎，但真实世界里真正决定成败的，恰恰是那些「非典型」路径——自定义解析、异构数据源、非常规查询模式。作者那句「ClickHouse 从不说你错」值得所有工程师刻在脑子里：低报错率不等于高正确率，一个把所有输入都吞下去的系统，反而把验证成本全部转移给了使用者。相比之下，传统数据库会因为你写了个烂执行计划而直接拒绝或者报警，这种「难伺候」其实是免费的护栏。我建议读者把这个教训泛化到任何列式存储和 OLAP 引擎上，包括那些新兴的分析型产品——性能参数只有在正确的数据布局下才成立，而数据布局是否正确，引擎自己不会告诉你。下一步值得观察的是两件事：一是 OpenTelemetry 标准路径与自定义路径之间的性能鸿沟会不会随着 ClickHouse 生态工具的成熟而收窄，这决定了它能否从「专家的引擎」变成「团队的默认选择」；二是团队层面如何制度化验证习惯，比如把 query_log 检查纳入代码评审和 CI 流程，而不是依赖某个资深工程师的个人直觉。如果你正准备把日志平台迁到 ClickHouse，这篇文章可能帮你省下几周的排查时间。

🏷️ ClickHouse, database, observability, performance