浅谈hudi 的callback回调机制
关于hudi的write operations,hudi有4种类型,分别为upsert/insert/bulk_insert/delete[软删除/硬删除]。
了解hudi的都知道,hudi有一个核心的机制就是timeline,hudi的instantDTO包含action(动作),ts(时间),state(状态)。

action主要包括:
commits:提交表示将一批记录原子写入表中;
cleans:删除表中不再需要的旧版本文件的后台活动;
delat_commite:增量提交指的是将一批记录原子写入 MergeOnRead 类型的表中，其中一些/所有数据可以只写入增量日志;
compaction:协调 Hudi 内差异数据结构的后台活动，例如：将更新从基于行的日志文件移动到列格式。 在内部，压缩表现为时间轴上的特殊提交;
ROLLBACK:表示提交/增量提交不成功并回滚，删除在此类写入期间产生的任何部分文件.
SAVEPOINT:将某些文件组标记为“已保存”，这样清理器就不会删除它们。 在发生灾难/数据恢复情况时，它有助于将表恢复到时间线上的某个点。
参考官方文档如下。

关于hudi 的数据actions后，有几种数据状态,状态包括如下:
REQUESTED:表示已计划但尚未启动的操作;
INFLIGHT:表示当前正在执行该操作;
已完成:表示时间轴上的操作已完成;

下面重点看一下hudi的callback。
目前hudi的commit的回调提供了http/kafka/plusar的方案，具体配置信息可以参考官方文档。
以下主要看一下阅读一下源码

接口HoodieWriteCommitCallback，主要发布了call的方法。

回调发送内容数据为HoodieWriteCommitCallbackMessage。
主要包括了提交时间、表名、表存储路径、hudi write的统计信息.可以下钻分析一下HoodieWriteState实体类

http的callback方式的实现类

官方文档的配置信息主要是针对HoodieWriteCommitHttpCallbackClient生成的，可以阅读一下该类，核心是send方法

HoodieWriteCommitKafkaCallback，将callbackmessage类型数据转成json

接下来看hudi的对接引擎是怎么用的

抽象类witeclient的

在commitStats方法中，最后提交成功后进行回调机制

举例查看flink write

**

总结:

**
1、根据内部需求可以自定义实现回调接口,比如实现dubbo的方案，或者针对该方案可以进行二次开发改造，
2、实时和离线数仓如何去结合回调机制进行整个数仓的建设
问:离线调度的方案该如何实现,多个commit,下游该如何去识别该批任务已经完成了。
答:计算引擎+hudi实现任务计算，数据任务回调发送到下游数据。根据HoodieWriteCommitCallbackMessage，数据进行合并解析。在下有一个任务启动前，判断是否上一个任务已经完成了。
3、针对2的问题，上游任务完成状态的标准判定。
有时间判断的标准，按照上下游的时间是否合理，定时促发任务。
如果上游数据有一个延迟，如何去控制。全量和增量解法,如果是全量的数据，就会存在数据丢失，增量存在数据延迟。可以不采取定时促发的机制，轮训监听上游数据成功。可以借用调度器方案(海豚调度器)的dag的方案
4、针对实时方案,不需要依赖数据处理，可以通过监控进行数据异常和延迟判断。
5、在commit执行到一半是异常出错后，应该需要回滚。否则数据丢失。