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 使用者最佳實踐--離線上混部
- 根據線上業務的波谷時段，配置定時擴容任務，在定時任務指定的時間到達時，調用TKE Kubernetes API，送出擴容請求，Yarn NodeManager則會以Pod的形式被Kubernetes建立出來，并且根據鏡像裡事先準備好的配置，自動向Yarn ResourceManager注冊，進而提供算力資源。 該方案幫助使用者提高線上叢集使用率的同時，提高了離線叢集的算力；
- 大資料管控平台也可以直接向TKE Kubernetes API發送擴充指令，以應對臨時的緊急大資料查詢任務，避免算力不足帶來的任務無法啟動，進而提高系統SLA；
- 使用者可以在控制台上配置自動擴縮容政策，結合Ceres Server\Client資源預測，将Yarn NodeManager建立在合适的節點上。