google-cloud-storage - 为什么运行管道时会向 GCS 写入零字节文件？

Question

我们的工作/管道正在将 ParDo 转换的结果写回 GCS，即使用 TextIO.Write.to("gs://...")

我们注意到，当作业/管道完成时，它会在输出存储桶中留下大量 0 字节文件。

管道的输入来自 GCS 的多个文件，因此我假设结果是分片的，这很好。

但是为什么我们会得到空文件？

Answer 1

这些空分片很可能是中间管道步骤的结果，结果有些稀疏，并且一些预分区分片中没有记录。

例如如果在 TextIO.Write 之前有一个 GroupByKey，并且键空间被分片为范围 [00, 01), [01, 02), ..., [fe, ff)(总共 255 个分片)，但所有从这个 GroupByKey 的输入发出的实际键在 [34, 81) 和 [a3, b5) 范围内，那么将产生 255 个输出文件，但其中大多数将是空的。 (这是一个假设的分区方案，只是为了给您提供想法)

我的其余回答将以问答的形式进行。

为什么会产生空文件？如果没有任何内容可输出，则不要创建文件!确实，从技术上来说，避免生产它们是可能的，例如通过在写入第一个元素时写入输出时延迟打开它们。 AFAIK 我们通常不会这样做，因为空的输出文件通常不是问题，而且理解空文件比缺少文件更容易:如果只输出 50 个分片中的第一个，那将非常令人困惑非空，并且您只会有一个名为 00001-of-000050 的输出文件:您会想知道其他 49 个文件发生了什么。

但是为什么不添加一个后处理步骤来删除空文件？原则上，我们可以添加一个删除空输出并重命名其余部分的后处理步骤(以与xxxxx-of-yyyyy 文件模式)如果空输出成为一个大问题。

空分片的存在是否表明我的管道存在问题？大量空分片可能意味着系统选择的分片不是最优的/不均匀的，我们应该将计算分成更少、更均匀的分片。如果这对您来说是个问题，您能否提供有关管道输出的更多详细信息，例如:您的屏幕截图显示非空输出也非常小:它们是否只包含少量记录？ (如果是的话，在事先不知道数据的情况下，可能很难实现统一分片)

但是我原始输入的分片不为空，输出的分片不镜像输入的分片吗？如果您的管 Prop 有 GroupByKey(或派生)操作，则会出现中间步骤，其中输入和输出中的分片数量不同:例如一个操作可能会消耗 30 个输入分片，但会产生 50 个输出分片，反之亦然。在其他一些不涉及 GroupByKey 的情况下，输入和输出中的分片数量也可能不同。

TL;DR 如果您的整体输出正确，那么这不是一个错误，但请告诉我们这对您来说是否有问题:)