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

隨著行業(yè)的快速發(fā)展和業(yè)務(wù)的高速迭代，數(shù)據(jù)量也呈爆炸式增長，傳統(tǒng)的大數(shù)據(jù)架構(gòu)在資源利用、高效運(yùn)維、可觀測性等方面存在諸多不足，已經(jīng)越來越無法適應(yīng)當(dāng)下的發(fā)展需求。具體來講，傳統(tǒng)大數(shù)據(jù)架構(gòu)主要存在以下幾方面的問題：

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

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

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

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

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

• 平臺服務(wù)層由開源組件插件化集成，支持靈活配置選用；
• 核心引擎層包括 Flink、Spark、云原生消息引擎、實(shí)時(shí)服務(wù)分析引擎、云原生日志搜索和統(tǒng)一存儲 HDFS 等核心組件，支持存算分離和自動調(diào)優(yōu)；
• 資源調(diào)度層支持統(tǒng)一計(jì)算資源調(diào)度和統(tǒng)一引擎云原生生命周期管理。

一大支撐體系是運(yùn)維管理平臺，是集開源組件、服務(wù)生命周期、集群、容災(zāi)、可觀測性于一體的一站式管理平臺。

1. 平臺服務(wù)層

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

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

• 信息門戶：? 一般是 BI 報(bào)表類，如 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等；

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

2. 核心引擎層

核心引擎層具備了存算分離的特點(diǎn)。

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

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

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

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

• 第一階段

#部署和管理 K8s 集群

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

• 第二階段

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

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

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

      #平滑演進(jìn)：YARN 作業(yè)和 K8s 作業(yè)混部

• 第三階段

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

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

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

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

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

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

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

存算分離

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

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

• 統(tǒng)一數(shù)據(jù)權(quán)限，降低安全風(fēng)險(xiǎn)：資源池包括數(shù)據(jù)，要有統(tǒng)一的權(quán)限和安全管理，降低安全風(fēng)險(xiǎn)；
• 統(tǒng)一資源調(diào)度和復(fù)用：資源池也需要統(tǒng)一的資源調(diào)度和復(fù)用，比如當(dāng)進(jìn)行了統(tǒng)一存儲后，在不同業(yè)務(wù)進(jìn)行復(fù)用時(shí)，我們可以進(jìn)行統(tǒng)一的調(diào)度。

存儲能力共用：

• 統(tǒng)一數(shù)據(jù) Copy，減少數(shù)據(jù)卸載：數(shù)據(jù)任務(wù)經(jīng)常出錯(cuò)，同步也會耗費(fèi)資源，當(dāng)任務(wù)同步出錯(cuò)時(shí)，定位很難，也非常耗費(fèi)人力，所以要盡量減少數(shù)據(jù)卸載；
• 統(tǒng)一數(shù)據(jù)容災(zāi)，保證高可靠要求：支持多種存算分離的部署形態(tài)，既可以完全分為計(jì)算、存儲兩個(gè)集群，也可以將計(jì)算和存儲混部在一個(gè) K8s 集群上，但此時(shí)計(jì)算存儲是單獨(dú)管理的。

存算分離負(fù)載：

• 降低擴(kuò)縮容和數(shù)據(jù) Rebalance 時(shí)間：云原生數(shù)據(jù)湖、數(shù)據(jù)倉、消息隊(duì)列、搜索引擎如果支持存算分離的部署模式，將存儲放在統(tǒng)一的大數(shù)據(jù)文件存儲或?qū)ο蟠鎯ι希@樣可以降低擴(kuò)縮容和數(shù)據(jù) Rebalance 時(shí)間；
• 增強(qiáng)對請求響應(yīng)能力：將存儲放在統(tǒng)一的大數(shù)據(jù)文件存儲或?qū)ο蟠鎯ι希部梢栽鰪?qiáng)對請求的響應(yīng)能力。

3. 資源調(diào)度層

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

• 多云部署和調(diào)度：提供跨云的額度管理（統(tǒng)一的 Quota），可以實(shí)現(xiàn)高可用；
• 統(tǒng)一資源池：支持計(jì)算統(tǒng)一負(fù)載，支持在離線混部；
• 云原生 YARN ：兼容 YARN 資源負(fù)載，平滑遷移現(xiàn)有的 Hadoop 的負(fù)載；
• 云原生 Operator：用 Helm Chart 管理整個(gè)引擎的云原生生命周期。

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

• Serverless YARN：從上圖可以看到，Resource Manager、Node Manager、Application Master 是 YARN 的三大組件。本方案是在 Resource Manager 中進(jìn)行修改，增加了新的組件。經(jīng)過這樣改造之后，對于客戶來說，新系統(tǒng)仍保持了通過 YARN Client 提交作業(yè)的使用方式，只是在 Resource Manager 這一層做了封裝調(diào)度，讓用戶把作業(yè)直接提交到 API Server，而這個(gè) API Server 其實(shí)是 K8s 的 API Server。也就是說，通過對 YARN 的 Resource Manager 進(jìn)行改造，可以讓原來使用 YARN 來提交資源請求的業(yè)務(wù)，平滑地把業(yè)務(wù)提交到 K8s 上 。?
• 云原生 Operator：這種方案是針對現(xiàn)有大數(shù)據(jù)組件的云原生化部署，把 Flink、 Spark 等計(jì)算引擎以 Cloud Native （云原生）的方式部署到 K8s 上。這種方案的好處有兩個(gè)，第一是可以通過 Operator 對計(jì)算引擎進(jìn)行全生命周期的管理，幫助用戶進(jìn)行更優(yōu)的批量作業(yè)重啟策略；第二是云原生和 K8s 融合得更好，它可以更精細(xì)地采集 Pod 上的日志，跟蹤整個(gè)大數(shù)據(jù)的引擎和作業(yè)的運(yùn)行狀態(tài)。

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

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

統(tǒng)一資源池

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

• 隊(duì)列屬性：設(shè)置資源池 Min-Max 屬性
• 更強(qiáng)的調(diào)度策略：任務(wù)優(yōu)先級調(diào)度、GANG 調(diào)度和 DRF 調(diào)度（GANG 調(diào)度策略保證一個(gè)作業(yè)的所有容器一起被調(diào)度，DRF 算法保證公平地將資源分配給資源池內(nèi)的各個(gè)作業(yè)）
• 更好的隔離控制：限制每個(gè) Pod 的 CPU 時(shí)間片和內(nèi)存使用量
• 更靈活的資源使用方式：空閑資源利用和隊(duì)列搶占

全局資源湖

• ResLake 具有資源的全局視圖、全局資源池和 Quota 管控
• 不限機(jī)房、不限集群，以最優(yōu)化資源利用率為最終的調(diào)度目標(biāo)

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

4. 運(yùn)維管理平臺

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

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

• 全鏈路監(jiān)測：可以全鏈路地監(jiān)測每個(gè)服務(wù)的運(yùn)行狀態(tài)，包括調(diào)用鏈、調(diào)用關(guān)系等，從而可以在故障時(shí)定位到具體出問題的調(diào)用環(huán)節(jié)；
• 開源組件管理：通過 Helm Chart 來對組件進(jìn)行部署，通過 Operator 對運(yùn)行組件進(jìn)行整個(gè)生命周期的管理，包括開始、終止、清理等一系列操作。因此，開源組件管理是從 K8s 平臺上對引擎或特定的開源組件，甚至是任務(wù)進(jìn)行管理的特殊模式，這個(gè)模式的優(yōu)勢是更快捷和更細(xì)粒度。
• 服務(wù)生命周期管理：通過統(tǒng)一可視化的管理界面，提供服務(wù)組件的渲染、發(fā)布和狀態(tài)管理服務(wù)。
• 集群管理：除集群擴(kuò)縮容、集群信息統(tǒng)計(jì)外，為了更好地監(jiān)控整個(gè)的作業(yè)運(yùn)行狀態(tài)和服務(wù)運(yùn)行狀態(tài)，往往需要更細(xì)粒度地采集容器日志，所以我們對這部分進(jìn)行了增強(qiáng)。另外，為了定位容器之間的運(yùn)行狀態(tài)，我們提供通過 Web Shell 登錄到 Pod 中，以命令行的形式輸入 Linux 指令，在瀏覽器上直接操作作業(yè)運(yùn)行環(huán)境的服務(wù)，類似于在本地終端操作遠(yuǎn)程服務(wù)器，這對作業(yè)開發(fā)以及問題定位來說是一個(gè)非常實(shí)用的工具。

三、降本增效：用戶場景與價(jià)值

1. 混合部署提升資源利用率

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

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

1. Flink 和 Spark 的混部?。即 Flink 不使用資源，或負(fù)載低的時(shí)候，資源可以出讓給 Spark，Spark 執(zhí)行完批式計(jì)算后，空閑的資源也可以出讓給流式計(jì)算（Flink）用。
2. APP 實(shí)時(shí)調(diào)用和大數(shù)據(jù)場景的混部?。在上圖提到的5個(gè)場景中，右側(cè)4個(gè)都是大數(shù)據(jù)場景。大數(shù)據(jù)場景可以和 APP 實(shí)時(shí)調(diào)用場景進(jìn)行資源復(fù)用——當(dāng) APP 在線資源使用量較少時(shí)，可以出讓給大數(shù)據(jù)場景使用，反之亦然。

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

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

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

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

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