隨著行業的快速發展和業務的高速迭代，數據量也呈爆炸式增長，大數據云原生化逐漸成為企業數字化轉型的重要演進方向。數字化驅動企業提升運營效率，洞察商業機會；云原生化提升 IT 系統效率，促進業務敏捷，大數據云原生化是為企業創新提供無限可能。

大勢所趨：云原生大數據

傳統的大數據架構在資源利用、高效運維、可觀測性等方面存在諸多不足，已經越來越無法適應當下的發展需求。具體來講，傳統大數據架構主要存在以下幾方面的問題：

1. 傳統大數據組件繁多，安裝運維復雜，在生產使用中需要大量的人力支持；
2. 在線業務和大數據業務各自使用獨立的資源池，使得資源流轉困難，利用率低，成本上升；
3. 傳統大數據架構沒有 CICD 機制，缺少測試和質量控制流程；
4. 傳統大數據缺少開箱即用的高可用、多租戶、日志、監控、告警、認識、授權、審計、計費等能力。

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

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

“3+1”架構模式：三大平臺一大支撐體系

云原生大數據平臺的功能架構可以總結為“三大平臺和一大支撐體系”。三大平臺分別是平臺服務層、核心引擎層和資源調度層：

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

平臺服務層

平臺服務層由開源組件插件化集成，靈活配置選用，這是整個平臺架構的一個關鍵設計。

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

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

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

核心引擎層

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

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

在存儲方面，采取統一存儲，兼容HDFS 語義，支持 TOS 透明加速、緩存加速和數據湖管理。

1、自動調優

大數據向云原生發展需要推動計算引擎與云原生深度融合，向著自動調優方向演進。從我們的經驗來看，這個過程可分為四個階段：

?第一階段

    ?部署和管理 K8s 集群

    ?應用自己管理容器和鏡像

?第二階段

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

    ?資源混部：在離線作業共享集群資源

       ?只關注作業資源的額度和并行度

    ?平滑演進：YARN 作業和 K8s 作業混部

?第三階段

    ?虛擬隊列：支持跨集群和機房作業自動調度

    ?利用閑置資源：利用超發和驅逐機制利用空閑資源

    ?引擎半自動調優：利用智能團隊推薦任務配置參數，人工確認下發

?第四階段（也是當前的終極目標）

    ?全局自動容災：實現跨機房自動調度和容災

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

    ?引擎自動調優：混合不使用 AI 技術優化使用資源，包括計算網絡和內存

2、存算分離

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

統一管理和調度：

?統一數據權限，降低安全風險：資源池包括數據，要有統一的權限和安全管理，降低安全風險；

?統一資源調度和復用：資源池也需要統一的資源調度和復用，比如當進行了統一存儲后，在不同業務進行復用時，我們可以進行統一的調度。

存儲能力共用：

?統一數據 Copy，減少數據卸載：數據任務經常出錯，同步也會耗費資源，當任務同步出錯時，定位很難，也非常耗費人力，所以要盡量減少數據卸載；

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

存算分離負載：

?降低擴縮容和數據 Rebalance 時間：云原生數據湖、數據倉、消息隊列、搜索引擎如果支持存算分離的部署模式，將存儲放在統一的大數據文件存儲或對象存儲上，這樣可以降低擴縮容和數據 Rebalance 時間；

?增強對請求響應能力：將存儲放在統一的大數據文件存儲或對象存儲上，也可以增強對請求的響應能力。

資源調度層

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

?多云部署和調度：提供跨云的額度管理（統一的 Quota），可以實現高可用；

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

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

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

傳統的資源調度系統向云原生演進，有兩種并行的方式，可供二選一：

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

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

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

在調度層面，實現云原生化需要做的兩件事情：

1、統一資源池

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

?隊列屬性：設置資源池 Min-Max 屬性

?更強的調度策略：任務優先級調度、GANG 調度和 DRF 調度（GANG 調度策略保證一個作業的所有容器一起被調度，DRF 算法保證公平地將資源分配給資源池內的各個作業）

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

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

2、全局資源湖

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

?不限機房、不限集群，以最優化資源利用率為最終的調度目標

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

運維管理平臺

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

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

?全鏈路監測：可以全鏈路地監測每個服務的運行狀態，包括調用鏈、調用關系等，從而可以在故障時定位到具體出問題的調用環節；

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

?服務生命周期管理：通過統一可視化的管理界面，提供服務組件的渲染、發布和狀態管理服務。

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

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

混合部署提升資源利用率

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

由于不同業務場景對于底層資源響應的核心指標不同，對底層資源的優化需求也會存在區別。如果要滿足這些不同場景的業務指標要求，在混部的時候就要有重點地進行對應的優化。以下是混部的兩個典型場景：

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

2.APP 實時調用和大數據場景的混部。在上圖提到的5個場景中，右側4個都是大數據場景。大數據場景可以和 APP 實時調用場景進行資源復用——當APP 在線資源使用量較少時，可以出讓給大數據場景使用，反之亦然。

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

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

多云部署實現多云成本最優復用

在多云的用戶場景下，我們可以提供多云部署和調度，實現多云成本最優復用和跨云隊列容災：

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

作者簡介：遲慧

火山引擎云原生計算自身產品專家，負責火山引擎云原生大數據平臺相關產品工作，具有多年的大數據開發平臺、大數據治理平臺的產品經驗。