2022年，火山引擎云原生計算團隊在云原生大數(shù)據(jù)領域進行了諸多探索與實踐�；诖�，云原生計算與 DataFun 聯(lián)合出品了云原生大數(shù)據(jù)知識地圖，從理念概述、架構介紹、功能詳述、場景及價值等方面對云原生大數(shù)據(jù)進行了詳細解讀。
01
大勢所趨：云原生大數(shù)據(jù)
隨著行業(yè)的快速發(fā)展和業(yè)務的高速迭代，數(shù)據(jù)量也呈爆炸式增長，傳統(tǒng)的大數(shù)據(jù)架構在資源利用、高效運維、可觀測性等方面存在諸多不足，已經(jīng)越來越無法適應當下的發(fā)展需求。具體來講，傳統(tǒng)大數(shù)據(jù)架構主要存在以下幾方面的問題：
傳統(tǒng)大數(shù)據(jù)組件繁多，安裝運維復雜，在生產(chǎn)使用中需要大量的人力支持;
在線業(yè)務和大數(shù)據(jù)業(yè)務各自使用獨立的資源池，使得資源流轉困難，利用率低，成本上升;
傳統(tǒng)大數(shù)據(jù)架構沒有 CICD 機制，缺少測試和質量控制流程;
傳統(tǒng)大數(shù)據(jù)缺少開箱即用的高可用、多租戶、日志、監(jiān)控、告警、認識、授權、審計、計費等能力。
云原生大數(shù)據(jù)是大數(shù)據(jù)平臺新一代架構和運行形態(tài)，是一種以平臺云原生化部署、計算云原生調度、存儲統(tǒng)一負載為特點，可以支持多種計算負載，計算調度更彈性，存儲效能更高的大數(shù)據(jù)處理和分析平臺。云原生大數(shù)據(jù)帶來了大數(shù)據(jù)在使用和運維方面的巨大變化，從以下三個角度來看：
業(yè)務層面：傳統(tǒng)模式下，業(yè)務獨立占用資源，在業(yè)務高峰時段占用全部資源，但在低谷時段資源占用率可能只有20%-30%;云原生模式下的業(yè)務是混部的，比如在線和離線業(yè)務，它可以按分時復用的方式來調用資源。
資源調度層面：在傳統(tǒng)模式下，如果一個 Flink 集群有100臺機器，那這100臺機器就由它獨占;云原生模式虛擬化出了資源池的概念。資源池可以承載不同類型的大數(shù)據(jù)集群，可以裝 Flink 集群，也可以裝 Spark 集群，而且這些集群都是按需拉起的，可以迅速回收，在不需要時可以釋放掉。
統(tǒng)一部署和運維安裝：原來的運維方式是每個集群要運維每個自己集群的狀態(tài)，出現(xiàn)集群之間的時延或者故障時，問題定位比較復雜。而云原生有統(tǒng)一的服務管理界面，以 Helm Chart 或 Operator 的形式，統(tǒng)一對服務進行發(fā)布、運維。這樣，出現(xiàn)問題時，我們可以通過統(tǒng)一的界面進行查看和管理，監(jiān)控告警日志也是和 K8s Pod(進程) 的采集、Node 采集相統(tǒng)一的，在監(jiān)控告警上，我們既可以看到 K8s 的節(jié)點和容器，也可以看到服務的運行狀態(tài)。
02
“3+1”架構模式：
三大平臺一大支撐體系
云原生大數(shù)據(jù)平臺的功能架構可以總結為“三大平臺和一大支撐體系”。三大平臺分別是平臺服務層、核心引擎層和資源調度層。
平臺服務層由開源組件插件化集成，支持靈活配置選用;
核心引擎層包括 Flink、Spark、云原生消息引擎、實時服務分析引擎、云原生日志搜索和統(tǒng)一存儲 HDFS 等核心組件，支持存算分離和自動調優(yōu);
資源調度層支持統(tǒng)一計算資源調度和統(tǒng)一引擎云原生生命周期管理。
一大支撐體系是運維管理平臺，是集開源組件、服務生命周期、集群、容災、可觀測性于一體的一站式管理平臺。
平臺服務層
平臺服務層由開源組件插件化集成，靈活配置選用，這是整個平臺架構的一個關鍵設計。
為了尊重現(xiàn)有用戶使用習慣，將用戶習慣使用的開源組件以插件化的形式進行了集成�，F(xiàn)有主流的大數(shù)據(jù)工作場景主要包括信息門戶、數(shù)據(jù)工程和數(shù)據(jù)科學三種，每個場景下都有許多用戶常用的開源組件：
信息門戶：一般是 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ù)治理平臺、調度平臺;
數(shù)據(jù)科學：一般適用于 AI 場景，如 Jupyter、Ray等;
上述三個場景是大數(shù)據(jù)工作中非常常見的場景，云原生大數(shù)據(jù)平臺通過插件化的方式集成這些開源組件，即開即用，具備極大的便捷性和靈活性。
核心引擎層
核心引擎層具備了存算分離的特點。
在計算方面，集成主流大數(shù)據(jù)計算引擎包括 Flink、Spark，同時集成了云原生消息中間件、實時服務分析引擎和云原生日志搜索服務;在存儲方面，采取統(tǒng)一存儲，兼容 HDFS 語義，支持 TOS 透明加速、緩存加速和數(shù)據(jù)湖管理。
自動調優(yōu)
大數(shù)據(jù)向云原生發(fā)展需要推動計算引擎與云原生深度融合，向著自動調優(yōu)方向演進。從我們的經(jīng)驗來看，這個過程可分為四個階段：
第一階段
部署和管理 K8s 集群
應用自己管理容器和鏡像
第二階段
資源池化：對底層 K8s 資源無感知
資源混部：在離線作業(yè)共享集群資源
只關注作業(yè)資源的額度和并行度
平滑演進：YARN 作業(yè)和 K8s 作業(yè)混部
第三階段
虛擬隊列：支持跨集群和機房作業(yè)自動調度
利用閑置資源：利用超發(fā)和驅逐機制利用空閑資源
引擎半自動調優(yōu)：利用智能團隊推薦任務配置參數(shù)，人工確認下發(fā)
第四階段(也是當前的終極目標)
全局自動容災：實現(xiàn)跨機房自動調度和容災
資源自動優(yōu)化：沒有負載的時候資源使用可以減低到0;毫秒級的冷啟動延時
引擎自動調優(yōu)：混合不使用 AI 技術優(yōu)化使用資源，包括計算網(wǎng)絡和內存
存算分離
云原生化具體工作主要包括了三個部分：統(tǒng)一管理和調度：
統(tǒng)一數(shù)據(jù)權限，降低安全風險：資源池包括數(shù)據(jù)，要有統(tǒng)一的權限和安全管理，降低安全風險;
統(tǒng)一資源調度和復用：資源池也需要統(tǒng)一的資源調度和復用，比如當進行了統(tǒng)一存儲后，在不同業(yè)務進行復用時，我們可以進行統(tǒng)一的調度。
存儲能力共用：
統(tǒng)一數(shù)據(jù) Copy，減少數(shù)據(jù)卸載：數(shù)據(jù)任務經(jīng)常出錯，同步也會耗費資源，當任務同步出錯時，定位很難，也非常耗費人力，所以要盡量減少數(shù)據(jù)卸載;
統(tǒng)一數(shù)據(jù)容災，保證高可靠要求：支持多種存算分離的部署形態(tài)，既可以完全分為計算、存儲兩個集群，也可以將計算和存儲混部在一個 K8s 集群上，但此時計算存儲是單獨管理的。
存算分離負載：
降低擴縮容和數(shù)據(jù) Rebalance 時間：云原生數(shù)據(jù)湖、數(shù)據(jù)倉、消息隊列、搜索引擎如果支持存算分離的部署模式，將存儲放在統(tǒng)一的大數(shù)據(jù)文件存儲或對象存儲上，這樣可以降低擴縮容和數(shù)據(jù) Rebalance 時間;
增強對請求響應能力：將存儲放在統(tǒng)一的大數(shù)據(jù)文件存儲或對象存儲上，也可以增強對請求的響應能力。
資源調度層
資源調度層主要起到統(tǒng)一計算資源調度，統(tǒng)一引擎云原生生命周期管理的作用，包含以下四個模塊：
多云部署和調度：提供跨云的額度管理(統(tǒng)一的 Quota)，可以實現(xiàn)高可用;
統(tǒng)一資源池：支持計算統(tǒng)一負載，支持在離線混部;
云原生 YARN ：兼容 YARN 資源負載，平滑遷移現(xiàn)有的 Hadoop 的負載;
云原生 Operator：用 Helm Chart 管理整個引擎的云原生生命周期。
傳統(tǒng)的資源調度系統(tǒng)向云原生演進，有兩種并行的方式，可供二選一：
Serverless YARN：從上圖可以看到，Resource Manager、Node Manager、Application Master 是 YARN 的三大組件。本方案是在 Resource Manager 中進行修改，增加了新的組件。經(jīng)過這樣改造之后，對于客戶來說，新系統(tǒng)仍保持了通過 YARN Client 提交作業(yè)的使用方式，只是在 Resource Manager 這一層做了封裝調度，讓用戶把作業(yè)直接提交到 API Server，而這個 API Server 其實是 K8s 的 API Server。也就是說，通過對 YARN 的 Resource Manager 進行改造，可以讓原來使用 YARN 來提交資源請求的業(yè)務，平滑地把業(yè)務提交到 K8s 上。
云原生 Operator：這種方案是針對現(xiàn)有大數(shù)據(jù)組件的云原生化部署，把 Flink、 Spark 等計算引擎以 Cloud Native (云原生)的方式部署到 K8s 上。這種方案的好處有兩個，第一是可以通過 Operator 對計算引擎進行全生命周期的管理，幫助用戶進行更優(yōu)的批量作業(yè)重啟策略;第二是云原生和 K8s 融合得更好，它可以更精細地采集 Pod 上的日志，跟蹤整個大數(shù)據(jù)的引擎和作業(yè)的運行狀態(tài)。
統(tǒng)一資源池(左圖);支持跨集群、跨機房、跨地域的全局資源湖(右圖)在調度層面，實現(xiàn)云原生化需要做的兩件事情：統(tǒng)一資源池對于虛擬的資源池的概念，我們認為它需要一些基本的要求，包括：
隊列屬性：設置資源池 Min-Max 屬性
更強的調度策略：任務優(yōu)先級調度、GANG 調度和 DRF 調度(GANG 調度策略保證一個作業(yè)的所有容器一起被調度，DRF 算法保證公平地將資源分配給資源池內的各個作業(yè))
更好的隔離控制：限制每個 Pod 的 CPU 時間片和內存使用量
更靈活的資源使用方式：空閑資源利用和隊列搶占
全局資源湖
ResLake 具有資源的全局視圖、全局資源池和 Quota 管控
不限機房、不限集群，以最優(yōu)化資源利用率為最終的調度目標
例如，當前在集群 A 有一個資源池，在集群 B 有一個資源池，為了容災的需求，我們可能把這兩個資源池作為一個主備的資源池，抽象出來一個虛擬隊列的概念。這樣在任務提交時，用戶就可以不關注資源池，只提交到虛擬隊列上即可，至于分配到 A 集群/機房還是分配到 B 集群/機房，會自動根據(jù)下面集群/機房的運行狀態(tài)來判斷。
運維管理平臺
集開源組件、服務生命周期、集群、容災、可觀測性于一體的一站式管理平臺。
大數(shù)據(jù)平臺應當具備可觀測性、開源組件管理、服務生命周期管理、集群管理、容災管理的功能和服務，圖中標藍部分是云原生計算進行了特別增強的部分，下面來重點闡述一下：
全鏈路監(jiān)測：可以全鏈路地監(jiān)測每個服務的運行狀態(tài)，包括調用鏈、調用關系等，從而可以在故障時定位到具體出問題的調用環(huán)節(jié);
開源組件管理：通過 Helm Chart 來對組件進行部署，通過 Operator 對運行組件進行整個生命周期的管理，包括開始、終止、清理等一系列操作。因此，開源組件管理是從 K8s 平臺上對引擎或特定的開源組件，甚至是任務進行管理的特殊模式，這個模式的優(yōu)勢是更快捷和更細粒度。
服務生命周期管理：通過統(tǒng)一可視化的管理界面，提供服務組件的渲染、發(fā)布和狀態(tài)管理服務。
集群管理：除集群擴縮容、集群信息統(tǒng)計外，為了更好地監(jiān)控整個的作業(yè)運行狀態(tài)和服務運行狀態(tài)，往往需要更細粒度地采集容器日志，所以我們對這部分進行了增強。另外，為了定位容器之間的運行狀態(tài)，我們提供通過 Web Shell 登錄到 Pod 中，以命令行的形式輸入 Linux 指令，在瀏覽器上直接操作作業(yè)運行環(huán)境的服務，類似于在本地終端操作遠程服務器，這對作業(yè)開發(fā)以及問題定位來說是一個非常實用的工具。
03
降本增效：用戶場景與價值
混合部署提升資源利用率
在混部的用戶場景下，云原生大數(shù)據(jù)平臺支持很多的業(yè)務場景，包括在線、流式、離線、查詢分析和批處理等。由于不同業(yè)務場景對于底層資源響應的核心指標不同，對底層資源的優(yōu)化需求也會存在區(qū)別。如果要滿足這些不同場景的業(yè)務指標要求，在混部的時候就要有重點地進行對應的優(yōu)化。以下是混部的兩個典型場景：
Flink 和 Spark 的混部。即 Flink 不使用資源，或負載低的時候，資源可以出讓給 Spark，Spark 執(zhí)行完批式計算后，空閑的資源也可以出讓給流式計算(Flink)用。
APP 實時調用和大數(shù)據(jù)場景的混部。在上圖提到的5個場景中，右側4個都是大數(shù)據(jù)場景。大數(shù)據(jù)場景可以和 APP 實時調用場景進行資源復用——當 APP 在線資源使用量較少時，可以出讓給大數(shù)據(jù)場景使用，反之亦然。
以字節(jié)跳動為例，我們在通過這樣多種計算資源混合部署調度之后，獲得了不俗的收益。
首先是高效的資源切換，可以做到數(shù)萬核離線資源分鐘級出讓。如在2022年春節(jié)時，抖音在線資源需求量非常高，我們將離線資源以分鐘級出讓了數(shù)十萬核給在線資源使用。而當遇到某些突發(fā)社會熱點導致的極端彈性場景時，高效的資源切換甚至可以成為業(yè)務的“保命利器”。
其次是利用率的提升，通過混部，可以降低整體公用的開銷，在字節(jié)跳動內部帶來 2% 的利用率提升;
最后是在離線資源的統(tǒng)一管理，在離線資源全量共池，可以實現(xiàn) Quota 管控、調度、運行、機器運維統(tǒng)一。
多云部署實現(xiàn)多云成本最優(yōu)復用
在多云的用戶場景下，我們可以提供多云部署和調度，實現(xiàn)多云成本最優(yōu)復用和跨云隊列容災：
提供全局虛擬隊列：在用戶使用多云的場景下，首先需要提供一個全局虛擬隊列的概念。如上圖，一個虛擬隊列就是一個資源池，下面對應不同的兩個物理資源池。用戶在提交的時候，不需要關注實際對應的集群，而是提交到一個虛擬隊列上，下層會針對作業(yè)進行相應的調度，自動分發(fā)到合適的集群/機房/隊列上，能夠有效提升容災能力。
應用按多因子綜合選擇流量分配：多云部署的另一個好處是可以通過多種因素的綜合考慮來選擇流量分配。比如在一個多云場景下，AZ1 理解為廠商1，AZ2 是廠商2，現(xiàn)在發(fā)現(xiàn)使用同樣多的 CU，在廠商2上比在廠商1上貴50%，那就可以通過多云調度把流量盡量分發(fā)到廠商1上。這是從成本角度考慮的一種情況，當然還可能存在雖然成本降低，但經(jīng)常宕機，響應時間較長，任務狀態(tài)出錯率高的情況，那就需要把重要的應用放到各方面指標較好的機房里，總的來說就是通過多種因子的綜合考量進行流量分配。在多云部署場景下，幫助用戶實現(xiàn)多云成本的最優(yōu)復用。
內容來源于網(wǎng)絡
以上是關于用戶增長師的相關信息，以供大家查看了解。想要了解更多用戶增長師信息，第一時間了解用戶增長師相關資訊，敬請關注唯學網(wǎng)用戶增長師欄目，如有任何疑問也可在線留言，小編會為您在第一時間解答!
