带有At_Least_Once源的S3检查点似乎会阻塞事件源，以保持检查点持续时间

Question

我正在尝试建立一个实时流处理系统，flink以s3为源，弹性为接收器。

我总共试验了4个检查站的案件。

1. 带有对齐检查点的Exactly_Once。
2. Exactly_Once有unAligned检查点。
3. 最大1个并发检查点的At_Least_Once。
4. At_Least_Once具有最大2个并发检查点。

带有Exactly_Once检查点的unAligned似乎在发布到Sink方面的延迟最小。

而其余三家公司的延迟似乎也是相似的。

按照docs: At_Least_Once不应该在检查点期间阻塞一个流的事件，以防延迟对齐。

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

工作详情：--

我们还有另一个服务，就是实时地将文件写入S3。零件文件每1分钟关闭一次。

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

我们预计最大处理延迟5米，但在案例2:--我们观察到8-10米的延迟。判例1,3,4：-延迟10-14米。

我们正在用16个类似的来源来运行这项工作。

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

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

Answer 1

以这种方式从S3中摄取，性能很差，而且成本很高(因为它每次迭代都要执行ListObjects )。

更好的解决方案是使用亚马逊S3事件通知使用自定义的SQS源(AFAIK没有正式的)。这是示例实现。