ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

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

Hudi RFC 提案全览与索引指南:从 rfc/README.md 读懂 115+ 项设计提案的演进脉络 数据湖湖仓一体大数据数据存储【免费下载链接】hudiUpserts, Deletes And Incremental Processing on Big Data.项目地址https://gitcode.com/gh_mirrors/hud/hudi点击查看免费下载本文以 Hudi 仓库根目录下的 rfc/README.md 为索引主线系统讲解 Hudi 的 RFCRequest 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 REVIEWRFC 已提交提案社区正在就设计/方案展开积极讨论。:hammer_and_wrench:IN PROGRESS实现的初始阶段正在进行中。ONGOING部分或大部分工作已经落地社区持续改进或推进后续阶段。ABANDONED由于各种原因提案未被实现。COMPLETED所有工作被认为已完成。这五种状态构成了一条典型的提案生命周期UNDER REVIEW评审→ IN PROGRESS实现中→ ONGOING持续演进或 COMPLETED完成部分提案会因设计变更、优先级调整等原因进入 ABANDONED废弃。例如RFC-69Hudi 1.X标注为COMPLETED对应 1.x 大版本演进已落地RFC-781.0 Migration标注为IN PROGRESS表明迁移工作仍在实施中RFC-51Change Data Capture标注为ONGOING表示核心能力已落地、社区仍在持续推进RFC-41Snowflake Integration标注为ABANDONED最终改由 Apache XTableIncubating方案承载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上节所述的五种状态之一。从编号与状态的分布可以快速获得两条有价值的判断早期提案RFC 1–35多数已完成且大部分设计文档位于外部 Confluence 历史站点rfc/README.md明确提示“Older RFC content is still here”指向历史归档从 RFC-8 开始提案文档逐步沉淀到仓库内。近期提案RFC 100仍在密集评审如 RFC-100非结构化数据存储、RFC-101HoodieRecordMerger API 更新、RFC-103Hudi LSM 树布局、RFC-105Trino Hudi Connector Shim/Bundle 重构、RFC-106Flink Writer 的 Record Level 与 Secondary Index、RFC-107分区感知的 RocksDB RecordIndexBackend、RFC-109Hudi 原生向量索引等反映了社区当前在索引、类型系统、存储布局与引擎集成上的投入方向。值得注意的维护细节表格中有部分行如 90、92、96、97、103、110–115只登记了标题而未附带仓库内文档链接。其中 RFC-92Bitmap Index与 RFC-103LSM 树布局在仓库内实际已存在对应目录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/rfc-8Metadata based Record Index元数据表记录索引rfc/rfc-27Data skipping index数据跳过索引提升查询性能rfc/rfc-34Hudi BigQuery IntegrationBigQuery 集成rfc/rfc-37Metadata based Bloom Index元数据表布隆索引rfc/rfc-38Spark Datasource V2 Integrationrfc/rfc-39Incremental source for Debeziumrfc/rfc-40Hudi Connector for Trinorfc/rfc-42Consistent Hashing Index一致性哈希索引rfc/rfc-44Hudi Connector for Prestorfc/rfc-45Asynchronous Metadata Indexing异步元数据索引rfc/rfc-46Optimizing Record Payload Handlingrfc/rfc-47Add Call Procedure Command for Spark SQLrfc/rfc-48LogCompaction for MOR tablesrfc/rfc-49Support sync with DataHubrfc/rfc-51Change Data Capture变更数据捕获rfc/rfc-53Lock-Free Message Queue 提升写入效率rfc/rfc-55Hive/Meta sync 类设计与层级改进rfc/rfc-56Early Conflict Detection For Multi-Writerrfc/rfc-57DeltaStreamer Protobuf Supportrfc/rfc-63Expression Indexes表达式索引rfc/rfc-65Partition TTL Management分区 TTL 管理rfc/rfc-66Non Blocking Concurrency Controlrfc/rfc-69Hudi 1.X1.x 大版本愿景rfc/rfc-73Multi-Table Transactions多表事务rfc/rfc-76Auto Record key generationrfc/rfc-77Secondary Index二级索引rfc/rfc-781.0 Migration1.0 迁移指南rfc/rfc-80Column Groups列组rfc/rfc-82Concurrent schema evolution detectionrfc/rfc-83Incremental Table Servicerfc/rfc-84Flink 算子中 DataStream 的优化 SerDerfc/rfc-87Flink writer 的 Avro 消除rfc/rfc-89Dynamic Partition Level Bucket Indexrfc/rfc-91Storage-based lock provider基于条件写入的存储锁rfc/rfc-93Pluggable Table Formats in Hudirfc/rfc-94Hudi Timeline UIrfc/rfc-95Hudi Flink Source基于 FLIP-27rfc/rfc-98Spark Datasource V2 Readrfc/rfc-99Hudi Type System Redesign类型系统重构rfc/rfc-100Unstructured Data Storage in Hudirfc/rfc-101Updates to the HoodieRecordMerger APIrfc/rfc-102Spark Batch Vector Searchrfc/rfc-103Hudi LSM tree layoutLSM 树布局rfc/rfc-105Trino Hudi Connector Shim/Bundle 重构rfc/rfc-106Flink Writer 的 Record Level 与 Secondary Indexrfc/rfc-107分区感知 RocksDB RecordIndexBackendrfc/rfc-109Hudi Native Vector Index原生向量索引注意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 定义了所有提案文档的统一结构共八个章节Proposers提案发起人GitHub 用户名通常 12 人Approvers批准人通常是 PMC 成员或模块负责人Status提案状态及关联 Issue 链接并明确要求“保持状态在rfc/README.md中同步更新”——这解释了 README 表格状态列的来源Abstract用一段话描述要解决的问题及必要性Background介绍理解该设计所需的背景上下文与设计取舍依据Implementation正文核心详细描述实现方案如何融入项目架构篇幅根据变更范围可长可短Rollout/Adoption Plan对存量用户的影响、旧行为如何平滑过渡、是否需要迁移工具、何时移除旧行为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.mdAbstract 明确说明现状是 Hudi 仅通过 Flink Source Function API 读取缺口是缺少遵循 Flink Source APIFLIP-27的一等公民实现Background 则补充 FLIP-27 解决了旧 SourceFunction 接口的哪些问题批流接口统一、有界数据处理、与 Kafka 混合源无缝切换回填。六、从 README 索引看技术演进版图按索引表中的标题与状态可以把 115 项提案粗略归为几条技术主线这也是深度阅读时的“地图”1. 存储格式与表服务层RFC-69Hudi 1.X 大版本愿景、RFC-781.0 迁移、RFC-80列组、RFC-93可插拔表格式、RFC-83增量表服务、RFC-100非结构化数据存储、RFC-103LSM 树布局。这些提案定义了 Hudi 作为数据湖存储格式的底层形态演进。2. 索引体系RFC-8Record Index、RFC-37元数据布隆索引、RFC-42一致性哈希索引、RFC-27Data Skipping、RFC-77二级索引、RFC-89动态分区桶索引、RFC-92位图索引、RFC-106Flink 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-40Trino 连接器、RFC-44Presto 连接器、RFC-105Trino 连接器 Shim/Bundle 重构、RFC-38 与 RFC-98Spark Datasource V2 读写、RFC-34BigQuery 集成、RFC-41Snowflake已废弃。5. 流式写入与增量处理RFC-51CDC、RFC-95FLIP-27 Flink Source、RFC-84Flink DataStream SerDe 优化、RFC-87Flink Writer Avro 消除、RFC-13/24/35Flink 集成系列、RFC-39Debezium 增量源、RFC-57DeltaStreamer Protobuf 支持。6. 表服务与运维RFC-19Clustering、RFC-48MOR Log Compaction、RFC-45异步元数据索引、RFC-65分区 TTL 管理、RFC-85Jira Issue/Sprint 管理、RFC-94Timeline UI。七、从提案到源码三条可验证的实现链路RFC 索引的价值不止于“看文档”更在于可以顺藤摸瓜到源码。以下三个例子展示了从rfc/README.md出发的溯源方法1. RFC-95FLIP-27 Flink Source→ 源码落地。该提案完成后的实现位于 hudi-flink-datasource/hudi-flink/src/main/java/org/apache/hudi/source/HoodieSource.java与HoodieTableSourcehudi-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-8Record 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 出发、沿编号进入对应设计文档、再下沉到源码与测试就是最可靠的研究路径。赞分享数据湖湖仓一体大数据数据存储【免费下载链接】hudiUpserts, Deletes And Incremental Processing on Big Data.项目地址https://gitcode.com/gh_mirrors/hud/hudi点击查看免费下载相关推荐ONNX 项目 RFC 提案流程与提案撰写指南从 RFC 到标准演进的完整路径ONNX 项目 RFC 提案流程与提案撰写指南从 RFC 到标准演进的完整路径 本文以 ONNX 仓库 docs/proposals/README.md ht人工智能机器学习深度学习OpenShell RFC 工作流详解从 create-rfc 技能到 rfc/ 模板的完整设计提案指南OpenShell RFC 工作流详解从 create rfc 技能到 rfc/ 模板的完整设计提案指南 在 OpenShell 这样的多 crate 平台型人工智能AI Agent自主智能体Agent 沙箱AI 安全治理形式化验证后端CLIONNX RFC 提案模板深度解析从 0000-template 到标准演进的设计流程指南ONNX RFC 提案模板深度解析从 0000 template 到标准演进的设计流程指南 ONNXOpen Neural Network Exchange人工智能机器学习深度学习上一篇FormsFX架构解析为什么它是JavaFX表单开发的革命性框架下一篇ESPnet 缅甸语 ASR 实战基于 HuBERT 自监督特征的 Transformer 低资源语音识别配方创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表