数据流GroupByKey对于具有小窗口(最好是2秒)的流式管道非常慢。

Question

我有一个简单的数据流管道配置为2秒的固定窗口。它从pub/sub读取，反序列化消息到对象，记录对象，根据给定的键对对象进行分组，然后对分组的对象执行一些处理。请记住，这是一个从1VM开始的数据流工作(不像它需要做洗牌，因为它只有一个VM)。它只看到几条消息(如2-3条)/秒。

| "read_messages" >> io.ReadFromPubSub(subscription=input_topic_subscription_path)
         | "window" >> WindowInto(FixedWindows(2))
         | "deser_obj" >> ParDo(DeSerializeToObject())
         | "key_by_id" >> WithKeys(lambda obj: obj.id)
         | "group_by_player_id" >> GroupByKey()
         | "process_group" >> ParDo(ProcessGroup())

我看到的问题是，GroupByKey的持续时间大约是36秒。process_group阶段的日志总是比deser_obj阶段的日志落后25-40秒。因此，管道的data freshness位于36秒左右。这似乎是没有意义的:有一个流式管道，处理在2秒微批，但每一个微型批处理需要36秒完成。

我甚至遵循了这个GCP教程，它的结果是相同的(即每个窗口花费36秒，GroupByKey是瓶颈)：https://cloud.google.com/pubsub/docs/pubsub-dataflow#python

数据流不是设计成像2秒微批次这样的小时间间隔进行流的吗？根据我所看到的数字，只有当您的流需要SLA >40秒时，我才会推荐数据流流。

Answer 1

正确的是，Dataflow还没有(还)调优来处理10秒以下的延迟，尽管36秒的速度看起来有点慢。FYI，ReadFromPubSub确实引入了一个洗牌来确保精确的一次，即没有重复的)，而GroupByKey也做了一个完全的分布式洗牌，尽管只有一个VM。