## 1.引言

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

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

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

## 2.大資料系統主要問題

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

- **彈性擴縮容能力無法滿足快速增長的業務需求**：隨著業務的發展，流量和資料量突增，尤其對於實時計算，需要資源能夠及時的擴容，以滿足業務需求。儘管一些大資料管控平臺嘗試實現自動的擴縮容（如透過叢集負載情況，進行擴容），然而，在傳統大資料平臺架構下，通常需要資源申請、依賴軟體安裝、服務部署等一系列步驟，該過程通常比較慢，對於叢集負載的緩解，不夠及時。
- **在離線分離部署及粗粒度排程無法提高資源的利用率**：在傳統Hadoop架構下，離線作業和線上作業往往分屬不同的叢集，然而線上業務、流式作業具有明顯的波峰波谷特性，在波谷時段，會有大量的資源處於閒置狀態，造成資源的浪費和成本的提升。在離線混部叢集，透過動態排程削峰填谷，當線上叢集的使用率處於波谷時段，將離線任務排程到線上叢集，可以顯著的提高資源的利用率。然而，Hadoop Yarn目前只能透過NodeManager上報的靜態資源情況進行分配，無法基於動態資源排程，無法很好的支援線上、離線業務混部的場景。
- **作業系統映象及部署複雜性拖慢應用釋出**：虛擬機器或裸金屬裝置所依賴的映象，包含了諸多軟體包，如HDFS、Spark、Flink、Hadoop等，系統的映象遠遠大於10GB，通常存在映象過大、製作繁瑣、映象跨地域分發週期長等問題。基於這些問題，有些大資料開發團隊不得不將需求劃分為映象類和非映象類需求，當需要修改映象的需求積累到一定程度，才統一進行釋出，迭代速度受限，當遇到使用者緊急且需要修改映象的需求時，勢必面臨很大的業務壓力。同時，購買資源後，應用的部署涉及到依賴部署、服務部署等環節，進一步拖慢應用的釋出。

![](https://main.qcloudimg.com/raw/4d90a66a5eb0300de2a975d8a950262b.png)

圖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叢集的算力。

![](https://main.qcloudimg.com/raw/f18a9faef810e07fff504d525f960fd9.png)

圖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](https://cloud.tencent.com/document/product/589)）系統上的大資料叢集，右側是騰訊雲EKS（[彈性容器服務](https://cloud.tencent.com/product/eks)）(Serverless Kubernetes)叢集。

![](https://main.qcloudimg.com/raw/1dba0d9013d9fc181f90ab182a1f83a0.png)

圖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叢集的擴容。 ![](https://main.qcloudimg.com/raw/b3942c6dad7062990bf91ce0d08e7978.png)

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

對於按時間彈性伸縮，使用者可以設定不同的時間規則來觸發擴縮容，比如設定一次性、按天、按周、按月重複的規則，當規則觸發後，進行彈性擴縮容流程，透過建立(刪除)EKS集中的Yarn-opterator的crd資源來完成Yarn叢集算力的增減。

![](https://main.qcloudimg.com/raw/2c8b95247f51aa479dcbfc1ac0f8490e.png)

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

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

![](https://main.qcloudimg.com/raw/2252407f82cde6e824f7e5d0d555051d.png)

圖6 彈性擴縮容方案（使用者自建叢集匯入EMR管控系統）

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

對於在離線混部模式，節點上的agent元件基於監控統計cpu和記憶體的真實使用情況，這些統計資訊由一個server統一收集，大資料管控平臺透過該server，獲取當前線上叢集中可以提供的閒置算力的規格及數量，呼叫Knetes api建立對應數量的資源，ex-scheduler擴充套件排程器確保Pod被建立在剩餘資源更多的節點上，其中申請資源的具體形式與彈性擴縮容模式中相同，由Yarn operator根據crd資源建立(刪除)Yarn pod。

![](https://main.qcloudimg.com/raw/02fff2361354ae3e02491b91ee0567db.png)

圖7 在離線混部方案

如上圖所示，[左側是TKE(騰訊雲容器服務)叢集](https://cloud.tencent.com/product/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的彈性擴縮容最佳實踐

![](https://main.qcloudimg.com/raw/975ef0caf3b24ef1d89003e3df9c39c1.png)

圖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的在離線混部最佳實踐

![](https://main.qcloudimg.com/raw/0e39abfd45e7441f23ba7faccba43051.png)

圖9 使用者最佳實踐--離線上混部

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

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

1. 根據線上業務的波谷時段，配置定時擴容任務，在定時任務指定的時間到達時，呼叫TKE Kubernetes API，提交擴容請求，Yarn NodeManager則會以Pod的形式被Kubernetes建立出來，並且根據映象裡事先準備好的配置，自動向Yarn ResourceManager註冊，從而提供算力資源。 該方案幫助使用者提高線上叢集利用率的同時，提高了離線叢集的算力；
2. 大資料管控平臺也可以直接向TKE Kubernetes API傳送擴充套件指令，以應對臨時的緊急大資料查詢任務，避免算力不足帶來的任務無法啟動，從而提高系統SLA；
3. 使用者可以在控制檯上配置自動擴縮容策略，結合Ceres Server\Client資源預測，將Yarn NodeManager建立在合適的節點上。

## 7. 總結

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

![](https://main.qcloudimg.com/raw/d46b4cd7bf09736a4de6d76784901719.png)

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

相關文章