一、引言
在数据湖架构中，如何在海量文件中实现ACID事务、支持时间旅行（Time Travel）并高效处理增量数据？Apache Hudi 给出的答案是——Timeline（时间线）。Timeline相当于Hudi内部的“数据库事务日志”，它记录了数据湖上发生的所有状态变更，它通过在 .hoodie 目录下维护一系列按时间顺序排列的日志文件，确保了：
- 读写隔离：读操作只会看到已经“Completed”的数据，不会被正在写入的事务所影响。
- 增量拉取：下游任务可以通过对比Timeline上的时间戳，精准获取两次提交之间的增量数据。
- 数据恢复：支持基于时间点的时间旅行（Time Travel）查询和回滚（Rollback）。
二、Timeline机制原理
Hudi作为数据湖领域的核心组件，其 Timeline（时间线）机制是整个系统的"心脏"——由一系列的 Instant（瞬间/时刻） 组成，每个 Instant 记录了在特定时间点对Hudi表执行的特定操作。一个完整的 Instant 包含三个核心要素：[时间戳 (Timestamp), 操作类型 (Action), 状态 (State)]。
Hudi Timeline 支持的 Action 类型共11 种：
| # | Action 类型 | 说明 | 适用表类型 |
|---|---|---|---|
| 1 | commit | COW 表的数据写入提交 | COW |
| 2 | deltacommit | MOR 表的数据写入提交（写入 log 文件） | MOR |
| 3 | clean | 清理旧版本的数据文件，回收存储空间 | COW / MOR |
| 4 | rollback | 回滚失败或部分完成的写入操作 | COW / MOR |
| 5 | savepoint | 标记某个 instant 为保存点，防止其对应文件被清理 | COW / MOR |
| 6 | compaction | 将 MOR 表的 log 文件与 base file 合并为新的 base file | MOR |
| 7 | restore | 将表恢复到某个 savepoint 对应的状态 | COW / MOR |
| 8 | clustering | 对数据文件进行重新组织（重排序、合并小文件） | COW / MOR |
| 9 | indexing | 异步构建或更新索引（列统计、布隆过滤器等） | COW / MOR |
| 10 | replace_commit | 替换文件组的提交（由 clustering/insert_overwrite 产生） | COW / MOR |
| 11 | logcompaction | 将 MOR 表多个 log 文件合并为更大的 log（不生成 base file） | MOR |
每个Action在其生命周期内会经历三种状态的流转：
- REQUESTED（已请求）：表明某个操作被调度，但尚未开始执行。
- INFLIGHT（执行中）：表明操作正在执行中。
- COMPLETED（已完成）：表明操作已成功完成，数据对外可见。
TimeLine的文件系统布局示意如下：
my_hudi_table/
├── .hoodie/
│ ├── 20240601120000000.commit.requested # REQUESTED
│ ├── 20240601120000000.commit.inflight # INFLIGHT
│ ├── 20240601120000000.commit # COMPLETED
│ ├── 20240601130000000.deltacommit.requested
│ ├── 20240601130000000.deltacommit.inflight
│ ├── 20240601130000000.deltacommit
│ ├── 20240601140000000.clean.requested
│ ├── 20240601140000000.clean.inflight
│ ├── 20240601140000000.clean
│ ├── hoodie.properties # 表级元数据
│ └── metadata/ # Metadata Table (1.0 核心)
│ ├── .hoodie/ # MDT 自身的 timeline
│ ├── files/ # 文件索引分区
│ ├── column_stats/ # 列统计分区
│ ├── bloom_filters/ # 布隆过滤器分区
│ ├── record_index/ # 记录级索引分区
│ ├── functional_index/ # 函数索引分区
│ └── timeline/ # ← 1.0 新增: 归档 Timeline
│ └── [LSM-Tree 格式的归档文件]
└── partition_path/
├── [file_group_id].parquet # base file (COW/MOR)
└── .[file_group_id]_[instant].[n].log # log file (MOR only)
三、Timeline版本核心差异（1.x vs 0.x）
1.存储架构的升级：从小文件噩梦到 LSM 日志
在 0.x 版本中，Timeline 严重依赖底层文件系统的文件级操作，一个完整的commit生命周期（Requested -> Inflight -> Completed），会在.hoodie目录下生成 3 个独立的物理小文件，Hudi将Timeline分为两部分：Active Timeline（存储最近的Instants，直接以文件形式放在 .hoodie 目录下）、Archived Timeline（旧的Instants会被打包压缩成单独的日志文件存放在 .hoodie/archived 目录下）。
在这种设计架构下，存在以下痛点：
- 小文件爆炸：对于分钟级或秒级的流式写入，
.hoodie目录会迅速积攒数以万计的极小 JSON 文件（几KB）。 - I/O 瓶颈：在 HDFS 上会对 NameNode 造成巨大压力；在 S3/OSS 等云存储上，
List目录和底层的Rename操作（用来原子的推进状态）极其缓慢，且容易触发 API 限流。
在1.x版本中，Hudi 引入了Timeline V2，它摒弃了“一个状态一个文件”的做法，转而采用类似关系型数据库 WAL（预写式日志）和 LSM-Tree 的设计。所有的 Instant 状态变更事件都被序列化（Avro格式），追加写入（Append）到统一的活跃日志文件（Active Timeline Log）中。
新版本Timeline架构带来显著提升：
- 彻底消灭元数据小文件：极大减少了文件数量，无论写入频率多高，Active Timeline 的物理文件数都被控制在极小范围内。
- 极速的元数据访问：文件系统的 List 和 I/O 操作下降了 10~100 倍，极大降低了流作业 Checkpoint 时的元数据同步延迟。
2.MVCC 与并发控制的重构：从单时间戳到双时间戳
Hudi 0.x 是基于 Instant Time 的阻塞式 MVCC，依赖唯一的Instant Time（即操作的发起时间）来决定事务顺序和可见性。它存在读阻塞的问题，假设有一个耗时 1 小时的 Compaction（开始于 T1），以及多个每分钟提交一次的 Ingestion 增量写入（开始于 T2, T3...）。由于 T1 迟迟未完成（处于 Inflight），当下游 Reader 在 T4 时刻读取数据时，为了保证强一致性，通常会阻塞或者无法看到 T1 之后已经完成的 T2, T3 数据。
为了解决上述问题，Hudi 1.x 引入了双时间戳机制来实现非阻塞 MVCC，除了记录开始的Instant Time，当事务真正写完时，会赋予一个Completion Time（完成时间）。在上述例子中，当下游 Reader 读取时，改用Completion Time构建数据快照。即使 T1 的 Compaction 还在跑，Reader 依然可以直接根据 Completion Time 看到已经完成的 T2, T3 数据，实现了长耗时后台任务与高频前台读写的彻底解耦。另外，在多 Writer 并发（如多线程更新不同文件组）时，结合 Completion Time 可以实现更灵活的乐观并发控制（OCC），大幅降低了以前经常出现的“冲突误杀（Conflict Aborts）”概率。
3.版本差异对比
| 对比维度 | Hudi 0.x (Timeline Layout V1) | Hudi 1.x (Timeline Layout V2) | 核心影响/价值 |
|---|---|---|---|
| 底层架构思想 | 基于离散物理文件的状态机 | 基于 LSM-Tree 的事件日志追加 (Log Append) | 彻底消除小文件噩梦，适配高频流写 |
| 文件数量与I/O | O(N)，N=事务数*3，产生海量小文件，对象存储 API 压力巨大 | O(1)，少量日志文件块轮转，极低 I/O 次数 | 极大降低云存储 API 成本与流计算延迟 |
| 持久化格式 | 大量纯文本 JSON 文件 | 高效的 Avro 序列化二进制日志 | 元数据体积缩小，解析速度更快 |
| 时间轴机制 | 单一时间戳：Instant Time | 双时间戳：Instant Time + Completion Time | 1.x 真正实现了快照隔离级别解耦 |
| 并发与读可见性 | 阻塞式 MVCC：耗时的长事务（如Compaction）会阻塞后续短事务的读取可见性 | 非阻塞 MVCC：基于完成时间隔离，长短事务互不干扰 | 大幅提升下游实时流读（Streaming Read）的时效性 |
| 运维排障方式 | 直观：可直接在文件系统 ls 或 cat 文件明文 | 间接：需依赖 Hudi CLI 或 Spark SQL (show_commits 等过程) | 对运维人员的工具链使用提出了新要求 |
四、写入流程的 Timeline 完整流转示意
┌─────────────────────────────────────────────────────────────────────┐
│ Hudi 1.0 写入流程 Timeline 状态流转 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ Step 1: 生成 Instant Time │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ instantTime = 当前时间戳 (yyyyMMddHHmmssSSS) │ │
│ │ 确保全局唯一性 (时间戳 + 单调递增序列) │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Step 2: REQUESTED 状态 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 创建文件: .hoodie/{instantTime}.commit.requested │ │
│ │ 含义: 操作已被调度，尚未开始执行 │ │
│ │ 内容: 写入计划 (目标分区、文件组信息等) │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Step 3: INFLIGHT 状态 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 创建文件: .hoodie/{instantTime}.commit.inflight │ │
│ │ 含义: 操作正在执行中 │ │
│ │ 开始实际数据写入 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Step 4: 执行数据写入 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ • COW: 写入新的 Parquet base file │ │
│ │ • MOR: 追加 log file │ │
│ │ • 同步更新 Metadata Table │ │
│ │ • 记录写入统计 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Step 5: 冲突检测 (多写者场景) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ • 检查是否有其他 completed instant 修改了相同文件组 │ │
│ │ • 无冲突 → 继续 │ │
│ │ • 有冲突 (MOR/NBCC) → log 天然兼容，继续 │ │
│ │ • 有冲突 (COW/OCC) → 失败，触发 rollback action │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Step 6: COMPLETED 状态 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 创建文件: .hoodie/{instantTime}.commit │ │
│ │ 含义: 操作已在 timeline 上完成 │ │
│ │ 内容: CommitMetadata 包含: │ │
│ │ ★ completionTime (实际完成时刻) ← 1.0 关键字段 │ │
│ │ • partitionToWriteStats (分区写入统计) │ │
│ │ • totalRecordsWritten / totalBytesWritten │ │
│ │ • 变更文件列表 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Step 7: 后置服务操作 (可异步) │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ • 触发 clean action (清理旧文件版本) │ │
│ │ • 触发 archival (归档超出保留的 instants 到 MDT) │ │
│ │ • 调度 compaction (MOR 表) │ │
│ │ • 调度 logcompaction (MOR 表，高频写入场景) │ │
│ │ • 调度 clustering (如果配置) │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
