大數據系統云原生漸進式演進的過程是怎樣的

這篇“大數據系統云原生漸進式演進的過程是怎樣的”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“大數據系統云原生漸進式演進的過程是怎樣的”文章吧。

1.引言

隨著云原生概念的興起，越來越多的企業投身于云原生轉型的浪潮，以解決傳統應用面臨的彈性能力不足、資源利用率較低、迭代周期較長等問題。通過云原生技術（如容器，不可變基礎設施和聲明式API等)，使得企業在公有云、私有云和混合云等云環境構建和運行應用變得更加容易，更能充分利用云環境的優勢，加速了企業應用迭代、降低資源成本、提高系統容錯性和資源彈性。

基于Hadoop生態的傳統大數據系統，同樣面臨著彈性能力不足、資源利用率低，管理困難等問題，云原生技術天然適合解決這些問題。然而，將基于Hadoop生態的傳統大數據系統改造成云原生架構，涉及到改造成本高、遷移風險大等諸多挑戰。那有沒有方案，既可以基于云原生技術解決大數據系統彈性能力不足，資源利用率低，管理困難等問題，又能保證改造成本、遷移風險比較低呢？騰訊云大數據團隊和容器團隊，基于大數據系統的現狀，結合大數據技術和容器技術的特點，推出了漸進式的云原生演進方案。使用該方案，可以在較小改造成本和遷移風險的前提下，實現大數據系統的云原生化，充分利用云原生的優勢。

本文依次分析了大數據系統當前面臨的主要問題、云原生如何解決這些問題、大數據系統云原生改造面臨的挑戰，基于這些問題和調整，重點介紹了基于Hadoop Yarn on Kubernetes Pod（下文會詳細介紹）的漸進式的云原生演進方案及其最佳實踐。

2.大數據系統主要問題

傳統的大數據系統圍繞著Hadoop生態快速的發展，百花齊放，各個企業也逐步建立了自己的大數據平臺，甚至是數據中臺。然而，在激烈的市場競爭和不斷增加的消費期望的雙重驅動下，一方面業務需要快速迭代以滿足迅速的增長，另一方面需要在資源需求不斷增長的同時控制高昂的成本以保持企業的競爭力。這就要求大數據系統能夠及時、快速的擴容以滿足生產需求，又能盡可能的提高資源的使用效率，降低資源的使用成本。具體的問題體現在以下幾點：

• 彈性擴縮容能力無法滿足快速增長的業務需求：隨著業務的發展，流量和數據量突增，尤其對于實時計算，需要資源能夠及時的擴容，以滿足業務需求。盡管一些大數據管控平臺嘗試實現自動的擴縮容（如通過集群負載情況，進行擴容），然而，在傳統大數據平臺架構下，通常需要資源申請、依賴軟件安裝、服務部署等一系列步驟，該過程通常比較慢，對于集群負載的緩解，不夠及時。

• 在離線分離部署及粗粒度調度無法提高資源的利用率：在傳統Hadoop架構下，離線作業和在線作業往往分屬不同的集群，然而在線業務、流式作業具有明顯的波峰波谷特性，在波谷時段，會有大量的資源處于閑置狀態，造成資源的浪費和成本的提升。在離線混部集群，通過動態調度削峰填谷，當在線集群的使用率處于波谷時段，將離線任務調度到在線集群，可以顯著的提高資源的利用率。然而，Hadoop Yarn目前只能通過NodeManager上報的靜態資源情況進行分配，無法基于動態資源調度，無法很好的支持在線、離線業務混部的場景。

• 操作系統鏡像及部署復雜性拖慢應用發布：虛擬機或裸金屬設備所依賴的鏡像，包含了諸多軟件包，如HDFS、Spark、Flink、Hadoop等，系統的鏡像遠遠大于10GB，通常存在鏡像過大、制作繁瑣、鏡像跨地域分發周期長等問題。基于這些問題，有些大數據開發團隊不得不將需求劃分為鏡像類和非鏡像類需求，當需要修改鏡像的需求積累到一定程度，才統一進行發布，迭代速度受限，當遇到用戶緊急且需要修改鏡像的需求時，勢必面臨很大的業務壓力。同時，購買資源后，應用的部署涉及到依賴部署、服務部署等環節，進一步拖慢應用的發布。

圖1 大數據系統主要問題

以上提到的彈性擴縮容、應用發布效率和資源利用率，是當前大數據系統普遍存在的問題，如何解決和應對這些問題，越來越成為企業較為關心的話題。接下來，我們將從云原生的角度來分析如何解決這些問題。

3. 云原生技術如何解決大數據系統問題

云原生技術如何解決彈性擴容問題: 在云原生架構中，應用程序及其依賴環境已經提前構建在鏡像中，應用程序運行在基于該鏡像啟動的容器中。在業務高峰期，隨著業務量的上升，向云原生環境申請容器資源，只需等待鏡像下載完成即可啟動容器（一般鏡像下載時間也是秒級的），當容器啟動后，業務應用將立即運行并提供算力，不存在虛擬機的創建、依賴軟件安裝和服務部署等耗時的環節。而在業務低峰期，刪除閑置的容器，即可下線相應的應用程序，以節省資源使用的成本。借助云原生環境和容器技術，可以快速的獲取容器資源，并基于應用鏡像秒級啟動應用程序，實現業務的快速啟停，實時的擴縮容業務資源以滿足生產需求。

云原生技術如何解決資源使用率低的問題: 在傳統架構中，大數據業務和在線業務往往部署在不同的資源集群中，這兩部分業務相互獨立。但大數據業務一般更多的是離線計算類業務，在夜間處于業務高峰，而在線業務恰恰相反夜間常常處于空載狀態。云原生技術借助容器完整(CPU，內存，磁盤IO，網絡IO等)的隔離能力，及kubernetes強大的編排調度能力，實現在線和離線業務混合部署，從而使在離線業務充分利用在線業務空閑時段的資源，以提高資源利用率。

另外，使用無服務器(serverless)技術，通過容器化的部署方式，做到有計算任務需求時才申請資源，資源按需使用和付費，使用完之后及時退還資源，極大的增加了資源使用的靈活性，提升資源使用的效率，有效的降低了資源使用的成本。

云原生技術如何解決發布周期長的問題: 傳統大數據系統中，所有環境基本上使用同一個鏡像，依賴環境比較復雜，部署、發布周期往往比較長。有時基礎組件需要更新，因為需要重新構建鏡像，并上傳到各個地域，耗時可能長達數天。而云原生架構使用容器進行部署，應用的發布和基礎組件的更新都只需要拉取新的鏡像，重新啟動容器，具有更新速度快的天然優勢，并且不會有環境一致性的問題，可以加快應用發布的節奏，解決應用發布周期長的問題。

4. 大數據系統向云原生架構演進的挑戰

云原生的技術雖然能解決當前大數據系統遇到的問題，然而，將大數據系統從傳統的基于Hadoop生態的架構，遷移到云原生架構，將會面臨一些挑戰：

• 應用改造成本高：將運行在Hadoop平臺的大數據應用遷移到云原生平臺，一方面需要大數據團隊將業務應用進行容器化改造，如系統任務的啟動方式、基礎設施的適配（環境變量、配置文件獲取方式的變更等），這些都需要大數據團隊來做適配，在資源管理的方式，則從適配Yarn修改為適配Kubernetes，總體改造成本比較高；另一方面，需要在大數據應用的資源申請層面進行改造，使其具備直接向Kubernetes集群申請資源的特性，也稱為Native on Kubernetes。目前Apache Spark、Apache Flink已經從框架內核不同程度的支持了該特性，但整體的完整對依賴于社區的努力。

• 遷移風險高：一次變更引入的改動越多，引發故障的幾率也越多。在Hadoop領域，大數據應用的資源，由 Hadoop Yarn負責管理和調度，具體來說，大數據應用運行在Yarn提供的Container之中，這里的Container，是Yarn中資源的抽象，并非Linux Container，將其遷移至以容器為技術的云原生架構，跨越了底層基礎架構，改動面比較大，風險相對也更高。

• 組織架構造成額外的成本：企業里負責開發和運維Hadoop系統的團隊，和容器團隊通常分屬不同的部門，其技術棧也有明顯區別，在遷移的過程中，存在過多的跨部門溝通，帶來額外的遷移成本，如果改動比較大，跨部分溝通的成本會非常大。

由此可見，將大數據應用從傳統Hadoop架構遷移至Kubernetes架構，并沒有那么簡單，尤其是依賴社區對大數據應用本身的改造，使其具備運行在云原生平臺的能力，然而這些改造，非一朝一夕所能完成，仍需要大數據應用社區在云原生方向作出更多的努力。

5. 大數據系統云原生漸進式演進方案

5.1 漸進式演進方案簡介

上文提到的大數據系統現存問題，云原生技術如何解決大數據系統的問題，以及大數據系統從傳統架構遷移到云原生架構的挑戰。那有沒有一種方案既能解決大數據系統的問題，讓大數據系統架構更加云原生。又可以降低遷移過程中的改造成本，規避遷移風險呢？

接下來本文將介紹大數據系統漸進式向云原生演進的方案，通過漸進式遷移演進的方式，在架構較小改動的情況下，通過云原生技術解決大數據系統的問題。通過較小的投入，獲得云原生技術的紅利，并且避免遷移過程的的風險。同時后期還可以在這基礎上進一步將大數據系統平滑演進到云原生架構。

漸進式演進方案主要有彈性擴縮容和離在線混合部署兩種模式，兩個模式的側重點略有不同，彈性擴縮容主要聚焦于如何利用云原生資源，借助serverless技術，快速擴容資源以補充算力，滿足業務實時需求。而離在線混部主要聚焦于利用在線業務空閑時段的閑置資源，通過將大數據離線計算任務調度到在線業務閑置資源的上，在保證業務穩定性的基礎上，大幅提升資源的使用效率。這兩種模式都使用了Yarn on Kubernetes Pod的形式，如下圖，其基本思想是，將Yarn NodeManager運行在Kubernetes集群中新擴容的Pod容器內，當Yarn NodeManager Pod啟動后，根據配置文件自動向已有的Hadoop集群的Yarn ResourceManager發起注冊，最終以Kubernetes Pod的形式補充Yarn集群的算力。

圖2 Yarn on Kubernetes Pod

5.2 漸進式演進之彈性擴縮容模式

在彈性擴縮容模式中，彈性擴縮容模塊會根據大數據集群資源的使用情況，動態的向serverless Kubernetes集群申請(釋放)資源。申請資源的具體形式為，在Kubernetes集群中創建(銷毀)Yarn operator的自定義資源（CustomResourceDefinition,CRD)，集群中部署的Yarn-operator會根據crd資源來創建(刪除) Yarn pod。在Yarn pod中會啟動Yarn nodemanager進程，Yarn nodemanager進程啟動后會自動向大數據集群中的Yarn resource-manager發起注冊，擴充(減少)大數據集群的算力，滿足任務的資源需求。

如圖1所示，左側是運行在騰訊云EMR（彈性MapReduce）系統上的大數據集群，右側是騰訊云EKS（彈性容器服務）(Serverless Kubernetes)集群。

圖3 彈性擴縮容方案（EMR大數據集群）

該方案的關鍵組件是Yarn-operator和Yarn-autoscaler。Yarn-autoscaler組件通過監聽Yarn集群中資源使用的情況，作出擴容或者縮容的判斷，然后向EKS集群創建Yarn-operaor crd資源。Yarn-operaor根據crd資源創建或刪除對應的Yarn pod實例，這兩個的組件的功能如下。

1）Yarn-operator

Yarn-operator通過kubernetes接口監聽大數據集群管控平臺中Yarn-autoscaler模塊創建的crd資源。Yarn-opterator完成的主要功能包括：

(1) 根據crd中的配置創建對應的Yarn pod; (2) 維護pod的生命周期，在pod出現異常時，自動重啟pod; (3) 指定pod進行縮容 (4) 在pod啟動失敗時，標記啟動失敗。

其中pod異常恢復和固定pod name主要參考了kurbernetes statefulsets的設計思路，保證節點異常后能以同樣的名稱加入到Yarn集群。指定pod進行縮容，支持不受pod下標順序的限制，刪除任意的pod實例，對于關心集群拓撲結構的用戶，操作空間更靈活。快速失敗標記能夠將將長時間未進入running狀態的Pod主動刪除，避免擴容流程長時間阻塞。

2）Yarn-autoscaler

Yarn-autoscaler組件提供按負載和按時間彈性伸縮兩種擴縮容方式。對于按負載伸縮，用戶可以對不同指標設置閾值來觸發擴縮容，比如設置Yarn root隊列的availablevcore、pending vcore、available mem、pending mem等。當Yarn中的這些指標達到預設閾值時，Yarn-autoscaler將觸發擴容過程，通過向EKS集群創建的Yarn-opterator的crd資源完成Yarn集群的擴容。

圖4 擴縮容規則管理--負載伸縮

對于按時間彈性伸縮，用戶可以設置不同的時間規則來觸發擴縮容，比如設置一次性、按天、按周、按月重復的規則，當規則觸發后，進行彈性擴縮容流程，通過創建(刪除)EKS集中的Yarn-opterator的crd資源來完成Yarn集群算力的增減。

圖5 擴縮容規則管理--時間伸縮

另外對于云上客戶自建的大數據集群，也可以通過將集群導入到EMR的管系統形式來實現彈性擴縮容，提升資源使用的效率。具體的只需在每個節點安裝EMR agent組件，然后EMR團隊在后臺增加對應的集群信息，即可以完成集群的導入。EMR agent本身對集群無任何侵入，消耗的資源也比較小(CPU 消耗小于0.1核，內存消耗小于150M)，主要做監控指標采集，日志采集，集群心跳上報等工作。安裝完agent后，集群將完整的被EMR管控系統納管，客戶不僅可以使用彈性擴縮容的能力，還可以在既使用自身日志監控的能力的同時使用EMR提供的日志監控能力。后續也可以持續享受EMR提供的各種能力。

圖6 彈性擴縮容方案（用戶自建集群導入EMR管控系統）

5.3 漸進式演進之在離線混部模式

對于在離線混部模式，節點上的agent組件基于監控統計cpu和內存的真實使用情況，這些統計信息由一個server統一收集，大數據管控平臺通過該server，獲取當前在線集群中可以提供的閑置算力的規格及數量，調用Knetes api創建對應數量的資源，ex-scheduler擴展調度器確保Pod被創建在剩余資源更多的節點上，其中申請資源的具體形式與彈性擴縮容模式中相同，由Yarn operator根據crd資源創建(刪除)Yarn pod。

圖7 在離線混部方案

如上圖所示，左側是TKE(騰訊云容器服務)集群，右側是EMR大數據集群。在線業務具有明顯的波峰浪谷特征，而且規律比較明顯，尤其是在夜間，資源利用率比較低，這時候大數據管控平臺向Kubernetes集群下發創建資源的請求，可以提高大數據應用的算力。這里主要通過四個組件來實現，recomm-agent、recomm-server、ex-scheduler和Yarn-operator。

• ceres-agent從prometheus(node-exporter、telegraf) 讀取節點的cpu idle信息，作為可以超賣的cpu數量，并通過node節點的可分配內存-總體請求內存作為空閑memory數量，并將計算結果patch到Node節點的node.status.capacity字段；

• ceres-server匯總ceres-agent在各節點patch的可超賣cpu和memory信息，根據http client提供的pod規格，返回可以支持的pod的數量；

• ex-scheduler是基于Kubernetes scheduler extender實現的一個擴展調度器，相對于Yarn調度器，Kuberentes調度器具有更細的調度粒度，比如以milli-cores為單位進行CPU資源的調度，如500m，表示0.5個cpu、以bytes為單位進行內存資源的調度等，更細的粒度通常能帶來更好的資源使用率。該調度器在score打分環節，根據待調度的pod中聲明的squeezed-cpu以及ceres-agent在節點的node.status.capacity寫入的squeezed-cpu，來決定Node的分值，空閑資源越多的節點，打分越高，從而篩選出實際資源空閑最多的節點。

• Yarn-opterator的主要作用是根據crd資源，動態創建(刪除)pod，功能和彈性擴容模式中的Yarn-opterator一樣，這里就不再重復介紹。

5.4 漸進式演進方案如何解決大數據系統的問題

以上兩種方案，解決了文章開始提到的一系列問題和挑戰。借助漸進式演進的方案，既能解決大數據系統的問題和遷移的挑戰，讓大數據系統架構更加云原生，充分利用云原生的能力，又可以降低遷移過程中的改造成本，盡可能的規避遷移風險，其主要體現在以下幾個方面：

• 在彈性擴縮容和資源申請方面，借助基于Kubernetes的serveless服務，做到資源按需創建、按需使用和付費；而資源的調度方式，則依然保證不變。具體來說，Kubernetes只是資源的提供方，只提供創建和銷毀資源的API，業務方負責調用該API來創建和銷毀資源，資源在Kubernetes上創建完成之后，該資源的Yarn NodeManager組件自動向Yarn ResourceManager注冊，以Kubernetes Pod的形式提供算力，后續執行作業時涉及到的資源調度，依然由Yarn負責。

• 在鏡像和發布周期方面，容器鏡像技術精簡了應用的運行環境，鏡像只需提供應用必須的依賴環境，使其存儲空間得到了極大的減少，上傳和下載鏡像的時間變的更短，快速啟動和銷毀變的很容易，總體極大的縮短了應用的發布周期。

• 在資源利用率方面，借助云原生架構的技術能力，多方位提升系統的資源利用率，如細粒度調度（將CPU和內存這兩個核心資源劃分的更細，從而更充分的分配系統資源）、動態調度（基于節點真實負載情況，而非靜態劃分的資源，將任務調度到已分配了資源但是未實際使用的節點上，從而更充分的提高系統算力），在離線混部（根據離線任務和在線任務的周期性，削峰填谷，從而充分利用系統閑置資源）。

• 在應用改造成本、遷移風險和組織架構方面：通過漸進式的遷移，大數據應用團隊無需改造既有架構，只需制作當前所用的Hadoop版本的鏡像，即可完成在Kubernetes上創建容器資源補充算力，這種方式，可以最低程度的減少變更，從而盡可能的降低遷移風險，與此同時，大數據團隊保證Yarn資源調度和使用，容器團隊保證Yarn pod的穩定運行，分工明確，能最大限度的保證系統的穩定性。

6. 大數據系統云原生漸進式演進最佳實踐

6.1 基于EKS的彈性擴縮容最佳實踐

圖8 用戶最佳實踐--彈性擴容縮容

該用戶基于Hadoop Yarn自建了大數據集群，包含多種組件，如Spark、Flink、Hive等，當前遇到的主要問題是，面對臨時的突發流量，如何快速的擴容以提高算力，并且在計算完成后，如何實時的釋放資源以解決成本。借助騰訊云EKS的serverless能力，我們實現的快速自動擴縮容方案，正好可以滿足該用戶的訴求。

在控制臺上，用戶使用我們提供的自動擴縮容的配置策略，自由配置自動擴容、縮容的觸發閾值。比如配置當剩余CPU或者內存小于指定的值時，Yarn彈性伸縮組件會調用EKS Kubernetes API創建Yarn NodeManager Pod，容器啟動后自動注冊到Yarn ResourceManager，從而提供算力；當觸發了用戶配置的縮容策略時，如剩余CPU或者內存大于指定的值時，Yarn彈性伸縮組件同樣會調用EKS Kubernetes API縮容Yarn NodeManager Pod，整個過程中無需用戶創建虛擬機，計費方式以Pod的CPU和內存為基礎，真正的達到資源隨用隨建，按需付費。

6.2 混合云彈性基于TKE的在離線混部最佳實踐

圖9 用戶最佳實踐--離在線混部

某客戶大數據應用和存儲跑在Yarn管理的大數據集群，在生產環境中，面臨諸多問題，主要體現在大數據的算力不足和在線業務波谷時資源的浪費。如離線計算在算力不足時，數據準時性無法得到保證，尤其是當遇到隨機緊急大數據查詢任務，沒有可用的計算資源，只能停掉已有的計算任務，或者等已有任務完成，無論哪種方式，總體任務執行的效率都會大打折扣。

基于TKE的在、離線混部方案，將離線任務自動擴容至云上集群，與在線業務混合部署，充分利用云上波谷時段的閑置資源，提高離線業務的算力，并利用云上資源快速的彈性擴容能力，及時補充離線計算的算力。簡單來說，該方案提供了三種使用方式:

1. 根據在線業務的波谷時段，配置定時擴容任務，在定時任務指定的時間到達時，調用TKE Kubernetes API，提交擴容請求，Yarn NodeManager則會以Pod的形式被Kubernetes創建出來，并且根據鏡像里事先準備好的配置，自動向Yarn ResourceManager注冊，從而提供算力資源。 該方案幫助用戶提高在線集群利用率的同時，提高了離線集群的算力；

2. 大數據管控平臺也可以直接向TKE Kubernetes API發送擴展指令，以應對臨時的緊急大數據查詢任務，避免算力不足帶來的任務無法啟動，從而提高系統SLA；

3. 用戶可以在控制臺上配置自動擴縮容策略，結合Ceres Server\Client資源預測，將Yarn NodeManager創建在合適的節點上。

以上就是關于“大數據系統云原生漸進式演進的過程是怎樣的”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。