Google cloud dataflow Google数据流-墙时间/收集输出数向后

我们正在进行的数据流管道的第一步是使用Python Beam API读取BigQuery

beam.io.Read(
  beam.io.BigQuerySource(
    project=google_project,
      table=table_name,
      dataset=big_query_dataset_id
    )
)

该表有90多亿行

由于此调用而启动的导出作业似乎完成得非常快—通常在3-5分钟之间，数据流要读取的文件夹中的数据量为*.avro格式

但是，当实际执行此操作时，第一步将数据读入PCollection时，在大约10-20分钟内工作正常-我们可以看到墙时间在增加，在该步骤中添加到输出集合的元素数量在增加，工作人员也在扩大以提供帮助

但是，经过一段时间（通常约10亿个元素或数据行），墙时间和元素数量都开始稳步减少。vCPU小时数继续以预期的速度增长，这意味着我们仍在以某种方式运行/仍在为CPU时间付费，但墙时间持续下降，PCollection输出/元素计数一直趋向于零。这是相当令人困惑的-我们无法从日志中判断出任何问题（至少看起来事情正在运行？），但考虑到所需的工人数量/成本，我们真的希望看到事情正在向前发展的证据

我甚至对此表示怀疑，也许在浏览器级别上发生了一些疯狂的事情，但我可以确认不同浏览器之间的行为，甚至是看同一份工作的不同人员之间的行为

以前有人见过这种情况吗？如果有，是什么原因造成的？这只是Dataflow提供的步骤显示/图形中的一个错误，还是这里发生了其他事情

提前感谢您的帮助

Edit-通过大量实验，我们能够解决这个问题

墙时间倒流的原因似乎与工作人员在处理一些热键时内存不足而崩溃有关。然后，撞车的工人停止了报告，这似乎使工作时间缩短了

总的来说，我们通过以下几点解决了这个问题：

我们将尽可能多的逻辑从GroupBy转移到轻量级组合器

我们总体上限制了GroupBy的数量

我们添加了Shuffle模式的使用，这似乎对一些阻塞点groupby有所帮助

希望这能帮助遇到这个问题的其他人