datainfra前沿动态 · Vol.33

DataFusion Comet 加速 Iceberg：Spark 查询提速 40% + 差异化测试驱动 Rust 开发；AWS EMR 集成 Celeborn Remote Shuffle；Iceberg REST 联邦连结 Salesforce Data 360

本期聚焦三条基础设施加速线：DataFusion Comet 通过原生 Rust 执行加速 Spark 查询 40% 并驱动 Iceberg Rust 差异化测试开发，AWS EMR 集成 Apache Celeborn 实现 Shuffle 与计算解耦，AWS Glue Iceberg REST Endpoint 实现 S3 到 Salesforce Data 360 的零拷贝联邦。

DataInfra Apache Iceberg DataFusion Comet Iceberg Rust Apache Spark TPC-DS Apache Celeborn AWS EMR Remote Shuffle Salesforce Data 360 Zero Copy Iceberg REST Catalog AWS Glue Lake Formation Anyscale Ray cgroup v2 Resource Isolation Ray 2.56

本期聚焦 7 月 15 日前后集中出现的三条基础设施加速线：Apache Iceberg 博客发布重磅长文，详述 DataFusion Comet 如何通过 Rust 原生执行将 TPC-DS 3TB 查询加速约 40%，同时利用 Comet 的 fallback 机制将 Iceberg Java 的近万 Spark 测试转化为 Iceberg Rust 的差异化测试驱动开发循环，已贡献 40+ PR；AWS 大数据博客同一天连发两篇——Apache Celeborn Remote Shuffle 在 EMR on EKS/EC2 上实现 Shuffle 存储与 Spark 计算彻底解耦，以及 AWS Glue Iceberg REST Endpoint + Lake Formation 实现 Salesforce Data 360 到 S3 Iceberg 表的零拷贝联邦访问；Anyscale 于 7 月 14 日发布 Ray cgroup v2 资源隔离方案，将内核 OOM 和节点故障双降至零。三条线共同指向一个主题：加速——不只在查询层，也在 Shuffle 中间件、跨平台链路和集群稳定性层面全面推进。

Apache DataFusion Comet 加速 Iceberg：TPC-DS 提速 40%，差异化测试驱动 Rust 开发

事件概述

2026 年 7 月 15 日，Apache Iceberg 官方博客发布由 Iceberg 贡献者兼 DataFusion PMC 成员 Matt Butrovich 撰写的长文《Accelerating Apache Spark Queries (and Iceberg Rust Development) with Apache DataFusion Comet》，系统阐述了 Comet 项目如何通过 Rust 原生执行引擎加速 Spark 对 Iceberg 表的查询，以及这一架构如何将 Iceberg Java 的近 10,000 个 Spark 测试转化为 Iceberg Rust 的差异化测试驱动开发循环。这是 Iceberg 社区首次以官方博客形式正式介绍 Comet 与 Iceberg Rust 的双向协作关系。

技术解析

  • Comet 加速 Spark 查询的核心机制：Comet 是 Apple 于 2024 年捐赠给 Apache DataFusion 的子项目，其加速策略是在 Spark 物理计划层级截获执行——Spark 完成语法解析、逻辑与物理优化后，Comet 作为最后一个优化规则将 Spark 物理计划节点转换为 Comet 节点，而这些 Comet 节点在 DataFusion 的 Rust 引擎中通过列式 Arrow 数据执行。在 Iceberg 场景中，Comet 保留 Iceberg Java 的查询规划（生成 FileScanTask），然后将 FileScanTask 对象转换为 Iceberg Rust 的等效对象，由 Rust 库读取 Parquet 文件并转换为 Arrow 批次，馈入 DataFusion 执行引擎。这种”Java 规划 + Rust 执行”的混合架构在 AWS Data on EKS 团队的 TPC-DS 3TB benchmark 中实现约 40% 的整体加速（2,803.80s vs 4,665.47s），103 个查询中 102 个获得加速。

  • 差异化测试驱动的 Rust 开发循环：Comet 的 fallback 机制——当遇到 Iceberg Rust 尚不支持的特性时自动回退到 Iceberg Java——被巧妙地转化为开发工具。开发者可以”放松一个 fallback”，强制经过原生路径，然后运行 Iceberg Java 的测试套件观察哪些测试失败，通过 AI 辅助分类根因后修复 Iceberg Rust 中的缺口，最后重新运行确认通过。这一循环已经产出 40+ PR 贡献到 Iceberg Rust，涵盖 bug 修复、新特性（包括 table format v3 初步支持）和性能优化。关键点是这些贡献受益于 Iceberg Rust 的所有下游项目，而非仅为 Comet 专用。

  • 双向纠错能力：差异化测试不仅暴露 Rust 实现的缺口，也反过来发现 Java 实现中的 bug。文章透露 Comet 曾帮助验证 Iceberg Java 中一个 manifest delete file size 计算的 bug 修复，Iceberg Rust 的行为被作为”参照标准”来确认 Java 端的修正结果。

  • 当前限制与路线图：Comet 目前仅加速读取路径，写入仍走 Iceberg Java；遇到 table format v3 时默认 fallback；尚不支持所有读取场景。正在推进的特性包括：table format v3 的新数据类型（variant、geometry、geography）、row lineage、默认列值、表加密；写入路径加速是明确的下一步方向。

行业影响

这篇文章的意义远不止于”Spark 快了 40%“的 benchmark 数字。它揭示了一种新的开源协作模式：两个 Apache 项目（Iceberg 和 DataFusion）通过一个桥梁项目（Comet）形成了”测试套件共享→缺口发现→上游贡献→双向收益”的正向循环。对 Iceberg Rust 来说，它是一种前所未有的质量保障机制——不再需要手工镜像 Java 测试，而是直接以 Java 的测试套件作为 oracle。对 DataFusion 和 Comet 来说，与 Iceberg 的深度耦合使其成为”加速 Spark + Iceberg 栈的标准插件”，这在 Databricks Photon 和 Gluten+Velox 之外提供了第三条原生加速路径。

从更广的视角看，这是 Rust 在数据基础设施中持续渗透的又一步——从 Arrow-rs 的 Parquet 读取器到 DataFusion 的执行引擎再到 Iceberg Rust 的表操作库，Rust 正在成为 Java/Spark 加速层的首选”第二语言”。如果 Comet 的写入路径加速和 table format v3 支持如期完成，“Rust 原生 Iceberg 栈”有望成为湖仓查询的性能新基线。

相关链接

AWS EMR 集成 Apache Celeborn Remote Shuffle：Shuffle 与计算解锁，Spot 实例从此可靠

事件概述

2026 年 7 月 15 日，AWS 大数据博客发布《High-performance Remote Shuffle Service on Amazon EMR with Apache Celeborn》，为 EMR on EKS 和 EMR on EC2 用户提供了一套生产就绪的 Apache Celeborn 远程 Shuffle 服务架构方案。通过在独立的 Amazon EKS 集群上部署 Celeborn（Leader-Worker-Client 架构），Spark 的 Shuffle 数据从 Executor 本地磁盘迁移到共享的、存储优化的 Celeborn 集群中，实现 Shuffle 存储与计算资源的彻底解耦。

技术解析

  • Shuffle 存储解耦的三大收益：(1) Executor 节点可 100% 使用 Spot 实例，Spot 回收不再导致 Shuffle 数据丢失和上游阶段重算——传统架构中这是 Spark 在 Spot 上运行的最大风险；(2) 计算节点不需要为 Shuffle 过度配置存储——过去在 YARN 架构中，每个节点都要配备大量磁盘以应对可能的 Shuffle 负载，但只有少数节点实际承担显著的 Shuffle 工作；(3) Executor 可自由扩缩容，不会因持有 Shuffle 数据而被阻止缩容。

  • 共享服务架构：单个 Celeborn 集群作为共享服务可服务多个 EMR 集群，通过内部 NLB（端口 9097 RPC / 9098 Dashboard）暴露服务。Leader 节点使用 StatefulSet + EBS 持久卷 + Raft 共识（3 副本），Worker 节点使用本地 NVMe 实例存储并通过数据复制保护。Spark 端需禁用 External Shuffle Service，使用 Celeborn 的 ShuffleManager，指向 NLB 端点。

  • 可观测性栈：ADOT 采集器抓取 Prometheus 指标，支持两种监控后端——Amazon Managed Service for Prometheus + Managed Grafana，或自建 Prometheus + Grafana。

  • 双模式 EMR 支持：EMR on EKS 支持 StartJobRun API 和 Spark Operator 两种提交方式；EMR on EC2 通过 Steps API 以 client 模式提交。两种模式都通过同一 NLB 连接共享 Celeborn 集群。

行业影响

Celeborn 在 EMR 上的正式架构方案发布，标志着 Remote Shuffle Service（RSS）从”社区实验性方案”进入”云厂商推荐生产架构”阶段。回顾 Shuffle 架构的演进：第一代是 Spark 内建基于本地磁盘的 Shuffle（Shuffle 数据与 Executor 生命周期绑定）；第二代引入了 External Shuffle Service（ESS，数据持久化在节点级别但仍在计算节点上）；第三代就是 Celeborn 所代表的远程 Shuffle——将 Shuffle 中间数据从计算层完全剥离到独立的存储层。

这一趋势与 Databricks 的 Photon Shuffle 和阿里巴巴的 RSS（已用于内部超大规模生产）方向一致。Celeborn 作为 Apache 顶级项目，其对 EMR 的原生支持加上 Spot 成本优化的直接收益——Spot 实例通常比 On-Demand 便宜 60-90%——很可能推动更多的 AWS 上的 Spark 生产工作负载采用远程 Shuffle 架构。

相关链接

AWS Glue Iceberg REST Endpoint 联邦 Salesforce Data 360：零拷贝跨平台湖仓

事件概述

2026 年 7 月 15 日，AWS 大数据博客发布《Zero Copy access to Apache Iceberg tables in Amazon S3 from Salesforce Data 360》，详细阐述了如何利用 AWS Glue Data Catalog 的 Iceberg REST Endpoint 和 AWS Lake Formation 的细粒度权限控制，实现 Salesforce Data 360 对 S3 上 Apache Iceberg 表的零拷贝联邦访问。这是 Salesforce 与 AWS 两大平台在开放数据格式上实现互操作的关键里程碑。

技术解析

  • 零拷贝 = 文件级联邦：数据物理上始终留在客户 S3 桶中，不发生任何拷贝。工作流为：(1) Data 360 通过 Glue Iceberg REST Endpoint 获取 Iceberg 表的元数据（Schema、分区、S3 文件位置）；(2) Lake Formation 校验权限并颁发范围的临时凭证（Scoped Credentials），仅授予访问特定表数据的最低权限；(3) Data 360 分析引擎使用这些凭证直接从 S3 读取 Iceberg 原始数据文件。整个过程通过 IAM 进行 AWS Signature V4 签名认证。

  • Lake Formation 作为治理中枢：权限基于 Lake Formation 预定义的策略，通过 lakeformation:GetDataAccess 动态下发临时凭证。这意味着治理策略集中定义、运行时动态执行，Data 360 端无需预配置复杂的 S3 访问策略。

  • 配置简易性：在 Data 360 侧只需配置 5 个参数——IAM Access Key/Secret、Glue Iceberg REST Catalog URL、Catalog ID（12 位 AWS 账号 ID）、Signing Region 和 Service（glue）——即可从下拉列表中选择 Glue Catalog 中的数据库和 Iceberg 表建立数据流。

行业影响

此次集成的真正价值在于：Salesforce 作为全球最大的 CRM/SaaS 平台，首次通过开放标准（Iceberg REST Catalog）实现了对 AWS 数据湖的原生、安全、零拷贝访问。这不仅消除了 Salesforce 客户将 AWS 湖仓数据导入 Salesforce Data Cloud 的 ETL 管道成本和延迟，更重要的是在架构层面确认了 Iceberg REST Catalog 作为跨平台数据互操作标准的可行性。

将此与 Vol.31 报道的 AWS 多云湖仓 Agentic AI 架构、Vol.32 的 ApsaraMQ 零 ETL 摄取放在一起看：2026 年 7 月的 DataInfra 行业正在经历一次”联邦型数据访问”的密集落地——不是将数据集中到一个平台，而是通过开放标准（Iceberg REST Catalog）和零拷贝机制，让数据停在原地、被不同平台安全地直接访问。Salesforce + AWS 的这步棋，加上此前 Databricks Unity Catalog Delta API 对非 Databricks 引擎的开放，标志着”数据重力”正在从”你必须把数据搬到我的平台”向”你可以从任何平台访问数据”的方向逆转。

相关链接

Anyscale Ray 引入 cgroup v2 资源隔离：内核 OOM 和节点故障双降至零

事件概述

2026 年 7 月 14 日，Anyscale 工程博客发布《Enhancing Ray Cluster Stability With Resource Isolation》，详细介绍 Ray 2.56 引入的基于 Linux cgroup v2 的资源隔离方案。该方案将 Ray 系统进程（raylet、GCS）与用户工作负载在 CPU 和内存层面实现 cgroup 层级隔离，在视频预处理流水线的实验中实现了内核 OOM 和节点故障双降至零的效果。

技术解析

  • 双层 cgroup 架构：Root Cgroup 下分 system cgroup（Ray 系统进程）和 user cgroup（用户工作负载 + 非 Ray 进程）。system cgroup 通过 memory.low 保留最低内存（默认 10%、最小 500MiB、最大 10GiB），通过 cpu.weight 保障 CPU 份额（默认 5%）；user cgroup 通过 memory.high 限制内存上限，触发时由 Ray 的事件监控器自主决定杀死哪些 Worker——而非让内核 OOM Killer 随机杀进程。

  • 工作量感知的 Worker 杀死策略：当 memory.high 被触发时，Ray 的事件监控器即时接收内核通知（零延迟），按”优先杀死执行时间最短的任务”的策略选择性终止 Worker——保留已投入大量计算的长任务。该策略避免了内核 OOM Killer 最大的痛点：反复杀死进度最多的任务导致工作负载永远无法完成。

  • 阈值监控器解决跨 cgroup 内存记账：对象存储的内存由 raylet（系统进程）分配但被用户进程使用，造成内存记账漂移。额外的阈值监控器追踪跨 cgroup 的总内存使用量，确保全局上限不被突破。

  • 实验数据：在视频预处理流水线测试中，资源隔离方案将内核 OOM 从 163 次降至 0 次，节点故障从 5.33 次降至 0 次，任务失败降至 0 次，完成时间从 3,427s 缩短至 2,164s。

行业影响

Ray 的 cgroup v2 资源隔离虽然功能上是一件”基础设施运维优化”，但其设计哲学值得关注：不依赖外部调度器或容器编排层（如 Kubernetes）来隔离资源，而是在 Ray 进程内直接利用 Linux 内核特性实现自管理隔离。这使得 Ray 集群在裸金属、VM、容器化等不同部署形态下都能获得一致的资源保护能力。

对于运行超大规模 AI 数据管道的团队来说，这个功能的实际收益是：“Ray 集群不明原因周期性崩溃”这一最令人头疼的生产问题，可以通过 ray start --enable-resource-isolation 一个 flag 显著缓解。从更广的视角看，Ray、Spark（Celeborn Remote Shuffle）、Flink 等分布式框架都在从”依赖底层平台保障稳定性”向”框架自身内置资源隔离和故障恢复”方向演进——这是分布式数据处理从”能用”到”生产级稳定”的标志性阶段。

相关链接

编者评

四条动态共享一个没有明说但贯穿始终的技术主题：在 2026 年，数据基础设施的竞争正在从”功能覆盖”转向”性能与稳定的工程化深度”。DataFusion Comet 不是引入新的查询语法，而是用 Rust 重写了执行路径，让同一份 Iceberg 表快 40%；Apache Celeborn 不是发明新的 Shuffle 算法，而是将 Shuffle 数据从 Executor 本地盘剥离为独立服务，让 Spot 实例从”不可用”变成”随意用”；AWS Iceberg REST 联邦没有创造新的数据格式，而是通过零拷贝和临时凭证机制让现有数据湖被 Salesforce 直接消费；Ray cgroup v2 隔离没有添加新的调度策略，而是利用 Linux 内核既有特性让 Ray 集群告别 OOM 崩溃。

这种”不再发明新概念、深耕既有技术栈的工程化极致”的趋势，在 2026 年 H1 的 DataInfra 演进中变得越来越清晰。它可能不如新协议、新范式那般引人注目，但对于将 DataInfra 从”实验性工具链”推向”企业级生产基础”至关重要。正如本期 Iceberg 博客文章所揭示的——最好的工程工作有时候不是写出新的代码，而是让两套已有的代码能够互相验证对方的正确性。