郭紹斌

摘要：由于軟件需求和版本的升級，軟件代碼的重構(gòu)與演化成為軟件維護(hù)的主要手段和關(guān)鍵技術(shù)需求。Hadoop分布式軟件隨著分布式大數(shù)據(jù)處理技術(shù)的不斷發(fā)展，版本不斷地升級，隨之而來的是基于Hadoop平臺的應(yīng)用軟件也需要升級。這種升級過程為軟件演化技術(shù)的提出了新的挑戰(zhàn)。該文針對基于Hadoop平臺應(yīng)用軟件的演化方法和技術(shù)進(jìn)行討論，結(jié)合具體實例探討演化方法實現(xiàn)的技術(shù)過程，驗證演化方法和技術(shù)的有效性。該文主要討論Hadoop平臺應(yīng)用軟件演化中的功能移植和計算速度提升問題。在功能移植方面，研究了Hadoop1.0到升級到版本2.0的基礎(chǔ)類庫的映射關(guān)系，包括MapRe-duce的演化過程，并分析了Hadoop版本演化代碼復(fù)雜度;在速度提升方面，針對MapReduce任務(wù)進(jìn)行演化，并給出了Ma-preduce磁盤讀寫操作到內(nèi)存操作改進(jìn)算法，以及MapReduce作業(yè)如何轉(zhuǎn)換成Spark作業(yè)的算法。最后，對企業(yè)ETL處理中InnerJoin應(yīng)用進(jìn)行案例研究，詳細(xì)分析MapReduce和Spark編程模式下，InnerJoin的應(yīng)用差異。

關(guān)鍵詞：大數(shù)據(jù);Hadoop;Spark;MapReduce;軟件演化

中圖分類號：TP311 文獻(xiàn)標(biāo)識碼：A

文章編號：1009-3044（2019）31-0059-02

1研究背景

IDC最近的一份報告聲稱數(shù)字世界每兩年增加一倍，并在2013年至2020年間增加10倍;從4.4萬億千兆字節(jié)到41萬億千兆字節(jié)。近年來，由于社交游戲和地理空間應(yīng)用程序的普及，數(shù)據(jù)生成和分析取得了巨大的飛躍。在任何給定的時間，大約有一千萬人登錄他們最喜歡的社交游戲，如來自King的Candv Crush Saga或來自Supercell的Clash of Clans。Poke-non GO最近的熱潮更是說明了數(shù)據(jù)增長的必然性以及在最高存儲要求下更快處理的必要性。換句話說，在不久的將來，大數(shù)據(jù)處理過程中，各種組件的技術(shù)必定會進(jìn)步。

在過去十年中，Apache Hadoop平臺已經(jīng)成為處理大數(shù)據(jù)分析的最著名的開源框架之一，Hadoop分布式文件系統(tǒng)（HDFS）是Hadoop的底層存儲引擎。當(dāng)前的Hadoop生態(tài)系統(tǒng)包含傳統(tǒng)的批處理框架，如Mapmduce，以及基于內(nèi)存的DAG執(zhí)行框架，如Spark，用于迭代和交互式處理。HDFS以其可擴(kuò)展性和可靠性而聞名，為這些處理框架提供存儲功能。隨著信息時代的到來，Hadoop和HDFS等大數(shù)據(jù)系統(tǒng)正在高性能計算（HPC）集群中廣泛部署。

Hadoop版本從之前的1.x版本更新到2.x、3.x，其中對HDFS、MapReduce、任務(wù)管理、資源分配、拓展性都進(jìn)行了升級演化，更好的支持和滿足現(xiàn)在大數(shù)據(jù)處理中儲存的速度大小、計算的速度和耗費資源、資源管理、其它組件的支持性和擴(kuò)展性的需求。

2Hadoop版本演化復(fù)雜度分析

Hadoop作為一個開源的掛架，其源碼可以從gRhub克隆到本地進(jìn)行分析。目前Hadoop一共有191名代碼開發(fā)人員，發(fā)布了315個小版本、273個分支、22000次代碼提交，不斷提升Ha-doop的計算性能和擴(kuò)展性支持。

使用eclipse的JDT API來獲取Hadoop中各個類和包的關(guān)系。結(jié)合UML建模原則，類之間的關(guān)系主要包括繼承、關(guān)聯(lián)、依賴和實現(xiàn)。根據(jù)軟件架構(gòu)質(zhì)量度量指標(biāo)對Hadoop1.0.3、Ha-doop2.2.0、Hadoop2.4.0、Hadoop2.6.0、Hadoop2.7.3等版本源碼進(jìn)行分析。先分別求出hadoop-client-common和core包中各個類代碼行數(shù)的平均值，這個指標(biāo)是一個維度指標(biāo)，對于開發(fā)者而言，代碼行數(shù)越多，類越難讀懂，從而增加軟件架構(gòu)的復(fù)雜度。從下圖分析得出，Hadoop隨著版本的演化，其復(fù)雜度是在降低的。

3MapReduce任務(wù)演化

在Hadoop 2.0中引入了Yarn框架，Yarn框架中將Job-Tracker資源分配和作業(yè)控制分開，分為Resource Manager（RM）以及Application Master（AM），而Yarn框架作為一個通用的資源調(diào)度和管理模塊，同時支持多種其它的編程模型，比如最出名的sDark。

Yarn的主要三個組件如下：

Resource Manager：ResourceManager包含兩個主要的組件：定時調(diào)用器（Scheduler）以及應(yīng)用管理器（ApplieationManager）。

Application Master：每個應(yīng)用程序的ApplicationMaster負(fù)責(zé)從Scheduler申請資源，以及跟蹤這些資源的使用情況以及任務(wù)進(jìn)度的監(jiān)控。

Node Manager：NodeManager是ResourceManager在每臺機(jī)器的上代理，負(fù)責(zé)容器的管理，并監(jiān)控他們的資源使用情況（cpu，內(nèi)存，磁盤及網(wǎng)絡(luò)等），以及向ResourceManager/Scheduler提供這些資源使用報告。

在MapReduce編程模型中，Mapper、Reducer中封裝了應(yīng)用程序的數(shù)據(jù)處理邏輯。MapReduce要求所有儲存在HDFS上的數(shù)據(jù)解釋成鍵值對，經(jīng)過map、reduce函數(shù)處理，形成新的鍵值對。Hadoop1.0中，Mapper和Reducer類體系非常相似，其中包括四個方面的演化：Mapper由接口變成抽象類，且不再繼承JobConffigurable和Closeable兩個接口，而是直接在類中添加set-up和cleanup兩個方法進(jìn)行初始化和清理工作;將參數(shù)封裝到Context對象中，這使得接口具有良好的擴(kuò)展性;去掉MapRun-nable接口，在Mapper中添加run方法，以便用戶定制mapf）方法的調(diào)用;Reducer遍歷value的迭代器類型編程java.lang.Iter-able，使得用戶可以參用foreach形式遍歷所有value。

4ETL中InnerJoin任務(wù)編程模型演化

在企業(yè)ETL處理中，對兩個數(shù)據(jù)集根據(jù)key進(jìn)行inner join，是數(shù)據(jù)處理中常見的需求。MapReduce編程和Spark編程方面有很大的區(qū)別，MapReduce采用Java語言編程，Spark主要使用Scala語言進(jìn)行編程，如圖所示，MapReduce中的Mapper類轉(zhuǎn)變成Spark編程中map、flatMap、filter等算子，Reducer類轉(zhuǎn)變成re-duceByKey、groupBykey等算子，F(xiàn)ileOutputFormat.setOutputPath（job，outDir）轉(zhuǎn)變成value3.saveAs TextFile（outPath）。

Spark對兩個文件進(jìn)行inner join操作的算法步驟：

在實際計算時，spark會基于streamIter來遍歷，每次取出streamlter中的一條記錄RowA，根據(jù)Join條件計算KeyA，然后根據(jù)該KeyA去buildIter中查找所有滿足Join條件fKeyB=KeyA）的記錄RowBs，并將RowBs中每條記錄分別與RowAjoin得到j(luò)oin后的記錄，最后根據(jù)過濾條件得到最終join的記錄。

根據(jù)不同大小的數(shù)據(jù)集，每個數(shù)據(jù)集分別測試運行5次，MapReduce和Spark平均計算時間統(tǒng)計結(jié)果如下表：

結(jié)果表明，在InnerJoin任務(wù)模型上，MapReduce任務(wù)演化為Spark任務(wù)之后，在不改變運行結(jié)束的前提下，離線計算速度提升10倍，大大的節(jié)省了集群資源開銷。

5總結(jié)

Hadoop2.x版本對MapReduce向前兼容，hadoop2.x的client包中既有基于1.x版本編寫程序所需要的包和類，也有新的Ma-pReduce包和類?；?.x版本MapReduce任務(wù)可以直接在YARN上運行;通過實驗表明Spark計算速度比MapReduce要快10倍以上。從編程角度而言，Scala語言比Java語言編寫的時候要簡明許多。