Hudi RFC 提案全览与索引指南：从 rfc/README.md 读懂 115+ 项设计提案的演进脉络

• 数据湖
• 湖仓一体
• 大数据
• 数据存储

本文以 Hudi 仓库根目录下的 rfc/README.md 为索引主线，系统讲解 Hudi 的 RFC（Request For Comments）提案机制：状态机定义、编号目录结构、标准文档模板，以及从索引表延伸到仓库内 50+ 份设计文档与源码实现的方法。读完本文，你将能够按编号定位任意提案的设计文档、按状态筛选社区当前推进方向，并理解一份 RFC 从提案到落地（如 FLIP-27 Flink Source、Record Index、存储锁）的完整链路。

一、RFC 机制：Hudi 社区公开设计的入口

Apache Hudi 是一个开源数据湖存储格式与表服务项目，其核心特性（索引、并发控制、查询引擎集成、表服务等）几乎都遵循“先提案、后实现”的 RFC 流程。仓库中的rfc/目录正是这一流程的落地载体：rfc/README.md扮演索引门户的角色，集中登记所有 RFC 的编号、标题与当前状态；每个已开始的提案则在该目录下拥有独立的子目录（如rfc/rfc-8/、rfc/rfc-69/），内部存放该提案的完整设计文档。

根据rfc/README.md的说明，完整的 RFC 流程文档托管在 Apache Hudi 官方站点上，社区鼓励任何人在着手撰写新 RFC 之前先熟悉该流程。这意味着：rfc/README.md不是一份技术规范，而是社区设计流程的“地图”—— 它告诉你有哪些设计讨论正在进行或已经完成，以及如何找到每一份设计细节。

二、提案状态机：五种状态与含义

rfc/README.md定义了 RFC 的五种状态，是理解整个索引表的第一把钥匙。状态值如下（完整继承原文定义）：

状态	含义
UNDER REVIEW	RFC 已提交提案，社区正在就设计/方案展开积极讨论。
:hammer_and_wrench:IN PROGRESS	实现的初始阶段正在进行中。
ONGOING	部分或大部分工作已经落地；社区持续改进或推进后续阶段。
ABANDONED	由于各种原因，提案未被实现。
COMPLETED	所有工作被认为已完成。

这五种状态构成了一条典型的提案生命周期：UNDER REVIEW（评审）→ IN PROGRESS（实现中）→ ONGOING（持续演进）或 COMPLETED（完成），部分提案会因设计变更、优先级调整等原因进入 ABANDONED（废弃）。例如：

• RFC-69（Hudi 1.X）标注为COMPLETED，对应 1.x 大版本演进已落地；
• RFC-78（1.0 Migration）标注为IN PROGRESS，表明迁移工作仍在实施中；
• RFC-51（Change Data Capture）标注为ONGOING，表示核心能力已落地、社区仍在持续推进；
• RFC-41（Snowflake Integration）标注为ABANDONED，最终改由 Apache XTable（Incubating）方案承载；
• RFC-59、RFC-60、RFC-61、RFC-62 等则处于UNDER REVIEW，设计讨论尚未定稿。

状态行由提案作者在对应 RFC 文档中维护，并同步更新到rfc/README.md表格（这一要求同样写在 rfc/template.md 的 Status 一节中）。

三、索引表结构：编号、标题、状态三要素

rfc/README.md的主体是一张完整登记表，每一行包含三个核心要素：

• RFC Number：提案的唯一编号，从 1 递增到 115（截至当前仓库快照）；
• Title：提案标题，精确描述该提案要解决的技术问题；
• Status：上节所述的五种状态之一。

从编号与状态的分布，可以快速获得两条有价值的判断：

1. 早期提案（RFC 1–35）多数已完成，且大部分设计文档位于外部 Confluence 历史站点（rfc/README.md明确提示“Older RFC content is still here”，指向历史归档）；从 RFC-8 开始，提案文档逐步沉淀到仓库内。
2. 近期提案（RFC 100+）仍在密集评审：如 RFC-100（非结构化数据存储）、RFC-101（HoodieRecordMerger API 更新）、RFC-103（Hudi LSM 树布局）、RFC-105（Trino Hudi Connector Shim/Bundle 重构）、RFC-106（Flink Writer 的 Record Level 与 Secondary Index）、RFC-107（分区感知的 RocksDB RecordIndexBackend）、RFC-109（Hudi 原生向量索引）等，反映了社区当前在索引、类型系统、存储布局与引擎集成上的投入方向。

值得注意的维护细节：表格中有部分行（如 90、92、96、97、103、110–115）只登记了标题而未附带仓库内文档链接。其中 RFC-92（Bitmap Index）与 RFC-103（LSM 树布局）在仓库内实际已存在对应目录（rfc/rfc-92 与 rfc/rfc-103），说明索引表的链接维护存在一定滞后；另有部分编号（如 70–72、74 等）在表中指向的文档路径带有额外rfc/前缀，属于表内链接瑕疵。阅读时应以目录实际内容为准。

四、仓库内已落地的 RFC 文档清单

本仓库rfc/目录下实际存在 53 个 RFC 子目录（编号 8、27、34、37–40、42、44–60 中的多数、63、65、66、68、69、73、76–78、80、82–85、87、89、91–95、98–103、105–107、109），每个子目录内含同名rfc-N.md设计文档。核心清单如下：

注意：rfc/README.md表格中对 RFC-102、RFC-107 的链接路径写作rfc-102/rfc-102/md、rfc-107/rfc-107/md（缺少.），实际文档文件为 rfc/rfc-102/rfc-102.md 与 rfc/rfc-107/rfc-107.md。

五、RFC 文档的标准骨架：rfc/template.md

要读懂任何一份 RFC，先看模板。仓库内的 rfc/template.md 定义了所有提案文档的统一结构，共八个章节：

1. Proposers：提案发起人（GitHub 用户名），通常 1～2 人；
2. Approvers：批准人（通常是 PMC 成员或模块负责人）；
3. Status：提案状态及关联 Issue 链接，并明确要求“保持状态在rfc/README.md中同步更新”——这解释了 README 表格状态列的来源；
4. Abstract：用一段话描述要解决的问题及必要性；
5. Background：介绍理解该设计所需的背景上下文与设计取舍依据；
6. Implementation：正文核心，详细描述实现方案如何融入项目架构，篇幅根据变更范围可长可短；
7. Rollout/Adoption Plan：对存量用户的影响、旧行为如何平滑过渡、是否需要迁移工具、何时移除旧行为；
8. Test Plan：说明如何验证实现符合预期、如何确保无回归。

以 rfc/rfc-8/rfc-8.md 为例，其 Abstract 先指出 Hudi 更新时必须通过索引按记录键定位记录，现有 Bloom Index、Simple Index（默认）、HBase Index 各有局限（Bloom/Simple 在数据集大时查找开销高、且不保存记录键到文件路径的一一映射），随后提出将“记录键 → 文件路径”映射存入 Hudi Metadata Table 的 Record Index 方案——这正是模板中 Background 与 Implementation 分层的典型写法。再如 rfc/rfc-95/rfc-95.md，Abstract 明确说明现状是 Hudi 仅通过 Flink Source Function API 读取，缺口是缺少遵循 Flink Source API（FLIP-27）的一等公民实现，Background 则补充 FLIP-27 解决了旧 SourceFunction 接口的哪些问题（批流接口统一、有界数据处理、与 Kafka 混合源无缝切换回填）。

六、从 README 索引看技术演进版图

按索引表中的标题与状态，可以把 115 项提案粗略归为几条技术主线，这也是深度阅读时的“地图”：

1. 存储格式与表服务层：RFC-69（Hudi 1.X 大版本愿景）、RFC-78（1.0 迁移）、RFC-80（列组）、RFC-93（可插拔表格式）、RFC-83（增量表服务）、RFC-100（非结构化数据存储）、RFC-103（LSM 树布局）。这些提案定义了 Hudi 作为数据湖存储格式的底层形态演进。

2. 索引体系：RFC-8（Record Index）、RFC-37（元数据布隆索引）、RFC-42（一致性哈希索引）、RFC-27（Data Skipping）、RFC-77（二级索引）、RFC-89（动态分区桶索引）、RFC-92（位图索引）、RFC-106（Flink Writer 的 Record Level/Secondary Index）、RFC-107（分区感知 RocksDB 后端）、RFC-109（原生向量索引）。索引是 Hudi“更新定位记录”能力的核心，也是当前社区投入最密集的方向之一。

3. 并发与事务：RFC-22（多写者快照隔离 OCC）、RFC-56（多写者早期冲突检测）、RFC-66（非阻塞并发控制）、RFC-73（多表事务）、RFC-82（并发 schema 演进检测）、RFC-91（基于存储条件写入的锁提供者）。

4. 查询引擎集成：RFC-40（Trino 连接器）、RFC-44（Presto 连接器）、RFC-105（Trino 连接器 Shim/Bundle 重构）、RFC-38 与 RFC-98（Spark Datasource V2 读写）、RFC-34（BigQuery 集成）、RFC-41（Snowflake，已废弃）。

5. 流式写入与增量处理：RFC-51（CDC）、RFC-95（FLIP-27 Flink Source）、RFC-84（Flink DataStream SerDe 优化）、RFC-87（Flink Writer Avro 消除）、RFC-13/24/35（Flink 集成系列）、RFC-39（Debezium 增量源）、RFC-57（DeltaStreamer Protobuf 支持）。

6. 表服务与运维：RFC-19（Clustering）、RFC-48（MOR Log Compaction）、RFC-45（异步元数据索引）、RFC-65（分区 TTL 管理）、RFC-85（Jira Issue/Sprint 管理）、RFC-94（Timeline UI）。

七、从提案到源码：三条可验证的实现链路

RFC 索引的价值不止于“看文档”，更在于可以顺藤摸瓜到源码。以下三个例子展示了从rfc/README.md出发的溯源方法：

1. RFC-95（FLIP-27 Flink Source）→ 源码落地。该提案完成后的实现位于 hudi-flink-datasource/hudi-flink/src/main/java/org/apache/hudi/source/HoodieSource.java，与HoodieTableSource（hudi-flink-datasource/hudi-flink/src/main/java/org/apache/hudi/table/HoodieTableSource.java）配合，通过HoodieTableFactory暴露给 Flink SQL；测试覆盖见 hudi-flink-datasource/hudi-flink/src/test/java/org/apache/hudi/table/TestHoodieTableSource.java。这与提案 Abstract 中“实现遵循 Flink Source API、支持批流两种模式”的目标一一对应。

2. RFC-8（Record Index）→ 元数据表实现。提案提出的“将记录键到文件路径的映射存入 Hudi Metadata Table”已演变为今天hudi-common中基于 HFile 的元数据表索引体系，并与后续 RFC-37（布隆索引）、RFC-45（异步索引）共同构成hoodie.metadata系列配置的底层基础。

3. RFC-91（存储锁）→ 锁配置与实现类。该提案落地的实现类是 hudi-client/hudi-client-common/src/main/java/org/apache/hudi/client/transaction/lock/StorageBasedLockProvider.java，通过 hudi-client/hudi-client-common/src/main/java/org/apache/hudi/config/HoodieLockConfig.java 注册为可选锁提供者；对应测试见 hudi-client/hudi-client-common/src/test/java/org/apache/hudi/client/transaction/lock/TestStorageBasedLockProvider.java。

这种“README 索引 → 提案文档 → 源码类 → 测试”的四级溯源，是研究 Hudi 任何一项功能最可靠的技术路线。

八、如何参与：阅读、跟踪与提交新提案

阅读与跟踪。首选入口始终是 rfc/README.md：先看状态列锁定COMPLETED/ONGOING（已落地、有源码可对照）与UNDER REVIEW（社区正在讨论、反馈窗口活跃）的提案；再按上文的主题分类选取与自身场景相关的编号，进入对应rfc/rfc-N/rfc-N.md精读。RFC-8、RFC-40、RFC-69、RFC-95 结构规整、篇幅适中，适合作为新手精读样本。

提交新提案。流程要点（依据仓库内事实）：在动笔前先熟悉官方 RFC 流程文档（rfc/README.md明确要求）；撰写时严格套用 rfc/template.md 的八节骨架，在仓库rfc/下新建rfc-N/目录放置rfc-N.md；完成后把编号、标题、状态登记进 rfc/README.md 的索引表，并在后续实现推进时同步更新状态列（如从UNDER REVIEW更新为IN PROGRESS、最终为COMPLETED）。编号通常沿用社区已分配的 Issue 编号，具体以官方流程为准。

注意事项。当前仓库快照中rfc/README.md表内仍存在少量维护瑕疵：部分编号（90、92、96、97、103、110–115）仅有标题无链接，个别行（70–72、74）链接路径带冗余前缀，RFC-102/107 的链接缺扩展名。遇到这些行时，直接检查rfc/目录下是否存在对应子目录即可确认文档是否已落地；对于确实缺失文档的编号，说明其设计讨论仍停留在 README 登记或更早期的历史归档中。

九、小结

rfc/README.md是 Hudi 社区集体设计智慧的总索引：五态状态机提供了过滤视角，编号-标题-状态三列组成的登记表勾勒出从 1 到 115 的完整演进史，而 rfc/template.md 则保证了每一份提案都可被一致地阅读、评审与追踪。当你需要回答“Hudi 为什么这样做、未来会怎样做”时，从这份 README 出发、沿编号进入对应设计文档、再下沉到源码与测试，就是最可靠的研究路径。

• 数据湖
• 湖仓一体
• 大数据
• 数据存储