2026-06-08 ~ 2026-06-14
Ryan Blue 宣布投票通过，共有 13 票赞成且无 -1 反对票，因此不存在异议。
讨论主要围绕 Spark 发布加速后 Iceberg 的版本支持策略。由于 Iceberg 使用 Spark 内部 API 导致跨版本兼容性难以保证，且 CI 资源紧张，社区倾向于支持“最后一个 LTS + 两个最新次版本”的策略。目前大家同意先合并 Spark 4.2 支持，随后再投票决定是否移除 Spark 4.0。
@Cheng Pan: 对基于 Spark 4.2 编译的 Jar 在更高版本运行持悲观态度，因内部 Catalyst API 无兼容保证；建议先合并 4.2 支持，不阻塞后续开发。
@Szehon Ho: 鉴于 CI 挑战和兼容性信心不足，倾向于支持“最后一个 LTS + 两个最新次版本”的方案。
@Anurag Mantripragada: 同意先合并 Spark 4.2 支持，并计划在社区同步会议后发起移除 Spark 4.0 的投票。
初步达成共识，优先合并 Spark 4.2 支持，随后将启动关于移除 Spark 4.0 支持的投票流程。
Varun Lakhyani 提议优化 Iceberg 小文件（<= 1MB）的读取性能，通过一次性读取整个文件将 GET 请求次数从 3 次减少至 1 次。该方案已在 PR 中实现，并在 JMH 基准测试中取得了约 66% 的性能提升。此外，作者建议参考 arrow-rs 在 parquet-mr 中引入 footer size hint，以寻求更优的实现方式。
@Varun Lakhyani: 针对小文件读取，建议将原本分离的 footer 和数据读取合并为一次全文件缓冲读取，大幅减少 GET 请求。
@Varun Lakhyani: 初步测试显示该优化效果显著，处理 1000 个文件的时间从 537 秒降至 169 秒。
@Varun Lakhyani: 建议在 parquet-mr 层面暴露 footer size hint，以便采用更简洁的实现方式。
已提交初步实现的 PR #16729，目前正寻求社区对优化方案及 parquet-mr 相关改动的反馈。
Varun Lakhyani 提议优化 Iceberg 的 Parquet 读取路径，通过一次性获取整个小文件来消除当前的 3 次 GET 请求（Footer 大小、Footer、数据），以解决 S3 延迟问题。Russell Spitzer 认为这对 Root Manifest 和 V4 延迟优化至关重要，社区正在讨论是采用 Iceberg 优先方案还是改进 Parquet Java API。
@Varun Lakhyani: 建议对小文件采用单次 GET 请求获取全量数据，替代现有的串行请求模式（Footer 发现、Footer 获取、数据获取），从而降低延迟。
@Russell Spitzer: 认为该优化对减少 V4 延迟和串行请求瓶颈非常关键，倾向于 Iceberg 优先的解决方案，但也建议 Parquet Java 借鉴 Rust/C++ 实现增加新 API。
@Daniel Weeks: 认为这是值得投入的 IO 性能优化领域，但需考虑 FileIO 层的加密和指标处理，不应仅局限于 Parquet 视角。
社区一致认为这是重要的优化方向，下一步将具体评估实现路径（Iceberg 层或 Parquet API 层）及相关的技术细节（如加密支持）。
讨论了在模式演变过程中，策略生命周期管理（即“写入路径”）存在的缺口，即当前策略绑定列名而非字段 ID 导致的重定向和原子性问题。Sung Yun 澄清了这是关于策略的创建与更新而非执行，并提出了服务端绑定字段 ID 的解决方案。目前作者已分享详细分析文档供社区审阅。
@Sung Yun: 当前策略管理依赖列名，导致列重命名时策略重定向，且策略提交无法与模式变更保持原子性，建议通过服务端绑定字段 ID 来解决。
@Christian Thiel: 对提案感兴趣，建议明确名称到字段 ID 的绑定时机，特别是如何处理列的删除与重新添加（drop+re-add）场景。
@Daniel Weeks: 最初对写入端策略执行的必要性提出质疑（认为写入者通常拥有最高权限），后理解这是指策略的生命周期管理而非执行。
已形成初步分析文档，下一步由社区成员审阅文档并提供反馈。
社区讨论了发布 1.11.1 和 1.10.3 补丁版本的提议，旨在修复 V3 元数据正确性问题（如 DV 合并时的加密元数据保留）。Amogh 已创建 1.10.3 里程碑，多位成员投票支持发布，并提议在 1.11.x 中修复 Docker 镜像问题。
@Amogh Jahagirdar: 创建了 1.10.3 里程碑，并建议包含修复 DV 更改中加密元数据保留的 PR。
@Kevin Liu: 支持发布补丁，并提议在 1.11.x 版本中修复 iceberg-rest-fixture Docker 镜像。
@Manu Zhang: 支持发布补丁，但询问是否已创建 1.11.x 分支。
社区一致同意发布两个补丁版本，下一步需确认 1.11.x 分支状态并完成相关 PR 的审核与合并。
Aryash Gupta 跟进 PR #15639 的审查进度，Daniel Weeks 已查看代码但对核心逻辑提出异议。Russell Spitzer 解释邮件因审核机制卡顿导致回复延迟，并非有意忽视。
@Aryash Gupta: 请求更新 PR #15639 的状态，该请求已提交数月且指派给 @bryanck 但未获回复。
@Daniel Weeks: 质疑 PR 的行为逻辑，认为路由应由正确配置决定，而非在配置错误时进行假设。
@Russell Spitzer: 致歉称邮件卡在审核队列中，确认并非故意忽略该讨论。
PR 因行为逻辑存在争议尚未通过，需进一步讨论配置与路由假设的设计问题。
社区正在讨论 Iceberg Summit 2027 的筹备工作，重点在于选址建议及 EMEA 地区的活动推广。Danica Fine 强调，即将在格拉斯哥举办的 Lakehouse Day EU 的成功与否将直接影响未来在 EMEA 举办独立峰会的计划。讨论中成员们提出了包括美国西海岸、东海岸及欧洲多城市在内的多个潜在举办地。
@Danica Fine: 呼吁参与 10 月格拉斯哥的 Lakehouse Day EU，其成功将证明 EMEA 地区举办独立 Iceberg Summit 的能力。
@Viktor Kessler / Andrei Tserakhau: 建议在欧洲（如巴塞罗那、巴黎、柏林、阿姆斯特丹）举办峰会，以推动 Iceberg 全球化。
@Neelesh Salian / Bill Zhang / Kurtis Wright: 提议美国多地作为备选，包括圣克拉拉/圣何塞、纽约市以及西雅图/丹佛/芝加哥等。
目前尚未确定最终地点，当务之急是社区成员积极注册并参与 Lakehouse Day EU，以展示 EMEA 地区的需求。
讨论主要围绕如何在 REST 规范中将任意信息传递给请求签名者展开。参与者同意采用增量步骤，先定义一个包含基础字段的最小化结构体，而非一次性引入所有复杂特性。目前已在具体字段选择上达成初步一致，并推动了相关代码实现。
@Sung Yun: 建议分阶段实施，先采用仅包含 base-uri、endpoint-path 和 properties 的最小化结构体，后续再扩展可选字段。
@Alexandre Dutra: 同意最小化方案，但建议同时包含 headers 字段，并暂时排除复杂的“安全原语”直至刷新机制明确。
@Alexandre Dutra: 总结了之前的会议共识，包括使用结构体而非属性包，以及通过请求头传递安全原语。
双方就初始结构体方案达成一致，Alexandre Dutra 已提交 PR #16822 以落实这些变更。
讨论旨在澄清 Iceberg 规范中 `day` 分区转换字段在 Avro schema 中的类型定义模糊性问题。社区已达成共识，将结果类型从 `int` 更改为 `date`，以匹配主流实现行为并解决兼容性问题。目前正准备发起正式投票以合并规范澄清 PR。
@Kevin Liu: 建议保持解释的格式无关性，强调最关键的是将结果类型从 `int` 改为 `date`。
@Gang Wu: 确认 iceberg-cpp 也为 day transform 生成 date 类型，支持目前的共识。
@Andrei Tserakhau: 总结了共识内容（类型改为 date，历史兼容性遵循 Avro 规范），并指出修改 spec.md 需要正式投票流程。
下一步将发起正式投票流程，通过后合并 PR #16446 以正式澄清规范。
ASF 基础设施团队指出 Iceberg 项目仍是 GitHub 托管运行器的最大消耗者，虽然其占用比例略有下降。Yufei Gu 询问资源限制是基于所有仓库还是仅限主仓库，而 Abnob Doss 分享了 Rust 子项目通过修复重复构建显著节省 CI 时间的案例。团队建议参考最佳实践指南以进一步优化工作流。
@Bob Thomson: 通报 Iceberg 仍是运行器资源的最大消耗者，提供了优化工作流的最佳实践指南，建议关注耗时最长和最频繁的任务。
@Yufei Gu: 询问资源限制是基于所有仓库还是仅限主仓库，建议若整体使用合理可提高单仓配额。
@Abnob Doss: 分享了 Rust 子项目的优化案例，通过修复重复构建问题节省了大量 CI 运行时间。
社区正积极进行 CI 优化（如 Rust 子项目的修复），后续应继续参考最佳实践指南，重点关注耗时最长和执行最频繁的任务（如 Java 构建）。
本周新建 0 个 Issue
本周无新建 JIRA。