Hudi 时间线与增量查询
Hudi 的时间线（timeline）按时间顺序记录每次提交动作与状态：commit、deltacommit、compaction、clean 等。增量查询可以按时间点拉取某段区间内的变更，适合做下游增量同步；时间线过长会影响元数据读取性能，需要通过归档（archive）与清理策略控制长度。
基本信息
| 时间线 | 按时间顺序记录的提交历史 |
|---|---|
| 动作类型 | commit、deltacommit、compaction、clean |
| 增量查询 | 按起止时间点拉取变更 |
| 归档 | 定期归档旧提交的瞬时文件 |
| 主要风险 | 归档过早导致增量起点失效 |
典型使用场景
- 下游增量同步：按上次消费时间点拉取变更，避免全量扫描
- 变更审计：按时间线定位某次写入对应的提交动作与状态
- 压缩运维：关注 compaction 是否按计划执行，避免读放大累积
- 归档配置：按提交数量阈值归档旧瞬时文件，控制时间线长度
- 排查读取变慢：先看时间线文件数量与归档目录规模
增量查询
增量查询
-- 增量查询：按上次消费时间点拉取变更
set hoodie.<table>.consume.mode=INCREMENTAL;
set hoodie.<table>.consume.start.timestamp=20261012080000;
set hoodie.<table>.consume.max.commits=10; -- 单次最多消费若干个提交
SELECT * FROM hudi_trade_order WHERE dt = '2026-10-12';
-- 起点管理要集中：下游各自记住进度时，起点丢失即造成重复或漏数时间线动作与关注点
| 动作 | 含义 | 关注点 |
|---|---|---|
| commit | 一次写入提交 | 是否按调度持续产生 |
| deltacommit | MOR 表的增量提交 | delta 文件是否持续增长 |
| compaction | 把增量合并到基础文件 | 是否按时执行，影响读放大 |
| clean / archive | 清理与归档旧版本 | 保留策略与增量起点 |
增量查询要与归档、清理策略一起设计：归档过早会让下游的增量起点失效，碰到这种情况只能改成全量重跑。
时间线过长的直接表现是元数据读取变慢，所有读取路径都受影响；归档阈值与清理策略要按实际提交频率设定，不能沿用默认值。
增量查询适合链路短的场景：如果下游又基于增量结果做多层加工，中间任何一层起点出问题都会传导到最末端，因此起点进度要以元数据形式集中记录。