我有一个 Dataflow 作业，它从我的 GCS 存储桶中读取按时间和主机划分的日志文件。桶的结构如下：
/YYYY/MM/DD/HH/mm/HOST/*.gz
每个作业最终可能会消耗大约 10,000 个大小约为 10-100 KB 的日志文件。
我们的工作通常需要大约 5 分钟才能完成。我们有时会看到我们的工作量飙升至该时间量的 2-3 倍，并且发现大部分增长都出现在与读取数据文件相关的工作项目中。我们如何才能减少我们的作业执行时间的这种差异？从 GCS 读取是否存在吞吐量问题？
【问题讨论】：
您在工作中看到的差异很可能是由于 GCS 网络延迟造成的。虽然通常从 GCS 检索项目的延迟相当小，但它可能会根据网络条件和一天中的时间等各种因素而飙升。从 GCS 读取时，没有关于延迟的 SLA。 GCS 的吞吐量可能不是因素，因为您正在读取的数据文件的大小相当小。
如果网络条件导致您的延迟显着增加，这种影响将与您正在阅读的文件数量成比例地增长。
缓解工作时间差异的一种方法是在读取日志文件之前尝试合并日志文件，这样您可以读取的文件更少但大小更大。
【讨论】：
我对此有不同的见解。读取gzip 文件意味着它首先在工作机器上解压缩。 gzip 文件上的解压缩是单核（理想情况下是 1 个 n1-standard-1 worker）操作，因为 gzip 作为压缩格式是不可拆分的。
在上述情况下，可能有一些文件与其他文件相比要大得多，并且很可能会导致创建落后者（数据流作业中滞后的工作人员），这会增加作业执行时间。
我可以想到两种解决方案来尽可能缩短作业执行时间 -
bzip2 等可拆分压缩格式，以便所有文件都进行大规模并行化，并尽快完成读取操作。gzip 文件的大小尽可能小，以便大量工作人员消耗大量文件，并且总执行时间更短。例如，让 10 个工作人员读取 10 个 100KB 的 gzip 文件，让 100 个工作人员读取每个 10KB 的 zip 文件。 GCP 按分钟计费，因此费用很可能保持不变。【讨论】：