我们正在执行的数据流管道的第一步是使用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格式的预期数据量位于文件夹中，以供Dataflow读取。
但是，当实际执行此操作时，在第一步将数据读取到PCollection中的过程中，事情似乎可以正常工作约10-20分钟-我们可以看到墙体时间在增加，添加到Output集合上的元素数量这一步骤不断增加，而工作人员则不断扩大以提供帮助。
但是，在一定时间段（通常为10亿个元素或数据行）之后，挂墙时间和元素数量都开始稳定地减少。 vCPU小时数继续以预期的速度增长，这意味着我们仍在以某种方式运行/仍在为CPU时间付费，但是挂墙时间不断减少，PCollection输出/元素计数始终趋于零。这非常令人困惑-我们无法分辨出日志中是否有任何不妥之处（至少是出现正常吗？），但考虑到所需的工人数量/成本，我们非常希望看到证据表明事情正在向前发展。
我什至给这带来了疑问，即可能在浏览器级别上发生了一些疯狂的事情，但是我可以确认不同浏览器甚至是从事同一工作的不同人员之间的行为。
以前有没有人看过这个，是什么原因造成的？仅仅是Dataflow提供的步骤显示/图形中的错误，还是这里还有其他事情？
在此先感谢您的帮助！
编辑-能够通过大量实验解决问题。
挂墙时间似乎倒退的原因似乎与工人在试图处理一些热键的内存不足时崩溃有关。崩溃的工人然后停止报告，这似乎使完成工作的时间减少了。
总体而言，我们通过多种方式解决了问题：
希望这可以帮助遇到此问题的其他人。