北京
作者 | Renato Losio
譯者 | 明知山
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/
聲明：本文由 InfoQ 翻譯，未經許可禁止轉載。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
