大資料平臺是否更應該容器化?

大資料的發展歷史

大資料技術起源于Google在2004年前后發表的三篇論文，分布式檔案系統GFS、分布式計算框架MapReduce和NoSQL資料庫系統BigTable，熟稱"三駕馬車"，在論文發表后，Lucene開源專案的創始人Doug Cutting根據論文原理初步實作了類似GFS和MapReduce的功能，并在2006年，將該部分功能設定成獨立的專案即大名鼎鼎的Hadoop專案，Hadoop專案中主要包括分布式檔案系統HDFS和大資料計算引擎MapReduce兩個組件，

圖片來源于網路

在早期，MapReduce既是一個執行引擎，又是一個資源調度框架，集群的資源調度管理由MapReduce自己完成，但是這樣不利于資源復用，也使得MapReduce非常臃腫，于是一個新專案啟動了，將MapReduce執行引擎和資源調度分離開來，這就是Yarn，2012年，Yarn成為一個獨立的專案開始運營，隨后被各種大資料產品支持，成為大資料平臺上最主流的資源調度系統，伴隨著時代的發展，大資料場景下的計算引擎層出不窮，主要的有記憶體式計算引擎Spark,分布式實時計算Storm,流計算框架Flink等，這些計算引擎都使用Yarn進行資源管理和調度，

大資料平臺目前存在的問題

目前絕大多數大資料平臺都是基于Hadoop生態，使用Yarn作為核心組件來進行資源管理和調度，但這樣的平臺普遍存在如下問題：

(1) 資源彈性不足，無法按需自動擴容，大資料系統資源的高峰往往具有明顯的周期性，例如實時計算資源消耗主要在白天，離線分析中，日報型的計算任務資源的高峰一般在22:00以后，周報和月報型的計算任務業務高峰往往也是在一個固定的時間點，并且離線計算有時還有突發的計算任務，例如需要對歷史資料做一個統計，目前的大資料系統普遍缺乏資源的彈性，無法按需進行快速擴容，為了應對業務高峰和突發的計算任務只能預留出足夠多的資源來保證任務能夠正常回應，

(2) 資源利用率低，日志留存和流量清單等存盤密集型的業務CPU使用率長期小于30%，而計算類的業務雖然CPU消耗很高，但是存盤的資源使用率小于20%，大量資源閑置，并且考慮在線業務往往在低峰期會有大量的資源閑置，這些資源其實離線計算業務是完全可以利用的，但目前大資料的系統架構這部分資源完全沒有被利用，導致資源利用率進一步降低，

(3) 資源隔離性差，從Hadoop2.2.0版本開始，Yarn開始使用cgroup實作了CPU資源隔離，通過JVM提供的記憶體隔離機制來實作記憶體資源隔離，對于磁盤IO和網路IO的隔離目前社區還在討論中YARN-2139，YARN-2140，對于檔案系統環境的隔離，社區在Hadoop 3.0版本中支持通過Classpath isolation HADOOP-11656來避免不同版本的jar包沖突，但無法做到完整的檔案系統隔離，整體上看Yarn的資源隔離做的并不完善，這就造成了，多個任務運行到同一個作業節點上時，不同任務之間會存在資源搶占的問題，不同任務之間相互影響，

(4) 系統管理困難，在大資料系統中缺少統一的管理介面，也缺少路由管理，網路管理，磁盤管理等能力，這就造成大資料平臺的開發往往需要對管理系統進行深度定制，開發作業量大，系統管理困難，并且平臺遷移困難，例如大資料平臺中需要提供對大資料組件UI頁面的訪問能力，在大資料平臺構建中，為了能夠訪問組件的UI頁面往往需要單獨進行網路的打通，進行額外的路由的配置，并且很多時候這些配置都缺少標準的介面，無法做到自動化，管理起來十分困難，

(5) 管理方式不統一，在線業務和大資料業務雖然屬于不同的業務型別，但就管理平臺來說提供的功能是類似的，主要提供資源管理，業務(任務)管理，權限管理，可視化展示與操作等方面的功能，但因為管理方式不統一，底層框架與運行方式不同，造成了在線業務和大資料業務往往需要開發不同的平臺，由不同的團隊運維來管理，這極大的增加了額外的人力投入，造成不必要的人力損失，

Kubernetes編排系統現狀介紹

Kubernetes是谷歌開源的生產級的容器編排系統，在谷歌內部長達15年的使用積累，依賴其對功能場景的清晰定義，宣告式API的簡潔易用，充分的擴展性，逐步在容器編排領域的競爭中勝出，成為這一領域的領導者，伴隨著微服務，DevOps，持續交付等概念的興起和持續發酵，并依托于云原生計算基金會CNCF，Kubernetes保持著高速發展，正在成為"云計算時代的作業系統"，

Kubernetes究竟有多熱門，根據CNCF年初(2020)的統計資料，在2019年84%的企業在生產環境中使用了Kubernetes，隨著在生產環境的廣泛使用，Kubernetes的成熟度已經得到了大范圍的檢驗，很多公司已經提出了所有組件容器化的目標，借助云原生的技術，來提升組件運維管理和研發流程的效率，

圖片來源于網路

Kubernetes 如何解決大資料的問題

對于在線業務，使用容器技術能夠很好的提高資源使用率，基于容器構建CI/CD流程可以大幅提升研發效能和系統管理能力，使用集群的自動伸縮功能可以根據需要動態申請和釋放資源，提高資源使用的彈性，那么在大資料場景下，使用容器能否解決大資料平臺目前遇到的問題呢？

首先對于資源彈性不足的問題，Kubernetes可以通過彈性擴縮容來實作業務高峰時的快速擴容，避免為了應對業務高峰預留過多的資源，更進一步可以直接使用無服務計算(Serverless)技術，直接將大資料業務跑在無服務計算的容器上，做到按需使用和付費，使資源的使用完全彈性，

? Kubernetes集群自動擴縮容原理

對于資源使用率低的問題，一方面Kubernetes支持更加細粒度的資源劃分，這樣可以盡量做到資源能用盡用，最大限度的按需使用，另外一方面支持更加靈活的調度，并根據業務SLA的不同，業務高峰的不同，通過資源的超賣和混合部署來進一步提升資源使用率，由于在線業務和離線業務兩者之間SLA要求明顯不同，業務高峰期也明顯不同，容器化后使用離線在線混合部署，一般對資源使用率的提升在30%以上，

對于資源隔離性差的問題，容器技術從一開始就支持不同資源的隔離，CPU，記憶體，磁盤IO，網路IO，設備等這些都有比較完整的支持，在線業務使用容器技術，通過Kubernetes編排系統能夠很好的將不同業務實體混合部署到相同的節點上，實體之間使用隔離技術，完整的隔離，相互之間完全不受影響，

? Kubernetes隔離能力示意圖

對于系統管理困難的問題，Kubernetes不僅提供資源管理的能力，還提供路由管理，網路管理，監控日志等多方面的能力，同時對外通過統一的宣告式API進行訪問，基于Kubernetes構建大資料平臺，可以極大的簡化系統開發的難度，減少系統管理的復雜度，例如在大資料平臺中，使用Kubernetes提供的路由管理能力Service和 Ingress可以十分方便實作對大資料組件UI的訪問，并且Kubernetes還提供標準的宣告式API來管理，極大的簡化了自動化的復雜度，

? Kubernetes ingress 提供訪問大資料各個組件UI示意圖

如果在線業務和大資料業務都統一使用容器化的方式來部署，使用Kubernetes編排框架來管理，這樣就能將大資料業務和在線業務在同一個平臺中實作管理和運維，避免平臺管理團隊的人員分散，大大提高平臺管理團隊作業效率，

? 統一的業務管理平臺示意圖

大資料容器化技術現狀

大資料組件眾多，按照類別大致可以分為檔案存盤系統，NoSQL資料庫，計算框架，訊息中間件，查詢分析等，常用的大資料組件具體的分類如下表所示：

這些組件現在一般都有對應的開源專案來支持部署到Kubernetes上，本文將對一些常用的組件在Kubernetes的部署進行分析，

檔案存盤系統

HDFS on Kubernetes

HDFS主要包括Datanode，Namenode和Journalnode三個組件，在Kubernetes中進行部署時，由于Datanode需要存盤HDFS中的資料，對磁盤要求非常高，所以在Kubernetes中部署時Datanode采用DaemonSet的方式進行部署，每個存盤節點部署一個Datanode實體，而Namenode和Journalnode由于需要保持名稱不變，在Kubernetes中采用StatefulSet的方式進行部署，

NoSQL資料庫

Hbase on Kubernetes

Hbase主要包括兩種型別的節點，HMaster節點和HRegionServer節點，其中HMaster節點作為主節點，負責管理多個HRegionServer節點，HRegionServer節點作為worker節點，負責管理各個region，由于Hbase的實際資料存盤在HDFS中，Hbase本身并不存盤資料，所以HMaster和HRegionServer并不需要掛載磁盤，只是為了保持實體名稱不變，HMaster和HRegionServer都采用StatefulSet的方式進行部署，

資料查詢分析

Hive on Kubernetes

Hive主要包括hive-Server和metastore兩個組件，其中hive-Server作為訪問入口，可以按照在線服務一樣使用Deployment進行部署，metastore因為需要保持名稱不變，所以使用了StatefulSet的方式進行部署，

計算框架

Spark on Kubernetes

Spark是大資料領域比較早做容器化的一個組件，Spark從2.3版本支持原生的方式將任務跑在Kubernetes上，具體的實作原理如上圖所示，通過spark-submit腳本向kube-apiserver提交創建請求，先創建spark的driver實體，然后driver實體按照任務執行需要的資源大小，向kube-apiserver發起請求，創建對應的executor實體，由executor實體來執行任務，Driver實體通過監聽kube-apiserver中pod的資訊，對executor實體的生命周期進行管理，

Flink on Kubernetes

Flink與Spark類似，在其內核中直接對接了Kubernetes的kube-apiserver，以提高資源的使用效率，在Flink Client提交后，會先創建Flink Job Manager實體，然后再由Job Manager會呼叫Kubernetes的介面，根據任務的并行度來動態的創建對應的TaskManager實體，

通過對上面組件在Kubernetes的部署情況的分析，可以看到目前大部分的大資料組件都已經有專案來支持在Kubernetess上部署，并且借用Kubernetes不同型別的資源管理能力，就能實作對大資料組件的部署，大資料組件的容器化正在從嘗試走向成熟，

騰訊大資料容器化實踐

近兩年騰訊內部多個部門展開了大資料容器化的實踐，并取得了非常不錯的效果，充分證明了大資料容器化的可行性和大資料容器化在簡化運維管理成本，提升資源利用率上的效果，

云原生流計算平臺Oceanus容器化實踐

Oceanus 是騰訊云推出的流計算產品，其基于 Apache Flink 構建，提供全托管的云上服務，最大規模可達萬億級，使用流計算平臺Oceanus 可以方便的進行云端流式資料匯聚、計算，輕松的構建網站點擊流分析、電商精準推薦、物聯網 IoT 等應用，

近期騰訊云容器團隊和大資料團隊聯合推出了Oceanus on TKE(Tencent Kubernetes Engine)版本，通過將流計算任務運行在Kubernetes上，高效的解決了資源管理和隔離的問題，同時使用容器統一的日志采集方案，實作更好的日志采集和查看，另外使用Kubernetes提供的Ingress能力，靈活的支持查看各個大資料組件的運維頁面，

騰訊云容器團隊和大資料團隊正打算將大資料組件逐步都運行到Kubernetes上，以實作更好的資源隔離和資源管控，為客戶提供在離線統一的管理平臺，達到資源運維管理的極簡化，資源運行效率的極大化，

QAPM資料分析平臺全面容器化實踐

QAPM（Quick Application Performance Monitor) 資料分析平臺是騰訊云推出的客戶端性能分析平臺，其依托于騰訊云的全方位定位檢測APP性能的專項解決方案，實作對APP性能的高效性能分析，2018年，在開始設計和開發QAPM平臺時，為了在云上充分利用資源的彈性，在云下支持私有化交付，并且盡可能降低管理成本，平臺在設計之初就采用全容器化的方式進行部署，

具體的業務流程包括離線計算和流計算兩個主要部分，在離線計算中，資料從客戶端上報后，使用kafka進行轉發，然后將資料通過Hive寫入HDFS，Spark計算引擎把資料讀出，經過處理后將處理的結果存入ES，Postgres，Druid等后端存盤，用于前臺的展示與查詢，

在實時計算中，資料從客戶端上報后，使用kafka進行轉發，然后直接經過Flink進行流式處理，處理完后資料寫入入ES，Postgres，Druid等后端存盤，用于前臺的展示與查詢，

因為所有組件都使用容器化部署，每個組件都設計成了單獨的Charts包，這樣部署新的環境變得非常簡單，之前按照傳統的方式部署一套完整的環境，花費的時間在兩天甚至更多，但因為使用了容器化部署，一般半小時以內就可以完成部署和相關配置的修改，極大的提升了效率，

為了進一步提高資源資源利用率，QAPM平臺在容器化的基礎上通過將流計算業務和離線計算業務混合部署到了同一個集群，使用一個固定的資源池作為基礎資源，在業務高峰期使用彈性擴容的方式來補充資源，使整體資源使用效率提升了30%~50%，

總結

大資料與容器編排技術，一個是在資料處理領域歷史相對比較長久的互聯網的基石技術，一個是在業務編排領域近年來才興起的新興技術，兩者本來都在各自的生態中處于不斷發展壯大的階段，相互直接融合比較少，但近年來隨著Kubernete技術的成熟，使大資料容器化從設想變成了可能，通過容器化技術可以像在線業務場景一樣在大資料場景進一步提升運維管理和資源使用的效率，進一步釋放大資料的活力，

參考鏈接：

BIG DATA MANAGEMENT PLATFORM ABOUT INFORMATICA BIG DATA MANAGEMENT
【騰訊云原生】云說新品、云研新術、云游新活、云賞資訊，掃碼關注同名公眾號，及時獲取更多干貨！！

標籤：其他

上一篇：大型Kubernetes集群的資源編排優化

下一篇：揭秘！containerd 鏡像檔案丟失問題，竟是鏡像生成惹得禍