[英]Dataflow pipeline pauses after scaling down with low CPU utilization
在我们的流媒体管道中，我们从 pubsub 读取数据，进行一些验证，然后按 10 秒间隔 session window 中的键对其进行分组。之后，数据被进一步处理并再次写入 bigtable 和 pubsub。
我们正在使用 apache beam 2.28 和数据流流引擎。 白天我们处理的数据比晚上多，管道会自动增加工作人员 (n2d-standard-4) 的数量。 大多数情况下，它会从 2 名工人扩大到 4 或 5 名，以减少积压。 之后它将再次缩减，因为 CPU 利用率对于 4 或 5 个工作人员来说太低了。
正是在这一点上，所有工作人员的 CPU 利用率下降到接近 0%，并且整个管道开始严重落后。 结果是工作人员的数量再次扩大到更高的数量，并且管道进一步处理数据。 再次减少积压后，工人数量逐渐减少，出现同样的问题。
我们注意到，在 GroupByKey 步骤中，输入吞吐量或多或少保持不变，但 output 吞吐量降至 0。
我知道使用 GroupByKey 可以有热键，但我希望 1 个工作人员的 CPU 使用率非常高，而其他人则无事可做。
有谁知道可能导致此问题的原因是什么？
该问题是由于将 session window 与 groupbykey 结合使用、pubsub 无界源的水印如何工作以及何时将确认发送到 pubsub 引起的。
我们的 session window 有时间隔 10 秒 output 几分钟内没有任何消息（由于没有配置早期触发器并且消息在 10 秒 session 间隔内连续到达相同的键）。 因为这些步骤是我们管道实际执行中第一个融合阶段的一部分，这导致一些消息没有被 pubsub 确认（只有当第一个融合阶段完成时才会发送 ack）。 订阅上最旧的未确认消息时间不断增加，导致水印无法推进。
由于确认截止日期设置为 10 分钟，此问题变得更加直言不讳。 当工人数量减少时，这导致了原始问题中描述的问题。
我们能够通过在创建 session window（使用 groupbykey）之前添加 Reshuffle 并缩短确认截止日期来解决这个问题。
https://cloud.google.com/blog/products/data-analytics/handling-duplicate-data-in-streaming-pipeline-using-pubsub-dataflow https://cloud.google.com/dataflow/docs/guides /部署管道#融合优化
HPA 缩放在 Spring 引导启动期间触发。 HPA 中的当前 CPU 指标很高，但节点级别的 CPU 利用率很低
[英]HPA scaling is triggered during Spring boot startup. Current CPU metric in HPA is high though CPU utilization at node level is low
声明:本站的技术帖子网页，遵循CC BY-SA 4.0协议，如果您需要转载，请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.
