文章

Cloudflare R2 SQL 宣布新增支持聚合查询，包括 GROUP BY 和 SUM，显著增强了其数据分析能力。文章首先强调了聚合在分析中的重要性，通过 SQL 示例演示了使用 GROUP BY、ORDER BY 和 HAVING 子句进行数据汇总、排序和过滤。接着深入探讨了 R2 SQL 实现聚合的两种主要方法：scatter-gather 和 shuffling。scatter-gather 适用于不需要对聚合结果进行排序或过滤的简单聚合，其中分布式工作节点并行计算预聚合（pre-aggregates），由协调器（coordinator）进行合并。shuffling 聚合引入了一个数据混洗阶段，使用确定性哈希分区（deterministic hash partitioning）将相同分组键的数据路由到单个工作节点进行本地聚合。这种设计解决了高基数列聚合（high-cardinality column aggregations）中遇到的协调器瓶颈问题，并采用同步屏障（synchronization barrier）确保数据完整性。最后，通过协调器的 k 路径归并（k-way merge）有效合并本地最终结果。这些分布式执行策略使 R2 SQL 能够高效处理 R2 Data Catalog 中的海量数据集，无需复杂的 OLAP 基础设施。

Cloudflare 的博客文章详细介绍了其“Code Orange：小范围失败优先”弹性计划，该计划旨在应对近期两次导致中断的网络事件。该计划侧重于三个核心领域：首先，强制所有配置变更采用受控发布，并参照现有软件发布流程，从而减轻即时全局更新带来的风险。其次，对所有处理网络流量的系统进行彻底的故障模式审查和改进，确保即使在意外情况下也能实现可预测的行为。第三，优化“紧急访问”程序，并消除循环依赖，以加速事件响应和解决。文章强调要像对待软件更新一样谨慎对待配置更新，利用现有的健康介导部署 (Health Mediated Deployment， HMD) 系统进行自动化验证和回滚。Cloudflare 旨在第一季度末完成大部分工作，显著增强网络弹性和可靠性。

Cloudflare 开发了一个基于 Cloudflare Workers 的自动化内部维护调度器，旨在管理其遍布全球 330 多个数据中心的复杂且中断性强的维护操作。文章阐述了随着 Cloudflare 规模的扩大，手动协调变得愈发不切实际，因此急需一个集中的“大脑”来强制执行安全约束。主要挑战包括确保关键基础设施组件（如边缘路由器）和客户特定服务（如原名为“Aegis”的专用 CDN 出口 IP）在维护期间保持在线。他们最初在使用 Workers 加载过多数据时遇到了“内存不足”问题，后通过采用受 Facebook 的 TAO 启发的“图处理”方法解决，该方法仅获取必要的数据。这继而引发了“子请求问题”，通过结合请求去重、LRU 缓存、CDN 缓存和指数退避重试机制的“数据获取流水线”中间件得到了有效缓解，最终实现了约 99% 的缓存命中率。针对实时指标，他们与分布式 Prometheus 查询引擎 Thanos 进行集成，通过利用图接口将查询响应从多 MB 优化至 1KB。对于历史数据分析，他们将 Prometheus TSDB 块转换为 Apache Parquet 文件，从而实现了高效的列式存储和精确的 R2 范围请求，将查询性能显著提升达 15 倍。该解决方案确保了在快速全球扩张中网络的可靠性和可扩展性。

这份来自 Cloudflare 的博客文章，随附其 2025 年上半年 透明度报告，深入探讨了公司在处理客户信息的法律请求之外，应对流媒体滥用和版权侵权问题的演进策略。文章强调，恶意分子日益运用复杂的手段（常利用 AI）来传播受版权保护的内容。Cloudflare 详细介绍了其与版权所有者进行的实验性合作，旨在识别并响应未经授权的流媒体，这使得 DMCA 报告显著增加，随后公司也迅速采取了行动，包括终止相关账户。本文还讨论了 Cloudflare 的技术创新，例如由 AI 驱动的自动化系统，用以大规模检测和遏制滥用行为，同时通过限制流媒体视频传输来维持其免费服务。至关重要的是，文章将这种协作的、有针对性的方法与法律强制性封锁这种“不甚精细”的方法进行了对比，并引用了过度封锁及其对互联网用户（尤其是西甲联赛相关情况）的负面影响案例。最后，Cloudflare 概述了其针对封锁要求的审慎态度，强调了相称性、正当程序和透明度，以及公司为寻找有效且相称的在线侵权解决方案所做的持续努力。