1. Hudi 增量查询概述
各位同学好，我是你们的老朋友。今天咱们开始《Hudi 增量查询性能调优》的第一章。
先聊聊什么是增量查询。说白了，增量查询就是「只读新增或变更的数据」，而不是每次把整个表全扫一遍。我刚开始接触 Hudi 时，觉得这不就是个带时间戳的过滤吗？后来才发现，事情没那么简单。
1.1 什么是增量查询
Hudi 的增量查询，核心思路是：记录每次提交（commit）产生的变更数据，查询时指定一个起始时间点，只读取该时间点之后发生变更的文件组。
举个例子。假设你的订单表每小时更新一次。用快照查询，每次都要扫描全部历史数据。用增量查询，你只需要读「上次查完到现在」新增或修改的那部分数据。
核心机制：Hudi 在写入时，会为每个文件组维护一个 _hoodie_commit_time 字段。增量查询就是利用这个字段，结合 beginTime 参数，精准定位变更文件。
我个人习惯把增量查询理解为「订阅模式」——你订阅了一张表的变化，每次拉取只拿增量，不碰存量。
1.2 与快照查询的区别
很多新手会问：增量查询和快照查询到底差在哪？我直接列个对比表，一目了然。
| 对比维度 | 快照查询 | 增量查询 |
|---|---|---|
| 读取范围 | 全表最新快照 | 指定时间范围内的变更数据 |
| 数据量 | 大（全量） | 小（仅增量） |
| 查询延迟 | 高（扫描所有文件） | 低（只读变更文件） |
| 适用场景 | 全量分析、报表 | 实时流处理、CDC |
| 依赖条件 | 无 | 需指定起始时间戳 |
| 数据一致性 | 强一致（最新状态） | 最终一致（变更序列） |
你看，快照查询是「拍照片」，增量查询是「录视频」。照片能看到全貌，但每次重拍成本高；视频只记录变化，回放时省带宽。
我记得有一次，团队里有人用快照查询做实时大屏，每 5 秒扫一次全表。结果集群 CPU 直接飙到 90%。换成增量查询后，负载降到 15% 以下。嗯，这就是选错查询类型的代价。
1.3 适用场景分析
增量查询不是万能的。我根据自己的实战经验，把适用场景分成三类：
场景一：实时数据同步（CDC）
这是最典型的用法。比如从 MySQL 通过 Canal 同步到 Hudi，下游再用增量查询拉取变更，写入 Elasticsearch 或 Redis。你想想看，如果每次全量同步，ES 的索引重建成本得多高？
我的建议：CDC 场景下，增量查询的起始时间戳最好用 InstantTime 管理，不要用系统时间。我曾经踩过坑——系统时间回拨导致数据重复消费。
场景二：微批处理（Micro-Batch）
很多流处理框架（如 Spark Streaming）用微批模式。每批处理一个时间窗口的数据。增量查询天然适合这种模式：每批指定一个 beginTime 和 endTime，精准拉取窗口内的变更。
// 增量查询示例（Spark SQL）
spark.read()
.format("org.apache.hudi")
.option("hoodie.datasource.query.type", "incremental")
.option("hoodie.datasource.read.begin.instanttime", "20240101000000")
.option("hoodie.datasource.read.end.instanttime", "20240101010000")
.load("/path/to/hudi/table")
场景三：增量 ETL
数据仓库里，经常需要从 ODS 层增量抽取数据到 DWD 层。用快照查询的话，每天跑一次全量，存储和计算都扛不住。增量查询只拿当天新增的数据，效率高得多。
注意：增量查询不适合「需要全量历史回溯」的场景。比如你要做年度趋势分析，用增量查询逐条拉取，反而比快照查询慢。为什么？因为增量查询每次都要解析 commit 元数据，拉取次数多了，开销就上来了。
1.4 增量查询的核心流程
为了让你更直观地理解，我画了一张流程图。这张图展示了从「提交查询」到「返回结果」的完整链路。
流程其实不复杂。但这里有个坑——Timeline 的清理策略。Hudi 默认会清理旧的 commit 元数据。如果你指定的 beginTime 太早，对应的元数据已经被清理了，查询就会失败。
避坑指南：我曾经因为没配 hoodie.keep.max.commits，导致增量查询报错「Instant not found」。后来我习惯把保留的 commit 数设大一些，比如 1000 个，同时配合归档策略，既保证查询可用，又不让元数据膨胀。
1.5 增量查询的局限性
说了这么多优点，也得聊聊它的短板。增量查询不是银弹，我总结了三个常见问题：
- 不支持跨分区增量：默认只查当前分区。如果你要跨分区增量，得自己处理分区路径。
- 数据重复风险：如果任务失败重试，beginTime 没处理好，可能读到重复数据。
- 元数据依赖：Timeline 一旦损坏或清理，增量查询就废了。