Delta 协议演进治理指南解读 protocol_rfcs 目录与 RFC 全流程【免费下载链接】deltaAn open-source storage framework that enables building a Lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, and Hive and APIs项目地址: https://gitcode.com/GitHub_Trending/del/deltaDelta Lake 的事务日志协议Transaction Log Protocol定义了表格式table format的一切行为其任何变更都关乎所有读写引擎的兼容性。为保证协议演进的严谨与透明Delta 仓库自 2024 年起引入了一套以 RFC 为中心的治理流程所有提案、已接受与已拒绝的 RFC 均收录在 protocol_rfcs 目录中。本文以该目录及其 README 为骨架完整梳理 RFC 清单、三步生命周期、模板规范与状态迁移规则并结合仓库中的 PROTOCOL.md、模板文件及代表性 RFC 文档进行源码级佐证帮助读者理解 Delta 协议变更从提案到规范落地的全过程。protocol_rfcs 目录协议演进的档案室打开仓库根目录下的protocol_rfcs目录其结构本身就是协议治理的缩影accepted/已被接受并合入 Delta 规范的 RFC如 Catalog-Managed Tables、In-Commit Timestamps、Type Widening、Variant 等rejected/被拒绝的 RFC如 Managed Commitstemplate.md新建 RFC 必须克隆的模板目录根部存放仍在评审中的 Proposed RFC如 checkpoint-protection.md、iceberg-compat-v3.md、interval-types.md 等。这些 RFC 文档与仓库根部的 PROTOCOL.mdDelta 事务日志协议正式规范全文 3000 行形成分工RFC 是提案与讨论记录PROTOCOL.md 是最终生效规范。一个 RFC 被接受后其内容会折叠fold进 PROTOCOL.md 对应章节。例如 accepted/variant-type.md 开头便注明 Folded into PROTOCOL.md而 PROTOCOL.md 中确实存在完整的 Variant Data Type 章节accepted/in-commit-timestamps.md 提出的inCommitTimestamp字段也已落地为规范中commitInfo的可选字段见 PROTOCOL.md。RFC 全量清单截至本仓库快照protocol_rfcs/README.md记录了自 2024 年 2 月 6 日该流程引入以来全部提案、接受与拒绝的 RFC。以下三张表继承自原文档并将其中外部链接统一替换为仓库内相对路径。进行中的 Proposed RFCs提案日期RFC 文件关联 issueRFC 标题2023-02-26column-mapping-usage-tracking.md#2682Column Mapping Usage Tracking2024-04-30collated-string-type.md#2894Collated String Type2025-03-13checkpoint-protection.md#4152Checkpoint Protection2025-03-18iceberg-writer-compat-v1.md#4284IcebergWriterCompatV12025-05-19iceberg-compat-v3.md#4574IcebergCompatV32025-11-20materialize-partition-columns.md#5555Materialize Partition Columns2026-02-19nanosecond-timestamps.md#6081Nanosecond Timestamp Primitive Types2026-04-22iceberg-v4-metadata.md#6640Iceberg V4 Adaptive Metadata Tree2026-06-23interval-types.md#7077Interval Types已接受的 Accepted RFCs| 提案日期 | 接受日期 | RFC 文件 | 关联 issue | RFC 标题 | |:-|:-|:-|:-|:-| | 2025-04-07 | 2026-02-17 | accepted/catalog-managed.md | #4381 | Catalog-Managed Tables | | 2023-02-28 | 2023-03-26 | accepted/vacuum-protocol-check.md | #2630 | Enforce Vacuum Protocol Check | | 2023-02-02 | 2023-07-24 | accepted/in-commit-timestamps.md | #2532 | In-Commit Timestamps | | 2023-02-09 | 2025-01-28 | accepted/type-widening.md | #2623 | Type Widening | | 2023-04-24 | 2025-02-14 | accepted/variant-type.md | #2864 | Variant Data Type | | 2025-05-06 | 2026-05-01 | accepted/variant-shredding.md | #4032 | Variant Shredding |已拒绝的 Rejected RFCs提案日期拒绝日期RFC 文件关联 issueRFC 标题2023-02-142025-04-07rejected/managed-commits.md#2598Managed Commits值得注意的是Accepted 列表中最新的 catalog-managed.md 与 Rejected 列表中的 managed-commits.md 主题相近都是让外部实体接管提交原子性但前者从目录Catalog作为提交事实来源切入最终被接受后者则被拒绝。这组对照恰好说明协议变更的成败往往取决于提案对生态各方约束的设计是否周全。RFC 生命周期三步走流程protocol_rfcs/README.md将一次协议变更的全过程归纳为三个阶段本文结合仓库中的模板与具体 RFC 文档逐层展开。第一步提交初始提案Make initial proposal任何协议变更的起点都是在 GitHub 上创建一个Protocol Change Request类型的 issue该 issue 将作为该协议变更所有讨论的中心场所。提案者可以在 issue 描述中附带设计文档链接如果提案带有原型或其他可行性验证pathfinding相关代码改动应当放在一个公开的 PR 中便于社区评审。第二步添加 RFC 文档Add the RFC docissue 建立并与社区讨论、就该特性应当实现达成基本共识后在合入任何 master 代码之前必须先通过 PR 提交 RFC 文档。具体要求克隆模板复制 template.md 并创建新的 RFC Markdown 文档交叉引用 issueRFC 中必须用 see #xxx 关联 issue。严禁使用 closes #xxx、fixes #xxx、resolves #xxx 等措辞——因为不希望 RFC PR 合并时自动关闭 issueissue 要等到特性最终被接受或拒绝时才关闭。模板本身结构极简却信息完整template.md 要求 RFC 标题使用表特性名称/有意义的名字正文首行标注关联 issue随后给出协议变更的总体描述general description / context并预留对 PROTOCOL.md 的修改区块。这种标题—issue 链接—背景—规范修改草案的四段式结构保证每个 RFC 都具备可评审、可追溯的最小信息集。README 还给出了两条对贡献者至关重要的工程约束临时特性名约定对于表特性table feature强烈建议任何实验性支持使用带-dev后缀的临时特性名。这向潜在用户明确传达该实验特性不提供未来兼容性保证代码隔离与提案特性相关的代码在 RFC 达到 proposed 状态即 RFC PR 经过公开评审并合并之前不得合入主分支在 RFC 被接受即变更合入 Delta 规范之前相关代码必须用特性开关feature flags与生产代码隔离确保不影响现有用户。第三步接受或拒绝 RFCAccept or reject the RFCRFC 从 proposed 走向最终定论需要满足两条硬性验收标准存在一个经过充分测试的生产实现例如在 delta-spark 中至少有一些讨论和/或原型优先证明该特性在 Delta Kernel 中的可行性。满足标准后通过 PR 完成协议定稿动作密切验证协议规范改动与实际生产实现的一致性用 closes #xxx 交叉关联 PR 与原始 issue此时才允许关闭 issue并将 issue 标题更新为[ACCEPTED]前缀使提案结果一目了然更新 PROTOCOL.md 正式规范将 RFC 文档移入accepted子目录并更新状态索引从所有代码中移除表特性名里的-dev等临时/预览后缀。若 RFC 被拒绝则对应的 PR 需要以 closes #xxx 关闭 issue 并将标题改为[REJECTED]、将 RFC 移入rejected子目录、更新状态索引、删除与该特性相关的所有实验/预览代码。rejected/managed-commits.md 就是这条路径的完整实证。从提案到规范代表性 RFC 的源码级印证协议的每一步演进最终都沉淀为 PROTOCOL.md 的具体条款与仓库源码中的实际行为。以下选取几个有代表性的 RFC对照其文档与规范现状进行解读。Catalog-Managed Tables目录成为提交的事实来源accepted/catalog-managed.md 提出新的读写表特性catalogManaged它改变了 Delta 发现与访问表的方式传统 Delta 协议完全依赖文件系统完成读时发现read-time discovery与写时提交原子性通过 PUT-if-absent而该特性让管理表的 Catalog 成为某次提交尝试是否成功的事实来源。文档列举了六大收益从拒绝绕过 Catalog 的文件系统提交、支撑跨表事务到由 Catalog 直接托管小提交内容、发放存储凭证、充当最新表版本权威来源不再需要 LIST_delta_log乃至基于提交触发 VACUUM、布局优化、UniForm 转换等后续动作。该 RFC 对规范的多处修订同样值得关注提交文件可能暂存在_delta_log/_staged_commits目录命名遵循version.uuid.jsonversion 为 20 位零填充的提议提交版本号commitInfo动作必须携带唯一事务标识txnId元数据清理Metadata Cleanup时还需删除_staged_commits中早于 cutoff 检查点的 staged 提交文件。这些细节共同勾勒出Catalog 裁决、文件系统暂存、定时回填的混合提交模型。In-Commit Timestamps让时间旅行不再依赖文件修改时间accepted/in-commit-timestamps.md 解决的是一个隐蔽但关键的可靠性问题TIMESTAMP AS OF 时间旅行此前依赖提交文件的文件系统修改时间一旦文件操作改变 mtime时间旅行结果就可能出错。该 Writer 特性要求每次提交的commitInfo动作且必须是提交中的第一个动作包含inCommitTimestamp字段取写入方尝试提交的时刻与上一个提交的inCommitTimestamp 1 毫秒两者中的较大值从而保证跨提交严格单调递增。对于特性启用前已有的历史提交规范用两个表属性delta.inCommitTimestampEnablementVersion与delta.inCommitTimestampEnablementTimestamp记录启用边界读者据此判断每个版本应使用inCommitTimestamp还是文件修改时间。这些条款均已合入 PROTOCOL.md对应commitInfo的inCommitTimestampOpt可选字段与读者/写者要求段落。Type Widening 与 Variant类型系统的两次扩展accepted/type-widening.md 定义了一组明确的加宽转换规则整数加宽Byte - Short - Int - Long、浮点加宽Float - Double、日期加宽Date - Timestamp without timezone以及带精度/标度约束的 Decimal 加宽Decimal(p, s) - Decimal(p k1, s k2)要求k1 k2 0。类型变更历史以delta.typeChanges键记录在最近祖先 StructField 的 metadata 中对 map key/value 或 array element 的变更通过fieldPathkey/value/element嵌套时以点号分隔前缀定位。accepted/variant-type.md 则为半结构化数据引入variant类型在 Parquet 中表示为包含value与metadata两个 binary 字段的 struct并给出了 JSON 编码的 Schema 示例。文档还以表格形式明确了该类型与分区列、聚簇列、列统计、生成列、CHECK 约束、默认值、Change Data Feed 等既有特性的兼容矩阵例如 Variant 不可作为分区/聚簇列不支持 min/max 统计仅支持 nullCount。这两个特性在 PROTOCOL.md 中均有对应章节读者可在 PROTOCOL.md 中查阅完整规范。Checkpoint Protection为安全移除特性铺路checkpoint-protection.md 仍是 Proposed 状态但它解释了 Delta 协议治理中一个少为人知的问题移除表特性DROP FEATURE通常需要截断表历史而协议要求随版本单调递增导致移除特性前必须等待 24 小时避免损坏表。checkpointProtection通过受保护检查点在特性移除边界充当屏障把旧读者不支持的提交记录隐藏在屏障之后从而允许单次执行 DROP FEATURE 完成特性移除。该特性要求写者在delta.requireCheckpointProtectionBeforeVersion指定版本之前不得清理/新建检查点除非确认支持该版本的表协议在历史清理时写者必须先删提交、后删检查点且要么完整支持被清理版本、要么一次性截断到边界版本。它同样适用于协议不再单调递增后防止写者为不支持的旧版本写出损坏的检查点。Managed Commits一条被拒绝的路径rejected/managed-commits.md 曾提议引入managedCommit表特性让外部提交所有者commit-owner而非文件系统提供提交原子性并定义了_delta_log/_commits暂存目录、提交回填backfill与维护操作约束。虽然该提案最终被拒绝提案日期 2023-02-14拒绝日期 2025-04-07但它与后来被接受的 catalog-managed 思路一脉相承且其文档中对谁拥有提交、如何保证原子性的讨论至今仍是理解 Delta 提交协议的重要背景。如何参与协议演进对于想为 Delta 协议贡献力量或跟进其演进的开发者仓库内提供了清晰的入口阅读正式规范 PROTOCOL.md理解表特性Table Features、reader/writer 版本Reader Version 3 / Writer Version 7等基础概念翻阅 protocol_rfcs 目录下处于 Proposed 状态的 RFC这些是尚未定论、最需要社区讨论的内容对照 template.md 了解新 RFC 的撰写骨架遵循 README 中先 issue 后 RFC、-dev后缀、feature flag 隔离、验收后再合入规范的节奏推进自己的提案。协议治理的价值在于任何引擎Spark、Flink、Trino、PrestoDB、Hive都能依据同一份规范实现互操作而 RFC 机制确保了这份规范的每一次变化都有据可查、有讨论可循、有代码可验。掌握protocol_rfcs目录与这套流程也就掌握了阅读和理解 Delta 协议演进脉络的钥匙。【免费下载链接】deltaAn open-source storage framework that enables building a Lakehouse architecture with compute engines including Spark, PrestoDB, Flink, Trino, and Hive and APIs项目地址: https://gitcode.com/GitHub_Trending/del/delta创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考