【大數據雲原生系列】大數據系統雲原生漸進式演進最佳實踐

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 ServerClient資源預測，將Yarn NodeManager建立在合適的節點上。

7. 總結

本文提出了大數據雲原生漸進式演進的理念和最佳實踐，在極大減小改形成本、下降遷移風險的基礎上，解決了大數據應用當前面臨的主要問題。在將來，咱們將基於最小化遷移風險、最低改形成本等原則，設計並落地更多方案，使大數據應用更原生的跑在雲原生架構上，爲企業帶來更多的便利和實際收益。

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公衆號，及時獲取更多幹貨！！