Hi！ 1 换言之，是针对每个检查点，合并了多个并发subtask产生的文件对吧。
正确 2 除此以外，多个检查点之间的文件是没有办法合并的对吧。 正确 实际部分节点做的是后台IO了事情，是不是反映不到busy情况上 是的，busy 的计算方式是通过采样看有多少个线程正在工作。对于 sink 这种线程都在等待后台 io 的节点来说确实 busy 值不会很高。 yidan zhao <[email protected]> 于2021年11月4日周四 下午5:57写道： > hi,还想继续问下。这个合并机制，根据文档介绍如下。 > Whether to enable automatic compaction in streaming sink or not. The data > will be written to temporary files. After the checkpoint is completed, the > temporary files generated by a checkpoint will be compacted. The temporary > files are invisible before compaction. > 看文档，是指每次检查点完成后，会将单个检查点产生的文件进行合并。也就是说只有单个检查点产生的文件会被合并。 > 1 换言之，是针对每个检查点，合并了多个并发subtask产生的文件对吧。 > > 2 除此以外，多个检查点之间的文件是没有办法合并的对吧。 > > 3 另外一个问题：目前看flinksql写hive，streaming情况。从web > > ui上看不开启compact情况下，几乎每个节点都是蓝色，而且数据量不大。开启compact情况，几乎也都是蓝色，数据量也不大，但只有compact节点是持续红色。 > > 按照我的理解写hive这种情况下，实际部分节点做的是后台IO了事情，是不是反映不到busy情况上，busy比如只考虑对接受元素的处理，至于这个元素导致这个算子有多少background的工作并反映不出来。对吗。 > 所以即使看起来都是蓝色的，也不能降低并行度，而是自行根据数据量采用一个差不多的并行度。 >
