一文了解——雲原生大資料知識地圖

　　一、大勢所趨：雲原生大資料

　　隨著行業的快速發展和業務的高速迭代，資料量也呈爆炸式增長，傳統的大資料架構在資源利用、高效運維、可觀測性等方面存在諸多不足，已經越來越無法適應當下的發展需求。具體來講，傳統大資料架構主要存在以下幾方面的問題：

　　傳統大資料元件繁多，安裝運維複雜，在生產使用中需要大量的人力支援；

　　線上業務和大資料業務各自使用獨立的資源池，使得資源流轉困難，利用率低，成本上升；

　　傳統大資料架構沒有 CICD 機制，缺少測試和質量控制流程；

　　傳統大資料缺少開箱即用的高可用、多租戶、日誌、監控、告警、認識、授權、審計、計費等能力。　　

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

　　業務層面：傳統模式下，業務獨立佔用資源，在業務高峰時段佔用全部資源，但在低谷時段資源佔用率可能只有20%-30%；雲原生模式下的業務是混部的，比如線上和離線業務，它可以按分時複用的方式來呼叫資源。

　　資源排程層面：在傳統模式下，如果一個 Flink 叢集有100臺機器，那這100臺機器就由它獨佔；雲原生模式虛擬化出了資源池的概念。資源池可以承載不同型別的大資料叢集，可以裝 Flink 叢集，也可以裝 Spark 叢集，而且這些叢集都是按需拉起的，可以迅速回收，在不需要時可以釋放掉。

　　統一部署和運維安裝：原來的運維方式是每個叢集要運維每個自己叢集的狀態，出現叢集之間的時延或者故障時，問題定位比較複雜。而云原生有統一的服務管理介面，以 Helm Chart 或 Operator 的形式，統一對服務進行釋出、運維。這樣，出現問題時，我們可以透過統一的介面進行檢視和管理，監控告警日誌也是和 K8s Pod（程式） 的採集、Node 採集相統一的，在監控告警上，我們既可以看到 K8s 的節點和容器，也可以看到服務的執行狀態。

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

　　雲原生大資料平臺的功能架構可以總結為“三大平臺和一大支撐體系”。三大平臺分別是平臺服務層、核心引擎層和資源排程層。

　　平臺服務層由開源元件外掛化整合，支援靈活配置選用；

　　核心引擎層包括 Flink、Spark、雲原生訊息引擎、實時服務分析引擎、雲原生日誌搜尋和統一儲存 HDFS 等核心元件，支援存算分離和自動調優；

　　資源排程層支援統一計算資源排程和統一引擎雲原生生命週期管理。

　　一大支撐體系是運維管理平臺，是集開源元件、服務生命週期、叢集、容災、可觀測性於一體的一站式管理平臺。

　　1. 平臺服務層

　　平臺服務層由開源元件外掛化整合，靈活配置選用，這是整個平臺架構的一個關鍵設計。　　

　　為了尊重現有使用者使用習慣，將使用者習慣使用的開源元件以外掛化的形式進行了整合。現有主流的大資料工作場景主要包括資訊門戶、資料工程和資料科學三種，每個場景下都有許多使用者常用的開源元件：

　　資訊門戶： 一般是 BI 報表類，如 Superset、Apache Ranger 等；

　　資料工程： 一般是大資料開發工程師、數倉工程師，做資料開發、資料 ETL、資料處理、清洗所用到的元件，如使用 Zeppelin Notebook 做資料開發，對接資料治理平臺、排程平臺；

　　資料科學： 一般適用於 AI 場景，如 Jupyter、Ray等；

　　上述三個場景是大資料工作中非常常見的場景，雲原生大資料平臺透過外掛化的方式整合這些開源元件，即開即用，具備極大的便捷性和靈活性。

　　2. 核心引擎層

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

　　在計算方面，整合主流大資料計算引擎包括 Flink、Spark，同時整合了雲原生訊息中介軟體、實時服務分析引擎和雲原生日誌搜尋服務；

　　在儲存方面，採取統一儲存，相容 HDFS 語義，支援 TOS 透明加速、快取加速和資料湖管理。

　　自動調優

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

　　第一階段

　　部署和管理 K8s 叢集

　　應用自己管理容器和映象

　　第二階段

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

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

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

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

　　第三階段

　　虛擬佇列：支援跨叢集和機房作業自動排程

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

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

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

　　全域性自動容災：實現跨機房自動排程和容災

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

　　引擎自動調優：混合不使用 AI 技術最佳化使用資源，包括計算網路和記憶體

　　存算分離　　

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

　　統一管理和排程：

　　統一資料許可權，降低安全風險：資源池包括資料，要有統一的許可權和安全管理，降低安全風險；

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

　　儲存能力共用：

　　統一資料 Copy，減少資料解除安裝：資料任務經常出錯，同步也會耗費資源，當任務同步出錯時，定位很難，也非常耗費人力，所以要儘量減少資料解除安裝；

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

　　存算分離負載：

　　降低擴縮容和資料 Rebalance 時間：雲原生資料湖、資料倉、訊息佇列、搜尋引擎如果支援存算分離的部署模式，將儲存放在統一的大資料檔案儲存或物件儲存上，這樣可以降低擴縮容和資料 Rebalance 時間；

　　增強對請求響應能力：將儲存放在統一的大資料檔案儲存或物件儲存上，也可以增強對請求的響應能力。

　　3. 資源排程層

　　資源排程層主要起到統一計算資源排程，統一引擎雲原生生命週期管理的作用，包含以下四個模組：

　　多雲部署和排程：提供跨雲的額度管理（統一的 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 上的日誌，跟蹤整個大資料的引擎和作業的執行狀態。　　

　　統一資源池（左圖）；支援跨叢集、跨機房、跨地域的全域性資源湖（右圖）

　　在排程層面，實現雲原生化需要做的兩件事情：

　　統一資源池

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

　　佇列屬性：設定資源池 Min-Max 屬性

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

　　更好的隔離控制：限制每個 Pod 的 CPU 時間片和記憶體使用量

　　更靈活的資源使用方式：空閒資源利用和佇列搶佔

　　全域性資源湖

　　ResLake 具有資源的全域性檢視、全域性資源池和 Quota 管控

　　不限機房、不限叢集，以最最佳化資源利用率為最終的排程目標

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

　　4. 運維管理平臺

　　集開源元件、服務生命週期、叢集、容災、可觀測性於一體的一站式管理平臺。　　

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

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

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

　　服務生命週期管理：透過統一視覺化的管理介面，提供服務元件的渲染、釋出和狀態管理服務。

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

　　三、降本增效：使用者場景與價值

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

　　在混部的使用者場景下，雲原生大資料平臺支援很多的業務場景，包括線上、流式、離線、查詢分析和批處理等。

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

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

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

　　以位元組跳動為例，我們在透過這樣多種計算資源混合部署排程之後，獲得了不俗的收益。

　　首先是高效的資源切換，可以做到數萬核離線資源分鐘級出讓。如在2022年春節時，抖音線上資源需求量非常高，我們將離線資源以分鐘級出讓了數十萬核給線上資源使用。而當遇到某些突發社會熱點導致的極端彈性場景時，高效的資源切換甚至可以成為業務的“保命利器” 。

　　其次是利用率的提升，透過混部，可以降低整體公用的開銷，在位元組跳動內部帶來 2% 的利用率提升 ；

　　最後是在離線資源的統一管理，在離線資源全量共池，可以實現 Quota 管控、排程、執行、機器運維統一。

　　2. 多雲部署實現多雲成本最優複用　　

　　在多雲的使用者場景下，我們可以提供多雲部署和排程，實現多雲成本最優複用和跨雲佇列容災：

　　提供全域性虛擬佇列：在使用者使用多雲的場景下，首先需要提供一個全域性虛擬佇列的概念。如上圖，一個虛擬佇列就是一個資源池，下面對應不同的兩個物理資源池。使用者在提交的時候，不需要關注實際對應的叢集，而是提交到一個虛擬佇列上，下層會針對作業進行相應的排程，自動分發到合適的叢集/機房/佇列上，能夠有效提升容災能力。

　　應用按多因子綜合選擇流量分配：多雲部署的另一個好處是可以透過多種因素的綜合考慮來選擇流量分配。比如在一個多雲場景下，AZ1 理解為廠商1，AZ2 是廠商2，現在發現使用同樣多的 CU，在廠商2上比在廠商1上貴50%，那就可以透過多雲排程把流量儘量分發到廠商1上。這是從成本角度考慮的一種情況，當然還可能存在雖然成本降低，但經常當機，響應時間較長，任務狀態出錯率高的情況，那就需要把重要的應用放到各方面指標較好的機房裡，總的來說就是透過多種因子的綜合考量進行流量分配。在多雲部署場景下，幫助使用者實現多雲成本的最優複用。