2026-04-27 ~ 2026-05-03
Kurtis Wright 提议在 Iceberg 的文件层和 Catalog 层引入校验和机制，以增强数据的持久性和完整性。社区对此意见不一，部分开发者认为现有存储层已具备校验功能且元数据校验存在安全局限，而另一部分则分享了实际生产中检测到数据损坏的案例。最终发起人计划提交一份正式提案，建议将该功能设计为可选特性。
@Kurtis Wright: 提议在多个层级添加校验和以确保持久性和完整性，并倾向于将其设计为可选功能而非默认强制。
@Daniel Weeks: 反对引入该功能，认为现有 FileIO 检查已足够，且元数据校验和无法防止恶意篡改，只会增加不必要的复杂性。
@Andrei Tserakhau: 支持该提议，指出在生产环境中确实观测到了现有校验机制无法捕获的数据损坏问题，格式层校验能提供额外保障。
发起人将提交一份正式提案，建议将校验和作为可选功能，以进一步评估其在生产环境中的价值。
讨论核心在于 REST Catalog 中存储凭证与 KMS/加密凭证的管理方式是否应分离，以及当前 PR 是否应包含服务端凭证分发机制。虽然大家一致认为应解耦这两类凭证，但在当前 PR 是仅作为基础脚手架先行合并，还是应等待完整的凭证分发设计上存在不同意见。
@Chris Lu: 建议将存储凭证和加密凭证分开，因为二者范围、生命周期和故障模式不同，并提出可使用类型化凭证模型以便扩展。
@Prashant Singh: 反对当前 PR 仅从客户端获取加密凭证而服务端分发存储凭证的做法，认为服务端应负责分发所有必要凭证以保证权限模型的一致性。
@Ádám Szita: 认为支持表加密与定义 KMS 凭证分发机制是两个独立话题，不应强制要求 REST Catalog 实现凭证分发才能支持加密，以免阻碍现有功能。
初步结论是需要在规范层面将 KMS 凭证与存储凭证解耦。下一步建议是不要急于合并代码，需先明确规范变更和凭证分发的设计细节。
讨论主要聚焦于 Iceberg 部分更新功能的文件表示形式选择。社区已决定采用“完整/密集”表示法以简化写入逻辑，而非稀疏表示法。目前仍需解决当基文件包含删除行时，更新文件应如何对齐或填充数据的开放性问题。
@Gábor Kaszab: 确认选择密集表示法，因为稀疏表示在合并多次字段更新时极其复杂，且密集方案的 PoC 显示其性能优于现有 MoR。
@Péter Váry: 支持密集表示，因为行数对齐的文件能极大简化向量化读取器的数据拼接过程，避免稀疏转换开销。
@Gang Wu: 提出担忧，认为密集文件可能增加 SQL 计划的复杂性（需读取旧值或额外元数据），可能抵消写入加速的优势。
已确定部分更新采用“完整/密集”表示法；下一步将重点讨论如何处理基文件中已删除行的表示方式（如填充辅助值或跳过），以及是否需要分发行数元数据。
讨论主要关注 metadata.json 在读取路径上造成的内存压力问题，特别是在 Trino 协调器缓存大量表元数据时。Grant 提议对 snapshotLog 实施延迟加载以缓解堆内存占用，并提交了原型 PR，讨论随后扩展到了快照压缩和缓存策略权衡等解决方案。
@Grant Nicholas: 指出流式负载下 snapshots 和 snapshotLog 线性增长导致内存压力，提议对 snapshotLog 实施延迟加载，并建议短期优化读取路径，长期探索快照压缩等方案。
@Amogh Jahagirdar: 支持改进但指出时间旅行查询需加载日志会限制优化效果，建议对于高频写入表考虑直接查询目录而非缓存元数据，并明确此问题非 V4 特有而是实现层面的改进。
@Péter Váry: 提出“选择性快照压缩”的概念，建议通过合并历史快照来减少元数据中需要保留的快照数量。
初步确定短期方案为优化读取路径（如延迟加载），长期将探索选择性快照压缩、分离存储以及 REST catalog 改进等措施。
Yuya Ebihara 提议在 REST Catalog 中支持递归列出命名空间，以解决 Trino 等客户端因逐级请求导致的性能瓶颈。该提议已提交草案 PR，旨在为接口增加可选的 'recursive' 参数，并获得了社区成员的初步支持。
@Yuya Ebihara: Trino 连接器目前需逐级请求并扁平化结果，效率较低，建议通过添加 'recursive' 参数解决此问题。
@Ajantha Bhat: 认同该功能的价值，能减少客户端调用，但建议代码实现应更简洁和简化。
@Yufei Gu: 支持添加此可选参数，认为这对需要扁平化命名空间树的客户端非常有用。
提议获得初步认可，下一步将根据反馈完善 PR 的代码实现。
讨论主要围绕 Iceberg Java 1.11.0 版本发布的阻碍项清理进展展开。Aihua Xu 表示许可证问题已基本解决，仅剩一个核心功能 PR 待合并，Maximilian Michels 确认移除特定依赖项不构成发布阻碍。
@Aihua Xu: 大部分许可证阻碍已清理完毕，目前仅剩一个关于服务端错误消息传递的 PR 待合并。
@Maximilian Michels: 确认移除 flink-metrics-dropwizard 依赖项不是发布阻碍项，LICENSE 文件已更新。
@Aihua Xu: 计划在合并剩余的许可证相关 PR 后，继续推进发布流程。
待合并剩余的许可证 PR 和最后一个核心阻碍 PR 后，将推进发布流程。
讨论主要围绕解决 LICENSE 文件问题以解除 Iceberg 1.11 及 1.10.2 版本的发布阻塞。参与者提议暂时将 kafka-connect-runtime 和 open-api 从发布中排除，并提交了多个 PR 以修复云服务包及计算引擎的 LICENSE 文件。此外，社区成员指出了 Gradle 构建配置中存在的 artifact 误发布问题，建议后续进行清理。
@Kevin Liu: 提议排除 kafka-connect-runtime 和 open-api 以解除发布阻塞，并提交了修复多个云平台及计算引擎 LICENSE 文件的 PR。
@Fokko Driesprong: 同意不发布 Open-API jar，指出其构建的 Docker 镜像仅用于开发测试，不应作为发布物。
@Jean-Baptiste Onofré: 指出 Gradle 配置导致 test-fixtures 被误发布，同意暂不发布相关 artifact，建议版本发布后审查依赖。
初步达成共识，通过排除特定模块和合并 LICENSE 修复 PR 来解除 1.11 发布阻塞；后续将在版本发布后对依赖项和 Gradle 配置进行详细审查。
讨论主要围绕 Iceberg V4 规范中是否保留 partition tuple 展开，核心共识是暂时保留该结构以支持 equality deletes。参与者建议限制 partition tuple 的使用范围，并推动使用 stats 方式处理过滤和剪枝，以便未来能平滑移除该特性。
@Russell Spitzer: 建议暂时保留 partition tuple 以满足 equality deletes 的需求，但在 V4 代码中应隔离对其访问，为后续移除并转向 stats 方案做准备。
@Steven Wu: 同意暂时保留 partition tuple，并主张将其仅限于 equality deletes，同时扩展 stats 方法以覆盖非单调分桶和多参数转换。
@Micah Kornfield: 询问针对 Hive 表迁移的列投影边缘情况，应使用 tuple 还是 stats 处理 Identity 分区列。
初步结论是暂时保留 partition tuple，下一步行动包括在 V4 代码中隔离 tuple 访问逻辑，并致力于扩展 stats 结构以替代 tuple 进行过滤。
Ryan Blue 针对 Slack 平台上出现的营销和招揽行为发出警告，重申社区准则并指出违规者可能被禁言，旨在维护健康的协作环境。Robin Moffatt 随后建议设立 #mods 频道，以便非邮件列表用户也能便捷地举报违规内容或讨论管理问题。
@Ryan Blue: 强调社区禁止营销、招揽及招聘行为，违规账户将被 PMC 禁用，呼吁收到骚扰私信的用户向 PMC 成员举报。
@Robin Moffatt: 建议在 Slack 建立 #mods 频道，方便用户直接举报问题或讨论内容合规性，覆盖未订阅开发邮件列表的人群。
社区明确了打击违规招揽行为的立场，下一步可能会讨论或评估设立专门管理频道（#mods）的可行性。
Rich Bowen 代表主办方邀请 Iceberg 社区参加 Community Over Code Glasgow 2026 的黑客马拉松活动。此次活动作为试点重启，旨在为贡献者提供协作解决 Bug、文档等实际任务的空间。主办方希望 Iceberg 能指定联系人、准备任务清单并协助推广，以确认参与意向。
@Rich Bowen: 邀请 Iceberg 参与 Glasgow 2026 黑客马拉松，旨在让新老贡献者协作处理 Bug、文档等实际任务。
@Rich Bowen: 参与项目需提供现场联系人、准备任务清单（如 good-first-issues）并进行社区内部推广。
@Rich Bowen: 这是重启黑客马拉松的试点项目，建议感兴趣者回复邮件确认或加入 Slack #hackathon 频道沟通。
Iceberg 社区需回复邮件确认参与意向，或加入 ApacheCon Slack 的 #hackathon 频道进行进一步协调。
本周新建 0 个 Issue
本周无新建 JIRA。