大數據平台是否更應該容器化?


大數據的發展歷史

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

image.png-585.2kB

圖片來源於網絡

在早期,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-2139YARN-2140。對於文件系統環境的隔離,社區在Hadoop 3.0版本中支持通過Classpath isolation HADOOP-11656來避免不同版本的jar包沖突,但無法做到完整的文件系統隔離。整體上看Yarn的資源隔離做的並不完善,這就造成了,多個任務運行到同一個工作節點上時,不同任務之間會存在資源搶占的問題,不同任務之間相互影響。

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

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

image.png-780.8kB

Kubernetes編排系統現狀介紹

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

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

image.png-428.6kB

圖片來源於網絡

Kubernetes 如何解決大數據的問題

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

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

image.png-166.4kB

​ Kubernetes集群自動擴縮容原理

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

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

image.png-528.6kB

​ Kubernetes隔離能力示意圖

對於系統管理困難的問題,Kubernetes不僅提供資源管理的能力,還提供路由管理,網絡管理,監控日志等多方面的能力。同時對外通過統一的聲明式API進行訪問。基於Kubernetes構建大數據平台,可以極大的簡化系統開發的難度,減少系統管理的復雜度。例如在大數據平台中,使用Kubernetes提供的路由管理能力ServiceIngress可以十分方便實現對大數據組件UI的訪問,並且Kubernetes還提供標准的聲明式API來管理,極大的簡化了自動化的復雜度。

image.png-136.5kB

​ Kubernetes ingress 提供訪問大數據各個組件UI示意圖

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

image.png-337.2kB

​ 統一的業務管理平台示意圖

大數據容器化技術現狀

大數據組件眾多,按照類別大致可以分為文件存儲系統,NoSQL數據庫,計算框架,消息中間件,查詢分析等。常用的大數據組件具體的分類如下表所示:

大數據組件分類 代表性組件 主要作用
文件存儲系統 HDFS 數據底層存儲
NoSQL數據庫 Hbase、MongoDB 非結構化數據存儲
計算框架 Hadoop MapReduce、Spark、Storm、Flink 離線計算和流計算
消息系統 Kafka、ZeroMQ、RabbitMQ 消息存儲和轉發
數據查詢分析 Hive、Impala、Druid 數據查詢和分析

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

文件存儲系統

HDFS on Kubernetes

image.png-183.9kB

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

NoSQL數據庫

Hbase on Kubernetes

image.png-169.4kB

Hbase主要包括兩種類型的節點,HMaster節點和HRegionServer節點。其中HMaster節點作為主節點,負責管理多個HRegionServer節點。HRegionServer節點作為worker節點,負責管理各個region。由於Hbase的實際數據存儲在HDFS中,Hbase本身並不存儲數據,所以HMaster和HRegionServer並不需要掛載磁盤。只是為了保持實例名稱不變,HMaster和HRegionServer都采用StatefulSet的方式進行部署。

數據查詢分析

Hive on Kubernetes
image.png-111kB

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

計算框架

Spark on Kubernetes

image.png-53.3kB

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

Flink on Kubernetes

image.png-44.6kB

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

通過對上面組件在Kubernetes的部署情況的分析,可以看到目前大部分的大數據組件都已經有項目來支持在Kubernetess上部署,並且借用Kubernetes不同類型的資源管理能力,就能實現對大數據組件的部署。大數據組件的容器化正在從嘗試走向成熟。

騰訊大數據容器化實踐

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

雲原生流計算平台Oceanus容器化實踐

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

image.png-49.2kB

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

image.png-171.4kB

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

QAPM數據分析平台全面容器化實踐

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

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

image.png-185.2kB

在實時計算中,數據從客戶端上報后,使用kafka進行轉發,然后直接經過Flink進行流式處理。處理完后數據寫入入ES,Postgres,Druid等后端存儲,用於前台的展示與查詢。

image.png-82.4kB

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

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

總結

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

參考鏈接:

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


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM