💬 讨论 (10)
12 条回复 · 6 位参与者
讨论主要针对 Iceberg 官网搜索功能因索引了所有历史版本文档而导致结果重复的问题。社区成员探讨了添加版本选择器或仅索引最新版本等解决方案，最终决定采用 `mkdocs-exclude-search` 插件排除旧版本来快速修复。该修复已合并上线，后续将讨论默认文档版本应指向 "Nightly" 还是 "Latest"。
@Max Konstantinov: 提出问题并验证了使用 `mkdocs-exclude-search` 插件排除旧版本索引的可行性，认为这是比重构站点更快的解决方案。
@Russell Spitzer: 建议在搜索中增加版本下拉菜单，以实现按版本范围搜索，提供更好的用户体验。
@Kevin Liu: 支持快速修复方案，指出长期可迁移至 `mike`，并在修复上线后提出了关于 "Nightly" 与 "Latest" 默认设置的后续优化建议。
初步修复（PR #16368）已合并，移除了旧版本的搜索索引。后续行动包括修复剩余的重复结果（PR #16371），以及讨论是否将默认文档和搜索索引从 "Nightly" 切换为 "Latest"。
2 条回复 · 2 位参与者
讨论围绕 Iceberg V4 表的行时间戳提案展开，社区已达成共识将工作拆分为单调快照时间戳和行时间戳继承两部分。目前第一部分的 PR 已提交，第二部分计划在 V4 元数据树基本完成后进行，同时也明确了列级更新场景下的时间戳处理逻辑。
@Steven Wu: 提出将提案拆分为两部分实施，已提交单调快照时间戳的 PR，并解释了列级更新时时间戳应反映最新快照状态。
@Micah Kornfield: 提醒需关注行时间戳与列级更新功能之间的交互影响。
@Anton Okolnychyi: 支持该计划，并确认了表升级时现有行的处理方式。
方案已定，下一步将推进单调快照时间戳的 PR 合并，并在 V4 元数据树就绪后实施行时间戳继承。
1 条回复 · 2 位参与者
讨论核心在于 Iceberg 列更新应采用密集还是稀疏文件表示。Gabor 解释了选择密集表示以简化写入逻辑，Marco 则通过数据指出密集表示在大文件下性能优异但在小文件下存在性能回退风险。
@Gábor Kaszab: 选择密集表示是为了避免稀疏表示在写入路径合并更新时的复杂性，且性能仍优于现有 MoR。
@Marco Kroll: 基准测试显示密集表示在文件大于 16MB 时性能显著优于 CoW，但在小文件场景下性能反而下降。
@Marco Kroll: 指出规范需适应不同文件大小（如小文件回退到 CoW），并提出了 DV 共存排序和行数统计不变量等集成挑战。
建议针对特定文件大小范围进行下一轮基准测试以确定性能拐点，并考虑在规范中支持针对小文件的回退机制。
1 条回复 · 2 位参与者
Ryan Blue 提议在 REST 规范中新增 `unregister` 端点，旨在从目录中移除表但不删除底层数据，以支持跨目录迁移。该提议解决了现有 DROP 操作会自动清理文件以及无法安全处理并发操作的问题，目前已在社区开启 PR 征求意见。
@Ryan Blue: 现有的 DROP 端点会触发文件清理且不支持并发安全，因此需要独立的 `unregister` 端点来仅移除元数据引用并返回最新状态。
@Russell Spitzer: 支持该提议，认为这补全了目录间“可移植性”的关键功能。
若无异议，作者计划本周内发起投票线程。
0 条回复 · 1 位参与者
Varun Lakhyani 实现了针对压缩操作（重写数据文件）的基准测试，并在 PR 中分享了 S3 与本地文件系统的对比结果。该测试在 MacBook Pro M4 上进行，覆盖了不同文件数量的场景，作者请求社区对实现方法和结果提供反馈。
@Varun Lakhyani: 实现了压缩基准测试，配置包括 JMH、200 万行数据及不同文件分区，对比了 S3 和本地文件系统的性能差异。
已提交 PR #16219，目前主要等待社区对基准测试方法和潜在改进点的反馈。
0 条回复 · 1 位参与者
讨论主要关注如何将新提出的“First-class Tag”概念与现有的“Labels”工作进行整合，以避免产生两套并行的附件机制。Andrei 建议采用分层架构，将 Labels 作为通用的键值对附件原语，而将 Tags 视为构建在 Labels 之上的治理模型。
@Andrei Tserakhau: Labels 和 Tags 工作存在重叠，应合并而非并行开发；建议将 Labels 定义为通用附件机制，Tags 定义为上层的治理模型。
@Andrei Tserakhau: 需要统一术语，例如 EJ 提案中的 Governed/Standard 与 Labels CRUD 工作中的 catalog-managed/client-writable。
@Andrei Tserakhau: Tag 定义中的“允许值”特性可以解决 Yufei 在讨论中提出的互操作性问题。
建议在 Labels 工作的基础上构建 Tag 实体，并提议通过文档更新或会议同步来对齐双方的设计。
0 条回复 · 1 位参与者
本次讨论主要介绍了两个旨在利用 Iceberg 排序元数据优化 Spark 读取和压缩的 PR。第一个 PR 通过实现 SupportsReportOrdering API 消除冗余排序，第二个 PR 引入 K-way merge 策略实现无 shuffle 的保序压缩。两者结合确立了“一次排序、低成本维护”的模式，经大规模测试验证能显著降低资源消耗。
@Anurag Mantripragada: PR #14948 实现了感知排序的读取，通过向 Spark 报告有序性来消除 joins 和 order-by 等操作中的冗余排序阶段。
@Anurag Mantripragada: PR #16305 提供了 K-way merge 压缩策略，能在 O(n log k) 复杂度下无 shuffle 地合并已排序文件，维护成本远低于重新排序。
@Anurag Mantripragada: 这两个 PR 是互补的，读取优化依赖有序文件，而保序压缩能低成本维持这种状态，已在生产环境验证了资源节省效果。
作者请求社区专家对这两个 PR 进行评审，特别是关于 API 层面的设计反馈。
0 条回复 · 1 位参与者
Eduard Tudenhöfner 推进了 Iceberg V4 规范中关于改进列统计信息的提案，目前正针对 Content Stats Spec 进行迭代更新。最新的提案修改包括移除未使用的 `column_size`、新增变长类型的统计指标以及修正预留 ID 空间。作者希望社区确认后对设计提案进行投票，以便开始合并代码。
@Eduard Tudenhöfner: 移除了 `column_size`，因为早期版本中未使用。
@Eduard Tudenhöfner: 新增了 `avg_value_size` 和 `max_value_size` 用于统计变长类型（如 string/binary）的大小。
@Eduard Tudenhöfner: 建议对设计提案进行投票，以便推进代码合并及后续并行工作。
若社区无异议，下一步将对设计提案进行投票，并推进首批代码的合并。
0 条回复 · 1 位参与者
讨论主要围绕 Flink 中将 Equality Delete 转换为 Deletion Vectors (DV) 的功能实现及其对表格式版本的支持展开。Max 提交的 PR 目前仅支持 V3 表，而 Qian 和 Steven 表达了对 V2 表兼容性的需求。Max 指出支持 V2 原则上可行但存在效率折衷，Qian 则表示愿意协助开发 V2 的支持路径。
@Maximilian Michels: 当前实现仅限于 V3 表，支持 V2 并不困难，但在存储和查找效率上会有折衷。
@Qian Su: 组织内部大量使用 V2 表且迁移耗时，因此 V2 兼容路径非常有价值，并愿意为此贡献代码。
@Steven Wu: 该提案有助于移除 Equality Delete，并能验证索引方案在流式 CDC/Upsert 写入中的扩展性。
初步结论是当前 PR 将维持对 V3 表的支持。下一步 Max 将更新 PR 描述以明确 V3 限制，Qian 计划在 V3 基础代码落地后跟进开发 V2 的支持。
0 条回复 · 1 位参与者
Mukund Thakur 提议增加对旧分区规约数据文件进行重分区的支持，以解决现有重写工具因文件大小合规而跳过旧规约文件的问题。他提交了 PR #16190，并指出使用 `rewrite-all` 结合过滤器的现有方案在任务中断重跑时存在重复处理文件的缺陷。
@Mukund Thakur: 当前重写机制会跳过已满足大小要求的文件，导致旧分区规约的数据无法更新到新规约。
@Mukund Thakur: 使用 `rewrite-all=true` 配合过滤器的变通方案在作业失败重试时效率低下，会重复处理已扫描的文件。
讨论处于初始提案阶段，作者请求社区审查 PR #16190 以引入新功能来解决这一问题。