由于窗口对象或内部处理而丢弃大量事件的数据流

Question

最近开发了一个数据流消费者，它从PubSub订阅中读取数据，并将分组在同一窗口中的所有对象的组合输出到拼花文件。

当我在没有巨大负载的情况下进行测试时，一切似乎都很好。

然而，在执行了一些繁重的测试后，我可以看到，从发送到PubSub队列的1.000.000个事件中，只有1000个事件成功到达Parket！

根据不同阶段的多个墙时间，在应用窗口之前解析事件的墙时间似乎持续58分钟。写入拼花文件的最后阶段持续1小时32分钟。

我现在将展示其中最相关的代码部分，希望您能够了解这是由于窗口对象定义之前的逻辑造成的，还是由于窗口对象本身造成的。

pipeline
        .apply("Reading PubSub Events",
            PubsubIO.readMessagesWithAttributes()
                .fromSubscription(options.getSubscription()))
        .apply("Map to AvroSchemaRecord (GenericRecord)",
            ParDo.of(new PubsubMessageToGenericRecord()))
        .setCoder(AvroCoder.of(AVRO_SCHEMA))
        .apply("15m window",
            Window.<GenericRecord>into(FixedWindows.of(Duration.standardMinutes(15)))
                .triggering(AfterProcessingTime
                    .pastFirstElementInPane()
                    .plusDelayOf(Duration.standardSeconds(1)))
                .withAllowedLateness(Duration.ZERO)
                .accumulatingFiredPanes()
        )

还要注意，我正在运行Beam 2.9.0。

第二阶段中的逻辑是否会过于繁重，以至于消息到达得太晚而在窗口中被丢弃？逻辑基本上包括读取有效负载、解析为POJO（读取内部映射属性、过滤等）

但是，如果我向PubSub发送了一百万个事件，那么所有这些一百万个事件都会一直持续到拼花写入文件阶段，但是这些拼花文件并不包含所有这些事件，只是部分包含。这有意义吗？

我需要触发器独立于延迟消耗所有这些事件。

Answer 1

引用Apache Beam邮件列表上的答案：

这是一个不幸的可用性问题，触发器可能会意外关闭窗口并删除所有数据。相反，我认为你可能需要这个触发器：

Repeatedly.forever(
    AfterProcessingTime
                .pastFirstElementInPane()
                .plusDelayOf(Duration.standardSeconds(1)))

我建议使用以下方式来表示此触发器：

AfterWatermark.pastEndOfWindow().withEarlyFirings(
    AfterProcessingTime
                .pastFirstElementInPane()
                .plusDelayOf(Duration.standardSeconds(1)))

在第二种情况下，不可能意外“关闭”窗口并删除所有数据。