Beam runner 如何确定每束 PCollection 的大小

Question

根据Apache Beam 执行模型 - 捆绑和持久性：

“PCollection 中的元素不是同时处理所有元素，而是成束处理。将集合分成束是任意的，并且由运行器选择。这允许运行器在每个元素之后的持久结果之间选择适当的中间地带，并且如果出现故障则必须重试所有内容。例如，流运行器可能更喜欢处理和提交小包，而批处理运行器可能更喜欢处理更大的包。”

该段落表明包的大小是任意的，由跑步者决定。 我查看了 Apache Beam 的源代码，并查看了 Runner 模块，以了解运行程序如何确定包大小。 但是，我无法弄清楚。

有人可以指出在哪个 java 类或配置文件中计算包的大小吗？ 我对 DirectRunner 和 Cloud Dataflow Runner 的工作原理很感兴趣。

Answer 1

这通常不是要设置的旋钮，实际上它在数据流运行器线束/beam sdk 本身的开源代码中不是可用的旋钮。 运行者在打包捆绑包时做出选择，基于运行者运行高性能管道的偏好/目标。

在 Dataflow 中，一些闭源后端系统根据各种因素来确定这一点，包括分片、特定密钥可用的数据量以及管道的进度/吞吐量。 捆绑包大小本身并不基于任何类型的静态数字，而是根据管道/工人内部当前发生的情况动态选择的。

Answer 2

通过查看BigQueryIo，您可以看到他们添加了一个步骤，为每条记录生成分片编号：

  .apply("ShardTableWrites", ParDo.of(new GenerateShardedTable<>(numShards)))

之后，他们应用了Reshuffle和GlobalWindow ，就像按分片 id 分组一样，现在每个包将是使用相同分片 id 生成的行数。

放置更大的分片数以实现更大的捆绑。

我用它来读取和写入 BigTable，它工作得很好。

完整代码：

  PCollectionTuple tuple =
    tagged
        .apply(Reshuffle.of())
        // Put in the global window to ensure that DynamicDestinations side inputs are accessed
        // correctly.
        .apply(
            "GlobalWindow",
            Window.<KV<ShardedKey<String>, TableRowInfo<ElementT>>>into(new GlobalWindows())
                .triggering(DefaultTrigger.of())
                .discardingFiredPanes())
        .apply(
            "StreamingWrite",
            ParDo.of(
                    new StreamingWriteFn<>(
                        bigQueryServices,
                        retryPolicy,
                        failedInsertsTag,
                        errorContainer,
                        skipInvalidRows,
                        ignoreUnknownValues,
                        ignoreInsertIds,
                        toTableRow))
                .withOutputTags(mainOutputTag, TupleTagList.of(failedInsertsTag)));