2026-06-22 ~ 2026-06-28
Danny Jones 提出 -1，原因是发现存在一个自 0.9.1 以来的回归问题，即用户覆盖摘要属性后可能导致反序列化失败并引发 panic。
提供的投票回复中未发现异议（-1 票），所有回复均为赞成票（+1）。
讨论主要围绕列更新文件应强制采用“密集表示”还是将选择权留给各个引擎实现。多位开发者指出，若不强制规定，实际上会迫使所有读取端支持实现更复杂的稀疏表示，因此共识转向强制使用密集表示以简化读取路径。Anurag 将在下次同步会议上正式确认这一决定。
@Péter Váry: 若规范不明确指定表示方式，实际上要求所有引擎都必须支持稀疏表示，这会增加读取路径的性能开销和复杂性。
@Steven Wu: 支持强制使用密集表示（填充值），认为反对该方案的论据（如统计信息偏差、存储开销）并不足以构成阻碍，且密集表示能简化读取器实现。
@Andrei Tserakhau: 强制密集表示能最小化读取器实现成本，且不阻碍未来扩展；稀疏表示更适合留待未来的“列族”功能作为独立的格式版本引入。
初步结论是强制采用密集表示，Anurag 将在下次同步会议中将其列入议程以正式确认并结束该讨论。
讨论旨在优化 Iceberg 读取 Parquet 小文件时的 S3 请求效率，提议将原本的 3 次 GET 请求合并为 1 次全文件获取。Varun Lakhyani 提交了 PR 并通过基准测试证明，该方案相比默认实现性能提升约 40%，且比 AWS Analytics Accelerator (AAL) 减少了 HEAD 请求。社区认可了该方案在跨平台兼容性和原生优化上的价值。
@Varun Lakhyani: 提出的 EagerInputFile 方案能将每个文件的请求减少到 1 次 GET，相比 AAL 仍有 8-10% 的性能提升，且适用于 ADLS 和 GCS 等多种存储。
@Steve Loughran: 建议通过 S3 日志精确统计请求数以验证优化效果，并强调在 Manifest 中正确缓存文件大小对于避免重复探测至关重要。
@Daniel Weeks: 倾向于改进原生实现而非过度依赖 AAL，认为这种跨实现通用的解决方案对社区更有价值。
初步结论是该优化方案可行且有效。下一步计划合并该 PR 用于小文件优化，同时结合 Vectored IO 方案处理大文件，并完善文件大小缓存机制。
Neelesh Salian 提议建立共享的跨实现一致性测试，以解决不同 Iceberg 客户端间存在的互操作性问题（如元数据分歧、读取失败等）。该提议获得了社区成员的广泛支持，Sung Yun 指出双方已有类似提案，同意合并文档并统一方案。
@Neelesh Salian: 指出各实现缺乏共享测试导致互操作性问题，提议建立跨实现一致性测试并提供了原型文档。
@Sung Yun: 认为其并行提案与 Neelesh 的方案高度重合，建议合并文档，并讨论仓库布局、子模块集成及 CI 消费方式。
@Tanmay Rauth: 建议采用“解码值而非字节”的对比方式，并设计测试夹具以同时支持读取和写入的一致性验证。
社区一致认为有必要进行此项工作，Neelesh 和 Sung 将线下同步并合并提案文档，后续可能举行社区会议以进一步讨论细节。
Dataddo 代表请求更新 Apache Iceberg Vendors 页面上的公司描述以反映其最新能力。社区成员建议直接提交 PR，但因发件人发现 GitHub issue 创建受限，转而请求维护者协助进行更改。
@Carmen Torremocha: 提议更新 Dataddo 的公司描述，重点突出消除运营风险及支持 AI 代理等新能力。
@Eduard Tudenhöfner: 建议通过直接提交 Pull Request 的标准流程来处理页面更新请求。
@Carmen Torremocha: 反馈因权限受限无法创建 GitHub Issue，请求维护者代为发起或执行更改。
暂无最终定论，目前等待社区维护者回应权限问题或协助执行内容更新。
讨论围绕在 Iceberg Core 中引入新的 switch 表达式展开，虽然相关 PR (#16881) 曾被合并，但社区在同步会议中对大规模代码变更表示了担忧。最终决定暂时回滚 Core 模块的更改，未来此类优化应拆分为独立的 PR 提交并由审阅者决定是否接纳。
@Neelesh Salian: 提议在 1.12 版本中对 iceberg-core 进行 switch 表达式和模式匹配 instanceof 的改造，后续确认将回滚已合并的 Core 更改。
@Eduard Tudenhöfner: 支持新语法以提高可读性，但建议将 instanceof 的更改放在单独的 PR 中；针对大规模变更的担忧提出了回滚选项。
@Kevin Liu: 支持拆分为单独的 PR，认为这样更易于审查和变基。
决定暂时回滚 Core 模块的 switch 表达式更改，未来相关修改需以独立 PR 形式提交，并视审阅情况而定。
讨论围绕 Apache Iceberg 1.10.3 和 1.11.1 补丁版本的发布计划及 PR 里程碑归属问题展开。社区明确了版本回溯策略：1.10.3 的修复需合入 1.11.1，但 1.11.1 的修复不一定回溯至 1.10.3。此外，Kevin 建议将 iceberg-rest-fixture 修复纳入 1.11.1 以恢复 Docker 镜像发布。
@Amogh Jahagirdar: 明确了补丁回溯策略，指出 1.10.3 的修复应合入 1.11.1，但 1.11.1 的修复不一定回溯至 1.10.3（取决于功能是否存在或问题严重性）。
@Kevin Liu: 建议将 iceberg-rest-fixture 修复纳入 1.11.x 版本，以便重新启用 Docker 镜像发布。
@Matt Butrovich: 提交了修复 manifest delete file size 的 PR，并建议将其回溯移植到 1.10.x 和 1.11.x 版本。
确立了补丁版本的回溯移植规则，下一步将继续审查相关 PR 并按策略进行版本发布准备。
讨论主要关于支持对旧分区规约的数据文件进行重分区，以解决大表数据迁移和 SPJ（存储分区连接）性能问题。Mukund Thakur 提交了相关 PR，Imran Rashid 和 Cheng Pan 基于实际生产痛点对此表示强烈支持。
@Mukund Thakur: 提议支持将旧分区数据文件重分区至新规约，已提交 PR #16190 并正在开发优化算法 PR #16515。
@Imran Rashid: 强调 SPJ 需要一致的分区策略，且现有工具无法处理大表（如 15TB）的增量迁移，难以满足生产 SLA。
@Cheng Pan: 分享了实际案例，指出旧数据文件不符合当前分区规约会导致 SPJ 失效，验证了该功能的必要性。
社区对该功能需求达成共识，下一步需等待社区对相关 PR 的审查反馈。
讨论主要围绕 PR #15407，即更新 Delta Lake 到 Iceberg 的迁移工具以使用 Delta Kernel。目前代码已完全可用并支持 Delta v3 和 Deletion Vectors，但尚未设为默认实现，作者正寻求关于 Delta 内部 API 使用的反馈。
@Vladislav Sidorovich: 代码已功能完备并支持 Delta v3 和 Deletion Vectors，但尚未设为默认实现，需确认如何处理 Delta 内部 API 的使用。
@Xin Huang: 建议使用新的 TableManager API 而非旧的 Table API，并避免依赖最新的内核代码。
下一步需就 Delta 内部 API 的使用方式与相关审阅者达成一致，并根据建议调整 API 依赖。
Chandra 提议在 Apache Iceberg 中引入原生主键表支持，以更好地满足 CDC 和运营分析等现代工作负载的需求。Matt 指出社区近期已有关于约束支持（含主键）的相关讨论，建议 Chandra 查看现有提案文档以对齐或扩展想法。Chandra 回复将研究现有提案并评估其想法的契合度。
@Chandra Sekhar K: 提议引入原生主键表支持，指出当前 Iceberg 缺乏标准化抽象，难以高效支持 CDC 引入和流式 upsert 等基于主键的工作负载。
@Matt Butrovich: 指出社区已有关于约束支持（包括主键）的讨论和提案，建议 Chandra 查看现有文档，看其想法是否契合或能扩展现有方案。
Chandra 将查阅现有的约束支持提案文档，以确定其提议如何与社区现有进展相结合。
Andrei Tserakhau 提交了排序规则支持的规范变更 PR 及 Go 和 Java 的参考实现，旨在通过字符串字段注解和数据文件边界维持查询剪枝能力。该设计通过存储原始值而非排序键解决了版本兼容性问题，并引入提供者限定标识符以支持多种排序规则，目前正就字段结构位置征求社区意见。
@Andrei Tserakhau: 建议边界存储原始值而非排序键以解决 ICU/CLDR 版本不稳定问题，并使用提供者限定标识符支持非 ICU 排序规则。
@Andrei Tserakhau: 提出结构疑问，询问 collation_bounds 应作为独立 v3 字段还是放入 v4 的 content_stats 结构中。
@Szehon Ho: 认可该方向很有前景，并在规范提案中留下了具体评论。
社区正在审阅提案，下一步需确定 collation_bounds 的字段归属问题，并继续完善规范细节。
本周新建 0 个 Issue
本周无新建 JIRA。