Cloudflare 最近说明了其计费管道变慢的原因，问题最终追溯到 ClickHouse 查询规划阶段的锁竞争问题。团队针对该瓶颈进行了性能分析，并给 ClickHouse 打上补丁，将独占锁替换为共享锁，去掉每个查询对数据分片列表的复制操作，并优化了分片过滤逻辑。
Cloudflare 的计费管道为计费和反欺诈系统提供支撑，因此延迟会影响多个下游服务。在一次迁移大幅增加了数据分片数量后，ClickHouse 中的每日聚合任务明显变慢，尽管 I/O、内存使用量和扫描行数等标准性能指标看起来正常。
平均 SELECT 查询耗时(来源：Cloudflare 博客)
Cloudflare 在 ClickHouse 尚未支持内置数据过期功能时便开始使用该数据库，并管理着数百 PB 的数据。因此，Cloudflare 自行实现了数据保留策略，将 Ready-Analytics 表中的数据拆分为按天分区，并删除超过 31 天的数据。Cloudflare 高级分布式系统工程师 James Morrison 和 Christian Endres 解释说：
这套系统非常受欢迎，有数百个应用在使用。到 2024 年 12 月，它已经增长到超过 2PiB 的数据，每秒摄入数百万行。但它存在一个关键缺陷：数据保留策略。
在迁移过程中，Cloudflare 修改了 ClickHouse 的分区方案，加入了客户命名空间，从而可以按租户单独管理数据保留策略。ClickHouse 是一个开源分析型数据库，专为大规模数据的快速分析而设计，广泛应用于日志、指标统计、数据分析及实时报表场景。团队原本预计采用新分片方式后，单条查询访问的数据分片数量不会发生变化，但 Morrison 和 Endres 梳理出了问题及其根本原因：
大量时间被消耗在查询规划阶段。这是执行前的阶段，ClickHouse 会在这个阶段确定需要读取哪些数据分片……采样到的 CPU 时间中有 45% 花在一个叫作 filterPartsByPartition 的函数上……这个问题并不是 CPU 密集型任务导致，而是因为出现了严重的锁竞争。超过一半的查询耗时都花在等待获取一个互斥锁（MergeTreeData）上。
团队通过三项优化解决运行缓慢的问题：给 ClickHouse 打补丁，将独占锁替换为共享锁，同时取消每次查询对完整分片列表的复制操作。此外，他们还优化了分片过滤逻辑，不再每次都遍历完整列表。这些调整从整体上显著降低了查询延迟，并在分片数量持续增长时也能保持稳定的性能。Morrison 和 Endres 总结道：
2026 年 3 月部署该补丁后，查询耗时下降了 50%。更重要的是，这终于打破了查询耗时与分片数量之间的关联性。
(来源：Cloudflare 博客)
Reddit 上的大多数从业者关注的是最近的裁员事件和“单张大表”架构设计，而 Park Place Technologies 的现场工程师 Edydh Marquez Avila 则在 LinkedIn 上评论道：
Cloudflare 针对 ClickHouse 的这次排查也充分提醒我们，现代基础设施的故障越来越多地发生在协调层，而不是资源限制方面……这一现象带来的启发也不止局限于 ClickHouse 本身……仅靠高层监控数据已无法定位大规模并发系统的问题，底层执行链路的可视能力依旧至关重要。
虽然这些修复稳定了查询性能并解决了计费变慢的问题，但底层分区设计随着数据分片数量的持续增长仍可能带来运维问题。作者表示，不断增长的元数据负载也对负责管理 ClickHouse 集群协调的 ZooKeeper 造成了影响，团队将目前状态形容为“脆弱的平衡”，并对这套架构的长期可持续性提出了质疑。
Cloudflare 已将这些修改贡献给了 ClickHouse 项目，已被上游合并，并从 25.11 版本 开始可用。
查看英文原文：https://www.infoq.com/news/2026/06/cloudflare-clickhouse-bottleneck/
