浅谈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执行到一半是异常出错后,应该需要回滚。否则数据丢失。