Question

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

我们计划使用Sessions窗口策略，如果相关，则间隔持续时间为3秒。

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

Answer 1

我们一直在使用测试工具为我们的应用程序流程运行基准测试，但后来又恢复了将当前开箱即用的Google提供的PubSub基准测试到PubSub模板流程（请参阅：https://cloud.google.com/dataflow/docs/templates/overview，尽管未列出在这里 - 您可以从控制台创建它。

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

测试发布者 - ＆gt; PubSub - ＆gt;数据流 - ＆gt; PubSub - ＆gt;测试用户。

对于单个实例发布者和订阅者，我们改变了消息率并尝试了窗口和触发策略，看看我们是否可以改善平均延迟，但通常无法提高 1.7秒端到端每秒1,500 - 2000条消息（我们的典型工作量）。

然后，我们从等式中删除了数据流，并直接将发布者与订阅者联系起来，并且对于相同的消息速率，通常会看到 20-30毫秒的延迟。

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

我们对管道中各个点的时间戳进行了采样，并将值写入了一些自定义指标，并且看到将消息添加到PubSubIO.Read的初始PCollection的平均延迟大约是 380msec ，但最小值低至 25msec ，由于启动开销，我们忽略了较高的值。但似乎有一个我们无法影响的开销。

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

    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)));

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

1 个答案: