如何有效地处理数据流中的 largs gzipped 文件？答案

【问题标题】：How do I effectively process a largs gzipped file in dataflow?如何有效地处理数据流中的 largs gzipped 文件？
【发布时间】：2017-09-11 07:31:39
【问题描述】：

我们有一些批处理作业可以处理大约 10GB 压缩和大约 30GB 解压缩的 gzip 文件。

尝试在 Java 中处理此问题会花费不合理的时间，我们正在寻找更有效的方法。如果我们使用TextIO或者gcs的原生java sdk来下载文件需要8个多小时来处理，原因是ut由于某种原因可以横向扩展。很可能它不会拆分文件，因为它是 gzip 压缩的。

如果我解压缩文件并处理解压缩文件，这项工作大约需要 10 分钟，因此速度大约是 100 倍。

我完全可以理解，处理一个 gzip 文件可能需要一些额外的时间，但是 100 倍的时间太多了。

【问题讨论】：

【解决方案1】：

gzip 文件不可拆分是正确的，因此 Dataflow 无法并行读取每个 gzip 输入文件。如果可能的话，将未压缩的存储在 GCS 中是最好的方法。

关于 100 倍的性能差异：在您的管道的未压缩版本和压缩版本中，您的管道扩展到了多少个工作虚拟机？如果您有工作 ID，我们可以在内部查找以进一步调查。

【讨论】：

我认为我有多少工人并不重要，因为负载不可拆分。我试图从 30 名工人开始这项工作，但由于它无法拆分，它会自动缩小规模。
是否可以让TextIO 在处理之前解压缩并写入临时文件夹，以便并行加载。这实际上是我们目前正在尝试做的事情。
让 TextIO 首先解压缩并写入 GCS 会同样慢并且不会提高性能。除非多个管道正在读取相同的文件，因此解压缩的成本可以在它们之间分摊。
如果每个输入文件读取后拆分成多条记录，可以在拆分后添加一个GroupByKey，以便重新洗牌，让下游处理并行执行。
也许可以，但可能对TextIO 进行很多改进，以加快使用 gzip 文件的场景。我一直在做的一些小测试产生以下结果： * 处理压缩文件，8 小时。 * 处理解压文件，10 分钟。 * 下载文件，10 分钟。 * 解压文件，5 分钟。 * 上传解压文件：~30 mintes。因此，下载、解压缩、上传和处理的所有步骤大约需要 40-45 分钟。这比今天需要的 8 小时要短得多。