用于基于吞吐量的自动缩放的 Beam Runner 挂钩

Question

我很好奇是否有人可以让我更深入地了解各种 Beam Runners 如何管理自动缩放。我们似乎在“加速”和“减速”阶段都遇到了问题，我们不知道该怎么办。以下是我们特定流程的背景：

1- 二进制文件到达 gs://，并且对象通知会及时通知 PubSub 主题。 2- 每个文件需要在标准 VM 上进行大约 1 分钟的解析，以将大约 30K 记录发送到 Beam DAG 的下游区域。 3-“下游”组件包括向 BigQuery 的插入、GS: 中的存储以及各种其他任务。 4- 步骤 1 中的文件间歇性地到达，通常每小时 200-300 个批次，这使我们认为这是自动缩放的理想用例。

然而，我们所看到的让我们有些困惑：

1- 看起来当 'workers=1' 时，Beam 咬得比它可以咀嚼的多一点，最终导致一些内存不足错误，大概是因为第一个工作人员试图处理一些 PubSub 消息同样，这需要大约 60 秒/消息才能完成，因为在这种情况下，“消息”是二进制文件需要在 gs 中反序列化。 2- 在某些时候，跑步者（在本例中为 jobId 2017-11-12_20_59_12-8830128066306583836 的数据流）收到消息，需要额外的工作人员，现在可以完成实际工作。在此阶段，错误减少，吞吐量增加。不仅step1有更多的反序列化器，step3/下游任务也均匀分布。 3-唉，当 Dataflow 感觉到（我猜）足够多的 PubSub 消息“在飞行中”开始冷却一点时，上一步被缩短了。这似乎来得太快了，工作人员在自己咀嚼 PubSub 消息时就被拉扯了——甚至在消息被“确认”之前。

我们仍然对 Beam 感到非常兴奋，但我猜测不是最佳的启动/停止阶段会导致虚拟机使用量比所需的多 50%。跑者除了 PubSub 消费外，还寻找什么？他们看 RAM/CPU/等吗？？？除了 ACK PubSub 消息以向跑步者提供需要更多/更少资源的反馈之外，开发人员还能做些什么？

顺便说一句，如果有人怀疑 Google 对开源的承诺，我昨天与那里的一位员工谈到了这个话题，她表示有兴趣了解我的用例，特别是如果它在非 Dataflow 运行器上运行！我们还没有在 Spark（或其他地方）上尝试过我们的 Beam 工作，但显然有兴趣了解一位跑步者是否具有更好的能力来接受工人对 THROUGHP_BASED 工作的反馈。

提前致谢， 彼得

首席技术官， ATS, Inc.

Answer 1

Dataflow 中的流式自动缩放通常是这样工作的：

• Upscale：如果基于当前吞吐量，管道的积压超过几秒钟，则管道被升级。这里的 CPU 利用率并不直接影响 upsize 的数量。使用 CPU（假设它是 90%）无助于回答“需要多少工人”的问题。 CPU 确实会间接影响，因为当它们没有足够的 CPU 时管道会落后，从而增加积压。
• Downcale：当 backlog 很低（即

我希望以上基本描述有所帮助。

由于启动新 GCE 虚拟机的固有延迟，管道在调整大小事件期间会暂停一两分钟。预计在不久的将来会有所改善。

我会就你在描述中提到的工作提出具体问题。