问题描述
最近使用hudi 增量读的功能时，由于需要保留比较多的commits,因此设置比较的commits,假设spark steaming job 1分钟一个batch,保留一天增量读的commits数量就是1440。因此进行了如下设置。
"hoodie.keep.min.commits"= "1441"
"hoodie.keep.max.commits"="1442"
"hoodie.cleaner.commits.retained"= "1440"
"hoodie.cleaner.policy"="KEEP_LATEST_COMMITS"
设置之后，打开spark UI job页面，发现upsert partition 这个job 的提交时间 为09:43,而上一个job的提交时间为09:40,完成时间为09:41.从job页面上展示，中间 09:41到09:43的时间点像是整个job暂停了一样，没有什么其他展示。但是这短短的两分钟时间 job到底在做些什么操作呢
代码分享
- 首先,我们可以看一下job 的，job status描述，里面是
Getting small files from partitions:.翻到对应的Hudi代码，我们可以看到 调用的方法是getSmallFilesForPartitions. 如下图所示
getSmallFilesForPartitions方法调用之前，会调用averageBytesPerRecord方法，该方法是调用hoodie commits instants的内容来计算算出每个记录的平均size，因此会去扫描所有的commits文件。而且这一方法是在driver端完成的，因为没有算成是1个job。当你去打开driver端的stderr的log的时候，然后过滤09:43 也就upsert partition job的提交时间时，你会发现commits file扫描完成的时间，也就是upsert partition job的提交时间，这两个时间完成衔接的。
解决方案
如果我们既要解决hoodie commits过多的问题，又要保留1天的commits 文件来达到增量读的目的该如何解决呢？
我觉得比较好的方法是，增加spark streaming job的interval，将1分钟的延迟增加到5分钟，这样commits的个数可以从1440削减到288。这样在一定程度上可以缓解这个问题
