我很好奇是否有人能让我更清楚地了解各种Beam Runner如何管理自动缩放。我们似乎在“旋转向上”和“旋转向下”阶段都遇到了打嗝，我们不知道该怎么办。以下是我们特定流程的背景：

1-二进制文件到达gs：//，并且对象通知适当地通知PubSub主题。2-每个文件需要在标准VM上解析大约1分钟，以向Beam DAG的下游区域发出大约30K条记录。3-'下游'组件包括诸如插入到BigQuery，存储在GS：中以及各种杂项其他任务之类的东西。4-步骤1中的文件断断续续地到达，通常每小时以200-300个批次的方式到达，这使得我们认为这是自动缩放的理想用例。

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

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

我们仍然对Beam感到兴奋，但我猜，不太理想的加速/减速阶段会导致VM使用量比所需的多50%。除了PubSub消费之外，跑步者还需要什么？他们看RAM/CPU/等吗？？？除了确认PubSub消息之外，开发人员还能做什么来向运行人员提供所需资源更多/更少的反馈吗？

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

提前谢谢，彼得

CTO，ATS，股份有限公司。