Netflix 正在将其 30000 多个流式作业迁移至 开源的 Apache Flink Autoscaler ，覆盖多个 AWS 区域。此前，Netflix 发现其基于集群级别的自动扩缩容方案对于包含不同处理需求算子的复杂有状态管道效果欠佳。
Netflix 表示，某团队通过该方案将 Flink 计算支出年化降低了 58%，每年节省约 110 万美元。 Netflix 两种 Flink Autoscaler 的对比（来源： Netflix 博客 ） Netflix 自 2017 年开始运行 Apache Flink ，并于 2019 年左右构建了首个自动扩缩容系统。
该系统运行在 Mantis 上，读取来自 Atlas 的集群级遥测数据，包括 CPU、网络利用率、Kafka 延迟、输入速率和消费速率。它通过调整 TaskManager 总数量，在数千个管道上将资源使用量降低了 25% 至 45%。
其局限性在于扩缩容的粒度单元。由于原始自动扩缩容器是基于集群而非单个算子进行决策，作业中的所有算子实际上共享相同的扩缩容决策。
这对于包含分支、连接操作和数 TB 状态的有状态管道来说越来越不适用——在这些场景中，数据流的不同部分可能具有截然不同的处理需求。 Apache Flink Autoscaler 利用运行作业暴露的指标，结合吞吐量和繁忙时间估算每个算子的真实处理速率。
然后遍历作业图，为各个顶点分别计算所需的并行度。该方法在 FLIP-271 中有详细描述，旨在解决异构流式作业的自动扩缩容问题，以及有状态应用重新扩缩容的成本问题。
这项技术还借鉴了 DS2 项目的研究成果。参与这项工作的系统研究员 Vasiliki Kalavri 表示 ，该项目最初研究过关键路径分析，随后采用了 真实处理速率 作为更简单的基线方案。
事实证明，这个看似简单的想法效果却非常好。该方法随后成为 Flink 自动扩缩容工作的一部分。
Netflix 将该自动扩缩容器与其内部控制平面集成，而非直接通过 Flink Kubernetes Operator 部署。一个 Spring Boot 服务使用 Temporal 工作流来隔离各个作业的自动扩缩容决策。
Netflix 还修改了 JobManager 的指标收集机制，可支持多达 3000 个子任务的作业；增加了服务端指标过滤功能；在扩缩容时保留了前向连接子图；并增加了对 Sink 回压的处理逻辑。基于开源的 Flink Autoscaler 架构与 Temporal 工作流（来源： Netflix 博客 ） 前向连接问题也曾出现在 Apache Flink 开发者讨论 中。
跨 FORWARD 连接更改并行度可能需要重新分配数据，而 Netflix 的实现方式是将前向连接的算子保留在一起。另外，一个已开放的 FLINK-38538 问题指出，繁忙算子可能受到基于输出比率的扩缩容决策影响。
Flink 作业 DAG 展示各顶点的当前与目标并行度（来源： Netflix 博客 ） 与 KEDA 等通用的事件驱动自动扩缩容器（它们基于外部指标或事件来扩缩工作负载）不同，Flink 的自动扩缩容器是基于内部数据流图和算子容量进行推理的。 Netflix 目前使用的利用率目标为 0.45，低于 Flink 社区默认的 0.7，目标是减少大型有状态作业的激进式重新扩缩容。
Netflix 计划将其剩余的内部自动扩缩容实例迁移至开源实现，同时正在研究 Flink 2 的分离式状态架构，用以解决重新扩缩容期间状态恢复的成本问题。查看英文原文： /ai-market-guide/