如何降低 Flink 開發和運維成本？阿里雲實時計算平臺建設實踐

摘要：本文整理自阿里雲高階技術專家，Apache Flink Contributor 周凱波（寶牛），在 FFA 2022 平臺建設專場的分享。本篇內容主要分為四個部分：
業務背景
平臺架構演進
平臺核心功能建設
未來規劃

點選檢視直播回放和演講 PPT

一、業務背景

在阿里集團內部，實時業務的場景主要分為四大類。

第一個場景是實時 ETL，這是目前使用最廣泛的場景，比如在集團的實時資料公共層業務中會對資料做統一的實時清洗、轉換，為其他部門提供加工好的公共資料，便於業務部門進行二次分析。
第二個場景是實時監控，比如安全部門需要實時監測和分析使用者行為或事件，基於風控規則進行預警。
第三個場景是實時線上系統，它在淘寶的搜尋和廣告系統中使用很廣泛，主要是給使用者實時推薦個性化的商品和服務。
第四個場景是實時報表，比如每次大促活動的媒體大屏，以及生意參謀這種給商家的運營工具都會提供實時報表功能。

在集團內部，比較典型的資料處理鏈路分為四步。

首先是資料採集，資料的來源有 TT 等訊息佇列過來的日誌資料，來自資料庫的 Binlog 資料，以及訊息中介軟體的資料。
這些資料都會經過 Flink 進行處理，產出實時明細資料和彙總資料。
處理完的資料會寫入 Hologres/ODPS/ADB/Lindorm 等儲存和線上分析系統，既可以直接為實時大屏，報表統計等業務場景提供資料服務，也可以由 Flink 進行再一次的分析。

上圖是實時計算 Flink 在集團內的的業務規模。在大促期間，計算資源的峰值接近 200 萬 core，有 3 萬多個實時任務，服務了超過 90 個部門，在大促期間的峰值處理能力達到 69 億條每秒。

二、平臺架構演進

阿里實時計算平臺的發展分為四個階段，在 2013 年之前，處於一個百花齊放的狀態，沒有統一的實時計算平臺。2013 年，基於自研 Galaxy 引擎的 Bayes 平臺上線，開始服務資料魔方，雙 11 等實時業務場景。2017 年，集團將內部廣泛使用的三大實時計算引擎統一，合力打造 Blink 引擎，這時候基於 Blink 的全新的 Bayes 平臺上線。隨後的幾年，在阿里將 Blink 程式碼貢獻給 Flink 社群之後，開始打造內部的企業級增強 Flink 引擎。到了 2021 年，基於 Flink 引擎的雲原生大資料平臺阿里雲實時計算平臺 Realtime Compute 上線。

實時計算平臺 2.0 的特點是一個使用者一個 Hadoop 叢集，叢集中的計算節點是 ECS 機器。這套基於 Hadoop 生態的架構，雖然在當時能做到較好的資源隔離，但是也帶來了兩個問題：多租戶成本比較高和資源彈性不足。

我們需要運維很多個 Hadoop 叢集，除了運維成本高之外，Hadoop Master 節點也無法共用，造成管控資源的浪費；其次由於底層是基於 ECS 的資源粒度，擴縮容時間很長，使用者也無法按量付費去購買 1 個核的 CPU 資源，使用者的使用成本較高。

為了實現輕量化的多租戶和靈活的資源彈性，我們需要將實時計算平臺從 Hadoop 生態轉型到基於 K8s 的雲原生時代。

實時計算平臺 2.0 到 3.0 的升級包括四個方面:

第一個方面是引擎核心從 Blink 引擎升級到了 Flink 引擎，和社群介面相容，能夠隨時獲取社群最新的功能。同時也能透過外掛化機制，做到企業級核心的增強。
第二個方面是資源底座從 Yarn 切換到了 K8s 排程，能實現 Serverless 化，便於統一資源池和統一排程。
第三個方面是平臺架構也升級為微服務架構，具備靈活的可伸縮和可擴充套件能力。
第四個方面是技術品牌的升級，阿里雲與 Flink 社群原班人馬一起打造全球統一的大資料品牌 Ververica，進一步擴大 Flink 技術在全球範圍內的影響力。

3.0 平臺的技術棧，包括五層。最下面是 IaaS 層，主要是硬體基礎設施，包括物理機、虛擬機器、神龍裸金屬和 ARM 機型等。往上是儲存層，象 OSS，HDFS 這些系統主要用來儲存 Flink 作業的 Checkpoint/Savepoint 資料，以及使用者作業的 jar 包等資源。

再往上是排程層，由 K8s 進行統一排程。排程層之上是引擎層，是阿里基於開源 Flink 打造的企業級增強引擎，比如自研了狀態後端儲存 GeminiStatebackend。最上面一層是平臺層，阿里雲實時計算 Flink 平臺透過 Gateway 作為統一入口，內部分為 AppManager，SQLService 和 AutoPilot 等各個微服務。

3.0 平臺是採用的是基於微服務的分層架構，技術特點是容器化，微服務化和外掛化。Gateway 作為整個平臺的入口，負責使用者認證和鑑權，透過 API 路由統一透出平臺能力。AppManager 是一個 region 化的中心化管控服務，負責作業生命週期的管理。

在計算層，基於 K8s 之上的 VC 隔離技術，每個使用者看到的都是一個虛擬的 K8s 叢集，使用者之間的操作互不干擾，實現了比較好的多租戶隔離。同時，基於 K8s 的能力可以做到容器級別的資源彈性，比如可以支援申請一個核的 CPU 資源。

3.0 架構將功能拆分成一個個的微服務，每個服務能獨立開發部署和擴縮容。這樣的好處是能比較方便地做到服務能力的彈性擴充套件。另外，不同團隊可以負責不同微服務的開發，互不影響，提高協作效率。最後透過外掛化來對接各種外部系統，具備很好的靈活性。

3.0 架構是一個基於 VC 的 Flink 硬多租 Serverless 架構，隔離性非常好。

首先，每個使用者的 AppAgent 和 SQLService 這些管控服務是部署在使用者自己的虛擬叢集 VC 裡面，管控上做到了隔離。

其次，每個使用者有一套自己的 Tenant Master，對 K8s 的訪問互不干擾，做到了 Master 的隔離，而底層的 Super Master 是共享的，能節省管控成本。

最後，透過 kata 安全容器，雲盤，VPC 和彈性網路卡 ENI 這些阿里雲的基礎設施可以做到計算，儲存和網路的隔離。

在資源彈性方面，基於容器化技術實現了以 pod 為粒度的資源彈性，能滿足使用者按量付費的購買需求，降低使用者成本。最後，由於叢集資源的管理下層到了底座，平臺方不用關心底層的叢集和硬體，大大降低了運維成本。

三、平臺核心功能建設

作為一個全託管的大資料平臺，最核心的功能是對作業全生命週期的管理，包括作業的開發、除錯，執行、監控告警、錯誤/效能問題的診斷、效能的調優。使用者在平臺上的活動都是圍繞這些操作進行的。

在 3.0 平臺上，使用者可以使用預設的開發平臺，透過功能豐富的 SQL 編輯器進行 SQL 的開發除錯，同時平臺也具備良好的被整合能力，第三方平臺可以透過 OpenAPI 進行接入。比如像菜鳥物流雲、Dataphin 等都可以往 Flink 上提交作業。

我們知道 Flink 是一個流批一體的計算引擎，因此我們在平臺上也提供了流批一體的開發體驗，使用者只需要寫一個 SQL，就可以同時執行流和批作業，極大簡化 Flink 作業的開發運維成本。其次是 SQL 除錯能力，透過和 Flink Session Cluster 結合，能夠做到秒級別的 SQL 除錯，大大提升了使用者的開發效率。

在作業運維方面，平臺有兩個目標，分別是全託管和免運維。

全託管：使用者不需要關心叢集運維和 Flink 作業具體的提交流程，平臺幫使用者管理好作業，比如 Flink 作業生命週期管理，作業 Checkpoint 和 Savepoint 這些狀態集的管理，以及指標監控和告警等。

免運維：平臺提供一些白屏化的運維工具降低使用者的運維成本。以作業探查為例，平臺提供了日誌歸檔、分類、基於 Arthas 的火焰圖、基於 JMX 的記憶體動態和執行緒動態，幫助使用者去分析定位作業的執行瓶頸。

但是這些工具對使用者還是有一定的使用門檻，因此平臺提供了 AutoPilot 智慧診斷調優系統進一步達到免運維的目的。

Flink 作業如果想在有限的資源使用下達到最優的效能，需要對不同運算元的記憶體和併發度等引數分別進行配置。在社群開源版本中，使用者只能透過配置檔案進行全域性的配置，無法精確控制作業資源，這樣會造成資源浪費。另外對於 DataStream 作業，每次進行資源配置都需要修改程式碼，打包和部署都不夠靈活。

針對這個問題，我們透過 JSON 檔案描述作業的執行計劃，實現了運算元級別的 CPU/Mem 和併發度的精細化資源配置，同時提供視覺化的方式方便使用者進行編輯，使用者也可以透過 UI 介面配置運算元的 CPU/Mem 和併發度。這樣對於 SQL 和 DataStream 作業都能提供同樣的使用者體驗。

透過細粒度資源調優功能，對於一些專業使用者來說，能夠將作業效能調到最優，同時降低資源的成本。

接下來以 SQL 作業為例，介紹一下細粒度資源調優的基本原理。在 SQL 文字到 JobGraph 的翻譯中間過程中，會經過一步 StreamGraph 的生成。我們可以透過 JSON 檔案對 StreamGraph 中的各個運算元的資源進行描述，同時提供視覺化編輯的方式。

使用者透過視覺化介面，可以修改運算元併發/記憶體，還可以決定前後運算元是否 Chain 在一起，甚至還可以調整 SlotSharingGroup 來決定運算元是否共享同一個 Slot。

使用者調整好後的 JSON 檔案會應用到 StreamGraph 之上，生成最終的 JobGraph 去執行。

細粒度資源調優雖然可以將作業效能調到最優，同時降低資源成本，但是每個作業都手工配置也比較繁瑣。此外，使用者經常會遇到類似的問題，比如 Flink 調優引數眾多，需要了解底層細節；業務的流量有波峰和波谷，作業配置需要手工切換；作業執行不穩定，定位困難；叢集或者底層的硬體有問題，導致排查問題無從下手等等。

針對這些問題，在平臺上的解法是智慧診斷和智慧調優，讓系統自動化的做一些判斷，儘可能降低人工操作和干預，讓系統自動去做一些判斷。比如，作業的 Checkpoint 失敗，或者執行中發生了資料傾斜，這些平臺都可以監控到，然後反饋給使用者。

智慧診斷調優系統分為多個模組，包括 Agent Manager，它負責管理所有 Agent 節點，Agent 節點負責對於某個任務進行具體的診斷和調優。它包括定時排程器、檢測、分析、選擇和執行等各個服務。

智慧診斷調優系統的工作原理是，從各個地方收集作業的執行資訊，比如日誌，Metrics 指標，以及叢集層面的硬體和網路等資訊。將這些資訊彙總後，就可以分析出當前作業的症狀，然後從平臺積累的規則庫中選擇對應的方案去執行。比如，發現某個節點的效能不夠，建議使用者調大作業的併發度等配置引數；比如發現 JobManager 或 TaskManager 節點的 GC 嚴重，建議使用者調整記憶體引數等等。

智慧診斷調優系統的業務收益體現在以下三個方面：

自適應流量的高峰和低谷，降低業務成本。
在每年的 618、雙十一等大促期間實現資源的彈性回收，無須人工干預。
實現故障的自動診斷，降低運維成本，最終幫使用者達到降本增效的目的。

在 Flink 作業運維過程中，經常會遇到平臺上的運維功能很多，但是不知道什麼時候用哪個，比較分散。比如作業出現問題後，是先看日誌、Metrics 指標，還是 Flink Web UI。

其次，不同型別的異常需要處理的緊急程度不一樣。比如 Failover 異常，如果不是大面積出現，只是偶爾出現一次，不需要太關心。如果是 Checkpoint 超時，偶爾出現一次問題也不大，但是長時間出現就需要處理了。否則作業 Failover 後回追資料的成本會比較高。但是像 Connector 連線異常或者資源不足，會影響到作業的結果產出，就需要立即進行處理。

此外，不同人員的 Flink 專業知識背景也不一樣，因為並不是每個人都清楚該如何運維 Flink 作業。

針對這些問題，在平臺上的解法是，引入打分機制量化評估作業的風險程度，將健康分作為統一的入口，打通從現象到決策的端到端鏈路。

健康分的工作原理是透過智慧診斷服務獲取日誌、Metrics、叢集等資訊，診斷出作業的症狀，然後健康分服務進行統一打分，將作業判斷為高、中、低三個風險，並給出具體的 Action 告訴使用者應該怎麼操作。

這樣，使用者不需要掌握太多的專業知識，只需要看到健康分就能一目瞭然清楚的知道哪些作業需要處理，以及需要做什麼操作。

在健康分體系中，每個作業的初始分數是滿分 100 分，當作業出現一個高等級風險時扣五分，中等級風險時扣三分，低等級風險時扣一分。

以上圖中的作業為例，作業 A 是 95 分，處於低風險狀態，對應的 Action 是加大 akka 超時時間，這時候使用者並不需要進行緊急處理。作業 B 是 72 分，處於中風險狀態，對應的 Action 是調大 3 號節點併發，使用者可以稍後進行處理。作業 C 是 46 分，處於高風險狀態，對應的 Action 是下游 Kafka 服務訪問異常，請檢查服務是否正常。這時候資料已經無法正常產出了，使用者需要進行緊急處理，否則會引發生產故障。

除了前面介紹的在架構上做到了硬多租的隔離保證安全之外，平臺還提供了很多企業級的安全能力建設。

在專案空間級別做了許可權的隔離，每個使用者只能訪問自己所在的專案空間的資源。
每個專案空間的儲存是隔離的，比如採用不用的 OSS 物件儲存 Bucket，對 OSS 的訪問也採用臨時 Token，而不是固定的賬號密碼，這樣能保證儲存的安全。
透過實現基於角色的訪問控制（RBAC），在平臺上定義 Viewer、Editor、Owner 和 Admin 等角色，每種角色都有自己的許可權。比如 Viewer 只能檢視資料，無法啟停作業；Editor 可以啟停作業，但沒有許可權進行管理的操作。