Dataflow作业中的总读取时间具有较高的差异

Question

我有一个Dataflow作业，它从我的GCS存储桶中读取按时间和主机分割的日志文件。桶的结构如下：

/ YYYY / MM / DD / HH / MM / HOST / *。GZ

每个作业最终可能会消耗大约10-100 KB大小的10,000多个日志文件。

通常我们的工作大约需要5分钟才能完成。我们有时看到我们的工作量达到2-3倍的时间，并且发现大部分增长都出现在与读取数据文件相关的工作项中。我们如何减少工作执行时间的这种差异？从GCS读取是否存在吞吐量问题？

Answer 1

您在工作中看到的差异很可能是由于GCS网络延迟造成的。虽然通常从GCS检索项目的延迟相当小，但它可能会出现峰值，具体取决于网络条件和时间等各种因素。在从GCS读取时，延迟没有SLA。 GCS的吞吐量可能不是因为您正在阅读的数据文件的大小相当小。

如果网络条件导致您的延迟显着增加，则此效果将按您正在阅读的文件数量成比例增长。

缓解作业时间差异的一种方法是在读取日志文件之前尝试组合这些日志文件，以便减少要读取的文件大小。

Answer 2

我对此有不同的看法。读取gzip文件意味着它首先在工作计算机上解压缩。 gzip文件上的解压缩是单核（理想情况下是1 n1-standard-1 worker）操作，因为作为压缩格式的gzip不可拆分。

在上面的场景中，可能会有一些文件比其他文件大得多，并且很可能会导致创建落后者（数据流作业中的工作人员落后），这将增加作业执行时间。

我可以考虑两种解决方案，以尽可能减少作业执行时间 -

1. 更改为可分割的压缩格式，如bzip2，以便所有文件大规模并行化，并尽快完成读取操作。
2. 使gzip文件的大小尽可能减小，以便大量工作人员消耗大量文件，总执行时间更短。例如，有10名工作人员阅读每个100KB的10个gzip文件，有100名工作人员读取每个10KB的zip文件。 GCP每分钟向您收费，因此成本应该保持不变。