Iceberg 社区周报 | 2026-W12

2026-03-16 ~ 2026-03-22

📢 公告 (1)

🗳️ 投票 (3)

💬 讨论 (10)

HostnameVerificationPolicy in TLSConfigurer

11 条回复 · 4 位参与者

社区讨论了在 1.11.0 版本发布前,TLSConfigurer 中 HostnameVerificationPolicy 的默认设置问题。虽然最初提议默认使用更安全的 BOTH 模式,但讨论最终转向了更保守的方案,即根据是否提供自定义验证器来区分使用 CLIENT 或 BUILTIN,并决定不暴露 BOTH 选项以避免误用。

@Russell Spitzer: 反对默认使用 BOTH 或将其暴露,认为这容易导致误用且缺乏实际需求;建议逻辑应为:若存在自定义验证器则用 CLIENT,否则用 BUILTIN。

@Alexandre Dutra: 最初支持 BOTH,认为其能结合自定义逻辑与标准 JSSE 验证以增强安全性,但也指出了实现细节上 hostnameVerifier 默认非空的问题。

@Steven Wu: 最终认同 Russell 的观点,认为应保持 API 的限制性,不暴露 BOTH,若未来有明确需求再开放新接口。

达成初步结论,不暴露 HostnameVerificationPolicy.BOTH,而是采用 Russell 建议的逻辑(有自定义验证器时用 CLIENT,无则用 BUILTIN),以此解除 1.11.0 版本的发布阻碍。

REST Spec: Clarify identifier uniqueness across catalog object types

9 条回复 · 7 位参与者

讨论主要集中在 REST 规范中表和视图的标识符唯一性规则及其错误提示信息的不一致问题。Steven Wu 更新了 PR 以统一 409 冲突的措辞,明确强制表和视图之间的跨类型唯一性。社区达成共识,表和视图共享命名空间,而函数作为独立对象不受此限制。

@Steven Wu: 更新了 PR 以统一 409 冲突的错误提示,明确表和视图在重命名或创建时需强制跨类型唯一性检查。

@Péter Váry / Ryan Blue: 支持表和视图共享命名空间,但强调函数应作为独立对象处理,允许与表或视图同名。

@Daniel Weeks: 指出该问题主要局限于规范定义,对实现影响较小,建议通过简单的错误信息调整或 'oneOf' 响应来解决。

初步结论是确认表和视图必须跨类型唯一,而函数可以与它们同名。下一步行动是合并 Steven Wu 的 PR 以修复表/视图的错误信息,并由 Huaxin Gao 在后续的函数端点 PR 中明确说明函数的命名空间规则。

[SPEC] Add 404 response for /v1/config endpoint

8 条回复 · 5 位参与者

讨论提议在 Iceberg REST Catalog 规范中为 /v1/config 端点增加 HTTP 404 响应,以明确处理请求的 warehouse 不存在的情况。经过对 404 与 204 状态码适用性的讨论,社区确认了 404 的合理性及其与现有实现(如 Snowflake、Polaris)的一致性。

@Oğuzhan Ünlü: 提议将 404 响应正式纳入规范,以匹配 Snowflake Open Catalog 的现有生产行为,并保持与其他 Iceberg REST 端点处理缺失资源逻辑的一致性。

@Steven Wu: 最初质疑 404 可能引起歧义并建议使用 204 No Content,但在讨论后认可 404 是当前架构下的可接受方案。

@Kevin Liu: 支持该提议,指出 Apache Polaris 已有类似实现,并强调可通过错误响应中的 type 字段区分“路由不存在”和“资源不存在”。

社区达成共识,同意接受该提议,将通过 PR-15746 在 OpenAPI 规范中添加 NoSuchWarehouseResponse 以正式支持 404 响应。

Adding Tags field to Iceberg V4

6 条回复 · 5 位参与者

讨论围绕是否在 Iceberg V4 规范中添加 'attributes' 字段展开,提案人 Micah 试图将其纳入 V4 元数据更新以统一字段编号。然而,Prashant Singh 和 Russell Spitzer 对此表示强烈反对,主要担忧其对查询性能、互操作性及生态分叉的潜在风险。目前社区尚未达成共识,计划通过后续会议或邮件继续讨论。

@Micah Kornfield: 提议将字段重命名为 'attributes' 并纳入 V4 元数据提案,以确保字段编号一致性,并已根据社区反馈更新了相关限制细节。

@Prashant Singh: 反对提案,认为可配置的字段大小会严重影响清单文件条目数量和查询性能,且可能被用于存储供应商专有数据从而破坏互操作性。

@Russell Spitzer: 倾向于不添加该字段,认为这可能导致 Iceberg 生态分叉,且字段的复制行为难以定义,无法保证存储值的有效性。

由于存在重大反对意见,社区目前未达成共识。下一步行动是 Micah 将组织专门的同步会议(或利用社区例会时间)进行进一步讨论,同时也欢迎在邮件列表或设计文档中继续反馈。

A dashboard pulling together Iceberg design docs, threads, and more

3 条回复 · 4 位参与者

Guy Khazma 发起了一个仪表板项目,旨在整合 Iceberg 社区分散的设计文档、邮件讨论和 GitHub 信息。社区普遍认可该方向,认为能显著提升信息获取效率,但也指出当前版本存在内容缺失。讨论进一步涉及了是否将其托管至官网、资源维护方案以及标准化数据源的建议。

@Péter Váry: 认为整体方向很好,但建议建立规则或结构以便于信息发现,并指出目前缺少关于列更新和二级索引的文档。

@Yufei Gu: 希望该页面能托管在 Iceberg 官网上,并建议列出所有进行中的提案详情(如设计文档、会议安排、PR 等)。

@Maximilian Michels: 建议重点在于标准化数据源和爬虫逻辑,这样可以为未来构建各种仪表板提供良好的基础。

初步结论是项目有价值但需完善。下一步行动是 Guy 将继续迭代爬虫以填补缺失内容,社区后续需讨论托管及资源支持方案。

Efficient column updates in Iceberg

3 条回复 · 4 位参与者

讨论主要围绕 Iceberg 高效列更新的 POC 实现展开,展示了行对齐列更新文件表示的初步结果,并探讨了变更检测机制。团队测试了多线程并行读取策略,发现在独立环境下能提升性能,但在 Spark 集成中因 CPU 饱和导致性能下降。

@Anurag Mantripragada: 展示了行对齐列更新的初步结果,计划扩展 POC 以对比稀疏表示方案,并更新设计文档以涵盖变更检测内容。

@Péter Váry: 基准测试显示,单线程读取时间随列更新增加而延长,而多线程读取因基础文件读取量减少,运行时间略有缩短。

@Gábor Kaszab: 指出在 Spark 环境中,由于 CPU 已因行组拆分而饱和,额外的列级并行读取反而带来开销导致性能退化。

下一步将扩展 POC 以对比稀疏表示与行对齐方案的性能,在云存储大表上进行测试,并更新设计文档;同时需解决 Spark 环境下并行读取的性能瓶颈问题。

Joining the slack channel

3 条回复 · 3 位参与者

Yong Jin Lee 反馈官网上的 Slack 邀请链接失效无法加入频道。Russell Spitzer 随即提供了新的有效链接,并提交 PR 以更新官网上的过期链接。

@Yong Jin Lee: 官网上的 Slack 邀请链接无法使用。

@Russell Spitzer: 提供了新的有效链接,并指出链接每 400 人需更新一次。

@Russell Spitzer: 已提交 PR 更新官网上的过期链接。

问题已通过提供新链接解决,同时社区已提交 PR 更新官网链接以修复长期问题。

validate-from-snapshot-id support in merge query

3 条回复 · 2 位参与者

讨论主要关注 Iceberg merge 查询中无法显式设置 `validate_from_snapshot_id` 的问题,用户希望在多步骤流程开始时即进行快照验证以实现更严格的并发控制。目前该功能仅支持 overwrite 操作,Steven Wu 建议参考多语句事务设计,但用户指出具体代码实现存在缺口。用户最终引用相关 PR 询问是否需要提交功能请求。

@Somesh Dhal: 需要在 merge 查询中支持 `validate_from_snapshot_id`,以便在多步骤流程的初始读取阶段(而非仅提交阶段)验证快照,目前该功能仅在 overwrite 操作中受支持。

@Steven Wu: 初步判断该需求属于“多语句事务”行为的范畴,并提供了相关的设计文档和开发邮件线索供参考。

@Somesh Dhal: 发现 PR #7607 涉及向 merge 操作传递 options 的讨论,询问这是否属于功能缺口,并表示愿意提交功能请求。

尚未得出明确结论,用户 Somesh Dhal 正在确认是否应针对此功能缺口提交新的功能请求。

iceberg-rust / pyiceberg-core patch release, 0.9.1

2 条回复 · 3 位参与者

Kevin Liu 指出 pyiceberg-core 0.9.0 版本因构建工作流 bug,导致 Linux 平台缺失 Python 3.12 wheels 且错误构建了已 EOL 的 Python 3.8 wheels。相关修复已合并并验证,社区讨论决定发布 0.9.1 补丁版本以提供正确的 wheels。

@Kevin Liu: 指出构建错误源于 maturin-action 默认使用 Python 3.8,提议发布补丁版本。

@Shawn Chang: 支持发布补丁,并主动提出担任发布经理。

@Renjie Liu: 赞同发布补丁版本。

社区一致同意发布 0.9.1 补丁版本,Shawn Chang 将担任发布经理。

[Discussion] Collation Support

2 条回复 · 2 位参与者

Alexander Löser 提议在 Iceberg 规范中增加 Collation(排序规则)支持,旨在解决用户迁移痛点并提升多引擎互操作性。Andrei Tserakhau 基于 Delta 的实战经验表示愿意合作,并针对 ICU 版本稳定性、提供者抽象及操作正确性提出了关键改进建议。双方计划进一步协作并将讨论汇总至设计文档。

@Alexander Löser: 提议扩展 Schema 以支持字符串字段的 Collation 注解,以满足 Snowflake 用户迁移至 Iceberg 的需求。

@Andrei Tserakhau: 指出 ICU 排序键跨版本不稳定,建议存储原始字符串值并允许按文件进行版本注释,而非依赖排序键。

@Andrei Tserakhau: 建议引入提供者抽象层以支持非 ICU 排序规则(如 Spark 的 UTF8_LCASE),并强调了分区转换和 Parquet 下推等操作层面的正确性挑战。

提案获得积极反馈,双方达成合作意向。下一步将共享 Delta 设计文档以供参考,并将邮件中的反馈意见迁移至 Google Doc 中进行集中讨论。

🎫 JIRA (0)

本周新建 0 个 Issue

本周无新建 JIRA。