At_Least_Once 使用 S3 源的检查点似乎会在检查点持续时间内阻止事件源
At_Least_Once Checkpoint With S3 Source seems to block the event source for checkpointing duration
我正在尝试构建一个具有实时流处理的系统，flink 以 s3 作为源，elastic 作为接收器。
我一共尝试了4个关卡案例
- Exactly_Once 与对齐的检查点。
- Exactly_Once 具有未对齐的检查点。
- At_Least_Once 最多 1 个并发检查点。
- At_Least_Once 最多 2 个并发检查点。
Exactly_Once 未对齐的检查点似乎在发布到接收器时延迟最少。
虽然其余三个的延迟似乎相似。
根据文档：At_Least_Once 不应在检查点期间阻止一个流的事件，以防对齐延迟。
在基于文件系统的源的情况下，这种行为会改变吗？
职位详情：--
我们有另一项实时将文件写入 S3 的服务。
零件文件每 1 分钟关闭一次。
flink 作业在 PROCESS_CONTINUOUSLY 模式下使用 env.readFile 从这个 s3 路径消耗，window 大小为 30s。
我们期望最大处理延迟为 5m，但是
情况 2：-- 我们观察到 8-10 米的延迟。
情况 1、3、4 :-- 延迟 10-14 米。
我们运行这份工作有 16 个相似的来源。
我能够看到检查点延迟是由于来自两个来源的背压造成的。其tps分别为180和90，它们的对齐延迟分别为~7m和~6m。
但是我们可以看到资源消耗在整个期间保持相当稳定。内存峰值最多达到堆的 70%。
以这种方式从 S3 摄取性能不佳且成本高昂（因为它为每次迭代执行 ListObjects）。
更好的解决方案是使用自定义 SQS 源（据我所知，没有官方源）使用 Amazon S3 Event Notification. Here is a sample implementation。
我正在尝试构建一个具有实时流处理的系统，flink 以 s3 作为源，elastic 作为接收器。
我一共尝试了4个关卡案例
- Exactly_Once 与对齐的检查点。
- Exactly_Once 具有未对齐的检查点。
- At_Least_Once 最多 1 个并发检查点。
- At_Least_Once 最多 2 个并发检查点。
Exactly_Once 未对齐的检查点似乎在发布到接收器时延迟最少。
虽然其余三个的延迟似乎相似。
根据文档：At_Least_Once 不应在检查点期间阻止一个流的事件，以防对齐延迟。
在基于文件系统的源的情况下，这种行为会改变吗？
职位详情：--
我们有另一项实时将文件写入 S3 的服务。 零件文件每 1 分钟关闭一次。
flink 作业在 PROCESS_CONTINUOUSLY 模式下使用 env.readFile 从这个 s3 路径消耗，window 大小为 30s。
我们期望最大处理延迟为 5m，但是 情况 2：-- 我们观察到 8-10 米的延迟。 情况 1、3、4 :-- 延迟 10-14 米。
我们运行这份工作有 16 个相似的来源。
我能够看到检查点延迟是由于来自两个来源的背压造成的。其tps分别为180和90，它们的对齐延迟分别为~7m和~6m。
但是我们可以看到资源消耗在整个期间保持相当稳定。内存峰值最多达到堆的 70%。
以这种方式从 S3 摄取性能不佳且成本高昂（因为它为每次迭代执行 ListObjects）。
更好的解决方案是使用自定义 SQS 源（据我所知，没有官方源）使用 Amazon S3 Event Notification. Here is a sample implementation。