我们正在测试Cloud Dataflow，它每隔1分钟30秒就会从发布/订阅订阅中提取消息，并将数据转换为BigQuery TableRow并将其作为加载作业加载到BigQuery。
我们可以看到管道运行良好，可以每秒40名工人处理500,000个元素。但是，当尝试自动缩放时，即使我们仅向pub / sub发送50,000条消息，工人的数量也意外地增加到了40个并停留在那里。在这种情况下，不会出现任何未经确认的消息，并且工作者的CPU使用率将达到60％以下。我们注意到的一件事是，数据流系统的滞后缓慢增加。
答案 0 :(得分：0)
系统延迟会影响自动缩放吗？
Google并未真正公开其自动缩放算法的细节。不过，通常，它基于 CPU利用率，吞吐量和待办事项。由于您使用的是发布/订阅，因此，待办事项本身应基于未确认的消息数。不过，这些内容的消耗速度（即 Pub / Sub读取阶段的吞吐量）也已考虑在内。现在，整个吞吐量与每个阶段处理输入字节的速率有关。至于CPU利用率，如果上述方法不能“平稳运行”，则60％的利用率已经太高了。因此，某个阶段的系统延迟可以解释为该阶段的吞吐量，因此应该影响自动缩放。再者，这两个不应该总是混为一谈。例如，如果某个工人由于hot key而被卡住，则系统延迟很高，但是由于工作不可并行，因此无法进行自动缩放。因此，总而言之，这取决于。
如果是，是否有解决此问题的解决方案或方法？
您手边最重要的工具是执行图，堆栈驱动程序日志记录和堆栈驱动程序监视。通过监视，您应该考虑jvm，compute和dataflow指标。 gcloud dataflow jobs describe也很有用，主要用于查看如何融合步骤，并通过扩展来查看哪些步骤在同一工作程序中运行，如下所示：
gcloud dataflow jobs describe --full $JOB_ID --format json | jq '.pipelineDescription.executionPipelineStage[] | {"stage_id": .id, "stage_name": .name, "fused_steps": .componentTransform }'
Stackdriver监视公开了所有三个主要的自动缩放组件。
现在，您如何利用上述优势显然取决于问题。就您的情况而言，乍一看，我想说的是，如果将maxNumWorkers设置为40，那么您可以在没有自动缩放的情况下工作并且有40个工作程序，通常应该期望可以使用自动缩放执行 相同的操作再说一次，仅消息的数量并不能说明全部，它们的大小/内容也很重要。我认为您应该首先分析图表，检查哪一步具有最高的滞后性，查看输入/输出比率是多少，并检查日志中严重性> = WARNING的消息。如果您在这里分享了其中任何一个，也许我们可以发现更具体的内容。