用于实时处理的Google Cloud Dataflow延迟

Question

在我们只对高流量Google Dataflow群集进行简单转换并且每个"数据点"都很小的情况下,我们可以预期Dataflow的延迟有多低.

我们计划使用Sessions窗口策略,间隔持续时间为3秒,如果相关的话.

从数据点到数据流的时间到输出结果可能少于2秒是否现实？不到1秒？

Answer 1

我们一直在使用测试工具为我们的应用程序流程运行基准测试,但后来又恢复了对当前开箱即用的Google提供的PubSub到PubSub模板流程的基准测试(请参阅:https://cloud.google.com/dataflow/ docs/templates/overview虽然未在此处列出,但您可以从控制台创建它.

我们的测试工具生成并发送了数百个带有时间戳的数百字节JSON格式的消息,并比较了两端的延迟.非常简单:

测试发布者 - > PubSub - >数据流 - > PubSub - >测试订阅者.

对于单实例发布者和订阅者,我们改变了消息速率并尝试了窗口和触发策略,看看我们是否可以改善平均延迟,但通常无法在1,500 - 2000条消息中端到端地改进1.7秒以上每秒(我们的典型工作量).

然后,我们从等式中删除了Dataflow,并直接将发布者连接到订阅者,并且对于相同的消息速率,通常看到延迟通常在20-30毫秒左右.

恢复使用标准PubSub到PubSub数据流模板,我们看到端到端延迟类似于我们的应用程序数据流大约1.5 - 1.7秒.

我们在管道中的各个点对时间戳进行采样,并将值写入数字自定义指标,并且已经看到将消息添加到PubSubIO.Read的初始PCollection的平均延迟大约为380毫秒,但最小值为25毫秒,由于启动开销,我们忽略了更高的值.但似乎有一个我们无法影响的开销.

我们尝试的窗口策略如下所示:

    Pipeline p = Pipeline.create(options);
    /*
     * Attempt to read from PubSub Topic
     */
    PCollectionTuple feedInputResults =
            p.apply(feedName + ":read", PubsubIO.readStrings().fromTopic(inboundTopic))
            .apply(Window.<String>configure()
                .triggering(Repeatedly
                    .forever(AfterWatermark.pastEndOfWindow()
                            .withEarlyFirings(
                                    AfterProcessingTime
                                            .pastFirstElementInPane()
                                            .plusDelayOf(Duration.millis(windowDelay)))
                                            // Fire on any late data
                                            .withLateFirings(AfterPane.elementCountAtLeast(windowMinElementCount))))
                    .discardingFiredPanes())
            .apply(feedName + ":parse", ParDo.of(new ParseFeedInputFn())
                        .withOutputTags(validBetRecordTag,
                        // Specify the output with tag startsWithBTag, as a TupleTagList.
                        TupleTagList.of(invalidBetRecordTag)));