MRv1與YARN集羣共享HDFS存儲的技術實現
以服務化爲起點，雲梯集羣已將Hadoop分爲存儲（HDFS）服務與計算（MRv1和YARN）服務。兩個計算集羣共享着這個HDFS存儲集羣，這是怎麼做到的呢？
在引入YARN之前，雲梯的Hadoop是一個基於Apache Hadoop 0.19.1-dc版本，並增加許多新功能的版本。另外還兼容了Apache Hadoop 0.19、0.20、CDH3版本的客戶端。爲了保持對客戶端友好，雲梯服務端升級總會保持對原有客戶端的兼容性。另外，爲了訪問數據的便捷性，阿里的存 儲集羣是一個單一的大集羣，引入YARN不應迫使HDFS集羣拆分，但YARN是基於社區0.23系列版本，它無法直接訪問雲梯HDFS集羣。因此實現 YARN集羣訪問雲梯的HDFS集羣是引入YARN後第一個需要解決的技術問題。
Hadoop代碼主要分爲Common、HDFS、Mapred三個包。
- Common部分包括公共類，如I/O、通信等類。
- HDFS部分包括HDFS相關類，依賴Common包。
- Mapred部分包括MapReduce相關代碼，依賴Common包和HDFS包。
爲了儘量減少對雲梯HDFS的修改，開發人員主要做了以下工作。
- 使用雲梯的HDFS客戶端代碼替換0.23中HDFS，形成新的HDFS包。
- 對0.23新的HDFS包做了少量的修改使其可以運行在0.23的Common包上。
- 對0.23新的HDFS包做了少量修改使0.23的Mapred包能運行在新的HDFS包。
- 對雲梯的Common包的通信部分做了hack，使其兼容0.23的Common。
圖1 雲梯Hadoop代碼架構
新的雲梯代碼結構如圖1所示，相應闡述如下。
服務端
- 存儲部分使用原有的HDFS。
- MRv1計算集羣中提供原MRv1服務。
- YARN集羣提供更豐富的應用服務。
客戶端
- 雲梯現有的客戶端不做任何修改，繼續使用原有的服務。
- 使用YARN的服務需要使用新客戶端。
雲梯MR服務切換爲YARN要經過三個階段
- 服務端只有MRv1， 客戶端只有老版本客戶端。
- 服務端MRv1和YARN共存（MRv1資源逐漸轉移到YARN上）， 客戶端若需使用MRv1服務則保持客戶端不變；若需使用YARN服務則需使用新版客戶端。
- 服務端只剩下YARN，客戶端只有新版本客戶端。
通過上述修改，雲梯開發人員以較小的修改實現了YARN對雲梯HDFS的訪問。
Spark on YARN的實現
雲梯版YARN集羣已實現對MRv2、Hive、Spark、MPI、RHive、RHadoop等應用的支持。雲梯集羣當前結構如圖2所示。
圖2 雲梯架構圖
其中，Spark已成爲YARN集羣上除MapReduce應用外另一個重要的應用。
Spark是一個分佈式數據快速分析項目。它的核心技術是彈性分佈式數據集（Resilient Distributed Datasets），提供了比MapReduce豐富的模型，可以快速在內存中對數據集進行多次迭代，來支持複雜的數據挖掘算法和圖形計算算法。
Spark 的計算調度方式，從Mesos到Standalone，即自建Spark計算集羣。雖然Standalone方式性能與穩定性都得到了提升，但自建集羣畢 竟資源較少，並需要從雲梯集羣複製數據，不能滿足數據挖掘與計算團隊業務需求。而Spark on YARN能讓Spark計算模型在雲梯YARN集羣上運行，直接讀取雲梯上的數據，並充分享受雲梯YARN集羣豐富的計算資源。
Spark on YARN功能理論上從Spark 0.6.0版本開始支持，但實際上還遠未成熟，經過數據挖掘與計算團隊長時間的壓力測試，修復了一些相對關鍵的Bug，保證Spark on YARN的穩定性和正確性。
圖3展示了Spark on YARN的作業執行機制。
圖3 Spark on YARN框架
基於YARN的Spark作業首先由客戶端生成作業信息，提交給ResourceManager，ResourceManager在某一 NodeManager彙報時把AppMaster分配給NodeManager，NodeManager啓動 SparkAppMaster，SparkAppMaster啓動後初始化作業，然後向ResourceManager申請資源，申請到相應資源後 SparkAppMaster通過RPC讓NodeManager啓動相應的SparkExecutor，SparkExecutor向 SparkAppMaster彙報並完成相應的任務。此外，SparkClient會通過AppMaster獲取作業運行狀態。
目前，數據挖掘與計算團隊通過Spark on YARN已實現MLR、PageRank和JMeans算法，其中MLR已作爲生產作業運行。
雲梯YARN集羣維護經驗分享
雲梯YARN的維護過程中遇到許多問題，這些問題在維護YARN集羣中很有可能會遇到，這裏分享兩個較典型的問題與其解決方法。
- 問題1
問題描述：社區的CPU隔離與調度功能，需要在每個NodeManager所在的機器創建用戶賬戶對應的Linux賬戶。但阿里雲梯集羣有5000多個賬 戶，是否需要在每個NodeManager機器創建這麼多Linux賬戶；另外每次創建或刪除一個Hadoop用戶，也應該在每臺NodeManager 機器上創建或刪除相應的Linux賬戶，這將大大增加運維的負擔。
問題分析：我們發現，CPU的隔離是不依賴於Linux賬戶的，意味着即 使同一個賬戶創建兩個進程，也可通過Cgroup進行CPU隔離，但爲什麼社區要在每臺NodeManager機器上創建賬戶呢？原來這是爲了讓每個 Container都以提交Application的賬戶執行，防止Container所屬的Linux賬戶權限過大，保證安全。但云梯集羣很早前就已分 賬戶，啓動Container的Linux賬戶統一爲一個普通賬戶，此賬戶權限較小，並且用戶都爲公司內部員工，安全性已能滿足需求。
解決方案：通過修改container-executor.c文件，防止其修改Container的啓動賬戶，並使用一個統一的普通Linux賬戶（無sudo權限）運行Container。這既能保證安全，又能減少運維的工作量。
- 問題2
問題描述：MRApplicationMaster初始化慢，某些作業的MRApplicationMaster啓動耗時超過一分鐘。
問 題分析：通過檢查MRApplication-Master的日誌，發現一分鐘的初始化時間都消耗在解析Rack上。從代碼上分 析，MRApplicationMaster啓動時需要初始化TaskAttempt，這時需要解析split信息中的Host，生成對應的Rack信 息。雲梯當前解析Host的方法是通過調用外部一個Python腳本解析，每次調用需要20ms左右，而由於雲梯HDFS集羣非常大，有4500多臺機 器，假如輸入數據分佈在每個Datanode上，則解析Host需要花費4500×20ms=90s；如果一個作業的輸入數據較大，且文件的備份數爲3， 那麼輸入數據將很有可能分佈在集羣的大多Datanode上。
解決方案：開發人員通過在Node-Manager上增加一個配置文件，包含所有Datanode的Rack信息，MRApp-licationMaster啓動後加載此文件，防止頻繁調用外部腳本解析。這大大加快了MRApplicationMaster的初始化速度。
此外，雲梯開發人員還解決了一些會使ResourceManager不工作的Bug，並貢獻給Apache Hadoop社區。
在搭建與維護雲梯YARN集羣期間，雲梯開發人員遇到並解決了許多問題，分析和解決這些問題首先需要熟悉代碼，但代碼量巨大，我們如何能快速熟悉它們呢？這 需要團隊的配合，團隊中每個人負責不同模塊，閱讀後輪流分享，這能加快代碼熟悉速度。另外，Hadoop的優勢在於可以利用社區的力量，當遇到一個問題 時，首先可以到社區尋找答案，因爲很多問題在社區已得到了解決，充分利用社區，可以大大提高工作效率。
雲梯YARN集羣的優勢與未來之路
當前雲梯YARN集羣已經試運行，並有MRv2、Hive、Spark、RHive和RHadoop等應用。雲梯YARN集羣的優勢在於：
- 支持更豐富的計算模型；
- 共享雲梯最大的存儲集羣，訪問便捷、快速；
- AppHistory信息存儲在HDFS上，各種應用的作業歷史都能方便查看；
- 相對於MRv1集羣，雲梯YARN能支持更大規模的集羣；
- 相對於MRv1集羣，雲梯YARN集羣支持內存和CPU調度，資源利用將更加合理。
未來，雲梯將會把大多業務遷移到雲梯YARN集羣。針對YARN版本，雲梯將增加資源隔離與調度，增加對Storm、Tez等計算模型的支持，並優化YARN的性能。
作者沈洪，花名俞靈，就職於阿里巴巴集團數據平臺事業部海量數據部門，目前從事YARN、MapReduce的研究、開發與集羣的維護。
本文爲《程序員》原創文章，未經允許不得轉載，如需轉載請聯繫market#csdn.net(#換成@)
