我们有一个启用自动缩放功能的流传输管道。通常，一个工作人员足以处理传入的数据，但是如果存在积压，我们希望自动增加工作人员的数量。
我们的管道从Pubsub读取数据，并每3分钟使用加载作业将批次写入BigQuery。我们从一名工作人员开始运行此管道，向pubsub发布的数据是一名工作人员可能消耗的两倍。 2小时后，自动缩放仍未开始，因此积压的数据将约为1小时。鉴于自动缩放的目的是将积压保持在10秒以内（根据this SO answer），这似乎很差。
文档here表示，流作业的自动缩放处于beta状态，并且如果接收器是高延迟的，则可以自动进行缩放。是的，我想每3分钟执行BigQuery批处理就算是高延迟！改进此自动缩放算法是否有任何进展？
在此期间，我们是否可以采取任何变通方法，例如测量管道中不同点的吞吐量？我找不到任何有关如何将吞吐量报告给自动缩放系统的文档。
答案 0 :(得分：0)
后备日志是由未确认的消息创建的，我想您正在使用请求订阅。如果处理一条消息所需的时间比确认一条消息的时间长，则它将按照发布/订阅中的at-least-once delivery重新发送。唯一能够处理此消息的工作人员是第一个收到此消息的工作人员。在这种情况下，将不会创建任何实例。
您需要做的是在确认期限到期之前调整系统以处理消息。在某些情况下，使用推送消息可能会受益。我建议阅读有关Pub / Sub创建的backlog的文档。