具有相同密钥 apache 光束的多个 CoGroupByKey答案

【问题标题】：Multiple CoGroupByKey with same key apache beam具有相同密钥 apache 光束的多个 CoGroupByKey
【发布时间】：2017-12-17 09:17:32
【问题描述】：

我有一种情况，我需要将管道中的主要数据流 (1.5TB) 加入 2 个不同的数据集（4.92GB 和 17.35GB）。我用来为两者执行 CoGroupByKey 的密钥是相同的。有没有办法避免在第一次完成后重新洗牌连接的左侧？目前我只是将输出保留为 KV>。这似乎比在第一次加入后分段发射每个元素要好，但第二个 groupByKey 似乎仍然比我预期的要花更长的时间。我打算开始研究拆分 CoGroupByKey，看看我是否可以忽略对一侧进行分组，但我真的觉得现在不降到那个级别更安全。

This was prior to keeping Iterables grouped after the first join

【问题讨论】：

CoGroupByKey 支持任意数量的输入集合。是否可以将所有 3 个输入集合都设置为相同的键，并按顺序执行单个 CoGroupByKey 而不是 2 个？

标签： google-cloud-dataflow dataflow apache-beam

【解决方案1】：

在处理主要输入时，您是否考虑过将较小的数据集作为 View.asMap() 或 View.asMultimap() 侧输入访问？ Dataflow 运行器对 map 和 multimap 侧输入进行了优化实现，可以高效地执行键查找，而无需将整个数据加载到内存中。

【讨论】：

不幸的是，我最小的 PCollections 大约是 5GB。据我了解，它对于侧面输入来说太大了
我以前从未注意到文档中的--workerCacheMB 选项。这是你指的吗？如果是这样，您介意尝试一下我应该将其设置为什么作为测试的开始吗？ cloud.google.com/dataflow/model/par-do#side-inputs
边输入可以任意大——没有限制；我们已经看到管道使用 1+TB 大小的侧输入成功运行。 workerCacheMB 选项仅影响性能（缓存命中率），以防同一个工作人员多次访问侧输入。建议你完全不要设置这个选项（假设默认值），试一试，万一性能不理想再写回。
好的，太好了！我现在将处理该转换。如果我能让这些作为侧输入有效地工作，我的管道通常会简单得多。感谢您的指导！
@successhawk 哈哈，它回到了标准范围内（不幸的是）。这是我的一些糟糕的代码，我基本上是重新创建右侧元素列表并附加到每个左侧元素而不是创建一次右侧。至于大侧输入，我只尝试了几次，但我没有看到使用该方法的改进。另一方面，洗牌服务令人难以置信。我会看看我是否可以分享其中一些数字。