数据流作业中的总读取时间差异很大

Question

我有一个数据流作业，它从我的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文件意味着它首先在worker机器上被解压缩。对gzip文件的解压缩是一个单核心(理想情况下是1n1-标准-1工作者)操作，因为作为压缩格式的gzip是不可拆分的。

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

我可以想到两个解决方案来尽可能地减少作业执行时间-

1. 更改为像bzip2这样的可拆分压缩格式，以便将所有文件大规模并行化，并尽可能快地完成读取操作。
2. 使gzip文件的大小尽可能小，以便大量工作人员消耗大量文件，总执行时间更短。例如，让10个工人读取每个100KB的10个gzip文件，让100个工人每个工人读取10KB的zip文件。GCP每分钟向你收费，因此费用很可能保持不变。