我们的计费流程突然变慢了。罪魁祸首是ClickHouse隐藏的瓶颈

当我们的PB级ClickHouse集群的分区更改导致关键计费作业停止时,标准指标没有显示明显的错误。这篇文章探讨了我们如何在ClickHouse的查询规划器中识别严重的锁争用,并构建上游补丁来修复它。

在Cloudflare,我们是ClickHouse的重要用户, ClickHouse是一个开源在线分析处理(OLAP)数据库。每天,我们都会向ClickHouse拨打数百万次电话,以确定用户应为其使用Cloudflare产品收取多少费用。如果我们不能及时完成这些工作,发票就很难对账。

该渠道为数亿美元的使用收入、欺诈系统等提供动力,因此延迟会产生重大的下游影响。这就是为什么在迁移后, ClickHouse中的日常聚合作业(负责确保Cloudflare的账单消失)速度放缓时,这是一个大问题。所有通常的嫌疑人看起来都很干净: I/O、内存、扫描的行、读取的零件。

当ClickHouse查询速度较慢时,我们通常会检查的所有内容似乎都是正常的。这是我们如何发现隐藏在ClickHouse内部深处的隐藏瓶颈的故事,以及我们为修复它而编写的三个补丁。设置: PB级分析平台我们使用ClickHouse在几十个集群中存储超过100 PB的数据。

为了简化许多内部团队的入职流程,我们在2022年初构建了一个名为“Ready-Analytics”的系统。前提很简单:团队可以将数据流式传输到单个大型表中,而不是设计新表。数据集由命名空间消除歧义,每个记录使用一个标准模式(例如, 20个浮点字段、20个字符串字段、时间戳和indexID )。在ClickHouse中,数据排序方式对查询性能至关重要。

这就是indexID发挥作用的地方。它是一个字符串字段,构成主键的一部分,这意味着每个单独的命名空间都可以以最适合该命名空间所有者期望运行的查询的方式对其数据进行排序。总而言之,我们得到的主键如下所示: (namespace, indexID, timestamp)。这个系统很受欢迎,有数百个应用程序使用它。