隨著行業(yè)的快速發(fā)展和業(yè)務(wù)的高速迭代，數(shù)據(jù)量也呈爆炸式增長，大數(shù)據(jù)云原生化逐漸成為企業(yè)數(shù)字化轉(zhuǎn)型的重要演進方向。數(shù)字化驅(qū)動企業(yè)提升運營效率，洞察商業(yè)機會；云原生化提升 IT 系統(tǒng)效率，促進業(yè)務(wù)敏捷，大數(shù)據(jù)云原生化是為企業(yè)創(chuàng)新提供無限可能。

大勢所趨：云原生大數(shù)據(jù)

傳統(tǒng)的大數(shù)據(jù)架構(gòu)在資源利用、高效運維、可觀測性等方面存在諸多不足，已經(jīng)越來越無法適應(yīng)當(dāng)下的發(fā)展需求。具體來講，傳統(tǒng)大數(shù)據(jù)架構(gòu)主要存在以下幾方面的問題：

1. 傳統(tǒng)大數(shù)據(jù)組件繁多，安裝運維復(fù)雜，在生產(chǎn)使用中需要大量的人力支持；
2. 在線業(yè)務(wù)和大數(shù)據(jù)業(yè)務(wù)各自使用獨立的資源池，使得資源流轉(zhuǎn)困難，利用率低，成本上升；
3. 傳統(tǒng)大數(shù)據(jù)架構(gòu)沒有 CICD 機制，缺少測試和質(zhì)量控制流程；
4. 傳統(tǒng)大數(shù)據(jù)缺少開箱即用的高可用、多租戶、日志、監(jiān)控、告警、認識、授權(quán)、審計、計費等能力。

云原生大數(shù)據(jù)是大數(shù)據(jù)平臺新一代架構(gòu)和運行形態(tài)，是一種以平臺云原生化部署、計算云原生調(diào)度、存儲統(tǒng)一負載為特點，可以支持多種計算負載，計算調(diào)度更彈性，存儲效能更高的大數(shù)據(jù)處理和分析平臺。云原生大數(shù)據(jù)帶來了大數(shù)據(jù)在使用和運維方面的巨大變化，從以下三個角度來看：

• 業(yè)務(wù)層面：傳統(tǒng)模式下，業(yè)務(wù)獨立占用資源，在業(yè)務(wù)高峰時段占用全部資源，但在低谷時段資源占用率可能只有20%-30%；云原生模式下的業(yè)務(wù)是混部的，比如在線和離線業(yè)務(wù)，它可以按分時復(fù)用的方式來調(diào)用資源。
• 資源調(diào)度層面：在傳統(tǒng)模式下，如果一個Flink 集群有100臺機器，那這100臺機器就由它獨占；云原生模式虛擬化出了資源池的概念。資源池可以承載不同類型的大數(shù)據(jù)集群，可以裝 Flink 集群，也可以裝 Spark 集群，而且這些集群都是按需拉起的，可以迅速回收，在不需要時可以釋放掉。
• 統(tǒng)一部署和運維安裝：原來的運維方式是每個集群要運維每個自己集群的狀態(tài)，出現(xiàn)集群之間的時延或者故障時，問題定位比較復(fù)雜。而云原生有統(tǒng)一的服務(wù)管理界面，以 Helm Chart 或 Operator 的形式，統(tǒng)一對服務(wù)進行發(fā)布、運維。這樣，出現(xiàn)問題時，我們可以通過統(tǒng)一的界面進行查看和管理，監(jiān)控告警日志也是和 K8s Pod（進程） 的采集、Node 采集相統(tǒng)一的，在監(jiān)控告警上，我們既可以看到 K8s 的節(jié)點和容器，也可以看到服務(wù)的運行狀態(tài)。

“3+1”架構(gòu)模式：三大平臺一大支撐體系

云原生大數(shù)據(jù)平臺的功能架構(gòu)可以總結(jié)為“三大平臺和一大支撐體系”。三大平臺分別是平臺服務(wù)層、核心引擎層和資源調(diào)度層：

• 平臺服務(wù)層由開源組件插件化集成，支持靈活配置選用；
• 核心引擎層包括 Flink、Spark、云原生消息引擎、實時服務(wù)分析引擎、云原生日志搜索和統(tǒng)一存儲 HDFS 等核心組件，支持存算分離和自動調(diào)優(yōu)；
• 資源調(diào)度層支持統(tǒng)一計算資源調(diào)度和統(tǒng)一引擎云原生生命周期管理。
• 一大支撐體系是運維管理平臺，是集開源組件、服務(wù)生命周期、集群、容災(zāi)、可觀測性于一體的一站式管理平臺。

平臺服務(wù)層

平臺服務(wù)層由開源組件插件化集成，靈活配置選用，這是整個平臺架構(gòu)的一個關(guān)鍵設(shè)計。

為了尊重現(xiàn)有用戶使用習(xí)慣，將用戶習(xí)慣使用的開源組件以插件化的形式進行了集成。現(xiàn)有主流的大數(shù)據(jù)工作場景主要包括信息門戶、數(shù)據(jù)工程和數(shù)據(jù)科學(xué)三種，每個場景下都有許多用戶常用的開源組件：

• 信息門戶：一般是 BI 報表類，如Superset、Apache Ranger 等；
• 數(shù)據(jù)工程：一般是大數(shù)據(jù)開發(fā)工程師、數(shù)倉工程師，做數(shù)據(jù)開發(fā)、數(shù)據(jù) ETL、數(shù)據(jù)處理、清洗所用到的組件，如使用 Zeppelin Notebook 做數(shù)據(jù)開發(fā)，對接數(shù)據(jù)治理平臺、調(diào)度平臺；
• 數(shù)據(jù)科學(xué)：一般適用于 AI 場景，如 Jupyter、Ray等；

上述三個場景是大數(shù)據(jù)工作中非常常見的場景，云原生大數(shù)據(jù)平臺通過插件化的方式集成這些開源組件，即開即用，具備極大的便捷性和靈活性。

核心引擎層

核心引擎層具備了存算分離的特點。

在計算方面，集成主流大數(shù)據(jù)計算引擎包括 Flink、Spark，同時集成了云原生消息中間件、實時服務(wù)分析引擎和云原生日志搜索服務(wù)；

在存儲方面，采取統(tǒng)一存儲，兼容HDFS 語義，支持 TOS 透明加速、緩存加速和數(shù)據(jù)湖管理。

1、自動調(diào)優(yōu)

大數(shù)據(jù)向云原生發(fā)展需要推動計算引擎與云原生深度融合，向著自動調(diào)優(yōu)方向演進。從我們的經(jīng)驗來看，這個過程可分為四個階段：

?第一階段

    ?部署和管理 K8s 集群

    ?應(yīng)用自己管理容器和鏡像

?第二階段

    ?資源池化：對底層 K8s 資源無感知

    ?資源混部：在離線作業(yè)共享集群資源

       ?只關(guān)注作業(yè)資源的額度和并行度

    ?平滑演進：YARN 作業(yè)和 K8s 作業(yè)混部

?第三階段

    ?虛擬隊列：支持跨集群和機房作業(yè)自動調(diào)度

    ?利用閑置資源：利用超發(fā)和驅(qū)逐機制利用空閑資源

    ?引擎半自動調(diào)優(yōu)：利用智能團隊推薦任務(wù)配置參數(shù)，人工確認下發(fā)

?第四階段（也是當(dāng)前的終極目標(biāo)）

    ?全局自動容災(zāi)：實現(xiàn)跨機房自動調(diào)度和容災(zāi)

    ?資源自動優(yōu)化：沒有負載的時候資源使用可以減低到0；毫秒級的冷啟動延時

    ?引擎自動調(diào)優(yōu)：混合不使用 AI 技術(shù)優(yōu)化使用資源，包括計算網(wǎng)絡(luò)和內(nèi)存

2、存算分離

云原生化具體工作主要包括了三個部分：

統(tǒng)一管理和調(diào)度：

?統(tǒng)一數(shù)據(jù)權(quán)限，降低安全風(fēng)險：資源池包括數(shù)據(jù)，要有統(tǒng)一的權(quán)限和安全管理，降低安全風(fēng)險；

?統(tǒng)一資源調(diào)度和復(fù)用：資源池也需要統(tǒng)一的資源調(diào)度和復(fù)用，比如當(dāng)進行了統(tǒng)一存儲后，在不同業(yè)務(wù)進行復(fù)用時，我們可以進行統(tǒng)一的調(diào)度。

存儲能力共用：

?統(tǒng)一數(shù)據(jù) Copy，減少數(shù)據(jù)卸載：數(shù)據(jù)任務(wù)經(jīng)常出錯，同步也會耗費資源，當(dāng)任務(wù)同步出錯時，定位很難，也非常耗費人力，所以要盡量減少數(shù)據(jù)卸載；

?統(tǒng)一數(shù)據(jù)容災(zāi)，保證高可靠要求：支持多種存算分離的部署形態(tài)，既可以完全分為計算、存儲兩個集群，也可以將計算和存儲混部在一個 K8s 集群上，但此時計算存儲是單獨管理的。

存算分離負載：

?降低擴縮容和數(shù)據(jù) Rebalance 時間：云原生數(shù)據(jù)湖、數(shù)據(jù)倉、消息隊列、搜索引擎如果支持存算分離的部署模式，將存儲放在統(tǒng)一的大數(shù)據(jù)文件存儲或?qū)ο蟠鎯ι希@樣可以降低擴縮容和數(shù)據(jù) Rebalance 時間；

?增強對請求響應(yīng)能力：將存儲放在統(tǒng)一的大數(shù)據(jù)文件存儲或?qū)ο蟠鎯ι?，也可以增強對請求的響?yīng)能力。

資源調(diào)度層

資源調(diào)度層主要起到統(tǒng)一計算資源調(diào)度，統(tǒng)一引擎云原生生命周期管理的作用，包含以下四個模塊：

?多云部署和調(diào)度：提供跨云的額度管理（統(tǒng)一的 Quota），可以實現(xiàn)高可用；

?統(tǒng)一資源池：支持計算統(tǒng)一負載，支持在離線混部；

?云原生 YARN ：兼容 YARN 資源負載，平滑遷移現(xiàn)有的 Hadoop 的負載；

?云原生 Operator：用 Helm Chart 管理整個引擎的云原生生命周期。

傳統(tǒng)的資源調(diào)度系統(tǒng)向云原生演進，有兩種并行的方式，可供二選一：

?Serverless YARN：從上圖可以看到，Resource Manager、Node Manager、Application Master 是 YARN 的三大組件。本方案是在 Resource Manager 中進行修改，增加了新的組件。經(jīng)過這樣改造之后，對于客戶來說，新系統(tǒng)仍保持了通過 YARN Client 提交作業(yè)的使用方式，只是在 Resource Manager 這一層做了封裝調(diào)度，讓用戶把作業(yè)直接提交到 API Server，而這個 API Server 其實是 K8s 的 API Server。也就是說，通過對 YARN 的 Resource Manager 進行改造，可以讓原來使用 YARN 來提交資源請求的業(yè)務(wù)，平滑地把業(yè)務(wù)提交到 K8s 上。

?云原生 Operator：這種方案是針對現(xiàn)有大數(shù)據(jù)組件的云原生化部署，把 Flink、 Spark 等計算引擎以Cloud Native （云原生）的方式部署到 K8s 上。這種方案的好處有兩個，第一是可以通過 Operator 對計算引擎進行全生命周期的管理，幫助用戶進行更優(yōu)的批量作業(yè)重啟策略；第二是云原生和 K8s 融合得更好，它可以更精細地采集 Pod 上的日志，跟蹤整個大數(shù)據(jù)的引擎和作業(yè)的運行狀態(tài)。

統(tǒng)一資源池（左圖）；支持跨集群、跨機房、跨地域的全局資源湖（右圖）

在調(diào)度層面，實現(xiàn)云原生化需要做的兩件事情：

1、統(tǒng)一資源池

對于虛擬的資源池的概念，我們認為它需要一些基本的要求，包括：

?隊列屬性：設(shè)置資源池 Min-Max 屬性

?更強的調(diào)度策略：任務(wù)優(yōu)先級調(diào)度、GANG 調(diào)度和 DRF 調(diào)度（GANG 調(diào)度策略保證一個作業(yè)的所有容器一起被調(diào)度，DRF 算法保證公平地將資源分配給資源池內(nèi)的各個作業(yè)）

?更好的隔離控制：限制每個 Pod 的 CPU 時間片和內(nèi)存使用量

?更靈活的資源使用方式：空閑資源利用和隊列搶占

2、全局資源湖

?ResLake 具有資源的全局視圖、全局資源池和 Quota 管控

?不限機房、不限集群，以最優(yōu)化資源利用率為最終的調(diào)度目標(biāo)

例如，當(dāng)前在集群 A 有一個資源池，在集群 B 有一個資源池，為了容災(zāi)的需求，我們可能把這兩個資源池作為一個主備的資源池，抽象出來一個虛擬隊列的概念。這樣在任務(wù)提交時，用戶就可以不關(guān)注資源池，只提交到虛擬隊列上即可，至于分配到 A 集群/機房還是分配到 B 集群/機房，會自動根據(jù)下面集群/機房的運行狀態(tài)來判斷。

運維管理平臺

集開源組件、服務(wù)生命周期、集群、容災(zāi)、可觀測性于一體的一站式管理平臺。

大數(shù)據(jù)平臺應(yīng)當(dāng)具備可觀測性、開源組件管理、服務(wù)生命周期管理、集群管理、容災(zāi)管理的功能和服務(wù)，圖中標(biāo)藍部分是云原生計算進行了特別增強的部分，下面來重點闡述一下：

?全鏈路監(jiān)測：可以全鏈路地監(jiān)測每個服務(wù)的運行狀態(tài)，包括調(diào)用鏈、調(diào)用關(guān)系等，從而可以在故障時定位到具體出問題的調(diào)用環(huán)節(jié)；

?開源組件管理：通過 Helm Chart 來對組件進行部署，通過 Operator 對運行組件進行整個生命周期的管理，包括開始、終止、清理等一系列操作。因此，開源組件管理是從 K8s 平臺上對引擎或特定的開源組件，甚至是任務(wù)進行管理的特殊模式，這個模式的優(yōu)勢是更快捷和更細粒度。

?服務(wù)生命周期管理：通過統(tǒng)一可視化的管理界面，提供服務(wù)組件的渲染、發(fā)布和狀態(tài)管理服務(wù)。

?集群管理：除集群擴縮容、集群信息統(tǒng)計外，為了更好地監(jiān)控整個的作業(yè)運行狀態(tài)和服務(wù)運行狀態(tài)，往往需要更細粒度地采集容器日志，所以我們對這部分進行了增強。另外，為了定位容器之間的運行狀態(tài)，我們提供通過 Web Shell 登錄到 Pod 中，以命令行的形式輸入 Linux 指令，在瀏覽器上直接操作作業(yè)運行環(huán)境的服務(wù)，類似于在本地終端操作遠程服務(wù)器，這對作業(yè)開發(fā)以及問題定位來說是一個非常實用的工具。

降本增效：用戶場景與價值

混合部署提升資源利用率

在混部的用戶場景下，云原生大數(shù)據(jù)平臺支持很多的業(yè)務(wù)場景，包括在線、流式、離線、查詢分析和批處理等。

由于不同業(yè)務(wù)場景對于底層資源響應(yīng)的核心指標(biāo)不同，對底層資源的優(yōu)化需求也會存在區(qū)別。如果要滿足這些不同場景的業(yè)務(wù)指標(biāo)要求，在混部的時候就要有重點地進行對應(yīng)的優(yōu)化。以下是混部的兩個典型場景：

1. Flink 和 Spark 的混部。即 Flink 不使用資源，或負載低的時候，資源可以出讓給 Spark，Spark 執(zhí)行完批式計算后，空閑的資源也可以出讓給流式計算（Flink）用。

2.APP 實時調(diào)用和大數(shù)據(jù)場景的混部。在上圖提到的5個場景中，右側(cè)4個都是大數(shù)據(jù)場景。大數(shù)據(jù)場景可以和 APP 實時調(diào)用場景進行資源復(fù)用——當(dāng)APP 在線資源使用量較少時，可以出讓給大數(shù)據(jù)場景使用，反之亦然。

以字節(jié)跳動為例，我們在通過這樣多種計算資源混合部署調(diào)度之后，獲得了不俗的收益。

• 首先是高效的資源切換，可以做到數(shù)萬核離線資源分鐘級出讓。如在2022年春節(jié)時，抖音在線資源需求量非常高，我們將離線資源以分鐘級出讓了數(shù)十萬核給在線資源使用。而當(dāng)遇到某些突發(fā)社會熱點導(dǎo)致的極端彈性場景時，高效的資源切換甚至可以成為業(yè)務(wù)的“保命利器”。
• 其次是利用率的提升，通過混部，可以降低整體公用的開銷，在字節(jié)跳動內(nèi)部帶來2% 的利用率提升；
• 最后是在離線資源的統(tǒng)一管理，在離線資源全量共池，可以實現(xiàn) Quota 管控、調(diào)度、運行、機器運維統(tǒng)一。

多云部署實現(xiàn)多云成本最優(yōu)復(fù)用

在多云的用戶場景下，我們可以提供多云部署和調(diào)度，實現(xiàn)多云成本最優(yōu)復(fù)用和跨云隊列容災(zāi)：

• 提供全局虛擬隊列：在用戶使用多云的場景下，首先需要提供一個全局虛擬隊列的概念。如上圖，一個虛擬隊列就是一個資源池，下面對應(yīng)不同的兩個物理資源池。用戶在提交的時候，不需要關(guān)注實際對應(yīng)的集群，而是提交到一個虛擬隊列上，下層會針對作業(yè)進行相應(yīng)的調(diào)度，自動分發(fā)到合適的集群/機房/隊列上，能夠有效提升容災(zāi)能力。
• 應(yīng)用按多因子綜合選擇流量分配：多云部署的另一個好處是可以通過多種因素的綜合考慮來選擇流量分配。比如在一個多云場景下，AZ1 理解為廠商1，AZ2 是廠商2，現(xiàn)在發(fā)現(xiàn)使用同樣多的 CU，在廠商2上比在廠商1上貴50%，那就可以通過多云調(diào)度把流量盡量分發(fā)到廠商1上。這是從成本角度考慮的一種情況，當(dāng)然還可能存在雖然成本降低，但經(jīng)常宕機，響應(yīng)時間較長，任務(wù)狀態(tài)出錯率高的情況，那就需要把重要的應(yīng)用放到各方面指標(biāo)較好的機房里，總的來說就是通過多種因子的綜合考量進行流量分配。在多云部署場景下，幫助用戶實現(xiàn)多云成本的最優(yōu)復(fù)用。

作者簡介：遲慧

火山引擎云原生計算自身產(chǎn)品專家，負責(zé)火山引擎云原生大數(shù)據(jù)平臺相關(guān)產(chǎn)品工作，具有多年的大數(shù)據(jù)開發(fā)平臺、大數(shù)據(jù)治理平臺的產(chǎn)品經(jīng)驗。