在處理海量即時數據流時，如何動態調整計算資源以平衡性能與成本，是大型分散式系統面臨的核心挑戰。Netflix 作為 Apache Flink 的長期使用者，自 2017 年起便將其應用於數據處理。為了應對波動的流量，Netflix 在 2019 年開發了第一代自動擴展系統（Autoscaler），該系統基於 Mantis 平台，透過監控 Atlas 提供的集群級遙測數據，例如 CPU 利用率、網路吞吐量、Kafka 延遲（Kafka lag）以及輸入與消費速率，來決定是否增加或減少 TaskManager（Flink 的工作節點）的數量。
在初期階段，這種集群級的縮放方案成效顯著，成功為數千條流水線降低了 25% 到 45% 的資源消耗。然而，隨著業務複雜度增加，Netflix 發現這種粗粒度的調度方式遇到了瓶頸。
集群級縮放的局限性與挑戰
傳統的集群級縮放將整個 Flink 作業視為一個單一單位。這意味著作業中所有的算子（Operators，即處理數據的最小邏輯單元）必須共享同一個縮放決策。對於簡單的線性流水線，這種方式尚可運作；但對於複雜的有狀態流水線（Stateful Pipelines），情況則大不相同。
在包含分支（Branches）、連接（Joins）以及承載數 TB 級狀態（State）的大型作業中，數據流的不同部分對處理能力的需求截然不同。某些算子可能是計算密集型，而另一些則是 I/O 密集型。如果僅根據集群整體指標來縮放，會導致部分算子資源過剩而部分算子成為瓶頸，無法精確解決特定節點的壓力，且在重新縮放有狀態應用時，狀態恢復的開銷極其昂貴。
引入 Apache Flink Autoscaler 的核心機制
為了克服上述問題，Netflix 決定轉向採用開源的 Apache Flink Autoscaler。與以往關注外部集群指標不同，這套新機制的核心在於「算子級」的精準分析。它直接利用 Flink 作業運行時暴露的內部指標，透過吞吐量（Throughput）與繁忙時間（Busy Time）來估算每個算子的真實處理速率（True Processing Rate）。
該技術基於 FLIP-271 提案以及 DS2 研究項目的成果。其運作邏輯是遍歷作業的有向無環圖（Job Graph），計算每個頂點（Vertex，代表一個算子）所需的平行度（Parallelism）。這種方法將縮放決策從「集群層級」下沉到「算子層級」，使得異質性的流處理作業能夠根據每個步驟的實際負荷獨立調整資源，而非採取一刀切的策略。
Netflix 的實作優化與整合
Netflix 並非直接使用 Flink Kubernetes Operator 部署，而是將開源 Autoscaler 整合進其內部控制平面。他們使用 Spring Boot 服務搭配 Temporal（一個開源的持久化工作流編排引擎），為每個 Flink 作業隔離縮放決策流程，確保調度過程的可靠性與可追溯性。
在整合過程中，Netflix 針對大規模生產環境進行了多項關鍵優化：首先，修改了 JobManager 的指標收集機制，以支持單個作業包含高達 3,000 個子任務（Subtasks）的規模，並增加了伺服器端的指標過濾功能以降低負擔。其次，針對前向連接（Forward Connection）的算子進行了特殊處理，確保在縮放時保持這些算子的同步，避免不必要的數據重新分發（Redistribution）導致性能下降。此外，他們還加入了對 Sink 算子背壓（Backpressure）的處理邏輯，防止下游阻塞導致的錯誤縮放。
實務影響與未來展望
轉向算子級縮放後，Netflix 取得了顯著的成本效益。據報告，其中一個團隊將 Flink 的年度計算支出降低了 58%，單一案例每年節省約 110 萬美元。
在實際運行參數上，Netflix 將利用率目標設定為 0.45，低於社群預設的 0.7。這是為了在性能與穩定性之間取得平衡，避免大型有狀態作業因過於激進的縮放而頻繁觸發昂貴的狀態恢復過程。
儘管成效顯著，但挑戰依然存在。目前的縮放仍受限於狀態恢復的成本，這使得頻繁調整平行度具有風險。因此，Netflix 目前正研究 Flink 2 的解耦狀態架構（Disaggregated State Architecture），旨在將計算與狀態存儲分離，從根本上降低重新縮放時的狀態遷移成本，讓自動擴展能更加靈活且高效。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。