Rewinding the exponential: How we keep hardware usage down

逆转指数增长：我们如何降低硬件使用率 | Cloudflare 博客

post

数据

工程

基础设施

2026年10月13日

逆转指数增长：我们如何降低硬件使用率

Cathy Chi、Sergey Nuzhdin 和 Christian Endres

12分钟阅读

复制链接

超过20%的互联网流量经过Cloudflare网络，我们的数据团队负责将全球网络中的数据（以及更多内容）传输到相应的中心数据中心的数据管道。Cloudflare网络是一个全球分布的系统，支持数万台服务器。驱动Cloudflare日志、SQL API、可观测性、内部分析等功能的数据流经此网络，并通过我们的数据管道为客户提供服务。

今年5月，我们每秒处理约20亿个事件的数据交付。这包括客户流量以及来自内部团队发送的数据。年复一年，我们面对同样的问题——指数级的流量增长与线性的硬件增长之间的矛盾。我们必须应对这种增长，以控制资源成本。在过去五年中，我们通过各种改进，使硬件分配与数据量增长的比率相当于推迟了两年半的硬件扩容。本文将详细介绍这些改进：2022年拆分单一数据模式、2024年调整压缩算法、2026年春季重构管道复制架构、2026年夏季去中心化采样，以及2026年秋季在管道中引入聚合处理。

背景

我们的管道始于一个名为Logfwdr的内部服务，我们从高度分布的数据源（如Workers、FL）收集数据。随后，我们将这些数据传输到一组集中式接收器，最终推送到我们的缓冲系统Buftee。消费者从Buftee获取数据，并将其分发到最终目的地，如我们高度依赖的ClickHouse。

架构的简化版本，从Logfwdr开始，这是负责接收生产者事件并转发到集中式接收器的服务。接收器随后将数据排队到缓冲系统，下游消费者从中获取数据。

拆分单一架构

2022年，我们拆分了唯一的单一数据模式。此前，所有产品的字段都打包在一条数据流中，迫使Cloudflare内部消费者必须接收所有数据并通过过滤器进行解复用或丢弃记录。当时，Cloudflare的大多数数据产品都基于HTTP、安全性和CDN元数据。2021年，我们的消息模式如下：

此处某些字段属于同一产品，但有些字段彼此完全无关。假设这些团队并不需要单一架构中的所有字段。换句话说，我们可以为每个产品的必要字段创建小消息。虽然这会导致字段重复，但通过用产品特定的模式替代这个数据洪流，实际上将骨干网带宽使用量减少了35-40%，相当于消除了约一年的压缩流量增长。

该图表显示了在迁离大型单一架构后，压缩字节每秒吞吐量的下降趋势。

到2024年，随着流量持续增长，我们每天都要应对网络拥塞问题。为应对这一挑战，我们将压缩算法从LZ4更换为zstd。虽然我们之前已经尝试过zstd压缩，但当时发现CPU使用率较高。因此，我们谨慎地跟踪相关指标，以确保这种取舍是值得的。

最初，我们仅在少数服务器上部署了这一变更。令我们欣慰的是，CPU使用率没有出现明显变化。

2024.6.2版本是zstd压缩变更前的版本，而2024.7.1版本包含了zstd压缩变更。

随着信心增强，我们逐步将变更推广到全部服务器，CPU影响同样微乎其微。最终，压缩流量吞吐量减少了近40%。未压缩字节数保持原有增长趋势，这意味着在相同管道规模下，我们能够支持超过1.5倍的流量。换一种说法，估算的等效增长缩减使我们相当于提前了约10个月。

图表展示了我们每秒压缩字节数的有效减少。

如今在2026年，我们尝试了三种策略来减少未压缩字节数（从而减少压缩字节数）。

负载均衡

为使分析系统具备区域灾难的弹性，我们的系统需要将冗余数据存储在多个集中区域（受客户元数据边界约束的数据严格存储在其指定区域内）。历史上，实现灾难弹性最简单的方式是双写：Logfwdr将每个非区域分析事件的完整副本发送到两个集中区域。每个区域随后独立处理完整副本直至ClickHouse。我们还在每个区域应用采样，这是一种极其可扩展的技术，适用于任何流量条件下的所有数据量。我们对高流量进行降采样，同时保留罕见事件。

当只有少数流使用次级区域时，这种基础设施是可管理的。但随着我们将灾难弹性扩展到几乎所有分析流，Logfwdr流量整体翻倍。在指数级增长的流量面前，通过广域网传输每个事件两次变得不可持续。

我们之前已为Logpush解决了类似的挑战。对于Logpush，Logfwdr将集中数据中心视为统一的共享接收池：每条消息仅发送到一个区域，当机器或设施不可达时切换到另一个目的地。该模型在大型事件中已证明其价值，可无缝地在不同位置之间切换流量而无需人工干预。这种自动故障转移之所以可行，是因为Logpush传输是无状态的，客户目的地不关心哪个集中数据中心推送日志。

分析系统更为复杂。与无状态日志不同，两个区域的ClickHouse集群仍需要非区域数据的完整副本，以实现即时独立查询故障转移。突破点在于解耦管道传输与数据库冗余：

1. 共享摄入池：我们将Logpush的模型应用到分析流中。Logfwdr通过广域网将每个事件精确发送到可用的集中接收器。

1. 从集中式区域进行延迟复制：与在源端复制流量不同，复制尽可能在管道的后期进行。数据进入我们的分布式缓冲层 Buftee，远程插入器会将跨数据中心的副本流式传输到下游。

1. 弹性故障处理：如果集中式区域发生故障，Logfwdrs 会立即将所有非区域流量路由到存活的区域。如果跨数据中心连接出现短暂中断，每个集群会继续无背压地摄入本地流量；远程插入器在骨干网络恢复后，会从 Buftee 的保留缓冲区中追上数据。

此前，Logfwdr 会将每个非区域事件发送到两个区域的数据中心。之后，它只发送一次事件。远程插入器在 Buftee 之后生成第二个 ClickHouse 副本。

对于我们迁移的数据集，此次切换消除了约 43 GB/s 的压缩传输流量，同时仅在管道中增加了约 7 GB/s 的跨数据中心复制流量。两个架构因素解释了这种不对称性：

1. 复制发生在采样之后：在旧模型中，Logfwdrs 会通过广域网传输两次未经采样的原始事件副本。在新模型中，Logfwdrs 将单个副本发送到集中式接收器，接收器在缓冲到 Buftee 之前立即应用采样，仅传输已压缩的流。

1. 通过统一分区实现更好的压缩：源端数据分散在数千台独立服务器上。集中化后，流会被聚合并按更宽的时间窗口划分为统一批次。这种结构上的统一性使压缩算法能够实现比 Logfwdr 传输批次高得多的压缩率。

总体而言，这在广域网中实现了 36 GB/s 的净减少。我们最初将此方案部署到两个数据集：HTTP 分析和 Ready-Analytics（我们的内部一键式分析产品）。

我们的首次切换针对 HTTP 分析数据，流量减少了约 20GB/s（超过 50%）。

对于 Ready-Analytics 等数据集，流量立即下降了 43%（从约 28 GB/s 降至约 16 GB/s）。

自春季以来，我们一直在积极将更多数据集迁移到这种负载均衡架构中。

从一开始就进行采样

我们采用的另一项策略是进一步扩展采样机制，将关键处理步骤更早地引入管道。采样已经在我们的集中式服务中使用，特别是接收器，减轻了下游系统的压力。如果我们减少向下游传输的数据量（同时不牺牲数据质量），可以更高效地利用资源。

解决方案是在 Logfwdr 中进行采样，同时保持集中式接收器中的采样机制。简而言之，采样算法的工作原理是：每个数据集都有一个由生产团队选择用于索引和采样的键。采样时，我们首先对每个键的记录进行洗牌以消除偏差。然后，对于每组记录，我们选择的样本量等于记录总数的平方根。无论采样一次还是两次，结果都是一个具有代表性的样本。为了生成估计值，我们将计算结果按采样率进行缩放。例如，如果我们从 100 条记录中采样 10 条，采样率将是 10/100，原始数量的无偏估计值将是 10*10 = 100。

为验证该方法的有效性，我们通过比较写入 ClickHouse 的行数与使用多种键和不同流量特征估算的总数，确保从“最少出现”到“最多出现”的键在整个范围内都被覆盖。

蓝色曲线表示采样一次/原始数据，红色曲线表示双采样数据。即使数据库中的行数减少，估算结果仍保持一致。

最终结果是，对于数据量较大的键，采样率会降低。但数据量较少的键仍能保持相近的采样比例。这样我们在减少事件传输和存储量的同时，仍能保持样本的代表性。即使传输数据量减少，我们并未牺牲数据质量。

如果我们更深入地分析，通过幂律关系可以观察到，双采样（红色）的增长速度约为 x 0.319，而单采样/对照组（蓝色）的增长速度为 x 0.485。另一种理解方式是，某个键的数据量是另一个键的 100 倍时，单采样情况下存储的行数约为后者的 10 倍。而采用双采样后，存储的行数仅约为后者的 4 倍。具体来说，1160 万事件在 ClickHouse 中仅需要 18,000 行存储，而不是 79,000 行。双采样策略显著降低了“最多出现”键的存储需求，同时仍保留了“最少出现”键的事件细节。

该图表通过幂律关系展示了估算数据量与存储行数之间的趋平关系。请注意，x^0.25 的关系未被观察到，因为双采样是在不同机器和批次中独立进行的，而集中式接收器在合并部分批次后才会对剩余数据进行采样。

我们最初将该策略应用于三个最重要的数据集。每个数据集压缩数据量至少减少了一半，原本发送到集中式接收器的数据量为 25GB/s，即每天超过 2PB。

我们对所有应用双采样的数据集进行分析后发现，压缩字节/秒的减少效果都非常显著。

聚合

Cloudflare 提供了多个基于聚合（rollups）的分析数据集：这些数据集是在数据摄入时计算的原始事件汇总。这与采样策略形成了相反的权衡：采样策略通过近似回答任意问题来减少数据量，而聚合策略则通过预先选择维度和指标，精确回答一组固定的问题。

例如，在 HTTP 数据集中，我们测量的是特定分钟内 IP 地址的唯一出现次数，而不是记录每个 IP 地址本身。另一个例子是，我们汇总特定域名在特定分钟内按 HTTP 方法分组的 GET、POST、PUT 等请求总数。这些计算并不需要等到数据管道的末尾才开始执行。

历史上，这些聚合操作发生在数据管道的末尾，由从 Buftee 读取数据并插入到 ClickHouse 的插入器（inserter）执行。将聚合操作去中心化，是一个分散负载并减少集中化数据量的绝佳机会。

因此，我们构建了一个聚合功能，该功能在每个环节都会被使用，随着数据逐渐汇聚，不断创造将匹配的局部聚合结果合并的机会。与采样类似，记录会根据一个键进行分组，该键决定了哪些记录可以合并。我们在每个Logfwdr实例上进行聚合。当部分聚合后的事件到达集中接收器后，我们会再次进行聚合，接收器将这些重新聚合的事件推送到专用的分区缓冲区。由于这些缓冲区汇集了来自多个接收器的记录，当ClickHouse插入器以批量方式读取它们后，我们还会再次进行聚合。最后，我们在ClickHouse中使用聚合表引擎进行最终聚合。

此图展示了事件在整个流程中被聚合的示例流程。

我们首先将此功能应用于HTTP流量数据集。仅在这一数据集上，压缩字节流量就从9+ GB/s降至<2 GB/s。尽管这是当前基数最高的数据集，但对其的聚合仍然实现了约80%的流量减少。

HTTP汇总数据集的压缩字节每秒流量随时间变化情况。橙色表示数据到达插入器后仅进行一次聚合时的速率；绿色表示我们在流程更早阶段实施聚合后的速率。

这种聚合功能对易于压缩的数据集特别有效，尤其适用于像使用指标这类对总和和计数准确性要求极高的场景。这也意味着我们可以为生产团队提供另一种减少资源消耗的选项，除了已实施的采样方案。与Ready-Analytics类似，我们开发了一款通用的内部一键式聚合分析产品，名为Ready-Aggregates。随着我们在流程中持续改进这一新功能，预计节省的资源将持续增加。

影响

这种指数级增长最显著的证明是流量增长消耗可用容量的速度之快。

以Ready-Analytics为例，其中应用了三种机制中的两种：负载均衡和采样技术。5月中旬，负载均衡将流量降低了50%，从约26 GB/s降至约13 GB/s。两个月后，流量已开始回升至约20 GB/s。这相当于减少了原先一半的降幅，被自然流量增长抵消了。随后我们通过将该数据集的吞吐率降低至个位数（约8 GB/s）进一步释放了更多容量，当时采样方案开始实施。

Ready-Analytics在两次迁移中的总流量速率。绿色表示实际流量；黄色"幽灵"曲线重建了未使用负载均衡（5月）和采样（7月）时的流量。

如果没有这两项干预措施，到9月Ready-Analytics单独的流量就会突破60 GB/s。通过在中心数据中心处理更少的数据，我们还节省了大量CPU和内存资源。下图展示了负载均衡和采样对Ready-Analytics接收器CPU和内存使用的影响：减少了约50%，回收了约750个CPU和3.5 TiB内存。

在整个流程中，从春季到秋季，负载均衡（节省约38 GB/s）、采样（顶级数据集共节省约25 GB/s）和聚合（目前已节省7+ GB/s）总共消除了约70 GB/s的压缩流量。这些断崖式下降提供了即时的缓解。

通过这些努力，当前的吞吐量已落后于原先预测的增长轨迹约八个月。

如果我们拉远视角，展望五年后的未来，今年所做出的改变其长期影响与短期收益同样重要。我们已将未来五年内需要处理的数据量减少了一半。当前及未来持续进行的结构和算法优化，对于保持硬件需求的可持续性至关重要。

今年完成的工作所产生的长期影响表明，我们已将2031年的数据量预测值削减了一半。

如果您有兴趣帮助我们大规模解决这些挑战，我们正在招募人才！

目录栏

讨论栏

相关标签及社交媒体链接

相关标签

在社交媒体上关注

• Cloudflare

电子邮件订阅