在 Google Cloud Dataflow 上调试 BigQuery 的慢速读取答案

【问题标题】：Debugging slow reads from BigQuery on Google Cloud Dataflow在 Google Cloud Dataflow 上调试 BigQuery 的慢速读取
【发布时间】：2018-01-29 03:34:27
【问题描述】：

背景： 我们有一个非常简单的管道，它从 BigQuery 中读取一些数据（通常约为 300MB）过滤/转换它并将其放回 BigQuery。在 99% 的情况下，此管道会在 7-10 分钟内完成，然后再次重新启动以处理新批次。

问题： 最近，这项工作开始时不时地超过 3 小时，在 2000 次运行中可能一个月 2 次。当我查看日志时，我看不到任何错误，实际上这只是第一步（从 BigQuery 读取）需要这么长时间。

有没有人对如何调试这种情况有任何建议？特别是因为它实际上是从 BQ 读取的，而不是我们的任何转换代码。我们正在使用适用于 Python 0.6.0 的 Apache Beam SDK（也许这就是原因！？）

是否可以为作业定义超时？

【问题讨论】：

请附上 Dataflow 作业 ID，以便 Dataflow 团队中的某个人可以查看它并帮助调试性能。
感谢@jkff，有问题的慢 job_id 是“2018-01-24_21_26_22-2131680617017922084”。这是同一管道的 ID，但预计执行时间约为 10 分钟：“2018-01-24_23_31_21-15706979146276820485”
这里是另一个缓慢的工作示例“2018-01-16_11_06_28-7923202670027546242”（我最终不得不取消）。

标签： google-cloud-dataflow apache-beam

【解决方案1】：

这在 Dataflow 端或 BigQuery 端都是一个问题，具体取决于人们如何看待它。在拆分数据以进行并行处理时，Dataflow 依赖于对数据大小的估计。当 BigQuery 偶尔严重低估查询结果的大小时，会发生较长的运行时间，因此 Dataflow 会严重过度拆分数据，并且运行时会因读取大量导出的小文件块的开销而成为瓶颈由 BigQuery 提供。

一方面，这是我第一次看到 BigQuery 产生如此严重错误的查询结果大小估计。但是，由于大小估计本质上是尽力而为的，并且通常可以任意关闭，Dataflow 应该对此进行控制并防止这种过度拆分。我们会调查并解决这个问题。

同时想到的唯一解决方法是使用 Java SDK：它使用完全不同的代码来读取 BigQuery，据我所知，它不依赖于查询大小估计。

【讨论】：