更新时间:2024-05-28 GMT+08:00
分享

Hudi数据表Clean规范

Clean也是Hudi表的维护操作之一,该操作对于MOR表和COW表都需要执行。Clean操作的目的是为了清理旧版本文件(Hudi不再使用的数据文件),这不但可以节省Hudi表List过程的时间,也可以缓解存储压力。

规则

Hudi表必须执行Clean。

对于Hudi的MOR、COW表,都需要开启Clean。

  • Hudi表在写入数据时会自动判断是否需要执行Clean,因为Clean的开关默认打开(hoodie.clean.automatic默认为true)。
  • Clean操作并不是每次写数据时都会触发,至少需要满足两个条件:
    1. Hudi表中需要有旧版本的文件。对于COW表来说,只要保证数据被更新过就一定存在旧版本的文件。对于MOR表来说,要保证数据被更新过并且做过Compaction才能有旧版本的文件。
    2. Hudi表满足hoodie.cleaner.commits.retained设置的阈值。如果是Flink写hudi,则至少提交的checkpoint要超过这个阈值;如果是批写Hudi,则批写次数要超过这个阈值。

建议

  • MOR表下游采用批量读模式,采用clean的版本数为compaction版本数+1。

    MOR表一定要保证Compaction Plan能够被成功执行,Compaction Plan只是记录了Hudi表中哪些Log文件要和哪些Parquet文件合并,所以最重要的地方在于保证Compaction Plan在被执行的时候它需要合并的文件都存在。而Hudi表中只有Clean操作可以清理文件,所以建议Clean的触发阈值(hoodie.cleaner.commits.retained的值)至少要大于Compaction的触发阈值(对于Flink任务来说就是compaction.delta_commits的值)。

  • MOR表下游采用流式计算,历史版本保留小时级。

    如果MOR表的下游是流式计算,例如Flink流读,可以按照业务需要保留小时级的历史版本,这样的话近几个小时之内的增量数据可以通过log文件读出,如果保留时长过短,下游flink作业在重启或者异常中断阻塞的情况下,上游增量数据已经Clean掉了,flink需要从parquet文件读增量数据,性能会有下降;如果保留时间过长,会导致log里面的历史数据冗余存储。

    具体可以按照下面的计算公式来保留2个小时的历史版本数据:

    版本数设置为3600*2/版本interval时间,版本interval时间来自于flink作业的checkpoint周期,或者上游批量写入的周期。

  • COW表如果业务没有历史版本数据保留的特殊要求,保留版本数设置为1。

    COW表的每个版本都是表的全量数据,保留几个版本就会冗余多少个版本。因此如果业务无历史数据回溯的需求,保留版本数设置为1,也就是保留当前最新版本

  • clean作业每天至少执行一次,可以2~4小时执行一次。

    Hudi的MOR表和COW表都需要保证每天至少1次Clean,MOR表的Clean可以参考2.2.1.6小节和Compaction放在一起异步去执行。COW的Clean可以在写数据时自动判断是否执行。

分享:

    相关文档

    相关产品