我有一个dataflow流作业，它处理从pubsub主题消耗的数据，并将数据转换/写入bigtable示例。自动缩放设置包括：
autoscalingAlgorithm=THROUGHPUT_BASED
maxNumWorkers=15上一个作业已运行约1个月（作业id:2020-11-22\u 23\u 08\u 42-17274260380601237）。在~11-12 dec（2020）之前，它运行正常，即自动缩放按预期工作，吞吐量越高（cpu利用率越高），使用的工人越多，而当吞吐量降低（相应的cpu利用率）时，自动缩放回1个工人。然而，自12月11日至12日以来，数据流工作者的数量一直持续增加到最大值（15人），这并没有缩减，导致我们的数据流使用成本很高。
如文件中所述（参考：https://cloud.google.com/dataflow/docs/guides/deploying-a-pipeline#autoscaling)：如果流式处理管道积压时间少于10秒，并且工作人员在几分钟内平均使用少于75%的CPU，则数据流将缩小。缩小规模后，工人平均使用75%的CPU。然而，自12月11日至12日以来，这种情况一直没有发生。稳定后，工人的cpu利用率约为6%，这远低于缩小的水平，只是没有。
从特定pubsub主题的吞吐量流量来看，在过去1个月内，发布的消息保持了相当一致，没有出现特定的流量峰值。在向bigtable写入数据时，我也观察不到任何特定的错误。
尝试两次重新部署数据流作业，效果相同。不确定是否有其他人面临类似的问题，感谢任何建议，我可以在哪里寻找或解决。提前谢谢！
1条答案
按热度按时间zbwhf8kr1#
我搜索了googledataflow文档，找到了一条线索。
根据文档，数据流倾向于在工作磁盘数和持久磁盘数之间保持平衡。
这可能是问题的原因。
如果不使用流引擎，dataflow服务会为每个worker分配1到15个持久磁盘。
当您的数据流需要特定数量的工作节点（9~14）时，往往需要维护15个工作节点，因为持久磁盘将平均分布在15个工作节点上（每个节点1个pd）。
在12月11-12日之前，您的数据流将需要8个或更少的工作人员，因此缩小规模的过程会成功，因为pd将在这个数量上分布良好。
这个过程在dataflow文档中描述。
例如，如果管道需要3或4个处于稳定状态的worker，那么可以设置--maxnumworkers=15。管道自动在1到15个worker之间伸缩，使用1、2、3、4、5、8或15个worker，分别对应于每个worker 15、8、5、4、3、2或1个持久磁盘。
因此，在需要8个或更少的worker节点之前，您的数据流一直将worker节点的数量保持在15个。
要解决此问题，请将maxnumworkers提升到15以上。
这将使成本略有增加，但将成功地进行缩小规模。