StreamFileSink源码分析

flink 端到端数据一致性 两种方案
1、预写日志： StreamFileSink
2、2pc： 参考 FlinkKafkaProducer
3、幂等性：利用目标端数据库 的主键更新去重

StreamFileSink源码分析
1、initializeState 创建bucket
2、invoke bucket写入数据 In-progress ：当前文件正在写入中
3、snapshotState 关闭文件 Pending：当处于 In-progress 状态的文件关闭（closed）了，就变为 Pending 状态
4、notifyCheckpointComplete Finished ：在成功的 Checkpoint 后，Pending 状态将变为 Finished 状态，改文件名

forRowFormat行写可基于文件大小、滚动时间、不活跃时间进行滚动，但是对于forBulkFormat列写方式只能基于checkpoint机制进行文件滚动，即在执行snapshotState方法时滚动文件，如果基于大小或者时间滚动文件(row)，那么在任务失败恢复时就必须对处于in-processing状态的文件按照指定的offset进行truncate，我想这是由于列式存储是无法针对文件offset进行truncate的，因此就必须在每次checkpoint使文件滚动，其使用的滚动策略实现是OnCheckpointRollingPolicy。

重点方法
checkpoint初始化时 Buckets.initializeActiveBuckets.handlePendingInProgressFile
处于in-progress状态的文件，在该次Checkpoint成功之后，故障发生之前（这里假设状态恢复是由于发生故障引起），有以下几种可能，
1 仍然处于in-progress状态，没有继续写入，文件有效长度仍然是Checkpoint时由snapshotState方法记录下的currentFileValidLength；
2 仍然处于in-progress状态，发生了写入，文件有效长度大于记录下的currentFileValidLength；
3 已经关闭并处于pending状态；
4 已经处于finished状态；
无论处于以上哪种状态，现在需要做的，就是将文件的有效长度恢复到Checkpoint成功时记录的currentFileValidLength。因为恢复后的in-progress状态的文件不再继续写入（产生新文件来写入后续数据），因此先将该文件重命名置为finished状态（已经是finished状态则省略这一步），然后有两种做法，
1 如果文件系统支持truncate，则直接将文件truncate到currentFileValidLength这个有效长度即可；（hadoop2.7以上支持）
2 不支持truncate的话，则新建一个{valid_length_prefix}{part_prefix}-{parallel_task_index}-{count}{part_suffix}{valid_length_suffix}文件，将currentFileValidLength写入该文件，后续在读取数据文件时需要先读取这个记录了该文件有效长度的文件以确保数据的有效性，否则可能读取到重复的数据，这样就不能保证exactly-once语义了；

https://blog.csdn.net/kisimple/article/details/83998238?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control

https://www.cnblogs.com/night-xing/p/12576919.html
https://blog.csdn.net/lvwenyuan_1/article/details/102600860
https://www.cnblogs.com/Springmoon-venn/p/13847868.html