火山引擎云原生大數據在金融行業的實踐
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 將存儲資源緩存在目的機房一段時間。
全局的計算和存儲資源調度，可以避免大規?？鐧C房網絡通信，達成“最優化資源利用率。最小化作業完成時間”的最終調度目的。
ResLake 支持分發作業到具體的集群和隊列 ：
- 支持一個作業全部分發到同一個隊列；
- 支持一個作業的不同實例按照指定比例或者指定數量分發到不同隊列，包括同集群、同機房的不同集群、不同機房的隊列等。
結合上述分發策略，ResLake 提供三種容災能力：
- 遷移容災 ：
- 災難發生后，自動重新提交作業到備用隊列；
- 備用集群資源不足時，自動殺死低優作業以騰出資源；
- 多活容災 ： 基于多副本的輸入/輸出，在備用隊列啟動副本作業；
- 高可用容災 ： 基于作業自身 HA 能力，作業子實例被分發到兩個隊列同時運行。
4. 云原生大數據助力金融
火山引擎云原生大數據平臺致力于金融行業云原生大數據解決方案 ：
- Serverless YARN：基于云原生的 YARN 解決方案。
- Arcee Operator：基于云原生的大數據統一 Operator。
- GRO：基于云原生的高性能資源管理調度器。
- ResLake：基于云原生的多機房統一資源湖。
上述四個解決方案提供了精細強大的作業管理能力，高效極致的資源管理能力和跨機房作業容災能力，幫助大數據作業平滑遷移到云原生系統。滿足用戶在硬件資源不增加的情況下承載更多業務，整體提升集群資源利用率。
