企業(yè)在項(xiàng)目中完全使用Hadoop之前，數(shù)據(jù)移動(dòng)是必須解決的事情之一。如何將數(shù)千臺(tái)主機(jī)日志數(shù)據(jù)放入Hadoop?從關(guān)系型或者No/NewSQL系統(tǒng)以及Hadoop中獲取數(shù)據(jù)的最有效方法是什么?如何將Hadoop中生成的Lucene索引輸出到服務(wù)器?這些流程如何實(shí)現(xiàn)自動(dòng)化?

本文是《Hadoop從入門到精通》大型專題的第5章，將完全解答上述問(wèn)題，讓企業(yè)走上無(wú)憂數(shù)據(jù)移動(dòng)之路。本章，我們將首先介紹如何將不同位置和不同格式的數(shù)據(jù)移動(dòng)到Hadoop，之后將講解如何將數(shù)據(jù)移出Hadoop。

5.1 數(shù)據(jù)移動(dòng)的關(guān)鍵要素

將大量數(shù)據(jù)移入和移出Hadoop面臨很多挑戰(zhàn)，包括數(shù)據(jù)一致性和資源對(duì)數(shù)據(jù)源和目標(biāo)的影響。然而，在深入研究這些技術(shù)之前，我們需要討論在處理數(shù)據(jù)移動(dòng)時(shí)應(yīng)該注意的因素。

冪等

在編程中，一個(gè)冪等操作的特點(diǎn)是其任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。換句話說(shuō)，冪等操作無(wú)論執(zhí)行多少次都會(huì)產(chǎn)生相同的結(jié)果。在關(guān)系數(shù)據(jù)庫(kù)中，插入通常不是冪等的，因?yàn)槎啻螆?zhí)行不會(huì)產(chǎn)生相同的結(jié)果數(shù)據(jù)庫(kù)狀態(tài)?；蛘撸峦ǔＪ莾绲鹊?，因?yàn)樗鼈儗a(chǎn)生相同的最終結(jié)果。

無(wú)論何時(shí)寫入數(shù)據(jù)，都應(yīng)該考慮冪等性，Hadoop中的數(shù)據(jù)入口和出口沒(méi)有很大區(qū)別。分布式日志收集框架如何處理數(shù)據(jù)重傳?如何在多個(gè)任務(wù)并行插入數(shù)據(jù)庫(kù)的MapReduce作業(yè)中確保冪等行為?

聚合

數(shù)據(jù)聚合過(guò)程組合了多個(gè)數(shù)據(jù)元素。在數(shù)據(jù)入口的上下文中，這將大量小文件移動(dòng)到HDFS。在實(shí)際操作中，我們可能會(huì)面臨NameNode內(nèi)存以及MapReduce執(zhí)行時(shí)間慢等問(wèn)題，將文件或數(shù)據(jù)聚合在一起可以緩解此類問(wèn)題，這是一個(gè)需要考慮的功能。

數(shù)據(jù)格式轉(zhuǎn)換

數(shù)據(jù)格式轉(zhuǎn)換將一種數(shù)據(jù)轉(zhuǎn)換為另一種格式的操作。通常，源數(shù)據(jù)格式不適合在MapReduce等工具中進(jìn)行處理。例如，如果源數(shù)據(jù)采用多行XML或JSON格式，則可能需要考慮預(yù)處理步驟。這會(huì)將數(shù)據(jù)轉(zhuǎn)換為可以拆分的形式，例如每行一個(gè)JSON或XML元素，或者將其轉(zhuǎn)換為Avro等格式。

數(shù)據(jù)壓縮

數(shù)據(jù)壓縮不僅有助于減少靜態(tài)數(shù)據(jù)的占用空間，而且在讀取和寫入數(shù)據(jù)時(shí)也具有I/O優(yōu)勢(shì)。

可用性和可恢復(fù)性

可恢復(fù)性允許入口或出口工具在操作失敗時(shí)重試。由于任何數(shù)據(jù)源，接收器或Hadoop本身都不可能100%可用，因此在發(fā)生故障時(shí)可重試非常重要。

可靠的數(shù)據(jù)傳輸和數(shù)據(jù)驗(yàn)證

在數(shù)據(jù)傳輸中，檢查正確性的方法是驗(yàn)證數(shù)據(jù)在傳輸過(guò)程中是否發(fā)生損壞。當(dāng)使用異構(gòu)系統(tǒng)(如Hadoop數(shù)據(jù)入口和出口)時(shí)，數(shù)據(jù)通過(guò)不同主機(jī)，網(wǎng)絡(luò)和協(xié)議傳輸只會(huì)增加數(shù)據(jù)傳輸過(guò)程中出現(xiàn)問(wèn)題的可能性。檢查原始數(shù)據(jù)(如存儲(chǔ)設(shè)備)正確性的常用方法是循環(huán)冗余校驗(yàn)(CRC)，這是HDFS內(nèi)部用于維護(hù)塊級(jí)完整性的常用方法。

此外，由于生成數(shù)據(jù)的軟件存在錯(cuò)誤，源數(shù)據(jù)本身可能存在問(wèn)題。在入口時(shí)執(zhí)行數(shù)據(jù)驗(yàn)證允許進(jìn)行一次性檢查，而不是在發(fā)生問(wèn)題時(shí)處理數(shù)據(jù)的所有下游消費(fèi)者，強(qiáng)迫這些消費(fèi)者必須更新以處理數(shù)據(jù)中的錯(cuò)誤。

資源消耗和性能

資源消耗和性能分別是系統(tǒng)資源利用率和系統(tǒng)效率的度量。入口和出口工具通常不會(huì)對(duì)系統(tǒng)施加大量負(fù)載(資源消耗)，除非有非?？捎^的數(shù)據(jù)量。對(duì)于性能，要考慮的問(wèn)題包括工具是否并行執(zhí)行操作，如果是，提供了什么機(jī)制來(lái)調(diào)整并行度。如果數(shù)據(jù)源是生產(chǎn)數(shù)據(jù)庫(kù)并且正在使用MapReduce提取該數(shù)據(jù)，請(qǐng)不要使用大量并發(fā)map任務(wù)來(lái)導(dǎo)入數(shù)據(jù)。

監(jiān)控

監(jiān)控確保功能在自動(dòng)化系統(tǒng)中按預(yù)期執(zhí)行。對(duì)于數(shù)據(jù)入口和出口，監(jiān)控分為兩部分：確保入口和出口中涉及的進(jìn)程存活，并驗(yàn)證源和目標(biāo)數(shù)據(jù)是否按預(yù)期生成。監(jiān)控還應(yīng)包括驗(yàn)證正在移動(dòng)的數(shù)據(jù)量是否達(dá)到預(yù)期水平; 數(shù)據(jù)中意外的下降或高電流將提醒潛在的系統(tǒng)問(wèn)題或軟件錯(cuò)誤。

推測(cè)執(zhí)行

MapReduce具有一個(gè)稱為推測(cè)(Speculative)執(zhí)行的功能，可以在作業(yè)結(jié)束時(shí)為仍在執(zhí)行的任務(wù)啟動(dòng)備份，這有助于防止緩慢的硬件影響作業(yè)執(zhí)行時(shí)間。但是，這種做法也可能有問(wèn)題，如果使用map任務(wù)執(zhí)行插入關(guān)系數(shù)據(jù)庫(kù)，你應(yīng)該知道可以有兩個(gè)并行進(jìn)程插入相同的數(shù)據(jù)。

補(bǔ)充：推測(cè)執(zhí)行(Speculative Execution)是指在集群環(huán)境下運(yùn)行MapReduce，可能是程序Bug，負(fù)載不均或者其他的一些問(wèn)題，導(dǎo)致在一個(gè)JOB下的多個(gè)TASK速度不一致，比如有的任務(wù)已經(jīng)完成，有的卻只跑了10%，根據(jù)木桶原理，這些任務(wù)將成為整個(gè)JOB的短板，如果集群?jiǎn)?dòng)了推測(cè)執(zhí)行，這時(shí)為了***限度的提高短板，Hadoop會(huì)為該task啟動(dòng)備份任務(wù)，讓speculative task與原始task同時(shí)處理一份數(shù)據(jù)，哪個(gè)先運(yùn)行完，則將哪個(gè)結(jié)果作為最終結(jié)果，并且在運(yùn)行完成后Kill掉另外一個(gè)任務(wù)。

5.2 將數(shù)據(jù)移入Hadoop

在Hadoop中處理數(shù)據(jù)的***步是將其提供給Hadoop。有兩種主要方法可用于將數(shù)據(jù)移入Hadoop：在HDFS層(數(shù)據(jù)推送)寫入外部數(shù)據(jù)，或在MapReduce層讀取外部數(shù)據(jù)(更像是拉取)。在MapReduce中讀取數(shù)據(jù)具有以下優(yōu)點(diǎn)：操作可以輕松并行并具有容錯(cuò)能力。然而，并非所有數(shù)據(jù)都可以使用MapReduce訪問(wèn)，例如在日志文件下，其他系統(tǒng)需要依賴傳輸，包括用于最終數(shù)據(jù)hop的HDFS。

本節(jié)，我們將介紹將源數(shù)據(jù)移動(dòng)到Hadoop的方法，將使用上一節(jié)中的設(shè)計(jì)注意事項(xiàng)作為檢查和理解不同工具的標(biāo)準(zhǔn)。

5.2.1 HDFS命令行

Hadoop捆綁了許多方法來(lái)將數(shù)據(jù)導(dǎo)入HDFS。本節(jié)將介紹這些內(nèi)置工具如何滿足數(shù)據(jù)移動(dòng)中的各種需求，可以使用的***個(gè)也是最簡(jiǎn)單的工具是HDFS命令行。

為作業(yè)選擇正確的數(shù)據(jù)獲取工具

本節(jié)中的低級(jí)工具適用于一次性文件移動(dòng)，或者處理基于文件的舊數(shù)據(jù)源和目標(biāo)。但是，以這種方式移動(dòng)數(shù)據(jù)很輕易就會(huì)被Flume和Kafka(本章稍后介紹)等工具所淘汰，這些工具提供了自動(dòng)數(shù)據(jù)移動(dòng)管道。

注：Kafka是一個(gè)更好的平臺(tái)，用于從A到B(B可以是Hadoop集群)移動(dòng)數(shù)據(jù)，而不是老式的“復(fù)制文件”。使用Kafka，只需將數(shù)據(jù)泵入其中，就擁有了實(shí)時(shí)(例如通過(guò)Storm)或離線/批量作業(yè)(例如通過(guò)Camus)消費(fèi)數(shù)據(jù)。這種方法將在之后的章節(jié)中介紹。

使用CLI加載文件

如果需要手動(dòng)執(zhí)行，那么HDFS命令行界面(CLI)就是最合適的工具。它允許執(zhí)行在常規(guī)Linux文件系統(tǒng)上可執(zhí)行的大多數(shù)操作。本節(jié)，我們將重點(diǎn)介紹如何將數(shù)據(jù)從本地文件系統(tǒng)復(fù)制到HDFS中。

問(wèn)題

使用shell將文件復(fù)制到HDFS。

解決方案

HDFS命令行界面可用于一次性移動(dòng)，或者可以將其合并到腳本中以進(jìn)行一系列移動(dòng)。

討論

使用hadoop命令將文件從本地磁盤復(fù)制到HDFS：

$ hadoop fs -put local-file.txt hdfs-file.txt 

Hadoop -put命令的行為與Linux中的Linux cp命令不同，如果目標(biāo)已存在，則會(huì)被覆蓋; 在Hadoop中，副本失敗并顯示錯(cuò)誤：

put: `hdfs-file.txt': File exists 

必須添加-f選項(xiàng)以強(qiáng)制覆蓋文件：

$ hadoop fs -put -f local-file.txt hdfs-file.txt 

與Linux cp命令非常相似，可以使用相同的命令復(fù)制多個(gè)文件。在這種情況下，***一個(gè)參數(shù)必須是HDFS中復(fù)制本地文件的目錄：

$ hadoop fs -put local-file1.txt local-file2.txt /hdfs/dest/ 

可以使用Linux管道將命令輸出傳遞到HDFS文件——使用相同的-put命令并在其后添加單獨(dú)的連字符，這告訴Hadoop從標(biāo)準(zhǔn)輸入讀?。?/p>

$ echo "the cat sat on the mat" | hadoop fs -put - hdfs-file.txt 

要測(cè)試文件或目錄是否存在，請(qǐng)使用-test命令和-e或-d選項(xiàng)分別測(cè)試文件或目錄是否存在。如果文件或目錄存在，則命令的代碼為0;如果不存在，則為1：

 

$ hadoop fs -test -e hdfs-file.txt  
$ echo $?  
1  
$ hadoop fs -touchz hdfs-file.txt  
$ hadoop fs -test -e hdfs-file.txt  
$ echo $?  
$ hadoop fs -test -d hdfs-file.txt  
$ echo $?  
1 

如果只想在HDFS中“touch”文件(創(chuàng)建一個(gè)新的空文件)，那么touchz選項(xiàng)可以完成該工作：

 

 

CLI專為交互式HDFS活動(dòng)而設(shè)計(jì)，它也可以合并到腳本中，以用于自動(dòng)執(zhí)行某些任務(wù)。CLI的缺點(diǎn)是級(jí)別較低，并且沒(méi)有內(nèi)置任何自動(dòng)化機(jī)制。它需要為每個(gè)命令分配一個(gè)fork，如果在bash腳本中使用可能沒(méi)問(wèn)題，但如果試圖將HDFS功能集成到Python或Java應(yīng)用程序中，可能就會(huì)出現(xiàn)問(wèn)題。在這種情況下，為每個(gè)命令啟動(dòng)外部進(jìn)程的開(kāi)銷可能也是想要避免的。

使用REST加載文件

CLI便于快速運(yùn)行命令和編寫腳本。但是，它會(huì)產(chǎn)生為每個(gè)命令分配一個(gè)單獨(dú)進(jìn)程的開(kāi)銷，這可能是想要避免的，特別是編程語(yǔ)言與HDFS連接時(shí)。

問(wèn)題

沒(méi)有HDFS本機(jī)接口的編程語(yǔ)言如何與HDFS交互。

解決方案

使用Hadoop的WebHDFS接口，該接口為HDFS操作提供全功能的REST API。

討論

在開(kāi)始之前，需要確保在集群上啟用WebHDFS(默認(rèn)不啟動(dòng))，這由dfs.webhdfs.enabled屬性控制。如果未啟用，則需要更新hdfs-site.xml并添加以下內(nèi)容：

 

在這種技術(shù)中，我們將介紹在不安全的Hadoop集群上運(yùn)行WebHDFS.3的情況。如果正在使用安全的Hadoop集群，則不會(huì)提供user.name參數(shù)。

相反，我們將在與WebHDFS交互之前使用kinit對(duì)Kerberos進(jìn)行身份驗(yàn)證，然后在curl命令行中提供-negotiate -u：youruser。

警告：如果為已經(jīng)關(guān)閉了安全性的集群?jiǎn)⒂肳ebHDFS，則可以輕松地將其用作集群中任意用戶命令(只需將URL中的用戶名更改為簇)。建議僅在打開(kāi)安全性的情況下運(yùn)行WebHDFS。

要想在此技術(shù)中使用HTTP與NameNode進(jìn)行通信，需要知道運(yùn)行NameNode RPC服務(wù)的主機(jī)和端口，這是使用dfs.namenode.http-address屬性配置的。在偽分布式設(shè)置中，這很可能設(shè)置為0.0.0.0:50070。我們假設(shè)其余技術(shù)的偽分布式——替換適當(dāng)?shù)闹鳈C(jī)和端口進(jìn)行設(shè)置。

首先使用CLI在HDFS中創(chuàng)建文件：

$ echo "the cat sat on the mat" | hadoop fs -put - /tmp/hdfs-file.txt 

使用WebHDFS獲取有關(guān)該文件的各種有趣的元數(shù)據(jù)(用戶名替換為以下URL中的aholmes)：

 

命令語(yǔ)法由兩部分組成：一是路徑;二是正在執(zhí)行的操作。但是，需要提供執(zhí)行操作的用戶名，否則HDFS將假定你是一個(gè)訪問(wèn)受限的匿名用戶。

 

圖5.1 解析WebHDFS URL路徑

從HDFS讀取文件只需將OPEN指定為operation：

 

使用WebHDFS編寫文件分為兩步：***步通知NameNode創(chuàng)建新文件的意圖，可以使用HTTP PUT命令執(zhí)行此操作：

 

此時(shí)，文件尚未寫入。只是讓NameNode有機(jī)會(huì)確定要寫入哪個(gè)DataNode，這是在“Location”標(biāo)頭中指定的。需要獲取該URL，然后發(fā)出第二個(gè)HTTP PUT執(zhí)行實(shí)際寫入：

 

可以通過(guò)讀取文件來(lái)驗(yàn)證寫入是否成功：

 

WebHDFS支持可以使用常規(guī)命令行執(zhí)行所有HDFS操作，它更有用，因?yàn)樗梢栽L問(wèn)結(jié)構(gòu)化JSON表單中的元數(shù)據(jù)，從而更容易解析數(shù)據(jù)。

值得一提的是WebHDFS提供的一些附加功能。首先，文件的***個(gè)塊存放數(shù)據(jù)位置。NameNode將客戶端重定向到承載***個(gè)塊的DataNode，提供強(qiáng)大的數(shù)據(jù)位置。對(duì)于文件中的后續(xù)塊，DataNode充當(dāng)代理，并將數(shù)據(jù)流入保存塊數(shù)據(jù)的節(jié)點(diǎn)或從中保存數(shù)據(jù)。

WebHDFS還與Hadoop的安全身份驗(yàn)證集成，這意味著可以啟用Kerberos并在HTTP請(qǐng)求中使用委派令牌。此外，API將保持跨Hadoop版本的兼容性，這意味著目前發(fā)布的命令將適用于未來(lái)版本的Hadoop(反之亦然)。 這是一個(gè)有用的工具，用于訪問(wèn)運(yùn)行不同Hadoop版本的多個(gè)集群。

 

表5.1 WebHDFS庫(kù)

當(dāng)客戶端可以訪問(wèn)所有NameNode和DataNode時(shí)，WebHDFS非常有用。在鎖定環(huán)境中，情況可能并非如此，可能需要查看HttpFS。

從防火墻后面訪問(wèn)HDFS

生產(chǎn)Hadoop環(huán)境通常被鎖定以保護(hù)這些集群中的數(shù)據(jù)。部分安全程序可能包括將集群置于防火墻之后，如果嘗試從防火墻外部讀取或?qū)懭際DFS，這將是一件麻煩事。 這種技術(shù)著眼于HttpFS網(wǎng)關(guān)，它可以使用HTTP(通常在防火墻上打開(kāi))提供HDFS訪問(wèn)。

問(wèn)題

想要寫入HDFS，但有一個(gè)防火墻限制對(duì)NameNode或DataNode的訪問(wèn)。

解決方案

使用HttpFS網(wǎng)關(guān)，它是一個(gè)獨(dú)立的服務(wù)器，可通過(guò)HTTP提供對(duì)HDFS的訪問(wèn)。因?yàn)樗且粋€(gè)單獨(dú)的服務(wù)而且是HTTP，所以可以配置為在任何可以訪問(wèn)Hadoop節(jié)點(diǎn)的主機(jī)上運(yùn)行，并且可以打開(kāi)防火墻規(guī)則以允許流量到服務(wù)。

討論

HttpFS非常有用，因?yàn)樗粌H允許使用REST訪問(wèn)HDFS，而且具有完整的Hadoop文件系統(tǒng)實(shí)現(xiàn)，這意味著可以使用CLI和本機(jī)HDFS Java客戶端與HDFS進(jìn)行通信，如圖5.2所示。

 

圖5.2 HttpFS網(wǎng)關(guān)架構(gòu)

要啟動(dòng)并運(yùn)行HttpFS，必須指定代理用戶。這是將運(yùn)行HttpFS進(jìn)程的用戶，此用戶也將在Hadoop中配置為代理用戶。假設(shè)有一個(gè)名為foxyproxy的用戶，你將其指定為代理用戶。你用以下代碼更新core-site.xml：

 

基本上，這表明Hadoop應(yīng)該只接受來(lái)自主機(jī)localhost的代理請(qǐng)求，并且foxyproxy可以冒充任何用戶(你可以通過(guò)提供以逗號(hào)分隔的組列表來(lái)鎖定可以模擬的用戶集名)。更改用戶名，主機(jī)和組值，以便它們?cè)诃h(huán)境中有意義。

在對(duì)core-site.xml進(jìn)行更改后，我們需要啟動(dòng)HttpFS進(jìn)程：

$ sbin/httpfs.sh start 

現(xiàn)在，可以使用WebHDFS發(fā)出與之前技術(shù)中相同的curl命令。這是關(guān)于HttpFS網(wǎng)關(guān)的好處之一 ：語(yǔ)法完全相同。要在根目錄上執(zhí)行目錄列表，需要執(zhí)行以下操作：

 

此curl命令與先前技術(shù)中使用的curl命令的唯一區(qū)別是端口號(hào)。默認(rèn)情況下，HttpFS在端口14000上運(yùn)行，但可以通過(guò)編輯httpfs-env.sh來(lái)更改。表5.2中顯示了可以在文件中更改的一些有趣屬性。

 

表5.2 HttpFS屬性

可以在httpfs-site.xml中配置其他Kerberos以及用戶和組級(jí)別設(shè)置。

WebHDFS和HttpFS之間的差異

WebHDFS和HttpFS之間的主要區(qū)別在于客戶端對(duì)所有數(shù)據(jù)節(jié)點(diǎn)的可訪問(wèn)性。如果客戶端可以訪問(wèn)所有數(shù)據(jù)節(jié)點(diǎn)，那么WebHDFS將正常工作，因?yàn)樽x取和寫入文件涉及客戶端直接與數(shù)據(jù)節(jié)點(diǎn)通信以進(jìn)行數(shù)據(jù)傳輸。另一方面，如果位于防火墻之后，客戶端可能無(wú)法訪問(wèn)所有數(shù)據(jù)節(jié)點(diǎn)，在這種情況下，HttpFS選項(xiàng)最適合。使用HttpFS，服務(wù)器將與數(shù)據(jù)節(jié)點(diǎn)通信，客戶端只需要與單個(gè)HttpFS服務(wù)器通信。

如果可以，請(qǐng)選擇WebHDFS，因?yàn)榭蛻舳酥苯优c數(shù)據(jù)節(jié)點(diǎn)通信具有固有的優(yōu)勢(shì)：這允許輕松擴(kuò)展多個(gè)主機(jī)并發(fā)客戶端數(shù)量，而不會(huì)遇到通過(guò)HttpFS流式傳輸數(shù)據(jù)的網(wǎng)絡(luò)瓶頸。如果客戶端本身在數(shù)據(jù)節(jié)點(diǎn)上運(yùn)行，則更是如此，因?yàn)閷⑼ㄟ^(guò)直接從本地文件系統(tǒng)而不是網(wǎng)絡(luò)流式傳輸本地托管的HDFS數(shù)據(jù)塊來(lái)使用WebHDFS的優(yōu)勢(shì)。

使用NFS掛載Hadoop

通常，如果Hadoop數(shù)據(jù)可以作為文件系統(tǒng)的常規(guī)安裝來(lái)訪問(wèn)，那么使用Hadoop數(shù)據(jù)要容易得多。這允許使用現(xiàn)有腳本，工具和編程語(yǔ)言，并與HDFS中的數(shù)據(jù)進(jìn)行交互。本節(jié)介紹如何使用NFS掛載輕松地將數(shù)據(jù)復(fù)制到HDFS中和從HDFS復(fù)制數(shù)據(jù)。

問(wèn)題

將HDFS視為常規(guī)Linux文件系統(tǒng)，并使用標(biāo)準(zhǔn)Linux工具與HDFS進(jìn)行交互。

解決方案

使用Hadoop的NFS實(shí)現(xiàn)來(lái)訪問(wèn)HDFS中的數(shù)據(jù)。

討論

在Hadoop 2.1之前，NFS安裝HDFS的唯一方法是使用FUSE。由于各種性能和可靠性問(wèn)題，不建議將其用于一般用途。它還引入了額外的負(fù)擔(dān)，要求在任何客戶端計(jì)算機(jī)上安裝驅(qū)動(dòng)程序(換句話說(shuō)，它沒(méi)有提供NFS網(wǎng)關(guān))。

Hadoop中的新NFS實(shí)現(xiàn)解決了舊的基于FUSE系統(tǒng)的所有缺點(diǎn)。這是一個(gè)合適的NFSv3實(shí)現(xiàn)，允許運(yùn)行一個(gè)或多個(gè)NFS網(wǎng)關(guān)以提高可用性和吞吐量。

要啟動(dòng)并運(yùn)行NFS服務(wù)，首先需要停止在主機(jī)上運(yùn)行的NFS服務(wù)。在Linux系統(tǒng)上，可以使用以下命令實(shí)現(xiàn)：

 

 

圖5.3 Hadoop NFS

接下來(lái)，需要啟動(dòng)Hadoop NFS服務(wù)。啟動(dòng)的***個(gè)服務(wù)是portmap，它為協(xié)議及其關(guān)聯(lián)的傳輸和端口提供注冊(cè)服務(wù)。在受限的端口上運(yùn)行，因此需要以root用戶身份啟動(dòng)：

$ sudo hadoop-daemon.sh start portmap 

接下來(lái)，你需要啟動(dòng)實(shí)際的NFS服務(wù)，運(yùn)行此服務(wù)的用戶一定要與運(yùn)行HDFS的用戶相同，這一點(diǎn)非常重要：

$ hadoop-daemon.sh start nfs3 

通過(guò)運(yùn)行rpcinfo和showmount來(lái)驗(yàn)證服務(wù)是否正在運(yùn)行，應(yīng)該看到類似于以下的輸出：

 

現(xiàn)在，需要在主機(jī)目錄上安裝HDFS。以下示例選擇/hdfs作為安裝目錄。第二個(gè)mount命令驗(yàn)證是否已創(chuàng)建安裝：

 

現(xiàn)在，可以使用掛載的文件系統(tǒng)直接操作HDFS。

使用NFS網(wǎng)關(guān)時(shí)需要考慮以下幾點(diǎn)：

• HDFS是僅附加文件系統(tǒng)?？梢愿郊拥轿募荒軋?zhí)行隨機(jī)寫入。如果需要使用支持隨機(jī)寫入的文件系統(tǒng)來(lái)使用Hadoop，那么應(yīng)該看看MapR的Hadoop distribution。
• Hadoop 2.2版不支持Hadoop安全驗(yàn)證(Kerberos)，并且有一個(gè)添加該支持的開(kāi)放票證。
• 在Hadoop 2.4(或3.0)之前，不支持代理用戶。這實(shí)質(zhì)上意味著以前版本的Hadoop將以超級(jí)用戶身份執(zhí)行所有命令，因?yàn)橐驨FS網(wǎng)關(guān)作為與HDFS本身相同的用戶運(yùn)行。

由于這些限制，建議將NFS網(wǎng)關(guān)保留用于實(shí)驗(yàn)用途，或者用于不考慮用戶級(jí)安全性的單租戶集群。

使用DistCp在集群內(nèi)和集群間復(fù)制數(shù)據(jù)

如果移入或移出Hadoop的數(shù)據(jù)量很大，通過(guò)單個(gè)主機(jī)匯集數(shù)據(jù)，一定要盡可能優(yōu)化數(shù)據(jù)移動(dòng)。DistCp可以在Hadoop集群之間以及進(jìn)出NFS安裝的數(shù)據(jù)之間高效復(fù)制數(shù)據(jù)。

問(wèn)題

在Hadoop集群之間高效復(fù)制大量數(shù)據(jù)，并且進(jìn)行增量復(fù)制。

解決方案

使用DistCp，一種內(nèi)置于Hadoop中的并行文件復(fù)制工具。

討論

本節(jié)，我們將首先介紹DistCp的重要配置。之后，我們將繼續(xù)查看使用DistCp的特定方案，以及配置和運(yùn)行DistCp的***方法。

此技術(shù)涵蓋了Hadoop 2中可用的DistCp新版本，名為DistCp 2。此代碼被反向移植到Hadoop 1.2.0中，可通過(guò)使用distcp2作為命令啟用Hadoop 2來(lái)替換現(xiàn)有的DistCp，然后就可以正常使用distcp命令。

DistCp 2支持與DistCp的舊版本相同的命令行參數(shù)集，并帶來(lái)了許多有用的優(yōu)勢(shì)：

• 使用大量文件時(shí)減少了設(shè)置和執(zhí)行時(shí)間，因?yàn)轵?qū)動(dòng)程序不再需要預(yù)處理所有輸入(現(xiàn)在這已推遲到mapper)。
• 具有功能齊全的Java接口，無(wú)需Java客戶端將參數(shù)序列化為字符串。
• 原子提交允許全部復(fù)制語(yǔ)義。
• 使用-update跳過(guò)目標(biāo)中已存在的文件，如果文件屬性與源文件不同，將導(dǎo)致文件屬性發(fā)生更改。
• 作為副本的一部分，不再跳過(guò)空目錄。

DistCp使用僅map的MapReduce作業(yè)來(lái)執(zhí)行復(fù)制。以下是一個(gè)非常簡(jiǎn)單的示例，在單個(gè)Hadoop集群中用于將源目錄,/ hello,復(fù)制到目標(biāo)目錄,/world：

$ hadoop distcp /hello /world 

如果/ world目錄尚不存在，則此命令將創(chuàng)建/ world目錄，然后將/ hello(其所有文件和目錄遞歸)的內(nèi)容復(fù)制到/ world。

處理已存在的目標(biāo)文件

目標(biāo)中已存在的文件和目錄保持不變(即使文件不同)。

可以通過(guò)查看作業(yè)完成時(shí)轉(zhuǎn)儲(chǔ)到標(biāo)準(zhǔn)輸出的SKIP計(jì)數(shù)器來(lái)查看跳過(guò)的文件數(shù)：

 

-update和-overwrite參數(shù)巧妙地改變了復(fù)制內(nèi)容的行為。如果沒(méi)有這些選項(xiàng)，如果源是目錄，則在目標(biāo)目錄下創(chuàng)建該目錄。使用-update或-overwrite參數(shù)，僅復(fù)制文件和子目錄，而不復(fù)制源目錄。通過(guò)一個(gè)例子證明這一點(diǎn)：

 

忽略錯(cuò)誤

當(dāng)使用DistCp復(fù)制大量文件時(shí)，使用-i標(biāo)志執(zhí)行命令以忽略錯(cuò)誤是明智的。這樣，單個(gè)錯(cuò)誤不會(huì)導(dǎo)致整個(gè)復(fù)制過(guò)程失敗，可以通過(guò)使用-update選項(xiàng)重新發(fā)出相同的DistCp命令來(lái)再次嘗試復(fù)制失敗文件。

動(dòng)態(tài)復(fù)制策略

DistCp的默認(rèn)行為是通過(guò)均勻地傳播所有文件以使所有mapper復(fù)制大致相同的字節(jié)數(shù)來(lái)為每個(gè)mapper預(yù)分配工作。從理論上講，這聽(tīng)起來(lái)像是一種公平分配工作的好方法，但實(shí)際上，諸如硬件，硬件錯(cuò)誤和配置不良等因素往往導(dǎo)致長(zhǎng)尾工作執(zhí)行，少數(shù)落后的mapper占用時(shí)間比其他要長(zhǎng)。

使用DistCp 2，可以使用替代策略，其中mapper直接接收工作而不是預(yù)先分配，這被稱為動(dòng)態(tài)復(fù)制策略，使用-strategy動(dòng)態(tài)參數(shù)激活，添加此參數(shù)的效果是改進(jìn)復(fù)制時(shí)間。

原子提交

DistCp 2的另一個(gè)有用功能是原子提交。DistCp默認(rèn)將每個(gè)文件寫入臨時(shí)文件，然后移動(dòng)到最終目標(biāo)。這意味著無(wú)法撤消在作業(yè)中遇到錯(cuò)誤之前復(fù)制的文件。

因此，原子提交允許在復(fù)制所有文件時(shí)將實(shí)際的“提交”推遲到作業(yè)結(jié)束，這樣如果遇到錯(cuò)誤，你將看不到任何部分寫入，可以使用-atomic參數(shù)啟用此功能。

并行性和mapper數(shù)量

目前，DistCp最細(xì)的工作單元是文件級(jí)別。因此，無(wú)論文件多大，都只使用一個(gè)mapper來(lái)復(fù)制，提高作業(yè)的mapper數(shù)量對(duì)提高復(fù)制速度沒(méi)有任何影響。

默認(rèn)情況下，DistCp使用20個(gè)mapper運(yùn)行，每個(gè)mapper副本對(duì)應(yīng)的文件由選擇的復(fù)制策略確定。Hadoop開(kāi)發(fā)人員考慮了mapper數(shù)量的默認(rèn)設(shè)置，選擇正確的值是想要使用多少網(wǎng)絡(luò)帶寬以及希望在復(fù)制期間占用多少任務(wù)的函數(shù)，可以通過(guò)指定-m后跟的值來(lái)更改mapper的數(shù)量。

帶寬

***一個(gè)考慮因素是復(fù)制期間使用的網(wǎng)絡(luò)帶寬。大型副本可能會(huì)使集群之間的網(wǎng)絡(luò)飽和。企業(yè)中網(wǎng)絡(luò)運(yùn)營(yíng)人員保持運(yùn)行良好的一種方法是使用-bandwidth參數(shù)來(lái)指定每個(gè)map任務(wù)在復(fù)制期間消耗的帶寬量上限。此參數(shù)的值以兆字節(jié)/秒(MBps)為單位。

其他

到目前為止，我們已經(jīng)看到了DistCp中一些更有趣的選項(xiàng)。要查看完整的選項(xiàng)列表，可以運(yùn)行distcp命令，或者查看Hadoop文檔。