火山引擎雲原生大資料在金融行業的實踐

　　大資料架構向雲原生演進是行業的重要趨勢，火山引擎協助關鍵金融客戶在大資料雲原生方向進行了深度實踐，形成了整體解決方案，本文將分享火山引擎雲原生大資料在金融行業的實踐。

　　 1. 金融行業大資料需求

　　1.1 雲原生相比 Hadoop 的優勢

　　傳統大資料叢集通常基於 Hadoop 系統構建，傳統大資料作業通常是以裸程式的形式執行在節點上，很容易受到節點上的其他程式或其他因素干擾，因此帶來的作業穩定性問題經常困擾使用者。

　　一個實際的例子，如果一個 Flink 作業發生了延遲，找不到業務上的原因，但是觀測到節點的 CPU 使用率比較高。使用者通常選擇殺掉節點上的其他作業，使機器負載下降，這時作業很有可能恢復了正常。但是，最終也沒有定位到延遲的具體原因，一段時間後很可能會再次出現相同的問題，而且每次殺掉其他作業的處理方式非常繁瑣，並且代價比較高。

　　那麼，在大資料場景下，雲原生系統相比 Hadoop 系統，具備以下能力：

　　強制的容器化能力：可以遮蔽大資料作業的執行環境，提高執行時隔離能力；

　　可定製化的網路 / 儲存能力：可以支援大資料作業使用複雜的容器化網路技術，以及雲原生支援的任意儲存系統；

　　便捷的運維能力：可以輕鬆地進行節點上下線，叢集擴縮容，降低基礎設施運維成本。

　　因此，大資料架構向雲原生演進是全行業，特別是金融行業的重要趨勢。

　　困擾使用者的第二個問題是資源效率問題。

　　在實踐中，通常存在獨立的 K8s 叢集和 Hadoop 叢集。獨立的 K8s 叢集執行著線上服務，獨立的 Hadoop 叢集執行著大資料作業，這兩個叢集不僅不能彼此共享資源，而且資源利用率都非常低。

　　離線計算和線上業務的資源需求具有周期性變化，資源需求高峰時資源不足，低峰時資源冗餘。而線上業務與離線計算的資源高低峰期往往是錯開的，所以離線計算高峰時如何利用線上叢集資源，線上業務高峰時如何利用離線叢集資源，成為了降本增效的關鍵。

　　叢集管理的總體目標是在硬體資源不增加的情況下承載更多業務，整體提升叢集資源利用率。

　　因為線上服務部署在雲原生系統已經成為行業規範。在這個前提下，如果大資料系統也部署在雲原生系統，和線上服務部署在一起，那麼就具有如下優點：

　　線上資源和大資料資源可以高效、靈活地相互轉換；

　　整個叢集的利用率可充分地提升，降本增效；

　　資源共池，統一的配額管控、機器運維、軟體部署等，降低維護成本。

　　因此，資源的高效利用是金融行業特別關注的能力和需求。

　　1.2 大資料遷移雲原生的難點

　　現在，雲原生系統仍然存在很多不足，大資料叢集難以直接基於雲原生構建，這也是為什麼大部分公司仍然還在使用 Hadoop 系統的原因。大資料場景下，遷移使用雲原生系統存在以下不足：

　　一個執行在 Hadoop 系統上的傳統大資料作業遷移到雲原生系統，具有一定的改造成本；而一個大資料叢集通常存在數百個、數千個，甚至數萬個、數十萬個作業，全部遷移到雲原生系統上，改造成本巨大，難以實現；

　　傳統的大資料引擎，比如 Flink、Spark，最初不是針對雲原生系統設計，其 AM-Task 作業形態難以直接在雲原生系統上部署；

　　雲原生系統的原生排程器不具備與 Hadoop YARN 佇列類似的多租戶資源管控能力；

　　雲原生系統的原生排程器不存在“作業”概念，不具備作業排隊能力，不具備作業級排程策略；

　　雲原生系統的原生排程器吞吐能力差，不適用於任務量大且執行時間較短的大資料作業，比如一個只需要執行 1 分鐘的 Spark 作業，在排程階段就花費三分鐘，不僅使作業完成時間大幅增加，還造成了叢集資源浪費。

　　因此，只有在雲原生系統上補齊上述不足，才可以更好地支撐金融行業大資料場景。

　　 2. 雲原生大資料部署

　　為了滿足業務的多種需求，火山引擎支援大資料作業在雲原生系統上的兩種部署方式：

　　基於 Serverless YARN 的 Hadoop 方式部署。

　　基於 Arcee Operator 的雲原生方式部署。　　

　　2.1 基於雲原生的 YARN 解決方案 —— Serverless YARN

　　Serverless YARN 是基於雲原生的 YARN 解決方案，幫助大資料作業透明遷移到雲原生系統。簡單來說，在 K8s 系統上模擬實現了 YARN 系統，傳統作業可以像往常一樣提交和執行，不需要進行任何改造，完全感知不到 K8s 的存在。

　　Serverless YARN 保留了 YARN Client、YARN API，以及 YARN 原有的 AM 管理、Quota 管理、許可權管理等功能。

　　作業提交流程如下圖：　　

　　使用者在計算引擎的基礎上進行開發，呼叫 YarnClient SDK，提交作業到 Serverless YARN 的 Resource Manager 元件；

　　RM 元件為作業建立 AM Pod（每個作業有一個 Master 例項，負責管控整個作業，全稱為 Application Master）；

　　AM Pod 經過 K8s 的 API Server 和排程器排程到一個具體的節點，然後由節點上的 Kubelet 負責啟動和管控；

　　AM 啟動後定期向 RM 傳送心跳，心跳資訊包括自身執行狀態，以及資源申請請求；

　　AM 向 RM 申請更多資源，RM 將這些資源請求轉換為 K8s 上的 Pod，由 K8s 負責排程和啟動；

　　作業的其他 Pod 啟動，開始實際計算，受 AM 管控。

　　上述過程和 YARN 完全相同，唯一的區別在於所有作業例項都收斂到 K8s 上，透過 Kubelet 啟動容器並執行。

　　但是，YARN 系統負責啟動和管控作業例項的 NodeMananger 元件具有很多 Kubelet 不具備的大資料特有功能。所以，Serverless YARN 還在每個節點上部署了大資料輔助外掛，以彌補 Kubelet 的功能不足，比如：

　　提供為作業提前下載 Jar 包的功能（在大資料體系中稱為 Localization） ；

　　啟動計算引擎的 Shuffle 服務 ；

　　為大資料作業提供日誌服務 ；

　　為大資料作業提供監控能力 ，等等。

　　Serverless YARN 還提供作業遷移工具，新作業可以無縫提交到 Serverless YARN 叢集上，舊的 YARN 叢集等到沒有任何作業執行後，可以被操作下線。

　　更重要的是，Serverless YARN 做了深度的效能最佳化，RM 切主時間控制在秒級以內，Pod 排程吞吐提高到每秒 2000 個以上。

　　2.2 基於雲原生的大資料統一 Operator —— Arcee Operator

　　Arcee Operator 是基於雲原生的大資料統一 Operator，統一管控多種計算引擎。　　

　　Arcee 借鑑了 YARN 的兩級管理模式，管理大資料作業的 Application Master，再由 AM 管理計算 Worker。

　　這種管理模式能夠有效管理和表達大資料作業狀態，定製作業管理策略，確保計算引擎對計算作業執行有充分的掌握能力，有能力按需調整資源使用。　

　　除兩級管理外 ， Arcee Operator 還具備以下特性：

　　Arcee 定義了統一作業例項：Arcee Operator 利用 K8s 的自定義資源定義了統一作業例項，無論是 Spark 還是 Flink ，或者使其他類 YARN 的計算引擎，都可以使用統一的 CRD 描述作業，包括作業配置、作業規格等資訊，而且可以收集並展示作業的統一且詳細的執行狀態，有利於業務的統一表達和處理；

　　Arcee 實現了作業異常處理：Arcee Operator 可以實時監控所有作業狀態，處理作業異常，持續保障作業正常執行；比如因為節點磁碟故障而導致 AM 執行異常，Arcee 檢測到後在其他節點重新啟動 AM，並接管之前啟動的 Work Pod，使作業恢復正常執行；

　　Arcee 遮蔽了底層排程器：Arcee Operator 封裝了底層排程功能，降低了作業使用高階排程策略的門檻，比如優先順序排程、Gang 排程等大資料作業的強需求；並且可以從排程器上收集作業排程資訊，然後對外展示，使用者可以輕鬆知道“作業為什麼沒有進行排程”。

　　Arcee Operator 與其他雲原生部署方案相比具有諸多優勢，以 Spark 為例：

　　Spark 社群推薦的 K8s Native 方式，Spark Pod 沒有統一資源描述，很難進行管理和描述；

　　Google 的 Spark Operator 在 K8s Native 方式的基礎上封裝了 CRD，提供了統一的資源描述，但是它是以旁路的方式實現的，基本不存在管控策略，而且不支援 Spark Client 模式。

　　相比上述兩種方案，Arcee Operator 在適配大資料計算引擎的原生執行模式的同時，提供了 ：

　　統一的作業描述，以及詳細、準確的狀態資訊；

　　豐富的作業異常處理策略；

　　快速接入高階排程功能的能力。

　　 3. 雲原生大資料排程

　　火山引擎的雲原生大資料系統存在三層資源管理：

　　全域性的多機房統一資源湖 —— ResLake，負責全域性統一的資源管理、排程、分發和容災；

　　每個叢集上，GRO Scheduler 負責叢集內的 Quota 管控和 Pod 排程；

　　每個節點上，GRO Agent 負責單機排程和隔離增強。　　

　　3.1 基於雲原生的高效能資源管理排程器 —— GRO

　　GRO Scheduler 是基於雲原生的高效能資源管理排程器，管控叢集資源，並結合 GRO Agent 實現單機排程、隔離、和混部能力。　　

　　3.1.1 GRO Scheduler

　　雲原生系統原生排程器的主要功能是 Pod 放置，也就是為 Pod 選擇一個最優的節點，但是這完全不能滿足大資料作業的需求。

　　GRO Scheduler 參考 YARN 等大資料排程器，在 Pod 放置的基礎上，增加了 Quota 管控。　　

　　整個排程流程如圖：

　　Quota 管控：排程器首先將叢集資源分配給各個佇列，然後將佇列資源分配給該佇列的各個作業，最後將作業資源分配給該作業的各 Pod。不是所有 Pod 都可以獲得資源，只有獲得資源的 Pod 才可以進入後續的 Pod 放置流程；

　　Pod 放置：和原生排程器一樣，首先為 Pod 篩選符合條件的節點，然後對篩選出來的節點進行打分，最後將 Pod 繫結到分數最高的節點上。

　　大資料作業，特別是批式計算，只會佔用資源一段時間，執行結束後歸還資源。為了保證大資料作業可以充分利用叢集資源，通常使用者會提交多個作業，部分作業不能立刻獲得資源，而是排隊等待，直到有作業結束退出，才開始獲得資源開始執行。這其中涉及兩個重要的概念，“佇列”和“作業”。

　　雲原生系統原生排程器最初是針對線上服務設計，沒有這兩個概念。

　　沒有“ 佇列 ”的概念：一個叢集包含多個節點，可以供多個租戶同時使用叢集資源。為了避免一個租戶佔用叢集全部資源，而影響到其他租戶，叢集的運維人員或者資源的管理人員非常希望能夠按照一定比例，或者按照指定數量將叢集資源分配給不同租戶。而云原生系統不支援這樣的多租戶資源管控能力。

　　沒有“作業”的概念：在大資料叢集裡，一定存在作業排隊的情況，對於這些不同的作業，哪些獲得資源，哪些排隊等待，是需要一個能夠感知作業優先順序、規格或其他資訊的資源分配策略的。雲原生系統只有 Pod 的概念，而不能感知作業，不具備作業級的排程策略。

　　因此，為了更好地支援大資料場景資源分配， GRO 使用 K8s 自定義資源能力新增這兩個概念 ：

　　Queue CRD：描述了一個“佇列”，即 Quota（資源配額）的抽象；

　　PodGroup CRD：描述了一個“作業”，標識多個 Pod 屬於同一個集合，從而可以把多個 Pod 看作整體進行排程。

　　GRO 的每個佇列有兩個資源配額屬性：

　　Min Quota，又稱為保障資源量。排程器為該佇列預留 Min Quota 的資源量，不允許其他佇列佔用，以保障該佇列在需要使用時可以立刻獲得資源；

　　Max Quota，又稱為資源使用上限。排程器限制該佇列使用資源不超過 Max Quota 的資源量。

　　GRO 將根據所有佇列的 Min-Max 屬性，將叢集資源公平地分配給各個佇列，再根據不同的排程策略，將佇列資源公平地分配給佇列內的各個作業，再進一步分配各作業內的各個 Pod。

　　目前支援的幾種常用排程策略：

　　優先順序排程：所有作業按照定義的優先順序排序，排程器優先分配高優先順序的作業；

　　Gang 排程：排程器一次性為作業的所有 Pod 分配資源，或者一個 Pod 也不分配，保證不出現一個作業的部分 Pod 啟動，部分 Pod 排隊等待的情況；一個作業只有部分 Pod 啟動，有可能不能正常執行，這樣不僅浪費了叢集資源，還可能存在多個類似作業相互死鎖，導致所有作業都不能正常執行；

　　DRF 排程：排程器公平分配資源給各個作業的同時，兼顧多維度資源的比例，儘可能提升資源利用率；比如佇列剩餘大量 CPU 和少量記憶體時，優先分配 CPU 需求多、記憶體需求少的作業，避免佇列的記憶體完全耗盡，大量 CPU 剩餘，無法被利用的問題。

　　GRO 還支援其他 Quota 管控策略 ：

　　佇列間搶佔：佇列沒有使用的 Quota 允許臨時被其他佇列佔用，當佇列有資源需求時，可以從其他佇列將資源搶佔回來；

　　佇列內搶佔：佇列沒有剩餘 Quota，高優作業提交後可以將正在執行的低優作業佔用的資源搶佔回來；

　　大作業資源預留：資源需求較大的作業很有可能因為節點資源碎片一直無法排程，排程器支援預留節點資源，保證大作業排程成功。

　　GRO Scheduler 具有強大的 Pod 放置能力， 支援將一個 Pod 排程到具體節點的各種不同策略，支援大部分原生排程器功能，比如節點名稱、節點 Label、節點汙點、親緣性、集中排程、均衡排程等策略；也支援大數場景的高階策略，比如真實負載平均、GPU 共享、微拓撲排程等策略。

　　GRO Scheduler 具有極高的排程吞吐，採用批式排程，在支援複雜排程策略的前提下，排程吞吐效能仍然可以達到每秒上千個 Pod。

　　GRO Scheduler 具有豐富的資訊統計，支援佇列的資源統計，作業的狀態、資源、計量統計，作業的執行事件等資訊的收集和展示等。

　　大資料作業部署在雲原生系統上，線上服務也部署在雲原生系統上，在離線業務可以同時部署到同一個叢集上。GRO Scheduler 統一管控雲原生叢集資源，同時排程線上服務和大資料作業。

　　線上服務高峰時，離線計算儘量停止執行，線上服務使用叢集大部分資源；

　　線上服務低谷時，線上服務讓出大部分資源，離線計算開始執行。

　　以證券交易場景為例，每天交易時間是固定的，這期間線上服務承接大量流量，需要大量資源，離線計算作業全部停止，優先保證線上服務執行；當交易時間結束後，線上服務沒有流量，資源閒置，離線計算作業開始執行。

　　以上，在離線資源可以高效且靈活地相互轉換，整個叢集利用率得到極大地提升，實現降本增效。

　　同時，面對在離線業務，基礎元件運維人員只需要維護雲原生叢集，降低維護開銷。　　

　　3.1.2 GRO Agent

　　線上服務和大資料作業可以執行在一個叢集，不可避免地也會執行在一個節點上。但是大資料作業的執行特性是大幅利用機器資源，是有可能會影響到線上服務的。

　　雲原生系統的資源隔離機制可以限制每個 Pod 的 CPU 時間片和記憶體使用量，但是這樣的隔離程度是不夠的。比如大資料作業導致節點 Load 升高，會影響到同一個節點上的線上服務。

　　因此，GRO Agent 部署到每個節點上，用於增強單機隔離性。

　　單機隔離手段包括 CPU（排程權重、核心隔離）、記憶體（獨立記憶體水位）、磁碟（IOPS/頻寬限制）、網路（網路打標流量限制）等多個層面。

　　GRO Agent 支援線上 SLA 保障機制，監控節點上線上服務的執行情況，結合業務指標、資源指標、基礎指標等，在必要情況下，可以驅逐大資料 Pod，或者通知排程器重新遷移線上服務，以保障線上服務的穩定性。　　

　　3.1.3 閒置資源利用

　　GRO 支援閒置資源利用，實現資源超發，更進一步提高資源利用率，降低成本。

　　舉例來說，一個 4 核的 Flink Pod，在高峰期資源使用率是 3.9 核，但是低谷期資源使用率只有 0.2 核。因此不能簡單的減少 Flink Pod 的資源申請量，但是低谷期時會存在資源的大量浪費。因此 GRO 可以在低谷期時，排程一個低優的 Pod，利用空閒的 3.8 核資源。

　　執行流程簡述：

　　GRO Agent 監控所有 Pod 的資源使用情況，結合實時/歷史資源變化曲線，實時計算出節點上可以被重複利用的閒置資源量（BestEffort 資源）；

　　GRO Agent 上報 BE 資源量到 GRO Scheduler；

　　GRO Scheduler 排程有預期的低優作業到節點上使用 BE 資源；

　　GRO Agent 透過單機隔離機制保障正常 Pod 的穩定性和效能；

　　GRO Agent 根據 BE 資源變化情況壓縮混部 Pod 資源或者驅逐混部 Pod。

　　3.2 基於雲原生的多機房統一資源湖 —— ResLake

　　ResLake 是基於雲原生的多機房統一資源湖，統一管理全域性計算、儲存、網路資源，並提供全域性容災能力。　　

　　資料中心通常存在多個機房，每個機房也存在多個叢集，而每個叢集上都存在不同佇列。使用者面對不同機房、不同叢集的多個佇列，存在一定使用成本。

　　ResLake 提供了全域性虛擬佇列。 每個虛擬佇列對應不同機房或叢集的多個佇列。使用者提交作業到虛擬佇列，ResLake 考慮資源情況、儲存親和性等因素，自動分發到合適的機房、叢集和佇列。

　　另外，ResLake 還提供了全域性 Quota 管控。 ResLake 在排程作業時，會考慮 Quota 約束、資料區域性性、機房拓撲、自定義約束等條件。　　

　　ResLake 優先排程作業到和儲存資源更“近”的計算佇列。這裡的“近”，包括同一個叢集、同一個叢集，或者網路通訊開銷較小的不同機房。

　　ResLake 還支援管理和排程儲存資源：

　　針對週期性作業，ResLake 提交將儲存資源搬遷到計算佇列所在的機房；

　　針對臨時查詢，如果存在跨機房讀取儲存資料，ResLake 將儲存資源快取在目的機房一段時間。

　　全域性的計算和儲存資源排程，可以避免大規模跨機房網路通訊，達成“最最佳化資源利用率。最小化作業完成時間”的最終排程目的。

　　ResLake 支援分發作業到具體的叢集和佇列 ：

　　支援一個作業全部分發到同一個佇列；

　　支援一個作業的不同例項按照指定比例或者指定數量分發到不同佇列，包括同叢集、同機房的不同叢集、不同機房的佇列等。

　　結合上述分發策略，ResLake 提供三種容災能力：

　　遷移容災 ：

　　災難發生後，自動重新提交作業到備用佇列；

　　備用叢集資源不足時，自動殺死低優作業以騰出資源；

　　多活容災 ： 基於多副本的輸入/輸出，在備用佇列啟動副本作業；

　　高可用容災 ： 基於作業自身 HA 能力，作業子例項被分發到兩個佇列同時執行。　　

　　 4. 雲原生大資料助力金融

　　火山引擎雲原生大資料平臺致力於金融行業雲原生大資料解決方案 ：

　　Serverless YARN：基於雲原生的 YARN 解決方案。

　　Arcee Operator：基於雲原生的大資料統一 Operator。

　　GRO：基於雲原生的高效能資源管理排程器。

　　ResLake：基於雲原生的多機房統一資源湖。　　

　　上述四個解決方案提供了精細強大的作業管理能力，高效優秀的資源管理能力和跨機房作業容災能力，幫助大資料作業平滑遷移到雲原生系統。滿足使用者在硬體資源不增加的情況下承載更多業務，整體提升叢集資源利用率。