Netflix要重写三万条流任务的扩缩容

如果一间厨房里，切菜台已经排起长队，洗碗区却还空着，最省事的办法是给整间厨房统一加人。但人会加错地方。Netflix过去给流处理作业扩容，也遇到了类似问题：系统按整个集群判断资源多少，难以照顾管道中每个步骤不同的忙闲程度。现在，它正推动30,000多个、分布在多个AWS区域的Apache Flink作业转向开源自动扩缩容器。

这不是“重写三万条流任务”，而是更换和整合它们背后的资源治理方式。规模、架构和节省数据均来自Netflix方面，由InfoQ转述，目前缺少独立验证；“正在推动”也不代表迁移已经全部完成。

旧办法为什么不够用了

Apache Flink是一套持续处理数据流的系统。Netflix自2017年开始使用它，并在约2019年构建了首个自动扩缩容器——根据工作量自动增减计算资源，在积压风险和机器成本之间找平衡。

旧系统建立在Mantis和Atlas之上，观察CPU、网络利用率、Kafka lag（消息等待处理的积压量）、输入速率和消费速率等指标，再统一调整TaskManager数量。TaskManager可以理解为实际执行计算任务的工作进程。据Netflix自报，这套方案曾让数千条流水线的资源使用量下降25%至45%。

问题出在“统一调整”。一条流处理管道包含多个算子（operator）——过滤、聚合和join（把不同数据流按条件拼接）都可以是一个算子。旧方案以整个集群为扩缩容单位，等于厨房所有工位一起加人或减人。遇到分支、join和TB级状态的复杂任务时，各算子的工作量差异很大，统一决策便容易失准。

这里的“状态”，是任务为了继续计算而保留的历史，例如窗口计数、会话记录或join所需的数据。改变资源规模时，这些状态还要搬迁和恢复。状态越大，调整一次的代价通常越高。

新方案把瓶颈拆开看

Apache Flink Autoscaler换了观察尺度。它结合吞吐量和busy time（算子真正忙于处理数据的时间比例），估算每个算子的True Processing Rate，即在持续工作时的实际处理能力。随后，它沿job graph——描述各处理步骤及其连接关系的图——为每个vertex（图中的计算节点）分别计算所需并行度。并行度就是同一步骤同时由多少份计算资源执行。

这套思路见于FLIP-271，并建立在DS2项目研究之上。参与研究的系统研究员Vasiliki Kalavri称，团队最初探索的是更复杂的关键路径分析，后来改用True Processing Rate这个较简单的基线，并发现效果很好。这是研究参与者的评价，不是独立测试结论。

Netflix没有直接通过Flink Kubernetes Operator部署它，而是接入自己的内部控制平面。一个Spring Boot服务使用Temporal workflow，为每个作业单独运行扩缩容流程。官方博客还披露，最初遍历全部作业的批处理循环会被单个慢作业拖住；改为独立工作流后，异常作业只在自己的流程中失败和重试。

为适应生产规模，Netflix还修改了JobManager的指标采集，使其支持最多3,000个subtask（算子拆出的并行执行单元），并加入服务端指标过滤、sink backpressure处理，以及扩缩容时保持forward-connected subgraph不被拆散。sink backpressure指管道末端写出速度不足，压力逐级向上游传回。

最后一项尤其像生产系统里的“暗礁”。据Netflix官方博客，FORWARD方式直连的两个算子若被分别调成不同并行度，Flink可能不报错，却把原本本地传递的数据改成网络shuffle，也就是跨节点重新分发。Netflix因此把这类相连算子作为整体调整。相关风险也出现在Flink开发讨论中；另一个尚未解决的FLINK-38538问题，则涉及繁忙算子可能受到基于输出比例的决策影响。

真正值得看的，是治理边界

Netflix目前采用0.45的资源利用率目标，低于Flink社区默认的0.7，希望减少大型有状态作业过于激进的扩缩容。公司还会在区域故障转移或疏散期间阻止当地缩容，并在执行前检查新集群能否容纳作业的checkpoint状态。checkpoint是系统自动保存的恢复状态；与人工触发、可长期保留的savepoint不同，它主要用于故障恢复。

这说明自动扩缩容不只是“算出该开几台机器”。算法还要知道哪些步骤必须一起变化，状态是否搬得动，以及某个作业失败时会不会拖累其他作业。Netflix从自研方案向社区实现收敛，值得关注的正是这层平台工程：通用算法负责判断，内部控制面负责隔离和安全约束。

据Netflix自报，采用新方案的某个团队将Flink年化计算开支降低58%，折算每年约节省110万美元。这个数字很亮眼，但只来自一个团队，不能外推到全部30,000多个作业，也不等于已经完成整年验证。

局限与未知

• 现有材料没有披露整体迁移进度、失败率、状态恢复时长或跨区域稳定性，无法判断全面落地还需多久。
• 25%至45%的旧方案降耗，以及新方案58%的年化降本，均为Netflix自报，缺少独立对照和完整计算口径。
• Netflix计划把剩余内部扩缩容场景迁到开源实现，并研究Flink 2的分离式状态架构，以降低扩缩容时的状态恢复成本；这些仍是后续方向，不是已经实现的结果。