我正在尝试构建一个具有实时流处理的系统，flink以s3为源，以elastic为汇。
我总共为检查站试行了4个案例。
- 具有对齐检查点的Exactly_Once
- Exactly_Once与不对齐的检查点
- At_Least_Once，最多1个并发检查点
- At_Least_Once，最多2个并发检查点
带有不对齐检查点的Exactly_Once似乎在发布到接收器时延迟最小。
而其余三个的延迟似乎相似。
根据文档：在对齐延迟的情况下，At_Least_On不应在检查点期间阻止一个流的事件。
在基于文件系统的源的情况下，这种行为会改变吗？
有关作业的详细信息：--
我们有另一个服务，它正在向S3实时写入文件。零件文件每1分钟关闭一次。
flink作业在PROCESS_CONTINUOUSLY模式下使用env.readFile从s3路径消耗，窗口大小为30s。
我们预计最大处理延迟为5米，但情况2:--我们观察到8-10m的延迟。情况1、3、4：延迟10-14m。
我们正在使用16个类似的来源运行此作业。
我可以看出，检查点延迟是由于来自其中两个源的背压造成的。其tps分别为180和90，并且它们的对准延迟为~7m和~6m。
然而，我们可以看到，在整个时期内，资源消耗保持相当稳定。内存峰值最大为堆的70%。
以这种方式从S3中获取执行较差且成本高昂(因为它为每次迭代执行ListObjects(。
一个更好的解决方案是使用AmazonS3事件通知使用自定义的SQS源(AFAIK没有官方的(。下面是一个示例实现。