作者顏衛(wèi)，騰訊高級(jí)后臺(tái)開(kāi)發(fā)工程師，專(zhuān)注于Kubernetes大規(guī)模集群管理和資源調(diào)度，有過(guò)萬(wàn)級(jí)集群的管理運(yùn)維經(jīng)驗(yàn)。目前負(fù)責(zé)騰訊云TKE大規(guī)模Kubernetes集群的大數(shù)據(jù)應(yīng)用托管服務(wù)。
大數(shù)據(jù)技術(shù)起源于Google在2004年前后發(fā)表的三篇論文，分布式文件系統(tǒng)GFS、分布式計(jì)算框架MapReduce和NoSQL數(shù)據(jù)庫(kù)系統(tǒng)BigTable，俗稱(chēng)'三駕馬車(chē)'。在論文發(fā)表后，Lucene開(kāi)源項(xiàng)目的創(chuàng)始人Doug Cutting根據(jù)論文原理初步實(shí)現(xiàn)了類(lèi)似GFS和MapReduce的功能。并在2006年，將該部分功能設(shè)置成獨(dú)立的項(xiàng)目即大名鼎鼎的Hadoop項(xiàng)目。Hadoop項(xiàng)目中主要包括分布式文件系統(tǒng)HDFS和大數(shù)據(jù)計(jì)算引擎MapReduce兩個(gè)組件。
在早期，MapReduce既是一個(gè)執(zhí)行引擎，又是一個(gè)資源調(diào)度框架，集群的資源調(diào)度管理由MapReduce自己完成。但是這樣不利于資源復(fù)用，也使得MapReduce非常臃腫。于是一個(gè)新項(xiàng)目啟動(dòng)了，將MapReduce執(zhí)行引擎和資源調(diào)度分離開(kāi)來(lái)，這就是Yarn。2012年，Yarn成為一個(gè)獨(dú)立的項(xiàng)目開(kāi)始運(yùn)營(yíng)，隨后被各種大數(shù)據(jù)產(chǎn)品支持，成為大數(shù)據(jù)平臺(tái)上最主流的資源調(diào)度系統(tǒng)。伴隨著時(shí)代的發(fā)展，大數(shù)據(jù)場(chǎng)景下的計(jì)算引擎層出不窮，主要的有內(nèi)存式計(jì)算引擎Spark,分布式實(shí)時(shí)計(jì)算Storm,流計(jì)算框架Flink等。這些計(jì)算引擎都使用Yarn進(jìn)行資源管理和調(diào)度。
目前絕大多數(shù)大數(shù)據(jù)平臺(tái)都是基于Hadoop生態(tài)，使用Yarn作為核心組件來(lái)進(jìn)行資源管理和調(diào)度。但這樣的平臺(tái)普遍存在如下問(wèn)題：
(1) 資源彈性不足，無(wú)法按需自動(dòng)擴(kuò)容。大數(shù)據(jù)系統(tǒng)資源的高峰往往具有明顯的周期性。例如實(shí)時(shí)計(jì)算資源消耗主要在白天。離線分析中，日?qǐng)?bào)型的計(jì)算任務(wù)資源的高峰一般在22:00以后。周報(bào)和月報(bào)型的計(jì)算任務(wù)業(yè)務(wù)高峰往往也是在一個(gè)固定的時(shí)間點(diǎn)。并且離線計(jì)算有時(shí)還有突發(fā)的計(jì)算任務(wù)，例如需要對(duì)歷史數(shù)據(jù)做一個(gè)統(tǒng)計(jì)。目前的大數(shù)據(jù)系統(tǒng)普遍缺乏資源的彈性，無(wú)法按需進(jìn)行快速擴(kuò)容，為了應(yīng)對(duì)業(yè)務(wù)高峰和突發(fā)的計(jì)算任務(wù)只能預(yù)留出足夠多的資源來(lái)保證任務(wù)能夠正常響應(yīng)。
(2) 資源利用率低。日志留存和流量清單等存儲(chǔ)密集型的業(yè)務(wù)CPU使用率長(zhǎng)期小于30%。而計(jì)算類(lèi)的業(yè)務(wù)雖然CPU消耗很高，但是存儲(chǔ)的資源使用率小于20%。大量資源閑置。并且考慮在線業(yè)務(wù)往往在低峰期會(huì)有大量的資源閑置。這些資源其實(shí)離線計(jì)算業(yè)務(wù)是完全可以利用的，但目前大數(shù)據(jù)的系統(tǒng)架構(gòu)這部分資源完全沒(méi)有被利用。導(dǎo)致資源利用率進(jìn)一步降低。
(3) 資源隔離性差。從Hadoop2.2.0版本開(kāi)始，Yarn開(kāi)始使用cgroup實(shí)現(xiàn)了CPU資源隔離，通過(guò)JVM提供的內(nèi)存隔離機(jī)制來(lái)實(shí)現(xiàn)內(nèi)存資源隔離。對(duì)于磁盤(pán)IO和網(wǎng)絡(luò)IO的隔離目前社區(qū)還在討論中YARN-2139[2]，YARN-2140[3]。對(duì)于文件系統(tǒng)環(huán)境的隔離，社區(qū)在Hadoop 3.0版本中支持通過(guò)Classpath isolation HADOOP-11656[4]來(lái)避免不同版本的jar包沖突，但無(wú)法做到完整的文件系統(tǒng)隔離。整體上看Yarn的資源隔離做的并不完善，這就造成了，多個(gè)任務(wù)運(yùn)行到同一個(gè)工作節(jié)點(diǎn)上時(shí)，不同任務(wù)之間會(huì)存在資源搶占的問(wèn)題，不同任務(wù)之間相互影響。
(4) 系統(tǒng)管理困難。在大數(shù)據(jù)系統(tǒng)中缺少統(tǒng)一的管理接口，也缺少路由管理，網(wǎng)絡(luò)管理，磁盤(pán)管理等能力。這就造成大數(shù)據(jù)平臺(tái)的開(kāi)發(fā)往往需要對(duì)管理系統(tǒng)進(jìn)行深度定制。開(kāi)發(fā)工作量大，系統(tǒng)管理困難，并且平臺(tái)遷移困難。例如大數(shù)據(jù)平臺(tái)中需要提供對(duì)大數(shù)據(jù)組件UI頁(yè)面的訪問(wèn)能力。在大數(shù)據(jù)平臺(tái)構(gòu)建中，為了能夠訪問(wèn)組件的UI頁(yè)面往往需要單獨(dú)進(jìn)行網(wǎng)絡(luò)的打通，進(jìn)行額外的路由的配置。并且很多時(shí)候這些配置都缺少標(biāo)準(zhǔn)的接口，無(wú)法做到自動(dòng)化，管理起來(lái)十分困難。
(5) 管理方式不統(tǒng)一。在線業(yè)務(wù)和大數(shù)據(jù)業(yè)務(wù)雖然屬于不同的業(yè)務(wù)類(lèi)型，但就管理平臺(tái)來(lái)說(shuō)提供的功能是類(lèi)似的。主要提供資源管理，業(yè)務(wù)(任務(wù))管理，權(quán)限管理，可視化展示與操作等方面的功能。但因?yàn)楣芾矸绞讲唤y(tǒng)一，底層框架與運(yùn)行方式不同，造成了在線業(yè)務(wù)和大數(shù)據(jù)業(yè)務(wù)往往需要開(kāi)發(fā)不同的平臺(tái)，由不同的團(tuán)隊(duì)運(yùn)維來(lái)管理，這極大的增加了額外的人力投入，造成不必要的人力損失。
Kubernetes是谷歌開(kāi)源的生產(chǎn)級(jí)的容器編排系統(tǒng)，在谷歌內(nèi)部長(zhǎng)達(dá)15年的使用積累，依賴(lài)其對(duì)功能場(chǎng)景的清晰定義，聲明式API的簡(jiǎn)潔易用，充分的擴(kuò)展性，逐步在容器編排領(lǐng)域的競(jìng)爭(zhēng)中勝出，成為這一領(lǐng)域的領(lǐng)導(dǎo)者。伴隨著微服務(wù)，DevOps，持續(xù)交付等概念的興起和持續(xù)發(fā)酵，并依托于云原生計(jì)算基金會(huì)CNCF[5]，Kubernetes保持著高速發(fā)展，正在成為'云計(jì)算時(shí)代的操作系統(tǒng)'。
Kubernetes究竟有多熱門(mén)，根據(jù)CNCF年初(2020)的統(tǒng)計(jì)數(shù)據(jù)，在2019年84%的企業(yè)在生產(chǎn)環(huán)境中使用了Kubernetes。隨著在生產(chǎn)環(huán)境的廣泛使用，Kubernetes的成熟度已經(jīng)得到了大范圍的檢驗(yàn)。很多公司已經(jīng)提出了所有組件容器化的目標(biāo)，借助云原生的技術(shù)，來(lái)提升組件運(yùn)維管理和研發(fā)流程的效率。
對(duì)于在線業(yè)務(wù)，使用容器技術(shù)能夠很好的提高資源使用率，基于容器構(gòu)建CI/CD流程可以大幅提升研發(fā)效能和系統(tǒng)管理能力，使用集群的自動(dòng)伸縮功能可以根據(jù)需要?jiǎng)討B(tài)申請(qǐng)和釋放資源，提高資源使用的彈性。那么在大數(shù)據(jù)場(chǎng)景下，使用容器能否解決大數(shù)據(jù)平臺(tái)目前遇到的問(wèn)題呢？
首先對(duì)于資源彈性不足的問(wèn)題，Kubernetes可以通過(guò)彈性擴(kuò)縮容來(lái)實(shí)現(xiàn)業(yè)務(wù)高峰時(shí)的快速擴(kuò)容，避免為了應(yīng)對(duì)業(yè)務(wù)高峰預(yù)留過(guò)多的資源。更進(jìn)一步可以直接使用無(wú)服務(wù)計(jì)算(Serverless)技術(shù)，直接將大數(shù)據(jù)業(yè)務(wù)跑在無(wú)服務(wù)計(jì)算的容器上，做到按需使用和付費(fèi)，使資源的使用完全彈性。
對(duì)于資源使用率低的問(wèn)題。一方面Kubernetes支持更加細(xì)粒度的資源劃分，這樣可以盡量做到資源能用盡用，最大限度的按需使用。另外一方面支持更加靈活的調(diào)度，并根據(jù)業(yè)務(wù)SLA的不同，業(yè)務(wù)高峰的不同，通過(guò)資源的超賣(mài)和混合部署來(lái)進(jìn)一步提升資源使用率。由于在線業(yè)務(wù)和離線業(yè)務(wù)兩者之間SLA要求明顯不同，業(yè)務(wù)高峰期也明顯不同，容器化后使用離線在線混合部署，一般對(duì)資源使用率的提升在30%以上。
對(duì)于資源隔離性差的問(wèn)題。容器技術(shù)從一開(kāi)始就支持不同資源的隔離。CPU，內(nèi)存，磁盤(pán)IO，網(wǎng)絡(luò)IO，設(shè)備等這些都有比較完整的支持。在線業(yè)務(wù)使用容器技術(shù)，通過(guò)Kubernetes編排系統(tǒng)能夠很好的將不同業(yè)務(wù)實(shí)例混合部署到相同的節(jié)點(diǎn)上，實(shí)例之間使用隔離技術(shù)，完整的隔離，相互之間完全不受影響。
對(duì)于系統(tǒng)管理困難的問(wèn)題，Kubernetes不僅提供資源管理的能力，還提供路由管理，網(wǎng)絡(luò)管理，監(jiān)控日志等多方面的能力。同時(shí)對(duì)外通過(guò)統(tǒng)一的聲明式API進(jìn)行訪問(wèn)?；贙ubernete構(gòu)建大數(shù)據(jù)平臺(tái)，可以極大的簡(jiǎn)化系統(tǒng)開(kāi)發(fā)的難度，減少系統(tǒng)管理的復(fù)雜度。例如在大數(shù)據(jù)平臺(tái)中，使用Kubernetes提供的路由管理能力Service[7]和 Ingress[8]可以十分方便實(shí)現(xiàn)對(duì)大數(shù)據(jù)組件UI的訪問(wèn)，并且Kubernetes還提供標(biāo)準(zhǔn)的聲明式API來(lái)管理，極大的簡(jiǎn)化了自動(dòng)化的復(fù)雜度。
如果在線業(yè)務(wù)和大數(shù)據(jù)業(yè)務(wù)都統(tǒng)一使用容器化的方式來(lái)部署，使用Kubernetes編排框架來(lái)管理。這樣就能將大數(shù)據(jù)業(yè)務(wù)和在線業(yè)務(wù)在同一個(gè)平臺(tái)中實(shí)現(xiàn)管理和運(yùn)維。避免平臺(tái)管理團(tuán)隊(duì)的人員分散，大大提高平臺(tái)管理團(tuán)隊(duì)工作效率。
大數(shù)據(jù)組件眾多，按照類(lèi)別大致可以分為文件存儲(chǔ)系統(tǒng)，NoSQL數(shù)據(jù)庫(kù)，計(jì)算框架，消息中間件，查詢(xún)分析等。常用的大數(shù)據(jù)組件具體的分類(lèi)如下表所示：
| 大數(shù)據(jù)組件分類(lèi) | 代表性組件 | 主要作用 |
|---|---|---|
| 文件存儲(chǔ)系統(tǒng) | HDFS | 數(shù)據(jù)底層存儲(chǔ) |
| NoSQL數(shù)據(jù)庫(kù) | Hbase、MongoDB | 非結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ) |
| 計(jì)算框架 | Hadoop MapReduce、Spark、Storm、Flink | 離線計(jì)算和流計(jì)算 |
| 消息系統(tǒng) | Kafka、ZeroMQ、RabbitMQ | 消息存儲(chǔ)和轉(zhuǎn)發(fā) |
| 數(shù)據(jù)查詢(xún)分析 | Hive、Impala、Druid | 數(shù)據(jù)查詢(xún)和分析 |
這些組件現(xiàn)在一般都有對(duì)應(yīng)的開(kāi)源項(xiàng)目來(lái)支持部署到Kubernetes上，本文將對(duì)一些常用的組件在Kubernetes的部署進(jìn)行分析。
HDFS on Kubernetes
HDFS主要包括Datanode，Namenode和Journalnode三個(gè)組件。在Kubernetes中進(jìn)行部署時(shí)，由于Datanode需要存儲(chǔ)HDFS中的數(shù)據(jù)，對(duì)磁盤(pán)要求非常高，所以在Kubernetes中部署時(shí)Datanode采用DaemonSet[9]的方式進(jìn)行部署，每個(gè)存儲(chǔ)節(jié)點(diǎn)部署一個(gè)Datanode實(shí)例。而Namenode和Journalnode由于需要保持名稱(chēng)不變，在Kubernetes中采用StatefulSet[10]的方式進(jìn)行部署。
長(zhǎng)按識(shí)別下方二維碼，查看Kubernetes-HDFS項(xiàng)目更多細(xì)節(jié)：
Hbase on Kubernetes
Hbase主要包括兩種類(lèi)型的節(jié)點(diǎn)，HMaster節(jié)點(diǎn)和HRegionServer節(jié)點(diǎn)。其中HMaster節(jié)點(diǎn)作為主節(jié)點(diǎn)，負(fù)責(zé)管理多個(gè)HRegionServer節(jié)點(diǎn)。HRegionServer節(jié)點(diǎn)作為worker節(jié)點(diǎn)，負(fù)責(zé)管理各個(gè)region。由于Hbase的實(shí)際數(shù)據(jù)存儲(chǔ)在HDFS中，Hbase本身并不存儲(chǔ)數(shù)據(jù)，所以HMaster和HRegionServer并不需要掛載磁盤(pán)。只是為了保持實(shí)例名稱(chēng)不變，HMaster和HRegionServer都采用StatefulSet的方式進(jìn)行部署。
長(zhǎng)按識(shí)別下方二維碼，查看Hbase項(xiàng)目更多細(xì)節(jié)：
Hive on Kubernetes
Hive主要包括hive-Server和metastore兩個(gè)組件。其中hive-Server作為訪問(wèn)入口，可以按照在線服務(wù)一樣使用Deployment[11]進(jìn)行部署。metastore因?yàn)樾枰３置Q(chēng)不變，所以使用了StatefulSet的方式進(jìn)行部署。
Spark on Kubernetes
Spark是大數(shù)據(jù)領(lǐng)域比較早做容器化的一個(gè)組件。Spark從2.3版本支持原生的方式將任務(wù)跑在Kubernetes上。具體的實(shí)現(xiàn)原理如上圖所示，通過(guò)spark-submit腳本向kube-apiserver提交創(chuàng)建請(qǐng)求，先創(chuàng)建spark的driver實(shí)例。然后driver實(shí)例按照任務(wù)執(zhí)行需要的資源大小，向kube-apiserver發(fā)起請(qǐng)求，創(chuàng)建對(duì)應(yīng)的executor實(shí)例，由executor實(shí)例來(lái)執(zhí)行任務(wù)。Driver實(shí)例通過(guò)監(jiān)聽(tīng)kube-apiserver中pod的信息，對(duì)executor實(shí)例的生命周期進(jìn)行管理。
長(zhǎng)按識(shí)別下方二維碼，查看Spark項(xiàng)目更多細(xì)節(jié)：
Flink on Kubernetes
Flink與Spark類(lèi)似，在其內(nèi)核中直接對(duì)接了Kubernetes的kube-apiserver，以提高資源的使用效率。在Flink Client提交后，會(huì)先創(chuàng)建Flink Job Manager實(shí)例，然后再由Job Manager會(huì)調(diào)用Kubernetes的接口，根據(jù)任務(wù)的并行度來(lái)動(dòng)態(tài)的創(chuàng)建對(duì)應(yīng)的TaskManager實(shí)例。
長(zhǎng)按識(shí)別下方二維碼，查看Flink項(xiàng)目更多細(xì)節(jié)：
通過(guò)對(duì)上面組件在Kubernetes的部署情況的分析，可以看到目前大部分的大數(shù)據(jù)組件都已經(jīng)有項(xiàng)目來(lái)支持在Kubernetess上部署，并且借用Kubernetes不同類(lèi)型的資源管理能力，就能實(shí)現(xiàn)對(duì)大數(shù)據(jù)組件的部署。大數(shù)據(jù)組件的容器化正在從嘗試走向成熟。
近兩年騰訊內(nèi)部多個(gè)部門(mén)展開(kāi)了大數(shù)據(jù)容器化的實(shí)踐，并取得了非常不錯(cuò)的效果。充分證明了大數(shù)據(jù)容器化的可行性和大數(shù)據(jù)容器化在簡(jiǎn)化運(yùn)維管理成本，提升資源利用率上的效果。
Oceanus[12] 是騰訊云推出的流計(jì)算產(chǎn)品，其基于 Apache Flink 構(gòu)建，提供全托管的云上服務(wù)，最大規(guī)模可達(dá)萬(wàn)億級(jí)。使用流計(jì)算平臺(tái)Oceanus 可以方便的進(jìn)行云端流式數(shù)據(jù)匯聚、計(jì)算，輕松的構(gòu)建網(wǎng)站點(diǎn)擊流分析、電商精準(zhǔn)推薦、物聯(lián)網(wǎng) IoT 等應(yīng)用。
近期騰訊云容器團(tuán)隊(duì)和大數(shù)據(jù)團(tuán)隊(duì)聯(lián)合推出了Oceanus on TKE[13](Tencent Kubernetes Engine)版本，通過(guò)將流計(jì)算任務(wù)運(yùn)行在Kubernetes上，高效的解決了資源管理和隔離的問(wèn)題。同時(shí)使用容器統(tǒng)一的日志采集方案，實(shí)現(xiàn)更好的日志采集和查看。另外使用Kubernetes提供的Ingress能力，靈活的支持查看各個(gè)大數(shù)據(jù)組件的運(yùn)維頁(yè)面。
騰訊云容器團(tuán)隊(duì)和大數(shù)據(jù)團(tuán)隊(duì)正打算將大數(shù)據(jù)組件逐步都運(yùn)行到Kubernetes上，以實(shí)現(xiàn)更好的資源隔離和資源管控。為客戶(hù)提供在離線統(tǒng)一的管理平臺(tái)，達(dá)到資源運(yùn)維管理的極簡(jiǎn)化，資源運(yùn)行效率的極大化。
QAPM（Quick Application Performance Monitor) 數(shù)據(jù)分析平臺(tái)是騰訊云推出的客戶(hù)端性能分析平臺(tái)，其依托于騰訊云的全方位定位檢測(cè)APP性能的專(zhuān)項(xiàng)解決方案，實(shí)現(xiàn)對(duì)APP性能的高效性能分析。2018年，在開(kāi)始設(shè)計(jì)和開(kāi)發(fā)QAPM平臺(tái)時(shí)，為了在云上充分利用資源的彈性，在云下支持私有化交付，并且盡可能降低管理成本，平臺(tái)在設(shè)計(jì)之初就采用全容器化的方式進(jìn)行部署。
具體的業(yè)務(wù)流程包括離線計(jì)算和流計(jì)算兩個(gè)主要部分。在離線計(jì)算中，數(shù)據(jù)從客戶(hù)端上報(bào)后，使用kafka進(jìn)行轉(zhuǎn)發(fā)，然后將數(shù)據(jù)通過(guò)Hive寫(xiě)入HDFS。Spark計(jì)算引擎把數(shù)據(jù)讀出，經(jīng)過(guò)處理后將處理的結(jié)果存入ES，Postgres，Druid等后端存儲(chǔ)，用于前臺(tái)的展示與查詢(xún)。
在實(shí)時(shí)計(jì)算中，數(shù)據(jù)從客戶(hù)端上報(bào)后，使用kafka進(jìn)行轉(zhuǎn)發(fā)，然后直接經(jīng)過(guò)Flink進(jìn)行流式處理。處理完后數(shù)據(jù)寫(xiě)入入ES，Postgres，Druid等后端存儲(chǔ)，用于前臺(tái)的展示與查詢(xún)。
因?yàn)樗薪M件都使用容器化部署，每個(gè)組件都設(shè)計(jì)成了單獨(dú)的Charts包，這樣部署新的環(huán)境變得非常簡(jiǎn)單。之前按照傳統(tǒng)的方式部署一套完整的環(huán)境，花費(fèi)的時(shí)間在兩天甚至更多。但因?yàn)槭褂昧巳萜骰渴?，一般半小時(shí)以?xún)?nèi)就可以完成部署和相關(guān)配置的修改。極大的提升了效率。
為了進(jìn)一步提高資源資源利用率，QAPM平臺(tái)在容器化的基礎(chǔ)上通過(guò)將流計(jì)算業(yè)務(wù)和離線計(jì)算業(yè)務(wù)混合部署到了同一個(gè)集群。使用一個(gè)固定的資源池作為基礎(chǔ)資源，在業(yè)務(wù)高峰期使用彈性擴(kuò)容的方式來(lái)補(bǔ)充資源，使整體資源使用效率提升了30%~50%。
大數(shù)據(jù)與容器編排技術(shù)，一個(gè)是在數(shù)據(jù)處理領(lǐng)域歷史相對(duì)比較長(zhǎng)久的互聯(lián)網(wǎng)的基石技術(shù)，一個(gè)是在業(yè)務(wù)編排領(lǐng)域近年來(lái)才興起的新興技術(shù)。兩者本來(lái)都在各自的生態(tài)中處于不斷發(fā)展壯大的階段，相互直接融合比較少。但近年來(lái)隨著Kubernete技術(shù)的成熟，使大數(shù)據(jù)容器化從設(shè)想變成了可能。通過(guò)容器化技術(shù)可以像在線業(yè)務(wù)場(chǎng)景一樣在大數(shù)據(jù)場(chǎng)景進(jìn)一步提升運(yùn)維管理和資源使用的效率，進(jìn)一步釋放大數(shù)據(jù)的活力。
文章來(lái)源：騰訊云原生 / 原文鏈接
聯(lián)系客服
