datainfra前沿动态 · Vol.34

Iceberg V4 社区投票周：equality delete 的终局、Flink 转换方案就位；Parquet File 逻辑类型 18:0 通过；Apache 湖仓 IaC 化加速

本期聚焦 Apache 湖仓社区 7月11-18日开发动态：Iceberg V4 规范中 equality delete 面临废弃、Flink 转换方案正式就位消除最后技术障碍；Parquet File 逻辑类型全票通过为多模态 AI 数据集提供原生格式载体；Iceberg 与 Polaris 同时推进 Terraform Provider 标志着湖仓基础设施进入声明式管理时代。

DataInfra Apache Iceberg Iceberg V4 Equality Delete Deletion Vector Apache Flink Apache Parquet File Logical Type ALP Encoding Terraform IaC DataFusion Comet Ballista Apache Arrow Iceberg Rust

本期聚焦 7 月 11 日至 18 日 Apache 湖仓社区开发列表的密集活动——268 条消息、约 80 个独立线程、2 项格式级投票、5 个候选版本、1 位新 Committer。核心动态三条：Iceberg V4 规范中 equality delete 的废弃讨论正式推进，Flink 的 equality delete → deletion vector 转换方案（ConvertEqualityDeletes）以 6 个 commits 合并完成，消除了废弃 equality delete 的最后一个技术障碍；Parquet File 逻辑类型以 18:0 的压倒性票数通过，为多模态 AI 数据集（图像、音频、文档与表格特征并存）提供原生格式载体；Iceberg 与 Polaris 的 Terraform Provider 同时进入投票阶段，标志着湖仓基础设施从”手工运维”向”声明式管理（IaC）“的集体转型。

事件概述

2026 年 7 月 11 日至 18 日，Apache Iceberg 开发列表成为整个湖仓社区最活跃的技术讨论场——71 条消息分布在 equality delete 废弃、向量类型支持、排序规则一致性、manifest 条目唯一性、Vortex 文件格式、共享一致性测试 fixtures、完整性验证 action 等十余个线程中。最重磅的线程由 Huaxin Gao 发起：正式在 V4 规范的框架下重启 equality delete 废弃提案，而 Maximilian Michels 同期宣布 Flink 的 equality delete → deletion vector 转换方案（ConvertEqualityDeletes）已通过 6 个 commits 合并完成——这意味着 Russell Spitzer 在 2024 年 10 月首次提出废弃 equality delete 时缺失的”可行替代方案”，现已正式到位。

技术解析

  • equality delete 的技术债务：Iceberg 支持两种删除方式。equality delete（“删除所有 id=42 的行”）写入极快——流式写入器可以在微秒级发出而无需读取任何数据——但将所有读取成本转嫁给 reader：每次查询必须在序列号范围内对所有候选行执行 join 操作。positional delete（“删除文件 X 的第 1,507 行”）+ V3 deletion vectors 则将删除信息压缩为每个数据文件一个 bitmap，reader 只需 O(1) 位置检查。equality delete 还会阻塞 CDC 和行血缘——因为存在 equality delete 时表的真实状态需要全表扫描——并强制物化视图和二级索引的完全重建而非增量维护。参与讨论的 Steven Wu、Manu Zhang、Maximilian Michels、Xin Huang 等贡献者在首日即产生 8 条消息，共识方向明确：V4 是做出这个结构性决定的正确时间窗口。

  • Flink ConvertEqualityDeletes 的工作原理：新功能作为表维护任务 ConvertEqualityDeletes 发布，与 IcebergSink 集成。写入器继续以 equality delete 方式高效产出数据文件和 delete 文件；转换器读取它们，使用 Flink 状态中 RocksDB 支持的主键索引将 delete 解析为 deletion vectors，提交数据文件 + DV 到目标分支。支持两种部署模式：分离分支模式（写入在单独分支上进行，reader 永远看不到 equality delete）和单分支模式（在同一条分支上原地转换）。这为流式写入场景提供了”先用 equality delete 快速写入、后台异步转换为 DV”的完整路径，正是 2024 年时缺少的可行方案。

  • 其他 V4/Spec 进展：Yan Yan 发起 first-class vector type support 提案——面向 AI embedding 存储场景，偏好密集数值向量类型如 float[768]，与 Parquet 社区的 fixed-size lists 工作并行推进。Andrei Tserakhau 等深入讨论跨引擎字符串排序一致性问题——不同引擎使用不同 ICU 版本导致排序结果不同，在表级别固定 ICU 版本可保证一致性但牺牲升级自由。Russell Spitzer 推动在规范中明确 live manifest entries 必须按文件路径唯一。Neelesh Salian 等提出共享一致性测试 fixtures——创建独立于语言的共享仓库（参考 parquet-testing），PyIceberg、iceberg-rust 和 iceberg-go 已有概念验证。Priyadarshini Mitra 提出 ValidateTableIntegrity action——遍历完整元数据图验证所有引用文件在存储中存在。

行业影响

本周 Iceberg V4 社区活动揭示了一个重要的开源治理模式：大型格式级决策（如废弃一个删除机制）不是由单一厂商在封闭路线图中拍板，而是在公开邮件列表中由多厂商贡献者共同论证、等到可行替代方案就位后才推进。Flink 转换方案在 equality delete 废弃讨论重启的同一周合并完成，不是巧合——社区在”关门前先铺路”。这种”先证明替代方案可行，再讨论废弃旧方案”的节奏，是 Apache Way 治理模式下格式演进的标准操作流程。

从技术趋势看，equality delete 的潜在废弃和 deletion vector 的全面采用，将进一步拉近 Iceberg 与 Delta Lake 在 DML 性能上的距离——Delta Lake 从一开始就以 deletion vector 为主要删除机制。如果 V4 移除 equality delete 的强制支持，Iceberg 的读取路径将显著简化：不再需要处理两种互不兼容的删除文件格式的 join 逻辑。对于湖仓引擎开发者（Trino、StarRocks、Dremio 等），这意味着更简单的 reader 实现和更可预测的查询性能。

相关链接

Apache Parquet File 逻辑类型 18:0 全票通过——多模态 AI 数据集获原生格式载体，ALP 编码投票在即

事件概述

2026 年 7 月中旬，Apache Parquet 社区完成了一项里程碑式投票：由 Burak Yavuz 发起的 File 逻辑类型提案以 18 票 +1（含 4 票 binding）全票通过。投票人涵盖 Daniel Weeks、Russell Spitzer、Andrew Lamb、Gang Wu、Fokko Driesprong、Steve Loughran、Gunnar Morling 等跨项目核心贡献者。同时，Prateek Gaur 宣布 ALP（Adaptive Lossless Precision）浮点数据编码已准备就绪进入正式投票阶段——Arrow C++ 解码器可逐位读取 Java 写入数据，约 156 万个值和 18 个测试 fixture 实现零不匹配。Fokko Driesprong 计划下周启动 Parquet 1.18.0 发布流程。

技术解析

  • File 逻辑类型的设计意图：File 逻辑类型允许 Parquet 列携带类似文件的二进制 payload，并附加明确的语义标注（MIME 类型、文件名、大小等元数据）。在多模态 AI 数据集场景中——一张表内同时存在数值特征列、文本嵌入列、原始图像列和音频片段列——File 逻辑类型让查询引擎能够识别”这一列是 JPEG 图像”而非”这一列是未知二进制 blob”，从而实现智能预览、类型感知的谓词下推和跨引擎的工具互操作。这与 Iceberg 社区正在推进的向量类型支持（float[768]）形成互补——前者解决”未结构化数据如何存储在列式格式中”的问题，后者解决”结构化向量如何被类型系统识别”的问题。

  • ALP 编码的工程严谨性：ALP 专为浮点数据（Float32/Float64）设计，通过利用浮点数的精度分布特性实现无损压缩。Prateek Gaur 的测试方法论值得关注：使用 Arrow C++ 解码器逐位验证 Java 编码器产出——156 万个值、18 个 fixture 零不匹配——这种”跨语言逐位验证”远超出典型的单元测试覆盖范围，反映了 Parquet 社区对格式正确性的极高工程标准。对于时序数据库、IoT 传感器数据和科学计算场景，ALP 编码可显著降低浮点列的存储和 I/O 成本。

  • FIXED_SIZE_LIST 加速：Andrew McCormick 分享了 hint-aware reader 的基准测试数据——使用 Dremel 解码完整路径需约 2,600 纳秒/行，而利用 fixed-size 提示跳过 Dremel 组装后仅需约 1,430 纳秒/行，加速约 45%。这一优化对 embedding 向量存储场景至关重要——float[768] 的 fixed-size list 是 embedding 在 Parquet 中的自然表示。

  • 格式版本化 RFC 独立推进：Micah Kornfield 将格式版本化变更从主提案中抽成独立 RFC PR，放弃 SemVer 命名改用纯语言描述，建议写入器在格式发布后 6-18 个月内切换到新默认版本。这种渐进式的版本迁移策略反映了 Parquet 作为”最广泛部署的列式格式”的特殊约束——格式变更必须考虑数以万计的生产部署的向后兼容性。

行业影响

Parquet File 逻辑类型的通过，加上 Iceberg 社区的向量类型提案和 Parquet 社区的 ALP 编码即将投票，共同指向一个趋势：列式存储格式正在从”纯表格数据”向”多模态 AI 数据”扩展其语义表达能力。过去，图像、音频等非结构化数据在数据湖中通常以单独的对象存储路径存在，通过 URI 引用关联到表行——这种”外挂”模式割裂了数据治理、事务一致性和查询优化。File 逻辑类型让这些数据成为 Parquet 行中的一等公民，受同一事务保护、享受同一查询引擎的谓词下推。

从更广的视角看，Parquet 1.18.0 的即将启动标志着 Parquet 社区在 2026 年下半年的发布节奏加速。1.17.0（2025 年 10 月）引入了 Variant 类型和 Geo 类型支持，1.18.0 预计将在 File 逻辑类型和 ALP 编码的基础上进一步扩展格式的语义覆盖面。对于 Iceberg V4 和 Delta Lake 5.0 来说，Parquet 的演进直接决定了格式层的能力边界——因为两者都以 Parquet 为默认数据文件格式。

相关链接

Apache 湖仓 IaC 化加速——Iceberg + Polaris Terraform Provider 同时推进，DataFusion/Comet/Arrow 发布列车密集到站

事件概述

2026 年 7 月中旬，Apache 湖仓生态出现了一个值得关注的横向趋势：基础设施即代码（IaC）正在成为湖仓项目的标配。Matt Topol 发起了 Iceberg Terraform Provider v0.1.0 RC0（后升级至 RC1），支持通过 Terraform/OpenTofu 声明式管理 Iceberg 表、命名空间和目录配置；Sung Yun 同期发起了创建 terraform-provider-polaris 仓库的 lazy consensus 提案。与此同时，Apache 湖仓的多个子项目/相关项目在本周密集发布候选版本：DataFusion 54.1.0 RC1、Ballista 54.0.0 RC2（已通过）、Comet 0.17.1 RC1（已通过）、Arrow JS 21.2.0 RC1、Arrow Rust Object Store 0.14.1 RC1——形成了一条跨越查询引擎、分布式计算、Spark 加速和内存格式的”发布列车”。

技术解析

  • Terraform Provider 的双重意义：首先是运维层面——湖仓基础设施（表、命名空间、权限策略、存储配置）的创建和变更可以纳入 GitOps 工作流，享受版本控制、代码审查、CI/CD 自动化和漂移检测。其次是生态层面——Terraform 是跨云基础设施管理的最大公约数，Iceberg 和 Polaris 的 Terraform Provider 使得湖仓资源可以与 AWS S3 桶、GCP BigQuery 数据集、Databricks 工作区等云资源在同一份 Terraform 配置中统一编排。Iceberg Provider RC1 由 Neelesh Salian、Alex Stephen、Sung Yun 等多位贡献者验证，已准备好面向 Terraform 和 OpenTofu 注册表发布。

  • DataFusion/Ballista/Comet 三箭齐发：Matt Butrovich 同时主导 DataFusion 54.1.0 RC1 和 Comet 0.17.1 RC1 两个版本投票，Andy Grove 的 Ballista 54.0.0 RC2 在 RC1 失败后迅速修复并通过。这三个项目形成了一条清晰的 Rust 原生数据处理栈——DataFusion 是 SQL 查询引擎、Ballista 是分布式执行层、Comet 是 Spark 加速插件（刚在 Vol.33 中以 Iceberg 加速场景深度覆盖）。三者在同一周进入发布流程，且版本号对齐到 54.x/0.17.x，体现了 DataFusion 生态的协同发布节奏。

  • Arrow JS 21.2.0 和 Arrow Rust Object Store 0.14.1：Arrow JS 由 Sutou Kouhei 主导，面向前端/Node.js 数据分析场景；Arrow Rust Object Store 由 Andrew Lamb 发起，是 Rust 生态中访问 S3/GCS/Azure Blob 等对象存储的核心抽象层——Iceberg Rust、DataFusion 和 Ballista 都依赖它进行数据文件 I/O。0.14.1 的修复直接影响整个 Rust 数据处理栈的稳定性。

  • 新 Committer 诞生：Andrew Lamb 宣布 Adam Gutglick 晋升为 DataFusion Committer——这是 DataFusion 社区持续增长的标志，也是本期”发布列车”背后的社区治理基础。

行业影响

Terraform Provider 的集体推进揭示了一个更深层的趋势：湖仓基础设施正在从”运维脚本 + Web 控制台”时代进入”声明式配置 + GitOps”时代。这与 2023-2025 年 Kubernetes 生态中 Operator Pattern 的普及路径高度相似——先是手工 kubectl apply，然后是 Helm Chart，最后是 Terraform/Crossplane 的声明式管理。湖仓当前正处于从”手工创建表”到”Terraform 管理表”的转型起点。

DataFusion 生态的密集发布则指向另一个方向：Rust 在数据基础设施中的渗透正在从”单点组件”走向”全栈替代”。DataFusion（SQL 查询引擎）+ Ballista（分布式执行）+ Comet（Spark 兼容加速）+ Arrow Rust（内存格式 + 对象存储访问）已经构成了一条从 SQL 解析到分布式执行到持久化 I/O 的完整 Rust 数据处理栈。这套栈目前仍处于 Spark 的”补充和加速层”地位（如 Comet 保留 Spark 的查询规划，仅替换物理执行），但如果 Ballista 的分布式能力持续成熟，未来可能出现独立于 JVM 的纯 Rust 数据处理平台。

相关链接

编者评

本期是 datainfra 前沿动态创刊以来首次以”开发列表活动”而非”产品/版本发布”为主角的期刊。这并非因为 7 月中旬缺乏产品发布——事实上有 Polaris 1.6.0（7 月 8 日）和 Spark 3.5.9（7 月 16 日）等版本释出——而是因为 Iceberg V4 的规范演进正在进入一个”决定格式未来数年走向”的关键窗口期。equality delete 的废弃讨论、File 逻辑类型的全票通过、ALP 编码的投票在即、向量类型的首次提案——这些不是”某个版本的新功能”，而是”格式的设计哲学在社区公开辩论中逐渐成型”。

这种”开发透明性”正是 Apache Way 的核心价值：即使你没有投票权，你可以在提案阶段看到为什么某个设计被选择、为什么某个旧机制被废弃、替代方案是什么。对于正在规划 2026-2027 年数据架构的团队来说，Iceberg V4 的开发列表不是噪音——是最准确的技术路线图，比任何厂商的 keynote 都更早揭示方向。如果 V4 按当前节奏在 2026 年底或 2027 年初发布，那么今天开发列表上的每一个”VOTE”线程都是未来生产环境的默认行为。