Question

Since using the release of the latest build of Cloud Dataflow (0.4.150414) our jobs are running really slow when reading from cloud storage (GCS). After running for 20 minutes with 10 VMs we were only able to read in about 20 records when previously we could read in millions without issue.

It seems to be hanging, although no errors are being reported back to the console.

We received an email informing us that the latest build would be slower and that it could be countered by using more VMs but we got similar results with 50 VMs.

Here is the job id for reference: 2015-04-22_22_20_21-5463648738106751600

Instance: n1-standard-2
Region: us-central1-a

Answer 1

您的工作似乎是使用DoFn的旁边输入。由于最近Cloud Dataflow SDK for Java处理边输入的方式发生了变化，因此您的性能问题很可能与此相关。我正在回答相关问题的答案。

证据似乎表明管道如何处理侧输入存在问题。具体来说，对于主输入的每个元素，很可能一次又一次地从BigQuery重新读取侧输入。这与Dataflow工作人员使用的虚拟机类型的更改完全正交，如下所述。

这与Dataflow SDK for Java（版本0.3.150326）中所做的更改密切相关。在该版本中，我们更改了侧输入API以应用于每个窗口。对sideInput()的调用现在仅在与主输入元素的窗口对应的特定窗口中返回值，而不是整个侧输入PCollectionView。因此，无法再从sideInput()的{{1}}和startBundle调用finishBundle，因为该窗口尚未知晓。

例如，以下代码片段存在一个问题，该问题会导致每个输入元素重新读取侧输入。

DoFn

通过在第一次调用@Override public void processElement(ProcessContext c) throws Exception { Iterable<String> uniqueIds = c.sideInput(iterableView); for (String item : uniqueIds) { [...] } c.output([...]); }期间将侧输入缓存到变换的List成员变量（假设它适合内存），可以改进此代码，并使用缓存的{{1而不是后续调用中的侧输入。

此解决方法应该可以恢复之前看到的性能，此时可以从processElement调用侧输入。从长远来看，我们将努力为侧面输入提供更好的缓存。（如果这无法完全解决问题，请通过电子邮件与我们联系并分享相关的代码段。）

另外，确实有一个大约4/9/15的Cloud Dataflow Service更新，它更改了Dataflow工作人员使用的默认虚拟机类型。具体来说，我们减少了每个工作者的默认核心数，因为我们的基准测试显示它对于典型的工作来说是经济有效这是不在任何类型的数据流服务中的减速 - 默认情况下，它只是以每个工作者的较少资源运行。用户仍然可以选择覆盖工作人员数量以及工作人员使用的虚拟机类型。

Answer 2

我们遇到了类似的问题。当侧输入从已经将数据流入的BigQuery表中读取而不是批量加载时。当我们复制表格并从副本中读取时，一切正常。

如果您的表是流式传输的，请尝试复制它们并阅读副本。这是一种解决方法。

请参阅：Dataflow performance issues

Cloud Dataflow Running really slow when reading/writing from Cloud Storage (GCS)

2 个答案: