逆转指数增长：我们如何控制硬件使用量
内容提要
Cloudflare数据团队通过拆分单体数据模式、采用zstd压缩、重构管道复制、去中心化采样和引入聚合，将骨干网压缩流量减少约70GB/s，相当于推迟硬件扩容需求约两年半，并使2031年预计数据量减半。
延伸解读
从单体到产品化：拆分数据模式的关键作用
文章指出，2022年将单体数据模式拆分为产品特定模式，使骨干网带宽使用减少35-40%，相当于抵消约一年的压缩流量增长。这一举措表明，在数据管道中，消除不相关字段的冗余传输比单纯优化压缩算法更能从根本上缓解带宽压力。对于面临类似数据增长问题的团队，优先审视数据模式的合理性可能带来显著收益。
压缩算法升级的权衡：zstd替代LZ4的实践
2024年，团队将压缩算法从LZ4改为zstd，尽管此前担心CPU开销增加，但实际部署后CPU影响微乎其微，压缩流量减少近40%。这说明在硬件资源允许的情况下，采用更高压缩比的算法可以在不显著增加计算成本的前提下，有效提升现有管道的吞吐能力。团队通过逐步灰度验证了该决策的可行性。
负载均衡与延迟复制的架构解耦
通过将管道传输与数据库冗余解耦，Logfwdr只需发送一次数据，由下游远程插入器完成跨区域复制。对于迁移的数据集，压缩传输流量减少约43 GB/s，而新增的跨数据中心复制仅约7 GB/s。这种不对称收益源于复制发生在采样之后，且集中后的数据流具有更均匀的分区，从而获得更高的压缩率。
采样与聚合：在数据精度与资源消耗间取舍
去中心化采样在Logfwdr和接收器两处进行，对高频键进行更激进的采样，但保持低频键的细节，确保估计值无偏。聚合则相反，通过预定义维度和指标，在管道各阶段合并部分聚合，实现精确结果。两者分别适用于近似查询和固定指标场景，为生产者团队提供了灵活的资源优化选项。
Q&A
Cloudflare数据团队如何将骨干网压缩流量减少约70GB/s？
通过五项关键优化：2022年拆分单体数据模式，2024年将压缩算法从LZ4改为zstd，2026年春季重构管道复制（负载均衡），2026年夏季去中心化采样，2026年秋季引入聚合。这些措施合计减少约70GB/s压缩流量。
为什么拆分单体数据模式能减少带宽？
原先单一流包含所有产品字段，内部消费者需摄取全部数据再过滤。拆分为产品特定模式后，虽然字段有重复，但每个消息只包含所需字段，减少了不必要的数据传输，使骨干网带宽使用降低35-40%，相当于抵消约一年的压缩流量增长。
改用zstd压缩算法后，CPU使用率有变化吗？
没有明显变化。团队最初担心zstd会增加CPU使用，但先在少量服务器上测试，未观察到显著差异，随后逐步推广到整个集群，CPU影响依然很小。最终压缩流量减少了近40%，而未压缩字节增长不变，相当于用同样管道支持1.5倍以上流量。
负载均衡架构如何减少跨区域数据传输？
旧架构中Logfwdr将每个非区域分析事件双写到两个集中区域，导致跨广域网传输翻倍。新架构采用共享接收池：Logfwdr只发送一次事件到任一可用接收器，采样后存入Buftee，再由远程插入器跨数据中心复制到第二个ClickHouse集群。这样消除了约43GB/s压缩传输流量，仅增加约7GB/s复制流量，净减少36GB/s。
去中心化采样是如何工作的？
在Logfwdr和集中接收器两处都进行采样。每个数据集有一个键，采样时先按键打乱记录消除偏差，然后对每组记录选取样本量等于记录总数的平方根。这样无论采样一次还是两次，都能得到代表性样本。通过样本率缩放计算可得到无偏估计。对高频键，采样率降低，存储行数大幅减少，但低频键仍保留细节。
聚合功能在管道中如何实施？
聚合在管道每一步进行：在Logfwdr实例上聚合，在集中接收器上再次聚合，在ClickHouse插入器读取批次后第三次聚合，最后在ClickHouse中使用聚合表引擎。记录按键分组，可合并部分聚合结果。例如HTTP数据集压缩流量从9+GB/s降至<2GB/s，减少约80%。
这些优化对硬件扩容需求有什么长期影响？
过去五年的优化相当于推迟了约两年半的硬件扩容需求。仅2026年的措施就将预计2031年的数据量减半。吞吐量目前比原预测增长轨迹落后约八个月。这些结构性优化对保持硬件需求可持续至关重要。
