大數(shù)據(jù)基礎(chǔ)知識(shí)

1、HDFS特點(diǎn)和目標(biāo)硬件故障硬件故障硬件故障是常態(tài)， 而不是異常。 整個(gè) HDFS 系統(tǒng)將由數(shù)百或數(shù)千個(gè)存儲(chǔ)著文件數(shù)據(jù)片斷的服務(wù)器組成。實(shí)際上它里面有非常巨大的組成部分，每一個(gè)組成部分都很可能出現(xiàn)故障，這就意味著 HDFS 里的總是有一些部件是失效的，因此，故障的檢測和自動(dòng)快速恢復(fù)是 HDFS 一個(gè)很核心的設(shè)計(jì)目標(biāo)。數(shù)據(jù)訪問數(shù)據(jù)訪問運(yùn)行在 HDFS 之上的應(yīng)用程序必須流式地訪問它們的數(shù)據(jù)集， 它不是運(yùn)行在普通文件系統(tǒng)之上的普通程序。HDFS 被設(shè)計(jì)成適合批量處理的，而不是用戶交互式的。重點(diǎn)是在數(shù)據(jù)吞吐量，而不是數(shù)據(jù)訪問的反應(yīng)時(shí)間，POSIX 的很多硬性需求對于 HDFS 應(yīng)用都是非必須的，去掉

2、POSIX 一小部分關(guān)鍵語義可以獲得更好的數(shù)據(jù)吞吐率。大數(shù)據(jù)集大數(shù)據(jù)集運(yùn)行在 HDFS 之上的程序有很大量的數(shù)據(jù)集。典型的 HDFS 文件大小是 GB 到 TB 的級(jí)別。所以，HDFS 被調(diào)整成支持大文件。它應(yīng)該提供很高的聚合數(shù)據(jù)帶寬，一個(gè)集群中支持?jǐn)?shù)百個(gè)節(jié)點(diǎn)，一個(gè)集群中還應(yīng)該支持千萬級(jí)別的文件。簡單一致性模型大部分的 HDFS 程序?qū)ξ募僮餍枰氖且淮螌懚啻巫x取的操作模式。一個(gè)文件一旦創(chuàng)建、寫入、關(guān)閉之后就不需要修改了。這個(gè)假定簡單化了數(shù)據(jù)一致的問題和并使高吞吐量的數(shù)據(jù)訪問變得可能。一個(gè)Map-Reduce 程序或者網(wǎng)絡(luò)爬蟲程序都可以完美地適合這個(gè)模型。移動(dòng)計(jì)算比移動(dòng)數(shù)據(jù)更經(jīng)濟(jì)在靠近計(jì)算數(shù)

3、據(jù)所存儲(chǔ)的位置來進(jìn)行計(jì)算是最理想的狀態(tài)，尤其是在數(shù)據(jù)集特別巨大的時(shí)候。這樣消除了網(wǎng)絡(luò)的擁堵，提高了系統(tǒng)的整體吞吐量。一個(gè)假定就是遷移計(jì)算到離數(shù)據(jù)更近的位置比將數(shù)據(jù)移動(dòng)到程序運(yùn)行更近的位置要更好。HDFS 提供了接口，來讓程序?qū)⒆约阂苿?dòng)到離數(shù)據(jù)存儲(chǔ)更近的位置。異構(gòu)軟硬件平臺(tái)間的可移植性HDFS 被設(shè)計(jì)成可以簡便地實(shí)現(xiàn)平臺(tái)間的遷移， 這將推動(dòng)需要大數(shù)據(jù)集的應(yīng)用更廣泛地采用 HDFS 作為平臺(tái)。名字節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)HDFS 是一個(gè)主從結(jié)構(gòu)，一個(gè) HDFS 集群是由一個(gè)名字節(jié)點(diǎn)，它是一個(gè)管理文件命名空間和調(diào)節(jié)客戶端訪問文件的主服務(wù)器，當(dāng)然還有一些數(shù)據(jù)節(jié)點(diǎn)，通常是一個(gè)節(jié)點(diǎn)一個(gè)機(jī)器，它來管理對應(yīng)節(jié)點(diǎn)的存儲(chǔ)。

4、HDFS 對外開放文件命名空間并允許用戶數(shù)據(jù)以文件形式存儲(chǔ)。內(nèi)部機(jī)制是將一個(gè)文件分割成一個(gè)或多個(gè)塊，這些塊被存儲(chǔ)在一組數(shù)據(jù)節(jié)點(diǎn)中。名字節(jié)點(diǎn)用來操作文件命名空間的文件或目錄操作，如打開，關(guān)閉，重命名等等。它同時(shí)確定塊與數(shù)據(jù)節(jié)點(diǎn)的映射。數(shù)據(jù)節(jié)點(diǎn)負(fù)責(zé)來自文件系統(tǒng)客戶的讀寫請求。數(shù)據(jù)節(jié)點(diǎn)同時(shí)還要執(zhí)行塊的創(chuàng)建，刪除，和來自名字節(jié)點(diǎn)的塊復(fù)制指令。名字節(jié)點(diǎn)和數(shù)據(jù)節(jié)點(diǎn)都是運(yùn)行在普通的機(jī)器之上的軟件，機(jī)器典型的都是 GNU/Linux，HDFS 是用java 編寫的，任何支持 java 的機(jī)器都可以運(yùn)行名字節(jié)點(diǎn)或數(shù)據(jù)節(jié)點(diǎn)，利用 java 語言的超輕便型，很容易將 HDFS 部署到大范圍的機(jī)器上。典型的部署是由一

5、個(gè)專門的機(jī)器來運(yùn)行名字節(jié)點(diǎn)軟件，集群中的其他每臺(tái)機(jī)器運(yùn)行一個(gè)數(shù)據(jù)節(jié)點(diǎn)實(shí)例。體系結(jié)構(gòu)不排斥在一個(gè)機(jī)器上運(yùn)行多個(gè)數(shù)據(jù)節(jié)點(diǎn)的實(shí)例，但是實(shí)際的部署不會(huì)有這種情況。集群中只有一個(gè)名字節(jié)點(diǎn)極大地簡單化了系統(tǒng)的體系結(jié)構(gòu)。 名字節(jié)點(diǎn)是仲裁者和所有 HDFS 元數(shù)據(jù)的倉庫，用戶的實(shí)際數(shù)據(jù)不經(jīng)過名字節(jié)點(diǎn)。文件命名空間HDFS 支持傳統(tǒng)的繼承式的文件組織結(jié)構(gòu)。一個(gè)用戶或一個(gè)程序可以創(chuàng)建目錄，存儲(chǔ)文件到很多目錄之中。文件系統(tǒng)的名字空間層次和其他的文件系統(tǒng)相似?？梢詣?chuàng)建、移動(dòng)文件，將文件從一個(gè)目錄移動(dòng)到另外一個(gè)，或重命名。HDFS 還沒有實(shí)現(xiàn)用戶的配額和訪問控制。HDFS 還不支持硬鏈接和軟鏈接。然而，HDFS 結(jié)構(gòu)不

6、排斥在將來實(shí)現(xiàn)這些功能。名字節(jié)點(diǎn)維護(hù)文件系統(tǒng)的命名空間，任何文件命名空間的改變和或?qū)傩远急幻止?jié)點(diǎn)記錄。應(yīng)用程序可以指定文件的副本數(shù)，文件的副本數(shù)被稱作文件的復(fù)制因子，這些信息由命名空間來負(fù)責(zé)存儲(chǔ)。數(shù)據(jù)復(fù)制HDFS 設(shè)計(jì)成能可靠地在集群中大量機(jī)器之間存儲(chǔ)大量的文件，它以塊序列的形式存儲(chǔ)文件。文件中除了最后一個(gè)塊，其他塊都有相同的大小。屬于文件的塊為了故障容錯(cuò)而被復(fù)制。塊的大小和復(fù)制數(shù)是以文件為單位進(jìn)行配置的，應(yīng)用可以在文件創(chuàng)建時(shí)或者之后修改復(fù)制因子。HDFS 中的文件是一次寫的，并且任何時(shí)候都只有一個(gè)寫操作。名字節(jié)點(diǎn)負(fù)責(zé)處理所有的塊復(fù)制相關(guān)的決策。它周期性地接受集群中數(shù)據(jù)節(jié)點(diǎn)的心跳和塊報(bào)告。一

7、個(gè)心跳的到達(dá)表示這個(gè)數(shù)據(jù)節(jié)點(diǎn)是正常的。一個(gè)塊報(bào)告包括該數(shù)據(jù)節(jié)點(diǎn)上所有塊的列表。副本位置：第一小步塊副本存放位置的選擇嚴(yán)重影響 HDFS 的可靠性和性能。副本存放位置的優(yōu)化是 HDFS 區(qū)分于其他分布式文件系統(tǒng)的的特征，這需要精心的調(diào)節(jié)和大量的經(jīng)驗(yàn)。機(jī)架敏感的副本存放策略是為了提高數(shù)據(jù)的可靠性，可用性和網(wǎng)絡(luò)帶寬的利用率。副本存放策略的實(shí)現(xiàn)是這個(gè)方向上比較原始的方式。短期的實(shí)現(xiàn)目標(biāo)是要把這個(gè)策略放在生產(chǎn)環(huán)境下驗(yàn)證，了解更多它的行為，為以后測試研究更精致的策略打好基礎(chǔ)。HDFS 運(yùn)行在跨越大量機(jī)架的集群之上。兩個(gè)不同機(jī)架上的節(jié)點(diǎn)是通過交換機(jī)實(shí)現(xiàn)通信的，在大多數(shù)情況下，相同機(jī)架上機(jī)器間的網(wǎng)絡(luò)帶寬優(yōu)于在

8、不同機(jī)架上的機(jī)器。在開始的時(shí)候， 每一個(gè)數(shù)據(jù)節(jié)點(diǎn)自檢它所屬的機(jī)架 id， 然后在向名字節(jié)點(diǎn)注冊的時(shí)候告知它的機(jī)架 id。HDFS 提供接口以便很容易地掛載檢測機(jī)架標(biāo)示的模塊。一個(gè)簡單但不是最優(yōu)的方式就是將副本放置在不同的機(jī)架上，這就防止了機(jī)架故障時(shí)數(shù)據(jù)的丟失，并且在讀數(shù)據(jù)的時(shí)候可以充分利用不同機(jī)架的帶寬。這個(gè)方式均勻地將復(fù)制分散在集群中，這就簡單地實(shí)現(xiàn)了組建故障時(shí)的負(fù)載均衡。然而這種方式增加了寫的成本，因?yàn)閷懙臅r(shí)候需要跨越多個(gè)機(jī)架傳輸文件塊。默認(rèn)的 HDFS block 放置策略在最小化寫開銷和最大化數(shù)據(jù)可靠性、可用性以及總體讀取帶寬之間進(jìn)行了一些折中。一般情況下復(fù)制因子為 3，HDFS 的副

9、本放置策略是將第一個(gè)副本放在本地節(jié)點(diǎn)，將第二個(gè)副本放到本地機(jī)架上的另外一個(gè)節(jié)點(diǎn)而將第三個(gè)副本放到不同機(jī)架上的節(jié)點(diǎn)。這種方式減少了機(jī)架間的寫流量，從而提高了寫的性能。機(jī)架故障的幾率遠(yuǎn)小于節(jié)點(diǎn)故障。這種方式并不影響數(shù)據(jù)可靠性和可用性的限制，并且它確實(shí)減少了讀操作的網(wǎng)絡(luò)聚合帶寬，因?yàn)槲募K僅存在兩個(gè)不同的機(jī)架， 而不是三個(gè)。文件的副本不是均勻地分布在機(jī)架當(dāng)中，1/3 在同一個(gè)節(jié)點(diǎn)上，1/3 副本在同一個(gè)機(jī)架上，另外 1/3 均勻地分布在其他機(jī)架上。這種方式提高了寫的性能，并且不影響數(shù)據(jù)的可靠性和讀性能。副本的選擇為了盡量減小全局的帶寬消耗讀延遲，HDFS 嘗試返回給一個(gè)讀操作離它最近的副本。假如在讀

10、節(jié)點(diǎn)的同一個(gè)機(jī)架上就有這個(gè)副本，就直接讀這個(gè)，如果 HDFS 集群是跨越多個(gè)數(shù)據(jù)中心，那么本地?cái)?shù)據(jù)中心的副本優(yōu)先于遠(yuǎn)程的副本。安全模式在啟動(dòng)的時(shí)候，名字節(jié)點(diǎn)進(jìn)入一個(gè)叫做安全模式的特殊狀態(tài)。安全模式中不允許發(fā)生文件塊的復(fù)制。名字節(jié)點(diǎn)接受來自數(shù)據(jù)節(jié)點(diǎn)的心跳和塊報(bào)告。一個(gè)塊報(bào)告包含數(shù)據(jù)節(jié)點(diǎn)所擁有的數(shù)據(jù)塊的列表。每一個(gè)塊有一個(gè)特定的最小復(fù)制數(shù)。當(dāng)名字節(jié)點(diǎn)檢查這個(gè)塊已經(jīng)大于最小的復(fù)制數(shù)就被認(rèn)為是安全地復(fù)制了，當(dāng)達(dá)到配置的塊安全復(fù)制比例時(shí)（加上額外的 30 秒），名字節(jié)點(diǎn)就退出安全模式。它將檢測數(shù)據(jù)塊的列表，將小于特定復(fù)制數(shù)的塊復(fù)制到其他的數(shù)據(jù)節(jié)點(diǎn)。文件系統(tǒng)的元數(shù)據(jù)的持久化HDFS 的命名空間是由名字節(jié)點(diǎn)

11、來存儲(chǔ)的。名字節(jié)點(diǎn)使用叫做 EditLog 的事務(wù)日志來持久記錄每一個(gè)對文件系統(tǒng)元數(shù)據(jù)的改變，如在 HDFS 中創(chuàng)建一個(gè)新的文件，名字節(jié)點(diǎn)將會(huì)在 EditLog 中插入一條記錄來記錄這個(gè)改變。類似地，改變文件的復(fù)制因子也會(huì)向 EditLog 中插入一條記錄。名字節(jié)點(diǎn)在本地文件系統(tǒng)中用一個(gè)文件來存儲(chǔ)這個(gè) EditLog。 整個(gè)文件系統(tǒng)命名空間， 包括文件塊的映射表和文件系統(tǒng)的配置都存在一個(gè)叫 FsImage 的文件中，F(xiàn)sImage 也存放在名字節(jié)點(diǎn)的本地文件系統(tǒng)中。名字節(jié)點(diǎn)在內(nèi)存中保留一個(gè)完整的文件系統(tǒng)命名空間和文件塊的映射表的鏡像。這個(gè)元數(shù)據(jù)被設(shè)計(jì)成緊湊的，這樣 4GB 內(nèi)存的名字節(jié)點(diǎn)就足以

12、處理非常大的文件數(shù)和目錄。名字節(jié)點(diǎn)啟動(dòng)時(shí)，它將從磁盤中讀取 FsImage 和 EditLog，將 EditLog 中的所有事務(wù)應(yīng)用到 FsImage 的仿內(nèi)存空間，然后將新的 FsImage刷新到本地磁盤中，因?yàn)槭聞?wù)已經(jīng)被處理并已經(jīng)持久化的 FsImage 中，然后就可以截去舊的 EditLog。這個(gè)過程叫做檢查點(diǎn)。當(dāng)前實(shí)現(xiàn)中，檢查點(diǎn)僅在名字節(jié)點(diǎn)啟動(dòng)的時(shí)候發(fā)生，正在支持周期性的檢查點(diǎn)。數(shù)據(jù)節(jié)點(diǎn)將 HDFS 數(shù)據(jù)存儲(chǔ)到本地的文件系統(tǒng)中。數(shù)據(jù)節(jié)點(diǎn)并不知道 HDFS 文件的存在，它在本地文件系統(tǒng)中以單獨(dú)的文件存儲(chǔ)每一個(gè) HDFS 文件的數(shù)據(jù)塊。數(shù)據(jù)節(jié)點(diǎn)不會(huì)將所有的數(shù)據(jù)塊文件存放到同一個(gè)目錄中，而是

13、啟發(fā)式的檢測每一個(gè)目錄的最優(yōu)文件數(shù)，并在適當(dāng)?shù)臅r(shí)候創(chuàng)建子目錄。在本地同一個(gè)目錄下創(chuàng)建所有的數(shù)據(jù)塊文件不是最優(yōu)的，因?yàn)楸镜匚募到y(tǒng)可能不支持單個(gè)目錄下巨額文件的高效操作。當(dāng)數(shù)據(jù)節(jié)點(diǎn)啟動(dòng)的時(shí)候，它將掃描它的本地文件系統(tǒng)，根據(jù)本地的文件產(chǎn)生一個(gè)所有 HDFS 數(shù)據(jù)塊的列表并報(bào)告給名字節(jié)點(diǎn)，這個(gè)報(bào)告稱作塊報(bào)告。通信協(xié)議所有的通信協(xié)議都是在 TCP/IP 協(xié)議之上構(gòu)建的。 一個(gè)客戶端和指定 TCP 配置端口的名字節(jié)點(diǎn)建立連接之后， 它和名字節(jié)點(diǎn)之間通信的協(xié)議是 Client Protocal。 數(shù)據(jù)節(jié)點(diǎn)和名字節(jié)點(diǎn)之間通過 Datanode Protocol通信。RPC（Remote Procedure

14、Call）抽象地封裝了 Client Protocol 和 DataNode Protocol 協(xié)議。按照設(shè)計(jì)，名字節(jié)點(diǎn)不會(huì)主動(dòng)發(fā)起一個(gè) RPC，它只是被動(dòng)地對數(shù)據(jù)節(jié)點(diǎn)和客戶端發(fā)起的 RPC 作出反饋。異常處理編輯編輯魯棒性HDFS 的主要目標(biāo)就是在存在故障的情況下也能可靠地存儲(chǔ)數(shù)據(jù)。三個(gè)最常見的故障是名字節(jié)點(diǎn)故障，數(shù)據(jù)節(jié)點(diǎn)故障和網(wǎng)絡(luò)斷開。重新復(fù)制一個(gè)數(shù)據(jù)節(jié)點(diǎn)周期性發(fā)送一個(gè)心跳包到名字節(jié)點(diǎn)。網(wǎng)絡(luò)斷開會(huì)造成一組數(shù)據(jù)節(jié)點(diǎn)子集和名字節(jié)點(diǎn)失去聯(lián)系。名字節(jié)點(diǎn)根據(jù)缺失的心跳信息判斷故障情況。名字節(jié)點(diǎn)將這些數(shù)據(jù)節(jié)點(diǎn)標(biāo)記為死亡狀態(tài)，不再將新的 IO 請求轉(zhuǎn)發(fā)到這些數(shù)據(jù)節(jié)點(diǎn)上，這些數(shù)據(jù)節(jié)點(diǎn)上的數(shù)據(jù)將對 HDFS

15、 不再可用，可能會(huì)導(dǎo)致一些塊的復(fù)制因子降低到指定的值。名字節(jié)點(diǎn)檢查所有的需要復(fù)制的塊，并開始復(fù)制他們到其他的數(shù)據(jù)節(jié)點(diǎn)上。重新復(fù)制在有些情況下是不可或缺的，例如：數(shù)據(jù)節(jié)點(diǎn)失效，副本損壞，數(shù)據(jù)節(jié)點(diǎn)磁盤損壞或者文件的復(fù)制因子增大。數(shù)據(jù)正確性從數(shù)據(jù)節(jié)點(diǎn)上取一個(gè)文件塊有可能是壞塊，壞塊的出現(xiàn)可能是存儲(chǔ)設(shè)備錯(cuò)誤，網(wǎng)絡(luò)錯(cuò)誤或者軟件的漏洞。HDFS 客戶端實(shí)現(xiàn)了 HDFS 文件內(nèi)容的校驗(yàn)。當(dāng)一個(gè)客戶端創(chuàng)建一個(gè) HDFS 文件時(shí)，它會(huì)為每一個(gè)文件塊計(jì)算一個(gè)校驗(yàn)碼并將校驗(yàn)碼存儲(chǔ)在同一個(gè) HDFS 命名空間下一個(gè)單獨(dú)的隱藏文件中。當(dāng)客戶端訪問這個(gè)文件時(shí)，它根據(jù)對應(yīng)的校驗(yàn)文件來驗(yàn)證從數(shù)據(jù)節(jié)點(diǎn)接收到的數(shù)據(jù)。如果校驗(yàn)失敗

16、，客戶端可以選擇從其他擁有該塊副本的數(shù)據(jù)節(jié)點(diǎn)獲取這個(gè)塊。元數(shù)據(jù)失效FsImage 和 Editlog 是 HDFS 的核心數(shù)據(jù)結(jié)構(gòu)。這些文件的損壞會(huì)導(dǎo)致整個(gè)集群的失效。因此，名字節(jié)點(diǎn)可以配置成支持多個(gè) FsImage 和 EditLog 的副本。 任何 FsImage 和 EditLog 的更新都會(huì)同步到每一份副本中。同步更新多個(gè) EditLog 副本會(huì)降低名字節(jié)點(diǎn)的命名空間事務(wù)交易速率。但是這種降低是可以接受的，因?yàn)?HDFS 程序中產(chǎn)生大量的數(shù)據(jù)請求，而不是元數(shù)據(jù)請求。名字節(jié)點(diǎn)重新啟動(dòng)時(shí)，選擇最新一致的FsImage 和 EditLog。名字節(jié)點(diǎn)對于一個(gè) HDFS 集群是單點(diǎn)失效的。假如名

17、字節(jié)點(diǎn)失效，就需要人工的干預(yù)。還不支持自動(dòng)重啟和到其它名字節(jié)點(diǎn)的切換。特點(diǎn)快照快照支持在一個(gè)特定時(shí)間存儲(chǔ)一個(gè)數(shù)據(jù)拷貝，快照可以將失效的集群回滾到之前一個(gè)正常的時(shí)間點(diǎn)上。HDFS 已經(jīng)支持元數(shù)據(jù)快照。數(shù)據(jù)組織數(shù)據(jù)塊HDFS 的設(shè)計(jì)是用于支持大文件的。運(yùn)行在 HDFS 上的程序也是用于處理大數(shù)據(jù)集的。這些程序僅寫一次數(shù)據(jù)，一次或多次讀數(shù)據(jù)請求，并且這些讀操作要求滿足流式傳輸速度。HDFS 支持文件的一次寫多次讀操作。HDFS 中典型的塊大小是 64MB，一個(gè) HDFS 文件可以被被切分成多個(gè) 64MB 大小的塊，如果需要，每一個(gè)塊可以分布在不同的數(shù)據(jù)節(jié)點(diǎn)上。階段狀態(tài)一個(gè)客戶端創(chuàng)建一個(gè)文件的請求并不

18、會(huì)立即轉(zhuǎn)發(fā)到名字節(jié)點(diǎn)。實(shí)際上， 一開始 HDFS 客戶端將文件數(shù)據(jù)緩存在本地的臨時(shí)文件中。應(yīng)用程序的寫操作被透明地重定向到這個(gè)臨時(shí)本地文件。當(dāng)本地文件堆積到一個(gè) HDFS 塊大小的時(shí)候，客戶端才會(huì)通知名字節(jié)點(diǎn)。名字節(jié)點(diǎn)將文件名插入到文件系統(tǒng)層次中，然后為它分配一個(gè)數(shù)據(jù)塊。名字節(jié)點(diǎn)構(gòu)造包括數(shù)據(jù)節(jié)點(diǎn) ID（可能是多個(gè)，副本數(shù)據(jù)塊存放的節(jié)點(diǎn)也有）和目標(biāo)數(shù)據(jù)塊標(biāo)識(shí)的報(bào)文，用它回復(fù)客戶端的請求?？蛻舳耸盏胶髮⒈镜氐呐R時(shí)文件刷新到指定的數(shù)據(jù)節(jié)點(diǎn)數(shù)據(jù)塊中。當(dāng)文件關(guān)閉時(shí)，本地臨時(shí)文件中未上傳的殘留數(shù)據(jù)就會(huì)被轉(zhuǎn)送到數(shù)據(jù)節(jié)點(diǎn)。然后客戶端就可以通知名字節(jié)點(diǎn)文件已經(jīng)關(guān)閉。此時(shí)，名字節(jié)點(diǎn)將文件的創(chuàng)建操作添加到到持久化存

19、儲(chǔ)中。假如名字節(jié)點(diǎn)在文件關(guān)閉之前死掉，文件就丟掉了。上述流程是在認(rèn)真考慮了運(yùn)行在 HDFS 上的目標(biāo)程序之后被采用。這些應(yīng)用程序需要流式地寫文件。如果客戶端對遠(yuǎn)程文件系統(tǒng)進(jìn)行直接寫入而沒有任何本地的緩存，這就會(huì)對網(wǎng)速和網(wǎng)絡(luò)吞吐量產(chǎn)生很大的影響。這方面早有前車之鑒，早期的分布式文件系統(tǒng)如 AFS，也用客戶端緩沖來提高性能，POSIX 接口的限制也被放寬以達(dá)到更高的數(shù)據(jù)上傳速率。流水式復(fù)制當(dāng)客戶端寫數(shù)據(jù)到 HDFS 文件中時(shí)，如上所述，數(shù)據(jù)首先被寫入本地文件中，假設(shè) HDFS 文件的復(fù)制因子是 3，當(dāng)本地文件堆積到一塊大小的數(shù)據(jù)，客戶端從名字節(jié)點(diǎn)獲得一個(gè)數(shù)據(jù)節(jié)點(diǎn)的列表。這個(gè)列表也包含存放數(shù)據(jù)塊副本

20、的數(shù)據(jù)節(jié)點(diǎn)。當(dāng)客戶端刷新數(shù)據(jù)塊到第一個(gè)數(shù)據(jù)節(jié)點(diǎn)。第一個(gè)數(shù)據(jù)節(jié)點(diǎn)開始以 4kb為單元接收數(shù)據(jù)，將每一小塊都寫到本地庫中，同時(shí)將每一小塊都傳送到列表中的第二個(gè)數(shù)據(jù)節(jié)點(diǎn)。同理，第二個(gè)數(shù)據(jù)節(jié)點(diǎn)將小塊數(shù)據(jù)寫入本地庫中同時(shí)傳給第三個(gè)數(shù)據(jù)節(jié)點(diǎn)，第三個(gè)數(shù)據(jù)節(jié)點(diǎn)直接寫到本地庫中。一個(gè)數(shù)據(jù)節(jié)點(diǎn)在接前一個(gè)節(jié)點(diǎn)數(shù)據(jù)的同時(shí)，還可以將數(shù)據(jù)流水式傳遞給下一個(gè)節(jié)點(diǎn)，所以，數(shù)據(jù)是流水式地從一個(gè)數(shù)據(jù)節(jié)點(diǎn)傳遞到下一個(gè)?？稍L問性HDFS 提供多種方式由應(yīng)用程序訪問， 自然地， HDFS 提供為程序提供 java api， 為 c 語言包裝的 javaapi 也是可用的，還有一個(gè) HTTP 瀏覽器可以瀏覽 HDFS 中的文件，通過 W

21、ebDAV 協(xié)議訪問 HDFS 庫的方式也正在構(gòu)建中。DFSShellHDFS 允許用戶數(shù)據(jù)組織成文件和文件夾的方式，它提供一個(gè)叫 DFSShell 的接口，使用戶可以和HDFS 中的數(shù)據(jù)交互。命令集的語法跟其他用戶熟悉的 shells（bash,csh）相似。分布式文件系統(tǒng)分布式文件系統(tǒng)分布式文件系統(tǒng)（Distributed File System）是指文件系統(tǒng)管理的物理存儲(chǔ)資源不一定直接連接在本地節(jié)點(diǎn)上，而是通過計(jì)算機(jī)網(wǎng)絡(luò)與節(jié)點(diǎn)相連。分布式文件系統(tǒng)的設(shè)計(jì)基于客戶機(jī)/服務(wù)器模式。一個(gè)典型的網(wǎng)絡(luò)可能包括多個(gè)供多用戶訪問的服務(wù)器。另外，對等特性允許一些系統(tǒng)扮演客戶機(jī)和服務(wù)器的雙重角色。例如，用戶

22、可以“發(fā)表”一個(gè)允許其他客戶機(jī)訪問的目錄，一旦被訪問，這個(gè)目錄對客戶機(jī)來說就像使用本地驅(qū)動(dòng)器一樣，下面是三個(gè)基本的分布式文件系統(tǒng)。簡介計(jì)算機(jī)通過文件系統(tǒng)管理、存儲(chǔ)數(shù)據(jù)，而信息爆炸時(shí)代中人們可以獲取的數(shù)據(jù)成指數(shù)倍的增長，單純通過增加硬盤個(gè)數(shù)來擴(kuò)展計(jì)算機(jī)文件系統(tǒng)的存儲(chǔ)容量的方式，在容量大小、容量增長速度、數(shù)據(jù)備份、數(shù)據(jù)安全等方面的表現(xiàn)都差強(qiáng)人意。分布式文件系統(tǒng)可以有效解決數(shù)據(jù)的存儲(chǔ)和管理難題：將固定于某個(gè)地點(diǎn)的某個(gè)文件系統(tǒng)，擴(kuò)展到任意多個(gè)地點(diǎn)/多個(gè)文件系統(tǒng)，眾多的節(jié)點(diǎn)組成一個(gè)文件系統(tǒng)網(wǎng)絡(luò)。每個(gè)節(jié)點(diǎn)可以分布在不同的地點(diǎn)，通過網(wǎng)絡(luò)進(jìn)行節(jié)點(diǎn)間的通信和數(shù)據(jù)傳輸。人們在使用分布式文件系統(tǒng)時(shí)，無需關(guān)心數(shù)據(jù)是存

23、儲(chǔ)在哪個(gè)節(jié)點(diǎn)上、或者是從哪個(gè)節(jié)點(diǎn)從獲取的，只需要像使用本地文件系統(tǒng)一樣管理和存儲(chǔ)文件系統(tǒng)中的數(shù)據(jù)。決定因素文件系統(tǒng)最初設(shè)計(jì)時(shí)，僅僅是為局域網(wǎng)內(nèi)的本地?cái)?shù)據(jù)服務(wù)的。而分布式文件系統(tǒng)將服務(wù)范圍擴(kuò)展到了整個(gè)網(wǎng)絡(luò)。不僅改變了數(shù)據(jù)的存儲(chǔ)和管理方式，也擁有了本地文件系統(tǒng)所無法具備的數(shù)據(jù)備份、數(shù)據(jù)安全等優(yōu)點(diǎn)。判斷一個(gè)分布式文件系統(tǒng)是否優(yōu)秀，取決于以下三個(gè)因素：l 數(shù)據(jù)的存儲(chǔ)方式，例如有 1000 萬個(gè)數(shù)據(jù)文件，可以在一個(gè)節(jié)點(diǎn)存儲(chǔ)全部數(shù)據(jù)文件，在其他 N 個(gè)節(jié)點(diǎn)上每個(gè)節(jié)點(diǎn)存儲(chǔ) 1000/N 萬個(gè)數(shù)據(jù)文件作為備份；或者平均分配到 N 個(gè)節(jié)點(diǎn)上存儲(chǔ)，每個(gè)節(jié)點(diǎn)上存儲(chǔ)1000/N 萬個(gè)數(shù)據(jù)文件。無論采取何種存儲(chǔ)方式，目

24、的都是為了保證數(shù)據(jù)的存儲(chǔ)安全和方便獲取。l 數(shù)據(jù)的讀取速率，包括響應(yīng)用戶讀取數(shù)據(jù)文件的請求、定位數(shù)據(jù)文件所在的節(jié)點(diǎn)、讀取實(shí)際硬盤中數(shù)據(jù)文件的時(shí)間、不同節(jié)點(diǎn)間的數(shù)據(jù)傳輸時(shí)間以及一部分處理器的處理時(shí)間等。各種因素決定了分布式文件系統(tǒng)的用戶體驗(yàn)。 即分布式文件系統(tǒng)中數(shù)據(jù)的讀取速率不能與本地文件系統(tǒng)中數(shù)據(jù)的讀取速率相差太大，否則在本地文件系統(tǒng)中打開一個(gè)文件需要 2 秒，而在分布式文件系統(tǒng)中各種因素的影響下用時(shí)超過 10 秒，就會(huì)嚴(yán)重影響用戶的使用體驗(yàn)。l 數(shù)據(jù)的安全機(jī)制，由于數(shù)據(jù)分散在各個(gè)節(jié)點(diǎn)中，必須要采取冗余、備份、鏡像等方式保證節(jié)點(diǎn)出現(xiàn)故障的情況下，能夠進(jìn)行數(shù)據(jù)的恢復(fù)，確保數(shù)據(jù)安全。系統(tǒng)分類網(wǎng)絡(luò)文

25、件系統(tǒng)(NFS) 最早由 Sun 微系統(tǒng)公司作為 TCP/IP 網(wǎng)上的文件共享系統(tǒng)開發(fā)。 Sun 公司估計(jì)大約有超過 310萬個(gè)系統(tǒng)在運(yùn)行 NFS，大到大型計(jì)算機(jī)、小至 PC 機(jī)，其中至少有 80%的系統(tǒng)是非 Sun 平臺(tái)。Andrew 系統(tǒng)(AFS) 結(jié)構(gòu)與 NFS 相似，由卡內(nèi)基梅隆大學(xué)信息技術(shù)中心(ITC)開發(fā)、現(xiàn)由前 ITC 職員組成的Transarc 公司負(fù)責(zé)開發(fā)和銷售。AFS 較 NFS 有所增強(qiáng)。KASS 系統(tǒng)KASS File System（簡稱 KFS）是開始軟件自主研發(fā)基于 JAVA 的純分布式文件系統(tǒng)，功能類似于DFS、GFS、Hadoop，通過 HTTP WEB 為企業(yè)

26、的各種信息系統(tǒng)提供底層文件存儲(chǔ)及訪問服務(wù)，搭建企業(yè)私有云存儲(chǔ)服務(wù)平臺(tái)。DFS 系統(tǒng)(DFS) 是 AFS 的一個(gè)版本，作為開放軟件基金會(huì)(OSF)的分布分布式文件系統(tǒng)式計(jì)算環(huán)境(DCE)中的文件系統(tǒng)部分。如果文件的訪問僅限于一個(gè)用戶，那么分布式文件系統(tǒng)就很容易實(shí)現(xiàn)?？上У氖?，在許多網(wǎng)絡(luò)環(huán)境中這種限制是不現(xiàn)實(shí)的，必須采取并發(fā)控制來實(shí)現(xiàn)文件的多用戶訪問，表現(xiàn)為如下幾個(gè)形式：只讀共享 任何客戶機(jī)只能訪問文件，而不能修改它，這實(shí)現(xiàn)起來很簡單。受控寫操作 采用這種方法，可有多個(gè)用戶打開一個(gè)文件，但只有一個(gè)用戶進(jìn)行寫修改。而該用戶所作的修改并不一定出現(xiàn)在其它已打開此文件的用戶的屏幕上。并發(fā)寫操作 這種方法

27、允許多個(gè)用戶同時(shí)讀寫一個(gè)文件。但這需要操作系統(tǒng)作大量的監(jiān)控工作以防止文件重寫，并保證用戶能夠看到最新信息。這種方法即使實(shí)現(xiàn)得很好，許多環(huán)境中的處理要求和網(wǎng)絡(luò)通信量也可能使它變得不可接受。NFS 和 AFS 的區(qū)別NFS 和 AFS 的區(qū)別在于對并發(fā)寫操作的處理方法上。 當(dāng)一個(gè)客戶機(jī)向服務(wù)器請求一個(gè)文件(或數(shù)據(jù)庫記錄)，文件被放在客戶工作站的高速緩存中，若另一個(gè)用戶也請求同一文件，則它也會(huì)被放入那個(gè)客戶工作站的高速緩存中。當(dāng)兩個(gè)客戶都對文件進(jìn)行修改時(shí)，從技術(shù)上而言就存在著該文件的三個(gè)版本(每個(gè)客戶機(jī)一個(gè)，再加上服務(wù)器上的一個(gè))。有兩種方法可以在這些版本之間保持同步：無狀態(tài)系統(tǒng) 在這個(gè)系統(tǒng)中，服務(wù)

28、器并不保存其客戶機(jī)正在緩存的文件的信息。因此，客戶機(jī)必須協(xié)同服務(wù)器定期檢查是否有其他客戶改變了自己正在緩存的文件。這種方法在大的環(huán)境中會(huì)產(chǎn)生額外的 LAN通信開銷，但對小型 LAN 來說，這是一種令人滿意的方法。NFS 就是個(gè)無狀態(tài)系統(tǒng)。回呼(Callback)系統(tǒng) 在這種方法中，服務(wù)器記錄它的那些客戶機(jī)的所作所為，并保留它們正在緩存的文件信息。服務(wù)器在一個(gè)客戶機(jī)改變了一個(gè)文件時(shí)使用一種叫回叫應(yīng)答(callbackpromise)的技術(shù)通知其它客戶機(jī)。這種方法減少了大量網(wǎng)絡(luò)通信。AFS(及 OSFDCE 的 DFS)就是回叫系統(tǒng)?？蛻魴C(jī)改變文件時(shí)，持有這些文件拷貝的其它客戶機(jī)就被回叫并通知這些

29、改變。無狀態(tài)操作在運(yùn)行性能上有其長處，但 AFS 通過保證不會(huì)被回叫應(yīng)答充斥也達(dá)到了這一點(diǎn)。方法是在一定時(shí)間后取消回叫?？蛻魴C(jī)檢查回叫應(yīng)答中的時(shí)間期限以保證回叫應(yīng)答是當(dāng)前有效的?；亟袘?yīng)答的另一個(gè)有趣的特征是向用戶保證了文件的當(dāng)前有效性。換句話說，若一個(gè)被緩存的文件有一個(gè)回叫應(yīng)答，則客戶機(jī)就認(rèn)為文件是當(dāng)前有效的，除非服務(wù)器呼叫指出服務(wù)器上的該文件已改變了。數(shù)據(jù)軟件Yonghong Z-Data MartYonghong Data Mart 是一款數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)處理的軟件。Yonghong Data Mart 采用基于 ZDFS 的分布式列存儲(chǔ)系統(tǒng)，就是將數(shù)據(jù)分散存儲(chǔ)在多臺(tái)獨(dú)立的設(shè)備上。傳統(tǒng)的網(wǎng)絡(luò)

30、存儲(chǔ)系統(tǒng)采用集中的存儲(chǔ)服務(wù)器存放所有數(shù)據(jù)，存儲(chǔ)服務(wù)器成為系統(tǒng)性能的瓶頸，也是可靠性和安全性的焦點(diǎn)，不能滿足大規(guī)模存儲(chǔ)應(yīng)用的需要。分布式網(wǎng)絡(luò)存儲(chǔ)系統(tǒng)采用可擴(kuò)展的系統(tǒng)結(jié)構(gòu)，利用多臺(tái)存儲(chǔ)服務(wù)器分擔(dān)存儲(chǔ)負(fù)荷，利用位置服務(wù)器定位存儲(chǔ)信息，它不但提高了系統(tǒng)的可靠性、可用性和存取效率，還易于擴(kuò)展。Yonghong Data Mart 的分布式文件存儲(chǔ)系統(tǒng) (ZDFS)是在 Hadoop HDFS 基礎(chǔ)上進(jìn)行的改造和擴(kuò)展，將服務(wù)器集群內(nèi)所有節(jié)點(diǎn)上存儲(chǔ)的文件統(tǒng)一管理和存儲(chǔ)。 這些節(jié)點(diǎn)包括唯一的一個(gè)NamingNode， 在 ZDFS內(nèi)部提供元數(shù)據(jù)服務(wù)；許多 MapNode，提供存儲(chǔ)塊。存儲(chǔ)在 ZDFS 中的文件

31、被分成塊，然后將這些塊復(fù)制到多個(gè)計(jì)算機(jī)中（Map Node）。這與傳統(tǒng)的 RAID 架構(gòu)大不相同。塊的大小和復(fù)制的塊數(shù)量在創(chuàng)建文件時(shí)由客戶機(jī)決定。Naming Node 監(jiān)控存在服務(wù)器集群內(nèi)所有節(jié)點(diǎn)上的文件操作，例如文件創(chuàng)建、刪除、移動(dòng)、重命名等等。Network File SystemNFS 介紹NFS 定義（NFS）（Network File System）是個(gè)分布式的客戶機(jī)/服務(wù)器文件系統(tǒng)。NFS 的實(shí)質(zhì)在于用戶間計(jì)算機(jī)的共享。用戶可以聯(lián)結(jié)到共享計(jì)算機(jī)并像訪問本地硬盤一樣訪問共享計(jì)算機(jī)上的文件。管理員可以建立遠(yuǎn)程系統(tǒng)上文件的訪問，以至于用戶感覺不到他們是在訪問遠(yuǎn)程文件。NFS 是個(gè)到處可

32、用和廣泛實(shí)現(xiàn)的開放式系統(tǒng)。NFS 設(shè)計(jì)目標(biāo)允許用戶象訪問本地文件一樣訪問其他系統(tǒng)上的文件。提供對無盤工作站的支持以降低網(wǎng)絡(luò)開銷。簡化應(yīng)用程序?qū)h(yuǎn)程文件的訪問使得不需要因訪問這些文件而調(diào)用特殊的過程。使用一次一個(gè)服務(wù)請求以使系統(tǒng)能從已崩潰的服務(wù)器或工作站上恢復(fù)。采用安全措施保護(hù)文件免遭偷竊與破壞。使 NFS 協(xié)議可移植和簡單，以便它們能在許多不同計(jì)算機(jī)上實(shí)現(xiàn)，包括低檔的 PC 機(jī)。大型計(jì)算機(jī)、小型計(jì)算機(jī)和文件服務(wù)器運(yùn)行 NFS 時(shí)，都為多個(gè)用戶提供了一個(gè)文件存儲(chǔ)區(qū)。工作站只需要運(yùn)行 TCP/IP 協(xié)議來訪問這些系統(tǒng)和位于 NFS 存儲(chǔ)區(qū)內(nèi)的文件。 工作站上的 NFS 通常由 TCP/IP 軟件支

33、持。對 DOS 用戶，一個(gè)遠(yuǎn)程 NFS 文件存儲(chǔ)區(qū)看起來是另一個(gè)磁盤驅(qū)動(dòng)器盤符。對 Macintosh 用戶，遠(yuǎn)程 NFS 文件存儲(chǔ)區(qū)就是一個(gè)圖標(biāo)。NFS 部分功能服務(wù)器目錄共享 服務(wù)器廣播或通知正在共享的目錄，一個(gè)共享目錄通常叫做出版或出口目錄。有關(guān)共享目錄和誰可訪問它們的信息放在一個(gè)文件中，由操作系統(tǒng)啟動(dòng)時(shí)讀取?？蛻魴C(jī)訪問 在共享目錄上建立一種鏈接和訪問文件的過程叫做裝聯(lián)(mounting)， 用戶將網(wǎng)絡(luò)用作一條通信鏈路來訪問遠(yuǎn)程文件系統(tǒng)。NFS 的一個(gè)重要組成是虛擬文件系統(tǒng)(VFS)，它是應(yīng)用程序與低層文件系統(tǒng)間的接口。VFS 操作close 文件關(guān)閉操作create 文件生成操作fsy

34、nc 將改變保存到文件中g(shù)etattr 取文件屬性link 用另一個(gè)名字訪問一個(gè)文件lookup 讀目錄項(xiàng)mkdir 建立新目錄open 文件打開操作rdwr 文件讀寫操作remove 刪除一個(gè)文件rename 文件改名rmdir 刪除一目錄setattr 設(shè)置文件屬性AFS 服務(wù)器Andrew File System(AFS)Andrew 文件系統(tǒng)(AFS)AFS 是專門為在大型分布式環(huán)境中提供可靠的文件服務(wù)而設(shè)計(jì)的。 它通過基于單元的結(jié)構(gòu)生成一種可管理的分布式環(huán)境。一個(gè)單元是某個(gè)獨(dú)立區(qū)域中文件服務(wù)器和客戶機(jī)系統(tǒng)的集合，這個(gè)獨(dú)立區(qū)域由特定的機(jī)構(gòu)管理。通常代表一個(gè)組織的計(jì)算資源。用戶可以和同一

35、單元中其他用戶方便地共享信息，他們也可以和其他單元內(nèi)的用戶共享信息，這取決于那些單元中的機(jī)構(gòu)所授予的訪問權(quán)限。文件服務(wù)器進(jìn)程 這個(gè)進(jìn)程響應(yīng)客戶工作站對文件服務(wù)的請求，維護(hù)目錄結(jié)構(gòu)，監(jiān)控文件和目錄狀態(tài)信息，檢查用戶的訪問?；颈O(jiān)察(BOS)服務(wù)器進(jìn)程 這個(gè)進(jìn)程運(yùn)行于有 BOS 設(shè)定的服務(wù)器。它監(jiān)控和管理運(yùn)行其他服務(wù)的進(jìn)程并可自動(dòng)重啟服務(wù)器進(jìn)程，而不需人工幫助。卷宗服務(wù)器進(jìn)程 此進(jìn)程處理與卷宗有關(guān)的文件系統(tǒng)操作，如卷宗生成、移動(dòng)、復(fù)制、備份和恢復(fù)。卷宗定位服務(wù)器進(jìn)程 該進(jìn)程提供了對文件卷宗的位置透明性。即使卷宗被移動(dòng)了，用戶也能訪問它而不需要知道卷宗移動(dòng)了。鑒別服務(wù)器進(jìn)程 此進(jìn)程通過授權(quán)和相互鑒別

36、提供網(wǎng)絡(luò)安全性。 用一個(gè)“鑒別服務(wù)器”維護(hù)一個(gè)存有口令和加密密鑰的鑒別數(shù)據(jù)庫，此系統(tǒng)是基于 Kerberos 的。保護(hù)服務(wù)器進(jìn)程 此進(jìn)程基于一個(gè)保護(hù)數(shù)據(jù)庫中的訪問信息，使用戶和組獲得對文件服務(wù)的訪問權(quán)。更新服務(wù)器進(jìn)程 此進(jìn)程將 AFS 的更新和任何配置文件傳播到所有 AFS 服務(wù)器。AFS 還配有一套用于差錯(cuò)處理， 系統(tǒng)備份和 AFS 分布式文件系統(tǒng)管理的實(shí)用工具程序。 例如， SCOUT定期探查和收集 AFS 文件服務(wù)器的信息。信息在給定格式的屏幕上提供給管理員。設(shè)置多種閾值向管理者報(bào)告一些將發(fā)生的問題，如磁盤空間將用完等。另一個(gè)工具是 USS，可創(chuàng)建基于帶有字段常量模板的用戶帳戶。Ubik

37、 提供數(shù)據(jù)庫復(fù)制和同步服務(wù)。一個(gè)復(fù)制的數(shù)據(jù)庫是一個(gè)其信息放于多個(gè)位置的系統(tǒng)以便于本地用戶更方便地訪問這些數(shù)據(jù)信息。同步機(jī)制保證所有數(shù)據(jù)庫的信息是一致的。KFS 文件庫KFS（KASS File System ）實(shí)現(xiàn)價(jià)值1、高性能和高可靠性。支持通過增加服務(wù)器實(shí)現(xiàn)高并發(fā)、大存儲(chǔ)量、大吞吐量，且有效避免單點(diǎn)故障。2、可作為多個(gè)系統(tǒng)之間的文件共享存放平臺(tái)，多個(gè)系統(tǒng)均可遠(yuǎn)程訪問 KFS 文件庫，避免文件孤島。3、文件得到有效保護(hù)，多副本方式有效防止文件因單點(diǎn)故障導(dǎo)致無法及時(shí)訪問或丟失、損壞的問題。4、支持廣域網(wǎng)異地分布式存儲(chǔ)，同時(shí)控制流與數(shù)據(jù)流分離的模式，有效解決多網(wǎng)點(diǎn)辦公環(huán)境下公司文檔集中管理分散訪

38、問的問題，極大的優(yōu)化文檔管理模式與傳輸速度。功能特點(diǎn)1、完全基于 JAVA 實(shí)現(xiàn)，支持跨平臺(tái)部署。2、可獨(dú)立運(yùn)行，也可內(nèi)嵌至任何支持 JAVA 的 WEB 容器中運(yùn)行。3、不依賴任何第三方程序，也不依賴任何數(shù)據(jù)庫。4、 二次開發(fā)非常簡單?？蛻舳酥恍璋l(fā)送簡單的 HTTP 請求至 KFS 服務(wù)器的指定 URL 地址，即可完成 KFS 功能的遠(yuǎn)程調(diào)用。開發(fā)人員可以通過 IE 瀏覽器來完成所有的 KFS 功能調(diào)用。5、提供了豐富的功能。與操作系統(tǒng)提供的文件操作功能比較，我們提供了豐富的高級(jí)功能，如版本管理、文件刪除恢復(fù)、文件副本、文件日志、事件驅(qū)動(dòng)等等。6、系統(tǒng)高可靠性。優(yōu)異的架構(gòu)，無單點(diǎn)故障的設(shè)計(jì)，

39、集群同步的支持，信息流與數(shù)據(jù)流的分離設(shè)計(jì)，多副本機(jī)制，從多方面保障了整個(gè)系統(tǒng)的高可靠性和可用性。7、系統(tǒng)高可擴(kuò)展性。系統(tǒng)通過簡單配置即可實(shí)現(xiàn)文件存儲(chǔ)空間的擴(kuò)展，可通過擴(kuò)展名稱服務(wù)器集群來提高名稱服務(wù)器的并發(fā)性能，可通過增加副本文件來實(shí)現(xiàn)存儲(chǔ)服務(wù)器的 I/O 吞吐量擴(kuò)展。8、支持跨廣域網(wǎng)文件存儲(chǔ)。由于文件有多項(xiàng)副本存在，支持多項(xiàng)副本存儲(chǔ)在不同城市的數(shù)據(jù)服務(wù)器，以實(shí)現(xiàn)各地快速訪問文件目的。HadoopHadoop 是一個(gè)由 Apache 基金會(huì)所開發(fā)的分布式系統(tǒng)基礎(chǔ)架構(gòu)。用戶可以在不了解分布式底層細(xì)節(jié)的情況下，開發(fā)分布式程序。充分利用集群的威力進(jìn)行高速運(yùn)算和存儲(chǔ)。Hadoop 的框架最核心的設(shè)計(jì)就

40、是：HDFS 和 MapReduce。HDFS 為海量的數(shù)據(jù)提供了存儲(chǔ)，則MapReduce 為海量的數(shù)據(jù)提供了計(jì)算。2SparkSpark 是 UC Berkeley AMP lab 所開源的類 Hadoop MapReduce 的通用并行框架，Spark，擁有Hadoop MapReduce 所具有的優(yōu)點(diǎn)；但不同于 MapReduce 的是 Job 中間輸出結(jié)果可以保存在內(nèi)存中，從而不再需要讀寫 HDFS，因此 Spark 能更好地適用于數(shù)據(jù)挖掘與機(jī)器學(xué)習(xí)等需要迭代的 MapReduce 的算法。Spark 是一種與 Hadoop 相似的開源集群計(jì)算環(huán)境，但是兩者之間還存在一些不同之處，這

41、些有用的不同之處使 Spark 在某些工作負(fù)載方面表現(xiàn)得更加優(yōu)越，換句話說，Spark 啟用了內(nèi)存分布數(shù)據(jù)集，除了能夠提供交互式查詢外，它還可以優(yōu)化迭代工作負(fù)載。Spark 是在 Scala 語言中實(shí)現(xiàn)的，它將 Scala 用作其應(yīng)用程序框架。與 Hadoop 不同，Spark 和Scala 能夠緊密集成，其中的 Scala 可以像操作本地集合對象一樣輕松地操作分布式數(shù)據(jù)集。盡管創(chuàng)建 Spark 是為了支持分布式數(shù)據(jù)集上的迭代作業(yè)，但是實(shí)際上它是對 Hadoop 的補(bǔ)充，可以在 Hadoop 文件系統(tǒng)中并行運(yùn)行。 通過名為 Mesos 的第三方集群框架可以支持此行為。 Spark 由加州大學(xué)伯

42、克利分校 AMP 實(shí)驗(yàn)室 (Algorithms, Machines, and People Lab) 開發(fā)，可用來構(gòu)建大型的、低延遲的數(shù)據(jù)分析應(yīng)用程序基本原理Spark Streaming：構(gòu)建在 Spark 上處理 Stream 數(shù)據(jù)的框架，基本的原理是將 Stream 數(shù)據(jù)分成小的時(shí)間片斷（幾秒），以類似 batch 批量處理的方式來處理這小部分?jǐn)?shù)據(jù)。Spark Streaming 構(gòu)建在 Spark上，一方面是因?yàn)?Spark 的低延遲執(zhí)行引擎（100ms+），雖然比不上專門的流式數(shù)據(jù)處理軟件，也可以用于實(shí)時(shí)計(jì)算，另一方面相比基于 Record 的其它處理框架（如 Storm），一部分

43、窄依賴的 RDD 數(shù)據(jù)集可以從源數(shù)據(jù)重新計(jì)算達(dá)到容錯(cuò)處理目的。此外小批量處理的方式使得它可以同時(shí)兼容批量和實(shí)時(shí)數(shù)據(jù)處理的邏輯和算法。方便了一些需要?dú)v史數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)聯(lián)合分析的特定應(yīng)用場合。YARNApache Hadoop YARN （Yet Another Resource Negotiator，另一種資源協(xié)調(diào)者）是一種新的 Hadoop 資源管理器，它是一個(gè)通用資源管理系統(tǒng)，可為上層應(yīng)用提供統(tǒng)一的資源管理和調(diào)度，它的引入為集群在利用率、資源統(tǒng)一管理和數(shù)據(jù)共享等方面帶來了巨大好處。YARN 最初是為了修復(fù) MapReduce 實(shí)現(xiàn)里的明顯不足，并對可伸縮性（支持一萬個(gè)節(jié)點(diǎn)和二十萬個(gè)內(nèi)核的集群

44、）、可靠性和集群利用率進(jìn)行了提升。YARN 實(shí)現(xiàn)這些需求的方式是，把 Job Tracker 的兩個(gè)主要功能（資源管理和作業(yè)調(diào)度/監(jiān)控）分成了兩個(gè)獨(dú)立的服務(wù)程序全局的資源管理（RM）和針對每個(gè)應(yīng)用的應(yīng)用 Master（AM），這里說的應(yīng)用要么是傳統(tǒng)意義上的 MapReduce 任務(wù)，要么是任務(wù)的有向無環(huán)圖（DAG）。YARN 從某種那個(gè)意義上來說應(yīng)該算做是一個(gè)云操作系統(tǒng)， 它負(fù)責(zé)集群的資源管理。 在操作系統(tǒng)之上可以開發(fā)各類的應(yīng)用程序，例如批處理 MapReduce、流式作業(yè) Storm 以及實(shí)時(shí)型服務(wù) Storm 等。這些應(yīng)用可以同時(shí)利用 Hadoop 集群的計(jì)算能力和豐富的數(shù)據(jù)存儲(chǔ)模型， 共

45、享同一個(gè)Hadoop 集群和駐留在集群上的數(shù)據(jù)。 此外， 這些新的框架還可以利用YARN的資源管理器，提供新的應(yīng)用管理器實(shí)現(xiàn)。1YARN 簡介YARN 的基本思想是將 JobTracker 的兩個(gè)主要功能 （資源管理和作業(yè)調(diào)度/監(jiān)控） 分離，主要方法是創(chuàng)建一個(gè)全局的 ResourceManager（RM）和若干個(gè)針對應(yīng)用程序的ApplicationMaster （AM） 。 這里的應(yīng)用程序是指傳統(tǒng)的 MapReduce 作業(yè)或作業(yè)的 DAG （有向無環(huán)圖）。YARN 分層結(jié)構(gòu)的本質(zhì)是 ResourceManager。 這個(gè)實(shí)體控制整個(gè)集群并管理應(yīng)用程序向基礎(chǔ)計(jì)算資源的分配。ResourceMa

46、nager 將各個(gè)資源部分（計(jì)算、內(nèi)存、帶寬等）精心安排給基礎(chǔ) NodeManager（YARN 的每節(jié)點(diǎn)代理）。ResourceManager 還與ApplicationMaster 一起分配資源，與 NodeManager 一起啟動(dòng)和監(jiān)視它們的基礎(chǔ)應(yīng)用程序。在此上下文中，ApplicationMaster 承擔(dān)了以前的 TaskTracker 的一些角色，ResourceManager 承擔(dān)了 JobTracker 的角色。ApplicationMaster 管理一個(gè)在 YARN 內(nèi)運(yùn)行的應(yīng)用程序的每個(gè)實(shí)例。ApplicationMaster 負(fù)責(zé)協(xié)調(diào)來自 ResourceManager

47、的資源， 并通過 NodeManager 監(jiān)視容器的執(zhí)行和資源使用（CPU、內(nèi)存等的資源分配）。請注意，盡管目前的資源更加傳統(tǒng)（CPU 核心、內(nèi)存），但未來會(huì)帶來基于手頭任務(wù)的新資源類型（比如圖形處理單元或?qū)Ｓ锰幚碓O(shè)備）。從 YARN 角度講，ApplicationMaster 是用戶代碼，因此存在潛在的安全問題。YARN 假設(shè) ApplicationMaster 存在錯(cuò)誤或者甚至是惡意的，因此將它們當(dāng)作無特權(quán)的代碼對待。NodeManager 管理一個(gè) YARN 集群中的每個(gè)節(jié)點(diǎn)。NodeManager 提供針對集群中每個(gè)節(jié)點(diǎn)的服務(wù)，從監(jiān)督對一個(gè)容器的終生管理到監(jiān)視資源和跟蹤節(jié)點(diǎn)健康。MRv

48、1 通過插槽管理 Map 和 Reduce 任務(wù)的執(zhí)行，而 NodeManager 管理抽象容器，這些容器代表著可供一個(gè)特定應(yīng)用程序使用的針對每個(gè)節(jié)點(diǎn)的資源。 YARN 繼續(xù)使用 HDFS 層。 它的主要 NameNode 用于元數(shù)據(jù)服務(wù)，而 DataNode 用于分散在一個(gè)集群中的復(fù)制存儲(chǔ)服務(wù)。要使用一個(gè) YARN 集群，首先需要來自包含一個(gè)應(yīng)用程序的客戶的請求。ResourceManager 協(xié)商一個(gè)容器的必要資源，啟動(dòng)一個(gè) ApplicationMaster 來表示已提交的應(yīng)用程序。通過使用一個(gè)資源請求協(xié)議，ApplicationMaster 協(xié)商每個(gè)節(jié)點(diǎn)上供應(yīng)用程序使用的資源容器。執(zhí)行

49、應(yīng)用程序時(shí)，ApplicationMaster 監(jiān)視容器直到完成。當(dāng)應(yīng)用程序完成時(shí)，ApplicationMaster 從 ResourceManager 注銷其容器，執(zhí)行周期就完成了。2MRv1 的缺陷MapReduce 的第一個(gè)版本既有優(yōu)點(diǎn)也有缺點(diǎn)。 MRv1 是目前使用的標(biāo)準(zhǔn)的大數(shù)據(jù)處理系統(tǒng)。 但是， 這種架構(gòu)存在不足， 主要表現(xiàn)在大型集群上。 當(dāng)集群包含的節(jié)點(diǎn)超過 4,000 個(gè)時(shí)（其中每個(gè)節(jié)點(diǎn)可能是多核的），就會(huì)表現(xiàn)出一定的不可預(yù)測性。其中一個(gè)最大的問題是級(jí)聯(lián)故障， 由于要嘗試復(fù)制數(shù)據(jù)和重載活動(dòng)的節(jié)點(diǎn)， 所以一個(gè)故障會(huì)通過網(wǎng)絡(luò)泛洪形式導(dǎo)致整個(gè)集群嚴(yán)重惡化。但 MRv1 的最大問題是多

50、租戶。隨著集群規(guī)模的增加，一種可取的方式是為這些集群采用各種不同的模型。MRv1 的節(jié)點(diǎn)專用于 Hadoop，所以可以改變它們的用途以用于其他應(yīng)用程序和工作負(fù)載。當(dāng)大數(shù)據(jù)和 Hadoop 成為云部署中一個(gè)更重要的使用模型時(shí)，這種能力也會(huì)增強(qiáng)，因?yàn)樗试S在服務(wù)器上對 Hadoop 進(jìn)行物理化，而無需虛擬化且不會(huì)增加管理、計(jì)算和輸入/輸出開銷。2Yarn 的優(yōu)點(diǎn)大大減小了 JobTracker（也就是現(xiàn)在的 ResourceManager）的資源消耗，并且讓監(jiān)測每一個(gè) Job 子任務(wù) (tasks) 狀態(tài)的程序分布式化了，更安全、更優(yōu)美。在新的 Yarn 中，ApplicationMaster 是

51、一個(gè)可變更的部分，用戶可以對不同的編程模型寫自己的 AppMst， 讓更多類型的編程模型能夠跑在 Hadoop 集群中， 可以參考 hadoopYarn 官方配置模板中的 mapred-site.xml 配置。對于資源的表示以內(nèi)存為單位 ( 在目前版本的 Yarn 中，沒有考慮 cpu 的占用 )，比之前以剩余 slot 數(shù)目更合理。老的框架中，JobTracker 一個(gè)很大的負(fù)擔(dān)就是監(jiān)控 job 下的 tasks 的運(yùn)行狀況，現(xiàn)在，這個(gè)部分就扔給 ApplicationMaster 做了，而 ResourceManager 中有一個(gè)模塊叫做ApplicationsMasters( 注意不是

52、ApplicationMaster)，它是監(jiān)測 ApplicationMaster 的運(yùn)行狀況，如果出問題，會(huì)將其在其他機(jī)器上重啟。Container 是 Yarn 為了將來作資源隔離而提出的一個(gè)框架。這一點(diǎn)應(yīng)該借鑒了Mesos 的工作，目前是一個(gè)框架，僅僅提供 java 虛擬機(jī)內(nèi)存的隔離,hadoop 團(tuán)隊(duì)的設(shè)計(jì)思路應(yīng)該后續(xù)能支持更多的資源調(diào)度和控制 , 既然資源表示成內(nèi)存量，那就沒有了之前的map slot/reduce slot 分開造成集群資源閑置的尷尬情況。1YARN 的核心思想將 JobTracker 和 TaskTacker 進(jìn)行分離，它由下面幾大構(gòu)成組件：a. 一個(gè)全局的資源管

53、理器 ResourceManagerb.ResourceManager 的每個(gè)節(jié)點(diǎn)代理 NodeManagerc. 表示每個(gè)應(yīng)用的 ApplicationMasterd. 每一個(gè) ApplicationMaster 擁有多個(gè) Container 在 NodeManager 上運(yùn)行2YARN 的主要架構(gòu)ResourceManager（RM）RM 是一個(gè)全局的資源管理器，負(fù)責(zé)整個(gè)系統(tǒng)的資源管理和分配。它主要由兩個(gè)組件構(gòu)成：調(diào)度器（Scheduler）和應(yīng)用程序管理器（Applications Manager，ASM）。調(diào)度器 調(diào)度器根據(jù)容量、隊(duì)列等限制條件（如每個(gè)隊(duì)列分配一定的資源，最多執(zhí)行一定數(shù)

54、量的作業(yè)等），將系統(tǒng)中的資源分配給各個(gè)正在運(yùn)行的應(yīng)用程序。需要注意的是，該調(diào)度器是一個(gè)“純調(diào)度器”，它不再從事任何與具體應(yīng)用程序相關(guān)的工作，比如不負(fù)責(zé)監(jiān)控或者跟蹤應(yīng)用的執(zhí)行狀態(tài)等，也不負(fù)責(zé)重新啟動(dòng)因應(yīng)用執(zhí)行失敗或者硬件故障而產(chǎn)生的失敗任務(wù)，這些均交由應(yīng)用程序相關(guān)的 ApplicationMaster 完成。調(diào)度器僅根據(jù)各個(gè)應(yīng)用程序的資源需求進(jìn)行資源分配，而資源分配單位用一個(gè)抽象概念“資源容器”（Resource Container，簡稱 Container）表示，Container 是一個(gè)動(dòng)態(tài)資源分配單位，它將內(nèi)存、CPU、磁盤、網(wǎng)絡(luò)等資源封裝在一起，從而限定每個(gè)任務(wù)使用的資源量。此外，該調(diào)度器是一個(gè)可插拔的組件，用戶可根據(jù)自己的需要設(shè)計(jì)新的調(diào)度器，YARN 提供了多種直接可用的調(diào)度器，比如Fair Scheduler 和 Capacity Scheduler 等。應(yīng)用程序管理器應(yīng)用程序管