At_Least_Once检查点与S3源似乎阻止事件源的检查点持续时间

Question

我试图建立一个系统与实时流处理与flink具有s3作为源和弹性作为接收器。

我总共尝试了4个检查站案例。

1. 只有一次，检查点对齐
2. 使用未对齐的检查点执行一次
3. 至少\u次，最多1个并发检查点
4. 至少\u次，最多2个并发检查点

带有未对齐的检查点的Exactly\u Once似乎在向接收器发布时具有最小的延迟。

而其余三个的延迟似乎是相似的。

根据文档：At_Least_Once不应该在检查点期间阻塞一个流的事件，以防对齐延迟。

在基于文件系统的源的情况下，这种行为是否会改变？

作业详细信息：--

我们还有另一项服务，即实时将文件写入S3。零件文件每隔1分钟关闭一次。

Flink作业在窗口大小为30的PROCESS_CONTINUOUSLY模式下使用env.readFile从此s3路径消耗。

我们预计最大处理延迟为5m，但是对于案例2：-我们观察到延迟10m。案例1,3,4：-延迟14m。

我们正在使用16个类似的源运行此作业。

我可以看出，检查点延迟是由于来自两个来源的背压造成的。其tps分别为180和90，其对准延迟约为7m和6m。

然而，我们可以看到，资源消耗在整个期间保持相当稳定。内存峰值最大为堆的70%。

Answer 1

以这种方式从S3摄取数据的性能很差，而且成本很高（因为它为每个迭代都执行ListObjects）。

更好的解决方案是使用Amazon S3事件通知使用自定义SQS源（AFAIK没有官方的）。下面是一个示例实现。