日常節省 30%計算資源：阿里雲實時計算 Flink 自動調優實踐

來源：Apache Flink

摘要：本文整理自阿里雲開發工程師，Apache Flink Contributor 鍾旭陽，在 Flink Forward Asia 2022 生產實踐的分享。本篇內容主要分為四個部分：

    1. 歷史背景

    2. 框架簡介

    3. 案例介紹

    4. 未來規劃

01

歷史背景

批作業在運算元實際處理資料時，可以提前感知到要處理的這部分資料有多大。從而可以根據資料量的大小，選擇合適的資源處理資料。但流作業是一種 long-running 的作業，它的特點是流量會隨著時間進行變化。

我們沒有辦法在流作業剛啟動時，就預估到未來的流量有多少，需要多少資源。沒有一份初始的通用資源配置可以適用於一個流作業的所有場景。

並且，在通常情況下，使用者需要維護許多的 Flink 作業，其中會有很多邏輯複雜、節點很多的作業。如果靠每個使用者手工配置這些作業的資源配置，這一過程是比較繁瑣的。對於每個使用者來說，也是不太現實的。

同時，因為 Flink SQL 的廣泛推廣，使用者只需要關心自己的業務邏輯，就能夠使用 Flink 的能力。但也正是因為 Flink SQL 易用性，讓使用者缺乏對 Flink 內部實現細節的瞭解，調優成本會比較高。

綜合以上的種種問題，給作業資源配置和調優帶來一定的困難。

如果一份作業設定了不太合理的資源配置，在資源配置設定較高時，會增加業務的成本。從作業上看，資源的利用率會更低。在資源配置設定比較低的時候，會使整個作業的處理能力不足，導致作業出現吞吐比較低，延遲攀升的情況。在資源嚴重不足時，還會導致出現 Failover 的情況大大增加，從而影響整個作業的平穩執行。

我們期望作業自動調優的目標比較簡單，即配置一份在保障作業無延遲的前提下，儘可能的提高作業整體的吞吐量，提高作業的資源利用率，讓資源不再成為作業的瓶頸。

02

框架簡介

 

在 2016 年，我們支援使用資源配置、檔案配置的方式，為作業設定一些資源。當時作業以 DataStream 作業和 TableApi 作業為主。

我們透過提前預編譯的方式，將每個節點的初始資源配置進行輸出。讓使用者根據這份初始的資源配置，進行修改。然後，在提交作業執行時，透過引數，帶上這份最新的配置，就可以讓這份新配置生效。但是，由於作業資源存放在檔案當中，我們很難將需要修改的節點，和實際使用執行的節點，建立起對應的關係。

對於大作業來說，它們的資原始檔過於複雜。比如我需要調節 50 個節點中某個 AGG 的運算元，但是該作業中 AGG 運算元一共有四、五個。很難確認哪一個 AGG 運算元，才是我們需要調整的那個運算元。

因此，在 2017 年我們對其進行了改進，支援了視覺化的配置。使用者可以透過視覺化的拓撲圖，來修改指定的節點資源。它的好處是，對映關係會更加的清晰，使用者修改起來會更加的簡單方便。

隨著 SQL 作業的廣泛應用，在這個版本里我們也增加了對 SQL 作業的調優支援，來彌補社群不支援細粒度設定 SQL 作業每個運算元資源配置的不足。但這個版本仍然存在一些問題，比如大作業的拓撲圖仍然很複雜，使用者定位任務瓶頸時，需要多次執行作業，不斷地重試調節可能有問題的節點。

在 2018 年，我們支援了半自動配置 AutoConf。它的特點是，能夠結合作業的歷史執行情況，透過一系列的演算法，計算出此次啟動時，需要多少推薦資源。但是它的缺點也很明顯，針對無歷史執行記錄的作業，第一份配置通常是比較保守的，需要使用者經過多輪迭代啟停才能最終確定一份比較合理的資源配置。

在 2019 年，我們支援了全自動的配置 AutoScale。它能夠在作業執行時動態自適應的修改資源配置。這個版本基本不需要使用者干預，它能夠很好的支援改並存、改記憶體等修改資源配置的能力。但這個版本依然存在一些問題，由於 AutoScale 是執行在JM內部的，因此天然不支援一些類似動態啟停、檢視執行歷史記錄等等的運維需求，在 JM 異常時，調優也無法繼續工作，同時也不支援修改拓撲等策略，版本升級比較依賴 Flink 自身的版本。

在 2020 年，推出了獨立部署的調優服務 Autopilot。相比於它的前身，Autopilot 的調優服務會更加易用。使用者可以在介面手動看到的調優歷史，明確的知道 Autopilot 根據作業的哪些情況，做過哪些調整。整個流程對使用者更加透明化。即使沒有開啟 Autopilot，也可以為每個使用者的作業，提供一些輔助的呼叫資訊，給使用者手工調優帶來一定的幫助。

在 Autopilot 中，我們支援了更加豐富的調優策略，例如 JM 的資源最佳化，動態拆遷 chain 最佳化作業等。

Autopilot 調優主要調節的資源配置分為以下兩種，分別是基礎模式和專家模式。

在基礎模式中，使用者可以統一配置 TM 的 CPU 和記憶體，以及作業併發度。對於所有運算元而言，這些資源都是同構的，TM 數量取決於每個 TM 中，可以有多少的 Slot。基礎模式的特點是，配置簡單，適合每個節點資源差異比較小的作業。

在專家模式中，使用者可以單獨配置每個運算元所需要的 CPU、記憶體、併發等等，高度定製化，各個運算元的資源是異構的。使用專家模式可以更好的提高資源的利用率，滿足作業高吞吐的需求，節省資源。適合每一個節點資源差異比較大的作業。

Autopilot 自動調優框架，主要有以下幾個特點。

首先，它支援多個型別的 Flink 作業，Flink SQL 作業、DataStream 作業和 Python 作業，都可以使用 Autopilot 的調優能力。

其次，它支援多種執行模式。

在半自動模式下，我們支援定時調優，讓使用者指定不同的時間段，選擇不同的資源配置執行。適合一些突出的流量高峰場景和低谷場景。

在全自動的模式下，我們細分了資源分析模式和自動調優模式。在資源分析模式下，Autopilot 僅給出建議，不會自動重啟作業，適合一些不能啟停作業的敏感時期，比如大促期間。自動調優模式將根據流量的變化，自適應的改變作業的資源結構，最大程度的幫使用者解決成本問題，比較適合日常的作業執行。

Autopilot 調優的基本思路如下。

首先，我們會從 Flink 上採集當前作業的 Metrics，也會從一些其他的診斷系統，拿到一些作業的執行指標，進行分析。

然後，透過這些原始的指標分析，得到一些複合型指標。透過所有的指標生成多個帶有資源配置最佳化方案的調優計劃。在執行計劃時，從眾多的資源配置方案中，選擇一份最緊急的或最優的方案，更新作業配置。

在更新作業配置時，會優先檢視調優計劃是不是滿足熱更新的要求。如果滿足熱更新要求，會呼叫 JM 的 Rest 介面更新作業。如果不滿足條件，會用 backup 方案，讓作業管理平臺啟停作業。

在採集分析 Metric 階段，除了使用原始的 Metric 資訊，例如 CPU 利用率，Slot 利用率，記憶體利用率，Source 的延遲等等，也會生成複合型 Metric。比如當前延遲是不是可以 catch up，當前資料的傾斜程度是不是很嚴重等等，從而生成不同資源配置的調優計劃。

常見的調優計劃分為以下幾種：拆 chain、提高/減少併發度、提高/減少記憶體、新增 Flink conf 等等。最終，從多項調優計劃中，選擇一份最佳的計劃執行。

目前，Autopilot 支援兩種更新作業的方式。

• 熱更新作業配置，它的好處是處理速度更快，重啟的成本更低，但目前僅僅支援調節併發度。

• 呼叫管理平臺，重啟作業的 API。它的好處是可以支援所有的調優場景，來做一個最終的 backup。

如上圖所示，是作業平臺啟停流程和作業熱更新流程。我們以修改併發度為例，在作業平臺啟停流程時，我們需要將原作業停止，然後提交新的作業。等待新的作業在 K8s 等平臺上重新部署和執行。在整個流程中，作業斷流的時間較長，修改帶來的代價會比較高。

右圖是作業熱更新流程。我們透過 Rest 接收一份更新請求。然後，在 Job Master 裡，基於當前作業修改生成新的作業，然後再停止老的作業，最終部署一份新的作業。相較於作業平臺，熱更新節省了啟動初始化 Master 節點的時間，比作業平臺啟停，起停的成本更低。

上圖是 100 併發度作業擴縮容斷流時間對比，在擴容到 150 併發度時，作業平臺啟動需要花費 40 秒左右，熱更新重啟只需要 1.5 秒左右。

在縮容到 50 併發度時，作為平臺重啟需要 30 秒左右，熱更新重啟僅需要花費 0.4 秒。

從這張圖可以看到，熱更新重啟比調優作業平臺重啟，在重啟時間上有更加明顯的優勢。從而能夠最大限度的降低使用者作業斷流的風險，減少修改資源配置的成本。

潮汐流量是指流量的高峰和低谷，時間段具有周期性和可預見性。以電商平臺每年的雙十一活動為例，雙十一時的配置和平時閒時的配置差異比較大。直播平臺白天的配置，和晚上的配置差異也比較大。在這種流量高峰低谷的時間段比較明顯，並且時間段比較固定的場景，應用定時策略會更加的簡單高效。

定時策略主要針對自動調優無法覆蓋的場景。在應用自動調優時，如果流量頻繁抖動的化，最終會導致作業不斷進行呼叫，從而使作業不斷重啟。

在流量變化比較慢的時候，由於作業在一段時間內，Autopilot 只感知到當前最高的流量。因此，可能會出現無法一次調優到位的情況，需要經過很多次迭代才會達到比較好的效果。

定時策略就是為了解決以上問題。它能夠允許使用者針對作業的業務特點，設定作業的最佳資源狀態。在流量抖動比較頻繁時，不會重啟作業。當使用者有一份流量在高峰或低谷時需要用多少資源配置的先驗知識時，能夠用定時調優一次性的將作業調到一個比較好的狀態，也能夠避開一些作業的敏感時期。

上圖是定時調優的基本思路。Autopilot 在內部維護了多個資源配置的日曆，當某個時間點需要觸發定時策略，會選用該時間點的資源配置，更新作業配置。

這裡的更新同樣可以分為熱更新和作業管理平臺進行重啟。Autopilot 也會自動檢查新增或更新的定時策略時間是否和已有的定時策略時間衝突。

03

案例介紹

上圖是作業 Slot 處理能力達到瓶頸的案例，可以看到在左圖右邊的節點上，該節點每個值都很高，基本上達到了百分百，表明當前 Slot 的利用率很高。如果作業長時間處於這種狀態，會引起 Failover，影響作業的穩定性。前面的運算元已經被該運算元反壓，導致延時會不斷增加。

為了解決這個問題，Autopilot 將該運算元的併發提高到 320。修改之後，出現了右圖所示的情況，該運算元的 Slot 利用率，降低到比較正常的水準。

上圖是一個 TM 記憶體使用率過低的案例，可以看到使用者在一開始申請了 4G 記憶體，但在實際作業中，TM 只使用了 1G 左右，造成了記憶體浪費。作業成本較高，白白花費了 3G 記憶體的錢。

Autopilot 識別到這種情況，將 TM 記憶體從 4G 降低到 1.6G，幫助使用者降低了作業成本。之所以降到了 1.6G,是因為 Flink 側有最低記憶體設定的限制。如果調優太低，會導致作業直接起不來。

上圖是一個業務流量週期變化的案例，可以看到，左上角作業的 TPS 有一個先高、後低、再高的過程。下面部分是，Autopilot 識別到流量變化，自動調整了作業的併發度。

在流量低谷時，降低了整體併發度，因此需要的數量大大降低。在流量高峰時，出現延遲，重新進行擴容，保障高流量下作業的平穩執行。最終實現資源的彈性擴縮容，有效降低了資源的使用，節約成本的同時，提高了作業的穩定性。

上圖是大促之後自動降低資源，節約成本的案例。在大促期間，作業一般會使用比較高額的資源。一般情況下，使用者無法知道大促的流量什麼時候結束，什麼時候需要將作業資源配置，切換到較低的閒時狀態。

如果我們切換的較早，會導致預判流量失誤，造成較大的流量衝擊作業，導致作業不穩定。如果切換較晚，會浪費過量的資源。Autopilot 輔助業務方在大促結束後，根據流量來平穩、並且快速降低作業使用的資源，節約成本。

上圖是一個設定不同時間段的定時策略案例。我們可以設定早上 9 點到晚上 7 點，為業務的高峰期。在這段高峰期中，使用 30 併發度。在晚上 7 點到早上 9 點，為業務的低谷期，在這期間用 10 併發度。圖中是具體設定資源和設定資源時間段的示意圖。

04

未來規劃

未來，Autopilot 的主要目標是，進一步幫助使用者降本增效。Autopilot 將從三個角度不斷努力。

首先，我們將致力於提高 Autopilot 的易用性，方便使用者使用。我們將支援外掛化的能力，允許使用者自定義一些調優能力。比如自己排列組合一些 Metric，設定一些調優策略，來滿足自身業務的需要。增強外部整合的能力，開發提供 SDK 和 Open API 介面。

其次，我們將讓 Autopilot 更加智慧、更加專業。一個方向是，探索機器學習的一些策略，依靠現在成熟的機器學習演算法，提前進行流量預測，併發預測等工作。另一個方向是，結合叢集資訊和上游依賴作業資訊，進行調優。比如在流量高峰時，在上游的作業被自動調優的同時，下游被依賴的作業也可以順勢進行一定的自動調優。

最後，Autopilot 的穩定性是我們不斷努力的方向。一方面，我們會持續的加強熱更新的能力，讓更多的調優計劃支援熱更新，減小重啟帶來的斷流等較高的調優成本問題。另一方面，讓 Autopilot 覆蓋更多的場景來滿足不同的作業 Pattern，讓其更加全面，比如說 SQL 的寫法本身就有問題，UDF 實現方式有問題，有較大的外部 IO、源表 Partition 數導致無法進一步調高併發度，維表或結果表效能不行等等的諸多問題。