阿里巴巴作為國(guó)內(nèi)使用Hadoop最早的公司之一，已開啟了Apache Hadoop 2.0時(shí)代。阿里巴巴的Hadoop集群，即云梯集群，分為存儲(chǔ)與計(jì)算兩個(gè)模塊，計(jì)算模塊既有MRv1，也有YARN集群，它們共享一個(gè)存儲(chǔ)HDFS集 群。云梯YARN集群上既支持MapReduce，也支持Spark、MPI、RHive、RHadoop等計(jì)算模型。本文將詳細(xì)介紹云梯YARN集群的 技術(shù)實(shí)現(xiàn)與發(fā)展?fàn)顩r。

MRv1與YARN集群共享HDFS存儲(chǔ)的技術(shù)實(shí)現(xiàn)

以服務(wù)化為起點(diǎn)，云梯集群已將Hadoop分為存儲(chǔ)（HDFS）服務(wù)與計(jì)算（MRv1和YARN）服務(wù)。兩個(gè)計(jì)算集群共享著這個(gè)HDFS存儲(chǔ)集群，這是怎么做到的呢？

在引入YARN之前，云梯的Hadoop是一個(gè)基于Apache Hadoop 0.19.1-dc版本，并增加許多新功能的版本。另外還兼容了Apache Hadoop 0.19、0.20、CDH3版本的客戶端。為了保持對(duì)客戶端友好，云梯服務(wù)端升級(jí)總會(huì)保持對(duì)原有客戶端的兼容性。另外，為了訪問(wèn)數(shù)據(jù)的便捷性，阿里的存 儲(chǔ)集群是一個(gè)單一的大集群，引入YARN不應(yīng)迫使HDFS集群拆分，但YARN是基于社區(qū)0.23系列版本，它無(wú)法直接訪問(wèn)云梯HDFS集群。因此實(shí)現(xiàn) YARN集群訪問(wèn)云梯的HDFS集群是引入YARN后第一個(gè)需要解決的技術(shù)問(wèn)題。

Hadoop代碼主要分為Common、HDFS、Mapred三個(gè)包。

Common部分包括公共類，如I/O、通信等類。
HDFS部分包括HDFS相關(guān)類，依賴Common包。
Mapred部分包括MapReduce相關(guān)代碼，依賴Common包和HDFS包。
為了盡量減少對(duì)云梯HDFS的修改，開發(fā)人員主要做了以下工作。

使用云梯的HDFS客戶端代碼替換0.23中HDFS，形成新的HDFS包。
對(duì)0.23新的HDFS包做了少量的修改使其可以運(yùn)行在0.23的Common包上。
對(duì)0.23新的HDFS包做了少量修改使0.23的Mapred包能運(yùn)行在新的HDFS包。
對(duì)云梯的Common包的通信部分做了hack，使其兼容0.23的Common。

圖1 云梯Hadoop代碼架構(gòu)

新的云梯代碼結(jié)構(gòu)如圖1所示，相應(yīng)闡述如下。

服務(wù)端

存儲(chǔ)部分使用原有的HDFS。
MRv1計(jì)算集群中提供原MRv1服務(wù)。
YARN集群提供更豐富的應(yīng)用服務(wù)。
客戶端

云梯現(xiàn)有的客戶端不做任何修改，繼續(xù)使用原有的服務(wù)。
使用YARN的服務(wù)需要使用新客戶端。
云梯MR服務(wù)切換為YARN要經(jīng)過(guò)三個(gè)階段

服務(wù)端只有MRv1， 客戶端只有老版本客戶端。
服務(wù)端MRv1和YARN共存（MRv1資源逐漸轉(zhuǎn)移到Y(jié)ARN上）， 客戶端若需使用MRv1服務(wù)則保持客戶端不變；若需使用YARN服務(wù)則需使用新版客戶端。
服務(wù)端只剩下YARN，客戶端只有新版本客戶端。
通過(guò)上述修改，云梯開發(fā)人員以較小的修改實(shí)現(xiàn)了YARN對(duì)云梯HDFS的訪問(wèn)。

Spark on YARN的實(shí)現(xiàn)

云梯版YARN集群已實(shí)現(xiàn)對(duì)MRv2、Hive、Spark、MPI、RHive、RHadoop等應(yīng)用的支持。云梯集群當(dāng)前結(jié)構(gòu)如圖2所示。

圖2 云梯架構(gòu)圖

其中，Spark已成為YARN集群上除MapReduce應(yīng)用外另一個(gè)重要的應(yīng)用。

Spark是一個(gè)分布式數(shù)據(jù)快速分析項(xiàng)目。它的核心技術(shù)是彈性分布式數(shù)據(jù)集（Resilient Distributed Datasets），提供了比MapReduce豐富的模型，可以快速在內(nèi)存中對(duì)數(shù)據(jù)集進(jìn)行多次迭代，來(lái)支持復(fù)雜的數(shù)據(jù)挖掘算法和圖形計(jì)算算法。

Spark 的計(jì)算調(diào)度方式，從Mesos到Standalone，即自建Spark計(jì)算集群。雖然Standalone方式性能與穩(wěn)定性都得到了提升，但自建集群畢 竟資源較少，并需要從云梯集群復(fù)制數(shù)據(jù)，不能滿足數(shù)據(jù)挖掘與計(jì)算團(tuán)隊(duì)業(yè)務(wù)需求。而Spark on YARN能讓Spark計(jì)算模型在云梯YARN集群上運(yùn)行，直接讀取云梯上的數(shù)據(jù)，并充分享受云梯YARN集群豐富的計(jì)算資源。

Spark on YARN功能理論上從Spark 0.6.0版本開始支持，但實(shí)際上還遠(yuǎn)未成熟，經(jīng)過(guò)數(shù)據(jù)挖掘與計(jì)算團(tuán)隊(duì)長(zhǎng)時(shí)間的壓力測(cè)試，修復(fù)了一些相對(duì)關(guān)鍵的Bug，保證Spark on YARN的穩(wěn)定性和正確性。

圖3展示了Spark on YARN的作業(yè)執(zhí)行機(jī)制。

圖3 Spark on YARN框架

基于YARN的Spark作業(yè)首先由客戶端生成作業(yè)信息，提交給ResourceManager，ResourceManager在某一 NodeManager匯報(bào)時(shí)把AppMaster分配給NodeManager，NodeManager啟動(dòng) SparkAppMaster，SparkAppMaster啟動(dòng)后初始化作業(yè)，然后向ResourceManager申請(qǐng)資源，申請(qǐng)到相應(yīng)資源后 SparkAppMaster通過(guò)RPC讓NodeManager啟動(dòng)相應(yīng)的SparkExecutor，SparkExecutor向 SparkAppMaster匯報(bào)并完成相應(yīng)的任務(wù)。此外，SparkClient會(huì)通過(guò)AppMaster獲取作業(yè)運(yùn)行狀態(tài)。

目前，數(shù)據(jù)挖掘與計(jì)算團(tuán)隊(duì)通過(guò)Spark on YARN已實(shí)現(xiàn)MLR、PageRank和JMeans算法，其中MLR已作為生產(chǎn)作業(yè)運(yùn)行。

云梯YARN集群維護(hù)經(jīng)驗(yàn)分享

云梯YARN的維護(hù)過(guò)程中遇到許多問(wèn)題，這些問(wèn)題在維護(hù)YARN集群中很有可能會(huì)遇到，這里分享兩個(gè)較典型的問(wèn)題與其解決方法。

問(wèn)題1
問(wèn)題描述：社區(qū)的CPU隔離與調(diào)度功能，需要在每個(gè)NodeManager所在的機(jī)器創(chuàng)建用戶賬戶對(duì)應(yīng)的Linux賬戶。但阿里云梯集群有5000多個(gè)賬 戶，是否需要在每個(gè)NodeManager機(jī)器創(chuàng)建這么多Linux賬戶；另外每次創(chuàng)建或刪除一個(gè)Hadoop用戶，也應(yīng)該在每臺(tái)NodeManager 機(jī)器上創(chuàng)建或刪除相應(yīng)的Linux賬戶，這將大大增加運(yùn)維的負(fù)擔(dān)。

問(wèn)題分析：我們發(fā)現(xiàn)，CPU的隔離是不依賴于Linux賬戶的，意味著即 使同一個(gè)賬戶創(chuàng)建兩個(gè)進(jìn)程，也可通過(guò)Cgroup進(jìn)行CPU隔離，但為什么社區(qū)要在每臺(tái)NodeManager機(jī)器上創(chuàng)建賬戶呢？原來(lái)這是為了讓每個(gè) Container都以提交Application的賬戶執(zhí)行，防止Container所屬的Linux賬戶權(quán)限過(guò)大，保證安全。但云梯集群很早前就已分 賬戶，啟動(dòng)Container的Linux賬戶統(tǒng)一為一個(gè)普通賬戶，此賬戶權(quán)限較小，并且用戶都為公司內(nèi)部員工，安全性已能滿足需求。

解決方案：通過(guò)修改container-executor.c文件，防止其修改Container的啟動(dòng)賬戶，并使用一個(gè)統(tǒng)一的普通Linux賬戶（無(wú)sudo權(quán)限）運(yùn)行Container。這既能保證安全，又能減少運(yùn)維的工作量。

問(wèn)題2
問(wèn)題描述：MRApplicationMaster初始化慢，某些作業(yè)的MRApplicationMaster啟動(dòng)耗時(shí)超過(guò)一分鐘。

問(wèn) 題分析：通過(guò)檢查MRApplication-Master的日志，發(fā)現(xiàn)一分鐘的初始化時(shí)間都消耗在解析Rack上。從代碼上分 析，MRApplicationMaster啟動(dòng)時(shí)需要初始化TaskAttempt，這時(shí)需要解析split信息中的Host，生成對(duì)應(yīng)的Rack信 息。云梯當(dāng)前解析Host的方法是通過(guò)調(diào)用外部一個(gè)Python腳本解析，每次調(diào)用需要20ms左右，而由于云梯HDFS集群非常大，有4500多臺(tái)機(jī) 器，假如輸入數(shù)據(jù)分布在每個(gè)Datanode上，則解析Host需要花費(fèi)4500×20ms=90s；如果一個(gè)作業(yè)的輸入數(shù)據(jù)較大，且文件的備份數(shù)為3， 那么輸入數(shù)據(jù)將很有可能分布在集群的大多Datanode上。

解決方案：開發(fā)人員通過(guò)在Node-Manager上增加一個(gè)配置文件，包含所有Datanode的Rack信息，MRApp-licationMaster啟動(dòng)后加載此文件，防止頻繁調(diào)用外部腳本解析。這大大加快了MRApplicationMaster的初始化速度。

此外，云梯開發(fā)人員還解決了一些會(huì)使ResourceManager不工作的Bug，并貢獻(xiàn)給Apache Hadoop社區(qū)。

在搭建與維護(hù)云梯YARN集群期間，云梯開發(fā)人員遇到并解決了許多問(wèn)題，分析和解決這些問(wèn)題首先需要熟悉代碼，但代碼量巨大，我們?nèi)绾文芸焖偈煜に鼈兡?？這 需要團(tuán)隊(duì)的配合，團(tuán)隊(duì)中每個(gè)人負(fù)責(zé)不同模塊，閱讀后輪流分享，這能加快代碼熟悉速度。另外，Hadoop的優(yōu)勢(shì)在于可以利用社區(qū)的力量，當(dāng)遇到一個(gè)問(wèn)題 時(shí)，首先可以到社區(qū)尋找答案，因?yàn)楹芏鄦?wèn)題在社區(qū)已得到了解決，充分利用社區(qū)，可以大大提高工作效率。

云梯YARN集群的優(yōu)勢(shì)與未來(lái)之路

當(dāng)前云梯YARN集群已經(jīng)試運(yùn)行，并有MRv2、Hive、Spark、RHive和RHadoop等應(yīng)用。云梯YARN集群的優(yōu)勢(shì)在于：

支持更豐富的計(jì)算模型；
共享云梯最大的存儲(chǔ)集群，訪問(wèn)便捷、快速；
AppHistory信息存儲(chǔ)在HDFS上，各種應(yīng)用的作業(yè)歷史都能方便查看；
相對(duì)于MRv1集群，云梯YARN能支持更大規(guī)模的集群；
 相對(duì)于MRv1集群，云梯YARN集群支持內(nèi)存和CPU調(diào)度，資源利用將更加合理。
未來(lái)，云梯將會(huì)把大多業(yè)務(wù)遷移到云梯YARN集群。針對(duì)YARN版本，云梯將增加資源隔離與調(diào)度，增加對(duì)Storm、Tez等計(jì)算模型的支持，并優(yōu)化YARN的性能。

最新評(píng)論