datainfra前沿动态 · Vol.72

Apache Iceberg 1.12 删掉 Spark 3.4 与带行数据的位置删除，Rust 端加密卡在跨实现防篡改校验上；阿里云 OSS Tables 让 Spark 直连 Iceberg REST Catalog 免掉自建 Metastore；RocketMQ 无复制故障接管论文进 ACM FSE 2026；Managed Airflow Gen 3 把排队时间压掉，Pine59 单条管道 38 分钟降到 26 分钟

本期聚焦四条跨 9 月 16 至 18 日的进展：Apache Iceberg 1.12.0 进入发布候选，移除 Spark 3.4 支持与带行数据的位置删除，Iceberg Rust 0.11 因加密实现与 Java 校验不一致两次 RC 失败；阿里云 OSS Tables 原生兼容 Iceberg REST Catalog，Spark 改一行 catalog 配置即可读写，不必再部署 Hive Metastore；阿里云消息团队的 Replication-Free Failover 论文被 ACM FSE 2026 收录，靠存储协议层写隔离实现秒级接管而不复制业务数据；Google Cloud 的 Managed Airflow Gen 3 让 Pine59 的排队时间近乎归零，单条管道从近 38 分钟降到不足 26 分钟。

DataInfra Apache Iceberg Iceberg Rust 开放表格式 阿里云 OSS Tables REST Catalog Apache Spark RocketMQ 高可用 Apache Airflow Google Cloud 湖仓

本期四件事分布在表格式、元数据服务、消息中间件与工作流编排四处，动作的形状却一致：都在删掉一个一直被当作必需的冗余。阿里云消息团队不复制业务数据，改用存储协议层的写隔离来保证接管之后只有一个写者；OSS Tables 不让人再部署一套 Hive Metastore，把元数据交给 Iceberg REST Catalog 协议；Iceberg 1.12 删掉 V2 里带行数据的位置删除，也一并删掉各语言实现各写各的加密语义；Managed Airflow Gen 3 让任务不再长时间排队，把推理这类重执行从编排层剥出去。冗余没有消失，而是从「多存一份」上移到「某一层协议能证明只有一份在被写」。四处上移都各自带着一条限制条款，这些条款才是本期最值得读的部分。

Apache Iceberg 1.12.0 进入候选：删掉 Spark 3.4 与行内位置删除，Rust 端两次 RC 卡在跨实现兼容

事件概述

Apache Iceberg 的 Java 与 Rust 两条线在 9 月中旬一起接近终点，也一起在候选阶段遇到问题。Java 侧 1.12.0 的里程碑上挂着 210 个已合并 PR；Rust 侧 0.11.0 相对 0.10.1 有八十余项改动，主体是端到端表加密与 Variant 支持。Dremio 的 Alex Merced 在 9 月 18 日的预览文章里写明：截至当天两个版本都还没有正式发布，Java 的发布经理 Neelesh Salian 已通知 dev 列表候选可以切了，Rust 0.11.0 的投票则失败了两次，还差一个修复才能进 RC3。

比单个功能更值得行业注意的是发布节奏本身的改变。Iceberg 1.10.0 到 1.11.0 之间隔了约八个月，Neelesh 在 6 月启动 1.12 规划时把目标定在三个月左右，社区基本兑现。对一个已经把 Spark、Flink、Trino 与各家云目录都接在身上的表格式来说，节奏从「一年一次大版本」变成「一季度一次」，意味着错过 1.12 的功能只需要等三个月而不是大半年；反过来也意味着升级检查从「几年做一次」变成「每季度做一次」。

技术解析

  • 四项会真正打断作业的移除：Spark 3.4 运行时被删除（PR #14122），保留 3.5、4.0、4.1 并分别升到 3.5.9、4.0.4、4.1.3；带行数据的位置删除（PDWR）不再可写（PR #17706），rewrite_position_delete_files 与 rewrite_table_path 遇到仍带行数据的文件会直接抛异常，这是社区在 8 月 26 日同步会上定的口径；计划中要在 1.12 移除的废弃方法一并删掉，包括 Spark 4.0/4.1 里的 SparkTableUtil 废弃方法，SparkFilters 改为 SparkV2Filters；旧的 AWS 签名类被移除（PR #17627），由新的 RemoteSigningConfig 实现（PR #17709）接替。
  • PDWR 的两条出路：仍跑 V2 表且位置删除带行数据的团队，升级后维护作业会开始失败。Hongyue Zhang 的提案给了两条路——把表升到 V3 并把删除重写成 deletion vector，或者留在 V2 让数据合并把这些删除折叠进数据文件。这个决定要在升级之前做，不要等第一个作业报错之后再做。
  • Spark 4.2 是刻意缺席：Anton Okolnychyi 主张每个新 Spark 版本都是清理 DSv2 技术债的机会，社区把 Spark 4.2 模块合并进了 main，却不打进 1.12.0 的源码与二进制产物。Flink 方向相反，PR #17849 增加 Flink 2.2 与 2.3，一并保留 2.1。
  • Variant 补齐流式写入：Spark 增加 Variant 列的向量化 Parquet 读取；Flink 支持写入 shredded Variant；Kafka Connect 与通用 Record writer 能把 Variant 切碎到 Parquet 列里——这一条才是让 Variant 对流摄入真正可用的改动。里程碑里还修掉了精度大于 18 的 decimal 切碎、Variant 字符串边界改用 UTF-8 字节序、Variant 值列无统计信息时的崩溃，这几个都属于会静默扭曲剪枝结果的那类缺陷。
  • Flink 的完整等值删除转换链：一组 PR 补上了 planner、算子、DV 解析、committer 与 IcebergSink 的集成。等值删除写起来便宜、读起来贵，能在流作业内部把它转成 deletion vector，对喂给分析的 CDC 管道意义很大。
  • REST Catalog 与加密的细节：路径段改用 RFC 3986 百分号编码（PR #15989），修掉含特殊字符的表名；OpenAPI 增加 unregister table 端点、函数的 list/load 端点与 Variant 类型；Spark 新增把 DROP TABLE PURGE 委托给 REST Catalog 的属性，由目录而不是客户端决定怎么删文件。加密侧的最后一个阻塞项 PR #17984 把 manifest list 的加密密钥与使用它的快照一起提交，rewrite_manifests 现在会加密它写出的 manifest。
  • V4 的地基已经能看见：1.12.0 不产出 V4 表，但规范增加了 content stats 与相对路径，core 增加了 TrackedFile builder 与适配器、位置相对化工具、可选元数据位置，以及为 V4 写 Parquet 或 Avro manifest 的能力。相对路径是把表在 bucket 或区域之间挪动变成元数据操作的前提。
  • Rust 0.11.0 两次 RC 失败的原因都很有信息量：RC1 失败是因为 iceberg 与新 crate iceberg-property-macro 之间的循环 dev-dependency 让 cargo publish 无法执行，Kevin Liu 修掉循环并给 CI 加了 publish dry run。RC2 失败更关键——Alexander Bailey 发现 Rust 的加密实现跳过了 Java 要求的防篡改校验，导致候选版本写出的文件 Java 读不出来，修复（iceberg-rust PR #3236）是 RC3 的门槛。

行业影响

Rust 0.11.0 的第二次失败值得所有做多引擎湖仓的团队记住：一个 Rust writer 可以通过自己的全部测试，仍然产出 Java reader 拒绝的文件。单元测试抓不到这类问题，只有跨实现的 conformance 测试能抓到。Iceberg 社区为此新建的 apache/iceberg-verification 仓库就是用来放共享一致性 fixture 的，这个仓库的成熟度会比任何单个版本的功能列表更能决定 Iceberg 在异构引擎环境下的上限。

对使用者来说，1.12.0 是 V3 特性真正拿到引擎侧配套的版本：地理类型、来自流写入端的 shredded Variant、Flink 里的 deletion vector，恰好覆盖此前把多数团队留在 V2 的三类负载。但 Spark 在 1.12 里仍然不会默认建 V3 表——Cheng Pan 在 8 月问过，Neelesh 的回复是 Variant 与 geo 的缺口要先补上。V3 的普及还要再等一个版本。

相关链接

阿里云 OSS Tables：Spark 改一行 catalog 配置直连 Iceberg REST Catalog，不再需要 Hive Metastore

事件概述

9 月 16 日，阿里云社区发了一篇 OSS Tables 的深度文章，讲的是一件很具体的事：让 Spark 直接连 OSS 上的表，中间不再需要一套自建的 Hive Metastore。OSS Tables 原生兼容 Apache Iceberg REST Catalog 协议，Spark 用标准 Iceberg 客户端接上去，建表、查询、写入、时间旅行全部走标准 SQL，代码层面只改一行 catalog 配置。

文章把这个动作的动机讲得很直白。Spark 要读写湖里的表，先得有人记录有哪些表、schema 是什么、数据文件在哪，这个角色传统上由背后挂着一个关系库的 Hive Metastore 承担。它能工作，但每多一个组件就多一份运维负担，也多一块故障面。OSS Tables 的做法是把这个角色交给对象存储服务自己，通过标准协议对外提供。

技术解析

  • 接入配置：依赖是 iceberg-spark-runtime-3.5_2.12-1.10.1.jar 与 iceberg-aws-bundle-1.10.1.jar，两者版本必须一致，放进 $SPARK_HOME/jars 或用 --jars 传入；要求 Spark 3.5 及以上、Java 11 及以上。catalog 侧的关键配置为 catalog-impl 固定 org.apache.iceberg.rest.RESTCatalog、uri 填 https://{region}-internal.oss-tables.aliyuncs.com/iceberg（公网为 https://{region}.oss-tables.aliyuncs.com/iceberg）、warehouse 填 Table Bucket 的 ARN（acs:osstables:<Region>:<账号ID>:bucket/<桶名>）、rest.sigv4-enabled 固定 true、rest.signing-name 固定 osstables。
  • 凭证复用了 AWS 的命名：因为 Iceberg 的 sigv4 签名器与 S3FileIO 走的是标准 AWS SDK 凭证链，环境变量名带 AWS_ 前缀——AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_REGION，用 STS 临时凭证时再加 AWS_SESSION_TOKEN；填进去的值是阿里云的 AccessKey。文章特别提醒：用环境变量时 driver 和 executor 都要能读到，YARN 模式要在每个节点注入，Kubernetes 模式要注入到 pod，做不到就改用 Spark 配置项显式传。
  • 一个不能踩的配置坑：io-impl 不能设成 org.apache.iceberg.hadoop.HadoopFileIO。Iceberg 的设计本就避免 LIST 操作，而 OSS Table Bucket 是专为 Iceberg 调优的存储类型，直接禁掉 LIST；HadoopFileIO 为了兼容通用场景会发 LIST，接不进去。正确值是 org.apache.iceberg.aws.s3.S3FileIO，并配上 s3.endpoint（内网 https://oss-{region}-internal.aliyuncs.com）。
  • 维护被内化：文件合并、快照过期、孤立文件清理由 OSS Tables 内置，用户不必在 Spark 里手动跑 Iceberg 维护过程。
  • 两条硬约束：OSS Tables 目前只支持 Iceberg 格式，建表必须写 USING iceberg；删表必须带 PURGE 关键字，否则会报「OSS Tables only supports dropping tables with purge enabled」。

行业影响

这条更新与本期第一条是同一件事的两面：Iceberg 1.12 在把 REST Catalog 的边界磨细（路径百分号编码、unregister 端点、把 DROP TABLE PURGE 的决策权交给目录），云厂商在把 REST Catalog 实现成一项托管服务。两者叠加的结果是目录正在从「一套要自己部署和维护的服务」变成「一个按协议调用的端点」。

代价是配置正确性的责任从运维转移到了使用方。签名名固定为 osstables、签名区域必须与桶所在区域一致、两个 JAR 的版本必须对齐、凭证要在 driver 与 executor 两侧都存在——这些都不是能靠试错快速收敛的问题。io-impl 那条尤其典型：选错不是立刻报错，而是走到一条会发 LIST 的路径上，在一个禁止 LIST 的存储类型前撞墙。协议统一带来的便利，最终由配置面的严谨来兑付。

相关链接

不复制业务数据也能秒级接管：阿里云消息团队的 Replication-Free Failover 进了 ACM FSE 2026

事件概述

9 月 18 日，阿里云云原生社区介绍了消息团队被 ACM FSE 2026 Industry Papers Track 收录的论文《Replication-Free Failover: Protocol-Fenced Takeover for Stateful Services》，作者为金荣彤、顾寅友、季俊涛、傅玉宝、刘涛、赖福志、蔡高扬、林清山八人。FSE 2026 于 7 月 5 日至 9 日在蒙特利尔召开，Industry Papers Track 收的是经受过生产部署检验的工作。

论文要解的是云上有状态服务那个经典的三角矛盾：便宜、性能稳、恢复快，三者很难一起拿到。团队的切入点是——在数千个租户隔离的 RocketMQ 有状态集群里，不靠多副本能不能也快速恢复。

技术解析

  • 正常数据路径完全不变：方案保留单副本、单节点文件系统与云盘自带的存储侧冗余，在 RocketMQ 层不增加任何业务数据副本，也不产生额外的写放大，CommitLog 与 WAL 都不动。这样原有成本与稳态性能得以保留，与 Apache RocketMQ 社区版的兼容性也不受影响。
  • 所有权转移放在存储协议层：Multi-Attach 提前把磁盘暴露给候选节点，NVMe Persistent Reservation（NVMe PR）负责隔离写权限；再配合持有者校验、原子抢占、关键阶段标记与退避，确保恢复过程中写权限不会被再次抢占。
  • 接管一致性收成一个状态机：共享磁盘对新节点可见之后，恢复被压缩成一条闭环——确认写权限、清理陈旧缓存、挂载文件系统、回放 journal、执行崩溃恢复、通过就绪检查之后才恢复流量。
  • 故障检测问的是「还在持久化吗」而不是「还活着吗」：方案读共享磁盘上的租约版本进度来判断主节点是否仍在持久化。这个区别能抓住 I/O hang——节点在、持久化停了——也降低了对中心化控制面的依赖；网络分区期间则由存储层的写隔离保证接管后仍是单写者。
  • 高权限操作收进节点侧 Agent：NVMe PR、缓存处理、挂载等动作放在节点侧 Agent 里，业务容器不持有系统级权限；故障检测、权限切换、应用恢复与流量恢复串成一条可观测、可审计、可反复演练的端到端流程。
  • 效果：论文以 Apache RocketMQ 作为代表负载。常规 Kubernetes 单副本云盘配置需要数分钟恢复，该方案在秒级完成，且吞吐与延迟接近原生单副本部署。生产侧已完成数万次容灾演练并已上线。

行业影响

多数高可用路线是让节点变无状态：重构存储引擎、引入共享 WAL、挂上对象存储。这篇论文走的是反方向——保留 RocketMQ 的单节点文件系统与普通读写语义，只重做故障接管路径。因为 HA 机制不替代正常存储引擎，成熟的 CommitLog、文件系统缓存与崩溃恢复全部可以沿用，未来新增存储特性也不需要为 HA 单独重构一次。对 Broker 核心代码的侵入更小，社区升级更便宜，长期维护更轻。

把这条与 Iceberg Rust 的 RC2 失败放在一起看，两者的教训正好互补：一个跨实现的写入要能被另一个实现读出来，得靠共享的一致性验证；一个跨节点的接管要保证只有一个写者，得靠存储协议层的隔离。当「多存一份」不再是默认选项，证明「只有一份在被写」就成了新的地基工程。

论文全文见 ACM Digital Library，DOI 10.1145/3803437.3805226；阿里云侧对应的产品配置见 ApsaraMQ for RocketMQ 实例容灾文档。

相关链接

Managed Airflow Gen 3：排队时间近乎归零，Pine59 单条管道从近 38 分钟降到不足 26 分钟

事件概述

9 月 18 日，Google Cloud 与 Pine59 的高级数据工程师 Jan Hajný 联合发文，讲这家位置智能公司把数百个 DAG 的 monorepo 迁到 Managed Service for Apache Airflow（原 Cloud Composer）Gen 3 架构、跑 Airflow 3 的过程。Pine59 最重的指标之一是 Daily Foot Traffic，单个作业要计算多达 1400 万个不同位置的数据，重活在 BigQuery，编排全部交给托管 Airflow。

迁移动机来自一次压测。团队把生产负载放到刚可用的 Managed Airflow Gen 3 上跑，结果是处理速度、任务调度与整体稳定性立刻有可见改善，随后决定做完整迁移。

技术解析

  • 最直接的收益是排队时间：文章对比了同一个 DAG 超过 300 次运行在两种环境下的「queued + running」总时长——Managed Airflow Gen 2 配 Airflow 2.11，对比 Gen 3 配 Airflow 3.1，排队时间的差距非常明显。过去在峰值期任务常常卡在 queued 状态，Gen 3 下任务几乎立刻开始执行。
  • 单条管道的端到端数字：Daily Foot Traffic 管道此前耗时接近 38 分钟，新环境下同一负载不足 26 分钟。文章明确说明这中间也包含了迁移过程中做的 DAG 内部优化，两者叠加才得到这个结果——约 32% 的降幅不纯粹来自平台。
  • ML 推理从编排层剥离：过去 Pine59 用标准 Kubernetes operator 跑推理任务；迁到 Gen 3 后，团队单独建了一个专为模型推理优化的 GKE 集群并接入管道。编排与重量级 ML 计算分离，两类负载各自按自己的形状伸缩。
  • 两个自研插件：BigQuery Auto-linkify 自动识别 Airflow 日志与 XCom 里的 BigQuery 表名并生成到 BigQuery Studio 的直达链接（已作为公开 gist 发布）；DAG Run Configuration Search 在 DAG 概览页加了自定义搜索表单，可以按 DAG run 的 config 键值对检索运行实例。
  • 一层兼容 shim：团队在 monorepo 里加了一个 compat 模块，动态抽象不同 Airflow 版本之间的逻辑差异，用来简化跨版本的算子迁移。

行业影响

这条是同一个动作的第四种形态。Pine59 迁移里被拿掉的冗余不是数据副本，而是两层：排队等待，以及用通用 Kubernetes operator 承载 ML 推理。前者靠托管层的调度吞吐兑付，后者靠把执行外包给一个专用 GKE 集群兑付。「托管编排 + 专用执行」这个分工正在成为把 AI 负载塞进数据管道的主流解法——编排层负责依赖与重试，重计算交给形状匹配的集群。

要给这次迁移的数字加一条注脚：38 分钟到 26 分钟里包含了团队自己的 DAG 优化，文章没有给出拆分后的口径，不能把它读成纯粹的平台提速。排队时间的对比图也只有相对形态，没有给出绝对值。厂商客户案例里的百分比，在缺少对照组时都只能当作方向性证据。

相关链接

编者评

本期四件事落在四个不同的层，动作的形状却一致：都在删掉一个原本被认为必需的冗余，然后把正确性的赌注押到另一层协议上。阿里云消息团队删掉业务数据副本，改由存储协议层的 NVMe PR 写隔离来证明接管后只有一个写者；OSS Tables 删掉自建 Metastore，改由 Iceberg REST Catalog 协议与 sigv4 签名来证明访问者是谁；Iceberg 1.12 删掉 V2 里带行数据的位置删除，也一并删掉 Java 与 Rust 各写各的加密语义，改由共享 conformance fixture 来证明跨实现一致；Managed Airflow Gen 3 删掉排队等待，改由托管层的调度吞吐来证明任务能立刻跑起来。四处上移都配了一条限制条款，条款的位置就是各家认为最容易出事的地方：Rust 的 RC2 卡在防篡改校验上，OSS Tables 明确禁止 HadoopFileIO，Iceberg 要求升级前先给每张 V2 表定好去向，Google 那篇也写明 32% 的降幅里混着自己的 DAG 优化。把这些条款连起来看，2026 年下半年 DataInfra 的一条主线已经很清楚——冗余正在从数据层上移到协议层，而协议层的正确性只能靠可验证的测试与可审计的流程来证明，不能靠直觉。

本期中文源贡献了四条里的两条，是连续多期以来的第一次。被弃用的线索包括：阿里云 EMR Serverless StarRocks 与 DLF 的零迁移湖仓实践（9 月 17 日，教程性质，40 毫秒的查询耗时没有给基准口径，按优先技术内容的原则弃用）、Apache Flink 社区中文站同日发布的 FLIP-22 状态预声明与 FLIP-23 统一模型服务平台（后者是已被放弃的提案，前者尚无实现落地）、LanceDB v0.40.0-beta.3 与 ClickHouse v26.8.8.8-lts 两个补丁级发布、以及 Databricks 9 月 17 日一篇关于 Agent 网络搜索的文章（非数据基建）。DE Weekly 第 287 期是 9 月 13 日发刊，第 288 期尚未出，本期未取用；Snowflake、dbt、Anyscale、Flink 官方博客与 AWS Big Data Blog 在 9 月 18 日至 20 日均无新帖。