我们正在测试云数据流，它从Pub/Sub订阅中提取消息，并将数据转换到BigQuery TableRow，并在每1分钟30秒内将其作为加载作业加载到BigQuery。
我们可以看到，这条管道运行良好，可以用40名工人每秒处理50万个元素。但是，当尝试自动缩放时，即使我们只向Pub/Sub发送50000条消息，员工数量也会意外地增加到40人并保持不变。在这种情况下，没有未确认的消息，工人的CPU利用率低于60%。我们注意到的一件事是，数据流系统的滞后性上升缓慢。
- 系统滞后会影响自动缩放吗
- 如果是，是否有任何解决方案或方法来调试此问题
系统滞后会影响自动缩放吗？
谷歌并没有真正公开其自动缩放算法的细节。不过，一般来说，它是基于CPU利用率、吞吐量和积压。由于您使用的是Pub/Sub，积压工作本身应该基于未确认消息的数量。尽管如此，这些数据的消耗速率(即发布/子读取阶段的吞吐量(也被考虑在内。现在，吞吐量作为一个整体与每个阶段处理输入字节的速率有关。至于CPU利用率，如果前面提到的不能"顺利运行"，60%的利用率已经太高了。因此，某个阶段的系统滞后可以解释为该阶段的吞吐量，因此应该影响自动缩放。再说一遍，这两者不应该总是混为一谈。例如，如果一个工作人员因热键而被卡住，系统延迟很高，但没有自动缩放，因为工作不可并行。所以，总的来说，这取决于情况。
如果是，有什么解决方案或方法可以调试这个问题吗？
手头最重要的工具是执行图、stackdriver日志记录和stackdriver监控。从监控来看，您应该考虑jvm、计算和数据流指标。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 }'
堆栈驱动程序监控会暴露所有三个主要的自动缩放组件。
现在，你将如何利用上述优势显然取决于问题。在您的情况下，乍一看，我会说，如果您可以在没有自动缩放和40个工人的情况下工作，那么当您将maxNumWorkers设置为40时，您通常应该期望您可以使用自动缩放来执行相同的。再说一遍，仅凭消息的数量并不能说明全部情况，它们的大小/内容也很重要。我认为你应该从分析你的图表开始，检查哪一步的滞后性最高，看看输入/输出比是多少，并检查日志中严重性>=警告的消息。如果你在这里分享其中的任何一个，也许我们可以发现一些更具体的东西。