火山引擎云原生大數(shù)據(jù)在金融行業(yè)的實踐
1. 金融行業(yè)大數(shù)據(jù)需求
1.1 云原生相比 Hadoop 的優(yōu)勢
傳統(tǒng)大數(shù)據(jù)集群通常基于 Hadoop 系統(tǒng)構(gòu)建，傳統(tǒng)大數(shù)據(jù)作業(yè)通常是以裸進(jìn)程的形式運行在節(jié)點上，很容易受到節(jié)點上的其他進(jìn)程或其他因素干擾，因此帶來的作業(yè)穩(wěn)定性問題經(jīng)常困擾用戶。
一個實際的例子，如果一個 Flink 作業(yè)發(fā)生了延遲，找不到業(yè)務(wù)上的原因，但是觀測到節(jié)點的 CPU 使用率比較高。用戶通常選擇殺掉節(jié)點上的其他作業(yè)，使機器負(fù)載下降，這時作業(yè)很有可能恢復(fù)了正常。但是，最終也沒有定位到延遲的具體原因，一段時間后很可能會再次出現(xiàn)相同的問題，而且每次殺掉其他作業(yè)的處理方式非常繁瑣，并且代價比較高。
那么，在大數(shù)據(jù)場景下，云原生系統(tǒng)相比 Hadoop 系統(tǒng)，具備以下能力：
- 強制的容器化能力：可以屏蔽大數(shù)據(jù)作業(yè)的運行環(huán)境，提高運行時隔離能力；
- 可定制化的網(wǎng)絡(luò) / 存儲能力：可以支持大數(shù)據(jù)作業(yè)使用復(fù)雜的容器化網(wǎng)絡(luò)技術(shù)，以及云原生支持的任意存儲系統(tǒng)；
- 便捷的運維能力：可以輕松地進(jìn)行節(jié)點上下線，集群擴縮容，降低基礎(chǔ)設(shè)施運維成本。
因此，大數(shù)據(jù)架構(gòu)向云原生演進(jìn)是全行業(yè)，特別是金融行業(yè)的重要趨勢。
困擾用戶的第二個問題是資源效率問題。
在實踐中，通常存在獨立的 K8s 集群和 Hadoop 集群。獨立的 K8s 集群運行著在線服務(wù)，獨立的 Hadoop 集群運行著大數(shù)據(jù)作業(yè)，這兩個集群不僅不能彼此共享資源，而且資源利用率都非常低。
離線計算和在線業(yè)務(wù)的資源需求具有周期性變化，資源需求高峰時資源不足，低峰時資源冗余。而在線業(yè)務(wù)與離線計算的資源高低峰期往往是錯開的，所以離線計算高峰時如何利用在線集群資源，在線業(yè)務(wù)高峰時如何利用離線集群資源，成為了降本增效的關(guān)鍵。
集群管理的總體目標(biāo)是在硬件資源不增加的情況下承載更多業(yè)務(wù)，整體提升集群資源利用率。
因為在線服務(wù)部署在云原生系統(tǒng)已經(jīng)成為行業(yè)規(guī)范。在這個前提下，如果大數(shù)據(jù)系統(tǒng)也部署在云原生系統(tǒng)，和在線服務(wù)部署在一起，那么就具有如下優(yōu)點：
- 在線資源和大數(shù)據(jù)資源可以高效、靈活地相互轉(zhuǎn)換；
- 整個集群的利用率可充分地提升，降本增效；
- 資源共池，統(tǒng)一的配額管控、機器運維、軟件部署等，降低維護(hù)成本。
因此，資源的高效利用是金融行業(yè)特別關(guān)注的能力和需求。
1.2 大數(shù)據(jù)遷移云原生的難點
現(xiàn)在，云原生系統(tǒng)仍然存在很多不足，大數(shù)據(jù)集群難以直接基于云原生構(gòu)建，這也是為什么大部分公司仍然還在使用 Hadoop 系統(tǒng)的原因。大數(shù)據(jù)場景下，遷移使用云原生系統(tǒng)存在以下不足：
- 一個運行在 Hadoop 系統(tǒng)上的傳統(tǒng)大數(shù)據(jù)作業(yè)遷移到云原生系統(tǒng)，具有一定的改造成本；而一個大數(shù)據(jù)集群通常存在數(shù)百個、數(shù)千個，甚至數(shù)萬個、數(shù)十萬個作業(yè)，全部遷移到云原生系統(tǒng)上，改造成本巨大，難以實現(xiàn)；
- 傳統(tǒng)的大數(shù)據(jù)引擎，比如 Flink、Spark，最初不是針對云原生系統(tǒng)設(shè)計，其 AM-Task 作業(yè)形態(tài)難以直接在云原生系統(tǒng)上部署；
- 云原生系統(tǒng)的原生調(diào)度器不具備與 Hadoop YARN 隊列類似的多租戶資源管控能力；
- 云原生系統(tǒng)的原生調(diào)度器不存在“作業(yè)”概念，不具備作業(yè)排隊能力，不具備作業(yè)級調(diào)度策略；
- 云原生系統(tǒng)的原生調(diào)度器吞吐能力差，不適用于任務(wù)量大且運行時間較短的大數(shù)據(jù)作業(yè)，比如一個只需要運行 1 分鐘的 Spark 作業(yè)，在調(diào)度階段就花費三分鐘，不僅使作業(yè)完成時間大幅增加，還造成了集群資源浪費。
因此，只有在云原生系統(tǒng)上補齊上述不足，才可以更好地支撐金融行業(yè)大數(shù)據(jù)場景。
2. 云原生大數(shù)據(jù)部署
為了滿足業(yè)務(wù)的多種需求，火山引擎支持大數(shù)據(jù)作業(yè)在云原生系統(tǒng)上的兩種部署方式：
- 基于 Serverless YARN 的 Hadoop 方式部署。
- 基于 Arcee Operator 的云原生方式部署。
2.1 基于云原生的 YARN 解決方案 —— Serverless YARN
Serverless YARN 是基于云原生的 YARN 解決方案，幫助大數(shù)據(jù)作業(yè)透明遷移到云原生系統(tǒng)。簡單來說，在 K8s 系統(tǒng)上模擬實現(xiàn)了 YARN 系統(tǒng)，傳統(tǒng)作業(yè)可以像往常一樣提交和運行，不需要進(jìn)行任何改造，完全感知不到 K8s 的存在。
Serverless YARN 保留了 YARN Client、YARN API，以及 YARN 原有的 AM 管理、Quota 管理、權(quán)限管理等功能。
作業(yè)提交流程如下圖：
- 用戶在計算引擎的基礎(chǔ)上進(jìn)行開發(fā)，調(diào)用 YarnClient SDK，提交作業(yè)到 Serverless YARN 的 Resource Manager 組件；
- RM 組件為作業(yè)創(chuàng)建 AM Pod（每個作業(yè)有一個 Master 實例，負(fù)責(zé)管控整個作業(yè)，全稱為 Application Master）；
- AM Pod 經(jīng)過 K8s 的 API Server 和調(diào)度器調(diào)度到一個具體的節(jié)點，然后由節(jié)點上的 Kubelet 負(fù)責(zé)啟動和管控；
- AM 啟動后定期向 RM 發(fā)送心跳，心跳信息包括自身運行狀態(tài)，以及資源申請請求；
- AM 向 RM 申請更多資源，RM 將這些資源請求轉(zhuǎn)換為 K8s 上的 Pod，由 K8s 負(fù)責(zé)調(diào)度和啟動；
- 作業(yè)的其他 Pod 啟動，開始實際計算，受 AM 管控。
上述過程和 YARN 完全相同，唯一的區(qū)別在于所有作業(yè)實例都收斂到 K8s 上，通過 Kubelet 啟動容器并運行。
但是，YARN 系統(tǒng)負(fù)責(zé)啟動和管控作業(yè)實例的 NodeMananger 組件具有很多 Kubelet 不具備的大數(shù)據(jù)特有功能。所以，Serverless YARN 還在每個節(jié)點上部署了大數(shù)據(jù)輔助插件，以彌補 Kubelet 的功能不足，比如：
- 提供為作業(yè)提前下載 Jar 包的功能（在大數(shù)據(jù)體系中稱為 Localization） ；
- 啟動計算引擎的 Shuffle 服務(wù) ；
- 為大數(shù)據(jù)作業(yè)提供日志服務(wù) ；
- 為大數(shù)據(jù)作業(yè)提供監(jiān)控能力 ，等等。
Serverless YARN 還提供作業(yè)遷移工具，新作業(yè)可以無縫提交到 Serverless YARN 集群上，舊的 YARN 集群等到?jīng)]有任何作業(yè)運行后，可以被操作下線。
更重要的是，Serverless YARN 做了深度的性能優(yōu)化，RM 切主時間控制在秒級以內(nèi)，Pod 調(diào)度吞吐提高到每秒 2000 個以上。
2.2 基于云原生的大數(shù)據(jù)統(tǒng)一 Operator —— Arcee Operator
Arcee Operator 是基于云原生的大數(shù)據(jù)統(tǒng)一 Operator，統(tǒng)一管控多種計算引擎。
Arcee 借鑒了 YARN 的兩級管理模式，管理大數(shù)據(jù)作業(yè)的 Application Master，再由 AM 管理計算 Worker。
這種管理模式能夠有效管理和表達(dá)大數(shù)據(jù)作業(yè)狀態(tài)，定制作業(yè)管理策略，確保計算引擎對計算作業(yè)運行有充分的掌握能力，有能力按需調(diào)整資源使用。
除兩級管理外 ， Arcee Operator 還具備以下特性：
- Arcee 定義了統(tǒng)一作業(yè)實例：Arcee Operator 利用 K8s 的自定義資源定義了統(tǒng)一作業(yè)實例，無論是 Spark 還是 Flink ，或者使其他類 YARN 的計算引擎，都可以使用統(tǒng)一的 CRD 描述作業(yè)，包括作業(yè)配置、作業(yè)規(guī)格等信息，而且可以收集并展示作業(yè)的統(tǒng)一且詳細(xì)的運行狀態(tài)，有利于業(yè)務(wù)的統(tǒng)一表達(dá)和處理；
- Arcee 實現(xiàn)了作業(yè)異常處理：Arcee Operator 可以實時監(jiān)控所有作業(yè)狀態(tài)，處理作業(yè)異常，持續(xù)保障作業(yè)正常運行；比如因為節(jié)點磁盤故障而導(dǎo)致 AM 運行異常，Arcee 檢測到后在其他節(jié)點重新啟動 AM，并接管之前啟動的 Work Pod，使作業(yè)恢復(fù)正常運行；
- Arcee 屏蔽了底層調(diào)度器：Arcee Operator 封裝了底層調(diào)度功能，降低了作業(yè)使用高級調(diào)度策略的門檻，比如優(yōu)先級調(diào)度、Gang 調(diào)度等大數(shù)據(jù)作業(yè)的強需求；并且可以從調(diào)度器上收集作業(yè)調(diào)度信息，然后對外展示，用戶可以輕松知道“作業(yè)為什么沒有進(jìn)行調(diào)度”。
Arcee Operator 與其他云原生部署方案相比具有諸多優(yōu)勢，以 Spark 為例：
- Spark 社區(qū)推薦的 K8s Native 方式，Spark Pod 沒有統(tǒng)一資源描述，很難進(jìn)行管理和描述；
- Google 的 Spark Operator 在 K8s Native 方式的基礎(chǔ)上封裝了 CRD，提供了統(tǒng)一的資源描述，但是它是以旁路的方式實現(xiàn)的，基本不存在管控策略，而且不支持 Spark Client 模式。
相比上述兩種方案，Arcee Operator 在適配大數(shù)據(jù)計算引擎的原生運行模式的同時，提供了 ：
- 統(tǒng)一的作業(yè)描述，以及詳細(xì)、準(zhǔn)確的狀態(tài)信息；
- 豐富的作業(yè)異常處理策略；
- 快速接入高級調(diào)度功能的能力。
3. 云原生大數(shù)據(jù)調(diào)度
火山引擎的云原生大數(shù)據(jù)系統(tǒng)存在三層資源管理：
- 全局的多機房統(tǒng)一資源湖 —— ResLake，負(fù)責(zé)全局統(tǒng)一的資源管理、調(diào)度、分發(fā)和容災(zāi)；
- 每個集群上，GRO Scheduler 負(fù)責(zé)集群內(nèi)的 Quota 管控和 Pod 調(diào)度；
- 每個節(jié)點上，GRO Agent 負(fù)責(zé)單機調(diào)度和隔離增強。
3.1 基于云原生的高性能資源管理調(diào)度器 —— GRO
GRO Scheduler 是基于云原生的高性能資源管理調(diào)度器，管控集群資源，并結(jié)合 GRO Agent 實現(xiàn)單機調(diào)度、隔離、和混部能力。
3.1.1 GRO Scheduler
云原生系統(tǒng)原生調(diào)度器的主要功能是 Pod 放置，也就是為 Pod 選擇一個最優(yōu)的節(jié)點，但是這完全不能滿足大數(shù)據(jù)作業(yè)的需求。
GRO Scheduler 參考 YARN 等大數(shù)據(jù)調(diào)度器，在 Pod 放置的基礎(chǔ)上，增加了 Quota 管控。
整個調(diào)度流程如圖：
- Quota 管控：調(diào)度器首先將集群資源分配給各個隊列，然后將隊列資源分配給該隊列的各個作業(yè)，最后將作業(yè)資源分配給該作業(yè)的各 Pod。不是所有 Pod 都可以獲得資源，只有獲得資源的 Pod 才可以進(jìn)入后續(xù)的 Pod 放置流程；
- Pod 放置：和原生調(diào)度器一樣，首先為 Pod 篩選符合條件的節(jié)點，然后對篩選出來的節(jié)點進(jìn)行打分，最后將 Pod 綁定到分?jǐn)?shù)最高的節(jié)點上。
大數(shù)據(jù)作業(yè)，特別是批式計算，只會占用資源一段時間，運行結(jié)束后歸還資源。為了保證大數(shù)據(jù)作業(yè)可以充分利用集群資源，通常用戶會提交多個作業(yè)，部分作業(yè)不能立刻獲得資源，而是排隊等待，直到有作業(yè)結(jié)束退出，才開始獲得資源開始運行。這其中涉及兩個重要的概念，“隊列”和“作業(yè)”。
云原生系統(tǒng)原生調(diào)度器最初是針對在線服務(wù)設(shè)計，沒有這兩個概念。
沒有“ 隊列 ”的概念：一個集群包含多個節(jié)點，可以供多個租戶同時使用集群資源。為了避免一個租戶占用集群全部資源，而影響到其他租戶，集群的運維人員或者資源的管理人員非常希望能夠按照一定比例，或者按照指定數(shù)量將集群資源分配給不同租戶。而云原生系統(tǒng)不支持這樣的多租戶資源管控能力。
沒有“作業(yè)”的概念：在大數(shù)據(jù)集群里，一定存在作業(yè)排隊的情況，對于這些不同的作業(yè)，哪些獲得資源，哪些排隊等待，是需要一個能夠感知作業(yè)優(yōu)先級、規(guī)格或其他信息的資源分配策略的。云原生系統(tǒng)只有 Pod 的概念，而不能感知作業(yè)，不具備作業(yè)級的調(diào)度策略。
因此，為了更好地支持大數(shù)據(jù)場景資源分配， GRO 使用 K8s 自定義資源能力新增這兩個概念 ：
- Queue CRD：描述了一個“隊列”，即 Quota（資源配額）的抽象；
- PodGroup CRD：描述了一個“作業(yè)”，標(biāo)識多個 Pod 屬于同一個集合，從而可以把多個 Pod 看作整體進(jìn)行調(diào)度。
GRO 的每個隊列有兩個資源配額屬性：
- Min Quota，又稱為保障資源量。調(diào)度器為該隊列預(yù)留 Min Quota 的資源量，不允許其他隊列占用，以保障該隊列在需要使用時可以立刻獲得資源；
- Max Quota，又稱為資源使用上限。調(diào)度器限制該隊列使用資源不超過 Max Quota 的資源量。
GRO 將根據(jù)所有隊列的 Min-Max 屬性，將集群資源公平地分配給各個隊列，再根據(jù)不同的調(diào)度策略，將隊列資源公平地分配給隊列內(nèi)的各個作業(yè)，再進(jìn)一步分配各作業(yè)內(nèi)的各個 Pod。
目前支持的幾種常用調(diào)度策略：
- 優(yōu)先級調(diào)度：所有作業(yè)按照定義的優(yōu)先級排序，調(diào)度器優(yōu)先分配高優(yōu)先級的作業(yè)；
- Gang 調(diào)度：調(diào)度器一次性為作業(yè)的所有 Pod 分配資源，或者一個 Pod 也不分配，保證不出現(xiàn)一個作業(yè)的部分 Pod 啟動，部分 Pod 排隊等待的情況；一個作業(yè)只有部分 Pod 啟動，有可能不能正常運行，這樣不僅浪費了集群資源，還可能存在多個類似作業(yè)相互死鎖，導(dǎo)致所有作業(yè)都不能正常運行；
- DRF 調(diào)度：調(diào)度器公平分配資源給各個作業(yè)的同時，兼顧多維度資源的比例，盡可能提升資源利用率；比如隊列剩余大量 CPU 和少量內(nèi)存時，優(yōu)先分配 CPU 需求多、內(nèi)存需求少的作業(yè)，避免隊列的內(nèi)存完全耗盡，大量 CPU 剩余，無法被利用的問題。
GRO 還支持其他 Quota 管控策略 ：
- 隊列間搶占：隊列沒有使用的 Quota 允許臨時被其他隊列占用，當(dāng)隊列有資源需求時，可以從其他隊列將資源搶占回來；
- 隊列內(nèi)搶占：隊列沒有剩余 Quota，高優(yōu)作業(yè)提交后可以將正在運行的低優(yōu)作業(yè)占用的資源搶占回來；
- 大作業(yè)資源預(yù)留：資源需求較大的作業(yè)很有可能因為節(jié)點資源碎片一直無法調(diào)度，調(diào)度器支持預(yù)留節(jié)點資源，保證大作業(yè)調(diào)度成功。
GRO Scheduler 具有強大的 Pod 放置能力， 支持將一個 Pod 調(diào)度到具體節(jié)點的各種不同策略，支持大部分原生調(diào)度器功能，比如節(jié)點名稱、節(jié)點 Label、節(jié)點污點、親緣性、集中調(diào)度、均衡調(diào)度等策略；也支持大數(shù)場景的高級策略，比如真實負(fù)載平均、GPU 共享、微拓?fù)湔{(diào)度等策略。
GRO Scheduler 具有極高的調(diào)度吞吐，采用批式調(diào)度，在支持復(fù)雜調(diào)度策略的前提下，調(diào)度吞吐性能仍然可以達(dá)到每秒上千個 Pod。
GRO Scheduler 具有豐富的信息統(tǒng)計，支持隊列的資源統(tǒng)計，作業(yè)的狀態(tài)、資源、計量統(tǒng)計，作業(yè)的運行事件等信息的收集和展示等。
大數(shù)據(jù)作業(yè)部署在云原生系統(tǒng)上，在線服務(wù)也部署在云原生系統(tǒng)上，在離線業(yè)務(wù)可以同時部署到同一個集群上。GRO Scheduler 統(tǒng)一管控云原生集群資源，同時調(diào)度在線服務(wù)和大數(shù)據(jù)作業(yè)。
- 在線服務(wù)高峰時，離線計算盡量停止運行，在線服務(wù)使用集群大部分資源；
- 在線服務(wù)低谷時，在線服務(wù)讓出大部分資源，離線計算開始運行。
以證券交易場景為例，每天交易時間是固定的，這期間在線服務(wù)承接大量流量，需要大量資源，離線計算作業(yè)全部停止，優(yōu)先保證在線服務(wù)運行；當(dāng)交易時間結(jié)束后，在線服務(wù)沒有流量，資源閑置，離線計算作業(yè)開始運行。
以上，在離線資源可以高效且靈活地相互轉(zhuǎn)換，整個集群利用率得到極大地提升，實現(xiàn)降本增效。
同時，面對在離線業(yè)務(wù)，基礎(chǔ)組件運維人員只需要維護(hù)云原生集群，降低維護(hù)開銷。
3.1.2 GRO Agent
在線服務(wù)和大數(shù)據(jù)作業(yè)可以運行在一個集群，不可避免地也會運行在一個節(jié)點上。但是大數(shù)據(jù)作業(yè)的運行特性是大幅利用機器資源，是有可能會影響到在線服務(wù)的。
云原生系統(tǒng)的資源隔離機制可以限制每個 Pod 的 CPU 時間片和內(nèi)存使用量，但是這樣的隔離程度是不夠的。比如大數(shù)據(jù)作業(yè)導(dǎo)致節(jié)點 Load 升高，會影響到同一個節(jié)點上的在線服務(wù)。
因此，GRO Agent 部署到每個節(jié)點上，用于增強單機隔離性。
單機隔離手段包括 CPU（調(diào)度權(quán)重、核心隔離）、內(nèi)存（獨立內(nèi)存水位）、磁盤（IOPS/帶寬限制）、網(wǎng)絡(luò)（網(wǎng)絡(luò)打標(biāo)流量限制）等多個層面。
GRO Agent 支持在線 SLA 保障機制，監(jiān)控節(jié)點上在線服務(wù)的運行情況，結(jié)合業(yè)務(wù)指標(biāo)、資源指標(biāo)、基礎(chǔ)指標(biāo)等，在必要情況下，可以驅(qū)逐大數(shù)據(jù) Pod，或者通知調(diào)度器重新遷移在線服務(wù)，以保障在線服務(wù)的穩(wěn)定性。
3.1.3 閑置資源利用
GRO 支持閑置資源利用，實現(xiàn)資源超發(fā)，更進(jìn)一步提高資源利用率，降低成本。
舉例來說，一個 4 核的 Flink Pod，在高峰期資源使用率是 3.9 核，但是低谷期資源使用率只有 0.2 核。因此不能簡單的減少 Flink Pod 的資源申請量，但是低谷期時會存在資源的大量浪費。因此 GRO 可以在低谷期時，調(diào)度一個低優(yōu)的 Pod，利用空閑的 3.8 核資源。
運行流程簡述：
- GRO Agent 監(jiān)控所有 Pod 的資源使用情況，結(jié)合實時/歷史資源變化曲線，實時計算出節(jié)點上可以被重復(fù)利用的閑置資源量（BestEffort 資源）；
- GRO Agent 上報 BE 資源量到 GRO Scheduler；
- GRO Scheduler 調(diào)度有預(yù)期的低優(yōu)作業(yè)到節(jié)點上使用 BE 資源；
- GRO Agent 通過單機隔離機制保障正常 Pod 的穩(wěn)定性和性能；
- GRO Agent 根據(jù) BE 資源變化情況壓縮混部 Pod 資源或者驅(qū)逐混部 Pod。
3.2 基于云原生的多機房統(tǒng)一資源湖 —— ResLake
ResLake 是基于云原生的多機房統(tǒng)一資源湖，統(tǒng)一管理全局計算、存儲、網(wǎng)絡(luò)資源，并提供全局容災(zāi)能力。
數(shù)據(jù)中心通常存在多個機房，每個機房也存在多個集群，而每個集群上都存在不同隊列。用戶面對不同機房、不同集群的多個隊列，存在一定使用成本。
ResLake 提供了全局虛擬隊列。 每個虛擬隊列對應(yīng)不同機房或集群的多個隊列。用戶提交作業(yè)到虛擬隊列，ResLake 考慮資源情況、存儲親和性等因素，自動分發(fā)到合適的機房、集群和隊列。
另外，ResLake 還提供了全局 Quota 管控。 ResLake 在調(diào)度作業(yè)時，會考慮 Quota 約束、數(shù)據(jù)局部性、機房拓?fù)?、自定義約束等條件。
ResLake 優(yōu)先調(diào)度作業(yè)到和存儲資源更“近”的計算隊列。這里的“近”，包括同一個集群、同一個集群，或者網(wǎng)絡(luò)通信開銷較小的不同機房。
ResLake 還支持管理和調(diào)度存儲資源：
- 針對周期性作業(yè)，ResLake 提交將存儲資源搬遷到計算隊列所在的機房；
- 針對臨時查詢，如果存在跨機房讀取存儲數(shù)據(jù)，ResLake 將存儲資源緩存在目的機房一段時間。
全局的計算和存儲資源調(diào)度，可以避免大規(guī)?？鐧C房網(wǎng)絡(luò)通信，達(dá)成“最優(yōu)化資源利用率。最小化作業(yè)完成時間”的最終調(diào)度目的。
ResLake 支持分發(fā)作業(yè)到具體的集群和隊列 ：
- 支持一個作業(yè)全部分發(fā)到同一個隊列；
- 支持一個作業(yè)的不同實例按照指定比例或者指定數(shù)量分發(fā)到不同隊列，包括同集群、同機房的不同集群、不同機房的隊列等。
結(jié)合上述分發(fā)策略，ResLake 提供三種容災(zāi)能力：
- 遷移容災(zāi) ：
- 災(zāi)難發(fā)生后，自動重新提交作業(yè)到備用隊列；
- 備用集群資源不足時，自動殺死低優(yōu)作業(yè)以騰出資源；
- 多活容災(zāi) ： 基于多副本的輸入/輸出，在備用隊列啟動副本作業(yè)；
- 高可用容災(zāi) ： 基于作業(yè)自身 HA 能力，作業(yè)子實例被分發(fā)到兩個隊列同時運行。
4. 云原生大數(shù)據(jù)助力金融
火山引擎云原生大數(shù)據(jù)平臺致力于金融行業(yè)云原生大數(shù)據(jù)解決方案 ：
- Serverless YARN：基于云原生的 YARN 解決方案。
- Arcee Operator：基于云原生的大數(shù)據(jù)統(tǒng)一 Operator。
- GRO：基于云原生的高性能資源管理調(diào)度器。
- ResLake：基于云原生的多機房統(tǒng)一資源湖。
上述四個解決方案提供了精細(xì)強大的作業(yè)管理能力，高效極致的資源管理能力和跨機房作業(yè)容災(zāi)能力，幫助大數(shù)據(jù)作業(yè)平滑遷移到云原生系統(tǒng)。滿足用戶在硬件資源不增加的情況下承載更多業(yè)務(wù)，整體提升集群資源利用率。
