分布式文件系統(tǒng)

分布式文件系統(tǒng)Google文件系統(tǒng)GFS系統(tǒng)架構(gòu)容錯(cuò)機(jī)制系統(tǒng)管理技術(shù)Google業(yè)務(wù)全球最大搜索引擎、GoogleMaps、GoogleEarth、Gmail、YouTube等數(shù)據(jù)量巨大，且面向全球用戶提供實(shí)時(shí)服務(wù)

Google云計(jì)算平臺(tái)技術(shù)架構(gòu)文件存儲(chǔ)，GoogleDistributedFileSystem，GFS并行數(shù)據(jù)處理MapReduce分布式鎖Chubby分布式結(jié)構(gòu)化數(shù)據(jù)表BigTable分布式存儲(chǔ)系統(tǒng)Megastore分布式監(jiān)控系統(tǒng)Dapper

秘密武器：云計(jì)算平臺(tái)！GFS設(shè)計(jì)動(dòng)機(jī)Google需要一個(gè)支持海量存儲(chǔ)的文件系統(tǒng)購(gòu)置昂貴的分布式文件系統(tǒng)與硬件？為什么不使用當(dāng)時(shí)現(xiàn)存的文件系統(tǒng)？Google所面臨的問(wèn)題與眾不同

不同的工作負(fù)載，不同的設(shè)計(jì)優(yōu)先級(jí)（廉價(jià)、不可靠的硬件）需要設(shè)計(jì)與Google應(yīng)用和負(fù)載相符的文件系統(tǒng)是否可以在一堆廉價(jià)且不可靠的硬件上構(gòu)建可靠的分布式文件系統(tǒng)？GFS設(shè)計(jì)背景Google的應(yīng)用負(fù)載和技術(shù)環(huán)境集群中的節(jié)點(diǎn)失效是一種常態(tài)，而不是一種異常。按照傳統(tǒng)標(biāo)準(zhǔn)，文件都是非常巨大的，通常以G字節(jié)計(jì)。大部分文件都是只會(huì)在文件尾新增加數(shù)據(jù)，而少見(jiàn)修改已有數(shù)據(jù)的。應(yīng)用程序和文件系統(tǒng)API的協(xié)同設(shè)計(jì)提高了整個(gè)系統(tǒng)的靈活性。

5GFS設(shè)計(jì)背景設(shè)計(jì)預(yù)期持續(xù)監(jiān)視、錯(cuò)誤檢測(cè)、容錯(cuò)處理、自動(dòng)恢復(fù)對(duì)大文件有效管理同時(shí)支持小型文件文件超大文件的順序?qū)懭?、隨機(jī)小規(guī)模的寫(xiě)入大量的操作為在文件后追加數(shù)據(jù)，幾乎沒(méi)有隨機(jī)寫(xiě)入，寫(xiě)完后只讀，且讀取方式基本上只有大規(guī)模順序讀和小規(guī)模隨機(jī)讀支持多路合并模式進(jìn)行操作高性能的穩(wěn)定帶寬的網(wǎng)絡(luò)要比低延時(shí)更加重要接口常見(jiàn)操作create、delete、open、close、read、write特殊操作snapshot、recordappend(原子操作)6GFS將容錯(cuò)的任務(wù)交給文件系統(tǒng)完成，利用軟件的方法解決系統(tǒng)可靠性問(wèn)題，使存儲(chǔ)的成本成倍下降。GFS將服務(wù)器故障視為正?，F(xiàn)象，并采用多種方法，從多個(gè)角度，使用不同的容錯(cuò)措施，確保數(shù)據(jù)存儲(chǔ)的安全、保證提供不間斷的數(shù)據(jù)存儲(chǔ)服務(wù)

GFS架構(gòu)是怎樣的？系統(tǒng)架構(gòu)Client（客戶端）：應(yīng)用程序的訪問(wèn)接口

Master（主服務(wù)器）：管理節(jié)點(diǎn)，在邏輯上只有一個(gè)，保存系統(tǒng)的元數(shù)據(jù)，負(fù)責(zé)整個(gè)文件系統(tǒng)的管理ChunkServer（數(shù)據(jù)塊服務(wù)器）：負(fù)責(zé)具體的存儲(chǔ)工作。數(shù)據(jù)以文件的形式存儲(chǔ)在ChunkServer上實(shí)現(xiàn)機(jī)制客戶端首先訪問(wèn)Master節(jié)點(diǎn)，獲取交互的ChunkServer信息，然后訪問(wèn)這些ChunkServer，完成數(shù)據(jù)存取工作。這種設(shè)計(jì)方法實(shí)現(xiàn)了控制流和數(shù)據(jù)流的分離。Client與Master之間只有控制流，而無(wú)數(shù)據(jù)流，極大地降低了Master的負(fù)載。Client與ChunkServer之間直接傳輸數(shù)據(jù)流，同時(shí)由于文件被分成多個(gè)Chunk進(jìn)行分布式存儲(chǔ)，Client可以同時(shí)訪問(wèn)多個(gè)ChunkServer，從而使得整個(gè)系統(tǒng)的I/O高度并行，系統(tǒng)整體性能得到提高。

GFS特點(diǎn)有哪些？GFS特點(diǎn)采用中心服務(wù)器模式可以方便地增加ChunkServerMaster掌握系統(tǒng)內(nèi)所有ChunkServer的情況，方便進(jìn)行負(fù)載均衡不存在元數(shù)據(jù)的一致性問(wèn)題不緩存數(shù)據(jù)

文件操作大部分是流式讀寫(xiě)，不存在大量重復(fù)讀寫(xiě)，使用Cache對(duì)性能提高不大ChunkServer上數(shù)據(jù)存取使用本地文件系統(tǒng)，若讀取頻繁，系統(tǒng)具有Cache從可行性看，Cache與實(shí)際數(shù)據(jù)的一致性維護(hù)也極其復(fù)雜在用戶態(tài)下實(shí)現(xiàn)

利用POSIX編程接口存取數(shù)據(jù)降低了實(shí)現(xiàn)難度，提高通用性

POSIX接口提供功能更豐富

用戶態(tài)下有多種調(diào)試工具

Master和ChunkServer都以進(jìn)程方式運(yùn)行，單個(gè)進(jìn)程不影響整個(gè)操作系統(tǒng)

GFS和操作系統(tǒng)運(yùn)行在不同的空間，兩者耦合性降低只提供專(zhuān)用接口降低實(shí)現(xiàn)的難度對(duì)應(yīng)用提供一些特殊支持降低復(fù)雜度

GFSArchitectureClientClient代碼包含了google文件系統(tǒng)的API，并且會(huì)和master和

chunkserver進(jìn)行通信。client和master通信—交互元數(shù)據(jù)信息client會(huì)緩存從master獲取的元數(shù)據(jù)信息，以便對(duì)同一塊

的操作不在通過(guò)client-master交互。client和chunkserver通信—交互文件數(shù)據(jù)client所有的數(shù)據(jù)相關(guān)的通信是直接和chunkserver進(jìn)行，

但是不會(huì)緩存文件數(shù)據(jù)。11GFSArchitectureReadoperateClient讀取數(shù)據(jù)的操作順序：client把應(yīng)用要讀取的文件名和偏移量，根據(jù)固定的chunk大小，轉(zhuǎn)換成為文件的chunkindex。向master發(fā)送這個(gè)包含了文件名和chunkindex的請(qǐng)求。master返回相關(guān)的chunkhandle以及對(duì)應(yīng)的位置，client緩存這些信息。client就向最近的對(duì)應(yīng)位置的chunkserver發(fā)起請(qǐng)求，請(qǐng)求包含chunkhandle以及一個(gè)在這個(gè)chunk內(nèi)需要讀取得字節(jié)區(qū)間。chunkserver返回給client要讀取的chunkdata。12GFSArchitectureMaster負(fù)責(zé)管理所有的文件系統(tǒng)的元數(shù)據(jù)文件和chunk的namespace訪問(wèn)控制信息文件到chunk的映射關(guān)系當(dāng)前chunk的位置等等Master控制系統(tǒng)級(jí)別的活動(dòng)chunk的分配管理孤點(diǎn)chunk的垃圾回收機(jī)制chunk在chunkserver之間的移動(dòng)Master用心跳信息周期地跟每個(gè)chunkserver通信，給他們以指示并收集他們的狀態(tài)單一Master設(shè)計(jì)必須減小master的讀/寫(xiě)操作，以避免它成為集群瓶頸。Master13GFSArchitectureMaster保存三種類(lèi)型的數(shù)據(jù)：文件和chunk的namespace文件到chunks的映射關(guān)系每個(gè)chunk副本的位置所有的元數(shù)據(jù)都是保存在Master的內(nèi)存里。前兩個(gè)由在master本地硬盤(pán)的記錄所有變化信息的operationlog來(lái)持久化保存的，這個(gè)記錄也會(huì)在遠(yuǎn)端機(jī)器上保存副本。Master并不持久化保存chunk位置信息，啟動(dòng)地時(shí)候以及chunkserver加入集群的時(shí)候，向每一個(gè)chunkserver詢問(wèn)他的chunk信息。Metadata14GFSArchitectureOperationlog保存了關(guān)鍵的元數(shù)據(jù)變化歷史記錄,它是GFS的核心。同時(shí)作為邏輯時(shí)間基線，定義了并行操作的順序。為了Operationlog的可靠性，保證寫(xiě)log原子性。我們把這個(gè)文件保存在多個(gè)不同的主機(jī)上，并且只有當(dāng)刷新這個(gè)相關(guān)的操作記錄到本地和遠(yuǎn)程磁盤(pán)之后，才會(huì)給客戶端操作應(yīng)答。master通過(guò)自己的operationlog回滾自身文件系統(tǒng)狀態(tài)。

為了減少啟動(dòng)時(shí)間，我們必須盡量減少操作日志的大小，采用checkpoint操作。master的恢復(fù)時(shí)候，只需要最新的checkpoint以及后續(xù)的log文件。Operationlog15GFS

Architecture在GFS下，每一個(gè)文件都拆成固定大小的chunk(塊)。每一個(gè)塊都由master根據(jù)塊創(chuàng)建的時(shí)間產(chǎn)生一個(gè)全局唯一的以后不會(huì)改變的64位的chunkhandle標(biāo)志。chunkservers在本地磁盤(pán)上用Linux文件系統(tǒng)保存這些塊，并且根據(jù)chunkhandle和字節(jié)區(qū)間，通過(guò)Linux文件系統(tǒng)讀寫(xiě)這些塊的數(shù)據(jù)。出于可靠性的考慮，每一個(gè)塊都會(huì)在不同的chunkserver上保存?zhèn)浞?。缺省情況下，我們保存3個(gè)備份。Chunkserver16GFSArchitectureChunksize是設(shè)計(jì)的關(guān)鍵參數(shù)(64M)。采用很大的chunksize優(yōu)點(diǎn)：它減少了客戶端和master的交互。減少網(wǎng)絡(luò)管理量。減少了元數(shù)據(jù)在master上的大小。采用很大的chunksize缺點(diǎn)：小型文件包含較少數(shù)目的chunk，也許只有一個(gè)chunk。保存這些文件的chunkserver就會(huì)在大量客戶端訪問(wèn)的時(shí)候就會(huì)成為焦點(diǎn)，導(dǎo)致系統(tǒng)局部過(guò)載。Chunksizeize17GFS讀Applications通過(guò)GFSclient向GFS提交一個(gè)讀請(qǐng)求，Client會(huì)將文件名（filename）和chunkindex（通過(guò)程序指定的字節(jié)偏移和固定的chunksize可以計(jì)算出chunk的偏移，發(fā)送給GFSMasterMaster通過(guò)filename在namespace中找到相應(yīng)的metadata，metadata中包含有文件對(duì)應(yīng)chunk的chunkhandle和所在在的chunkserver的位置client緩存Master回復(fù)的metadata。Client直接去找chunkserver數(shù)據(jù)，請(qǐng)求信息包含了chunkhandle和byterange。chunkserver返回具體的數(shù)據(jù)。client不必再和master交互了，直接向chunkserver要數(shù)據(jù)，除非client上緩存的metadata過(guò)期了，或者文件被重新打開(kāi)了。2015/10/17GFS寫(xiě)一是單個(gè)client順序?qū)懚嵌嗫蛻舳说牟⑿袑?xiě)這里的寫(xiě)指都是追加操作一致性Lease租約Checkpoint時(shí)間戳Checksum校驗(yàn)2015/10/17GFSWrite

客戶端向Master請(qǐng)求chunk每個(gè)副本所在的ChunkServer，其中PrimaryChunkServer持有修改Lease。如果沒(méi)有ChunkServer持有Lease，說(shuō)明該chunk最近沒(méi)有寫(xiě)操作，Master會(huì)創(chuàng)議一個(gè)任務(wù)，按照一定的策略將chunk的Lease授權(quán)給個(gè)中一臺(tái)chunkServer。

Master返回客戶端Primary和其它ChunkServer的位置信息，客戶端將緩存這些信息供以后使用。如果不出現(xiàn)故障，客戶端以后讀寫(xiě)該chunk都不需要再次請(qǐng)求Master。

客戶端將要追加的記錄發(fā)送到每個(gè)副本。每個(gè)ChunkServer會(huì)在內(nèi)部的LRU構(gòu)造中緩存這些數(shù)據(jù)。GFS中采用數(shù)據(jù)流和控制流星散的方法，從而能夠基于收集拓?fù)洳季指玫卣{(diào)劑數(shù)據(jù)流的傳輸。當(dāng)所有副本都確認(rèn)收到了數(shù)據(jù)，客戶端倡議一個(gè)寫(xiě)要求控制號(hào)令給Primary。因?yàn)镻rimary可能收到多個(gè)客戶端對(duì)同一個(gè)chunk的并發(fā)追加操作，Primary將確定這些操作的挨次并寫(xiě)入當(dāng)?shù)兀籔rimary把寫(xiě)請(qǐng)求提交給所有的Secondary副本。每一個(gè)Secondary會(huì)按照Primary確定的遞次執(zhí)行寫(xiě)操作；Secondary副本成功完成后應(yīng)對(duì)Primary；

Primary應(yīng)答客戶端，如果有副本發(fā)生錯(cuò)誤，將出現(xiàn)Primary寫(xiě)成功但是某些Secondary不成功的情況，客戶端將重試。2015/10/17GFSArchitecture文件名字空間的改變（比如，文件的創(chuàng)建）是原子操作。他們是由master來(lái)專(zhuān)門(mén)處理的。名字空間的鎖定保證了操作的原子性以及正確性。如果不論從哪個(gè)副本上讀，所有的客戶都看到同樣的數(shù)據(jù)，那么文件的這個(gè)區(qū)域就是一致的。如果文件的區(qū)域是一致的并且用戶可以看到修改操作所寫(xiě)的數(shù)據(jù)，那么它就是已定義的。

Consistencymodel21GFSArchitecture數(shù)據(jù)更改可能是寫(xiě)一個(gè)記錄或是一個(gè)記錄增加（writes/recordappends）寫(xiě)操作會(huì)把數(shù)據(jù)寫(xiě)在應(yīng)用程序指定的偏移位置。記錄增加會(huì)導(dǎo)致數(shù)據(jù)（記錄）增加，這個(gè)增加即使是在并發(fā)操作中也至少是一個(gè)原子操作。GFS可以在這些記錄之間增加填充，或者僅僅是記錄的重復(fù)。這些確定區(qū)間之間的填充或者記錄的重復(fù)是不一致的，并且通常是因?yàn)橛脩粲涗洈?shù)據(jù)量比較小造成的。一系列成功的改動(dòng)之后，改動(dòng)后的文件區(qū)是確保確定的對(duì)所有的數(shù)據(jù)副本，按照相同順序?qū)hunk進(jìn)行提交數(shù)據(jù)的改動(dòng)來(lái)保證這樣的一致性。采用chunk的版本號(hào)碼控制，來(lái)檢查是否有過(guò)期的chunk改動(dòng)，這種通常發(fā)生在chunkserver宕機(jī)的情況下。過(guò)期的副本將不參加到改動(dòng)或者提交給master，讓master通知客戶端這個(gè)副本chunk的位置。

Consistencymodel22GFS刪除一個(gè)文件刪除時(shí)，Master節(jié)點(diǎn)象對(duì)待其它修改操作一樣，立刻把刪除操作以日志的方式記錄下來(lái)。Master節(jié)點(diǎn)并不馬上回收資源，而是把文件名改為一個(gè)包含刪除時(shí)間戳的、隱藏的名字。當(dāng)Master節(jié)點(diǎn)對(duì)文件系統(tǒng)命名空間做常規(guī)掃描的時(shí)候，它會(huì)刪除所有三天前的隱藏文件。直到文件被真正刪除，它們?nèi)耘f可以用新的特殊的名字讀取，也可以通過(guò)把隱藏文件改名為正常顯示的文件名的方式“反刪除”。當(dāng)隱藏文件被從名稱(chēng)空間中刪除，Master服務(wù)器內(nèi)存中保存的這個(gè)文件的相關(guān)元數(shù)據(jù)才會(huì)被刪除。2015/10/17Google文件系統(tǒng)GFS系統(tǒng)架構(gòu)容錯(cuò)機(jī)制系統(tǒng)管理技術(shù)Master容錯(cuò)

MasterNameSpace，文件系統(tǒng)目錄結(jié)構(gòu)

Chunk與文件名的映射Chunk副本的位置信息(默認(rèn)有三個(gè)副本)

NameSpace，文件系統(tǒng)目錄結(jié)構(gòu)

Chunk與文件名的映射Chunk副本的位置信息Master單個(gè)Master，對(duì)于前兩種元數(shù)據(jù)，GFS通過(guò)操作日志來(lái)提供容錯(cuò)功能

第三種元數(shù)據(jù)信息保存在各個(gè)ChunkServer上，Master故障時(shí)，磁盤(pán)恢復(fù)

GFS還提供了Master遠(yuǎn)程的實(shí)時(shí)備份,防止Master徹底死機(jī)的情況ChunkServer容錯(cuò)

采用副本方式實(shí)現(xiàn)ChunkServer容錯(cuò)每一個(gè)Chunk有多個(gè)存儲(chǔ)副本（默認(rèn)為三個(gè)），分布存儲(chǔ)在不同的ChunkServer上用戶態(tài)的GFS不會(huì)影響ChunkServer的穩(wěn)定性副本的分布策略需要考慮多種因素，如網(wǎng)絡(luò)的拓?fù)?、機(jī)架的分布、磁盤(pán)的利用率等對(duì)于每一個(gè)Chunk，必須將所有的副本全部寫(xiě)入成功，才視為成功寫(xiě)入GFS中的每一個(gè)文件被劃分成多個(gè)Chunk，Chunk的默認(rèn)大小是64MBChunkServer存儲(chǔ)的是Chunk的副本，副本以文件的形式進(jìn)行存儲(chǔ)每個(gè)Chunk又劃分為若干Block（64KB），每個(gè)Block對(duì)應(yīng)一個(gè)32bit的校驗(yàn)碼，保證數(shù)據(jù)正確（若某個(gè)Block錯(cuò)誤，則轉(zhuǎn)移至其他Chunk副本）盡管一份數(shù)據(jù)需要存儲(chǔ)三份，好像磁盤(pán)空間的利用率不高，但綜合比較多種因素，加之磁盤(pán)的成本不斷下降，采用副本無(wú)疑是最簡(jiǎn)單、最可靠、最有效，而且實(shí)現(xiàn)的難度也最小的一種方法。Simple,andgoodenough!Google文件系統(tǒng)GFS系統(tǒng)架構(gòu)容錯(cuò)機(jī)制系統(tǒng)管理技術(shù)大規(guī)模集群安裝技術(shù)故障檢測(cè)技術(shù)

節(jié)點(diǎn)動(dòng)態(tài)加入技術(shù)

節(jié)能技術(shù)

新的ChunkServer加入時(shí)，只需裸機(jī)加入，大大減少GFS維護(hù)工作量

GFS構(gòu)建在不可靠廉價(jià)計(jì)算機(jī)之上的文件系統(tǒng)，由于節(jié)點(diǎn)數(shù)目眾多，故障發(fā)生十分頻繁

Google采用了多種機(jī)制降低服務(wù)器能耗，如采用蓄電池代替昂貴的UPS系統(tǒng)管理技術(shù)GFS集群中通常有非常多的節(jié)點(diǎn)，需要相應(yīng)的技術(shù)支撐

小結(jié)簡(jiǎn)單的，就是最好的！思考GFS有什么問(wèn)題嗎？提綱Hadoop簡(jiǎn)介Hadoop分布式文件系統(tǒng)HDFSHDFS使用HDFS2015/10/17Hadoop簡(jiǎn)介

Hadoop——Apache開(kāi)源組織的一個(gè)分布式計(jì)算框架，可以在大量廉價(jià)的硬件設(shè)備組成的集群上運(yùn)行應(yīng)用程序，為應(yīng)用程序提供了一組穩(wěn)定可靠的接口，旨在構(gòu)建一個(gè)具有高可靠性和良好擴(kuò)展性的分布式系統(tǒng)

Hadoop云計(jì)算系統(tǒng)Google云計(jì)算系統(tǒng)HadoopHDFSGoogleGFSHadoopMapReduceGoogleMapReduceHadoopHBaseGoogleBigtableHadoopZooKeeperGoogleChubbyHadoopPigGoogleSawzallHadoop云計(jì)算系統(tǒng)與Google云計(jì)算系統(tǒng)

Hadoop簡(jiǎn)介開(kāi)源項(xiàng)目Lucene：Java開(kāi)發(fā)的開(kāi)源高性能全文檢索工具包

開(kāi)源項(xiàng)目Nutch：第一個(gè)開(kāi)源的Web搜索引擎

Hadoop

Hadoop簡(jiǎn)介Hadoop項(xiàng)目組成

（1）HadoopCommon（2）Avro（3）Chukwa（4）HBase（5）HDFS（6）Hive（7）MapReduce（8）Pig（9）ZooKeeper

Hadoop優(yōu)點(diǎn)

（1）可擴(kuò)展（2）經(jīng)濟(jì)（3）可靠（4）高效提綱Hadoop簡(jiǎn)介Hadoop分布式文件系統(tǒng)HDFSHDFS使用設(shè)計(jì)前提與目標(biāo)

設(shè)計(jì)前提與目標(biāo)硬件錯(cuò)誤是常態(tài)而不是異常流式數(shù)據(jù)訪問(wèn)

超大規(guī)模數(shù)據(jù)集

簡(jiǎn)單一致性模型

移動(dòng)計(jì)算比移動(dòng)數(shù)據(jù)更簡(jiǎn)單

異構(gòu)軟硬件平臺(tái)間的可移植性

體系結(jié)構(gòu)HDFS主從結(jié)構(gòu)體系NameNode：主控制服務(wù)器，負(fù)責(zé)維護(hù)文件系統(tǒng)的命名空間（Namespace）并協(xié)調(diào)客戶端對(duì)文件的訪問(wèn)，記錄命名空間內(nèi)的任何改動(dòng)或命名空間本身的屬性改動(dòng)DataNode：負(fù)責(zé)它們所在的物理節(jié)點(diǎn)上的存儲(chǔ)管理保障可靠性的措施

1．冗余備份每個(gè)文件存儲(chǔ)成一系列數(shù)據(jù)塊（Block），默認(rèn)塊大小為64MB（可配置）。為了容錯(cuò)，文件的所有數(shù)據(jù)塊都會(huì)有副本（副本數(shù)量即復(fù)制因子，可配置）2．副本存放采用機(jī)架感知（Rack-aware）的策略來(lái)改進(jìn)數(shù)據(jù)的可靠性、可用性和網(wǎng)絡(luò)帶寬的利用率

復(fù)制因子為3時(shí)數(shù)據(jù)塊分布情況

保障可靠性的措施

3.心跳檢測(cè)NameNode周期性地從集群中的每個(gè)DataNode接受心跳包和塊報(bào)告，收到心跳包說(shuō)明該DataNode工作正常4.安全模式系統(tǒng)啟動(dòng)時(shí)，NameNode會(huì)進(jìn)入一個(gè)安全模式。此時(shí)不會(huì)出現(xiàn)數(shù)據(jù)塊的寫(xiě)操作5.數(shù)據(jù)完整性檢測(cè)

HDFS客戶端軟件實(shí)現(xiàn)了對(duì)HDFS文件內(nèi)容的校驗(yàn)和（Checksum）檢查保障可靠性的措施

6.空間回收

文件被用戶或應(yīng)用程序刪除時(shí)，先把它移動(dòng)到/trash目錄里；只要還在這個(gè)目錄里，文件就可以被迅速恢復(fù)7.元數(shù)據(jù)磁盤(pán)失效NameNode可以配置為支持維護(hù)映像文件和事務(wù)日志的多個(gè)副本，任何對(duì)映像文件或事務(wù)日志的修改，都將同步到它們的副本上8.快照

快照支持存儲(chǔ)某個(gè)時(shí)間的數(shù)據(jù)復(fù)制，當(dāng)HDFS數(shù)據(jù)損壞時(shí)，可以回滾到過(guò)去一個(gè)已知正確的時(shí)間點(diǎn)。HDFS目前還不支持快照功能提升性能的措施

提升性能措施副本選擇HDFS會(huì)盡量使用離程序最近的副本來(lái)滿足用戶請(qǐng)求，這樣可以減少總帶寬消耗和讀延時(shí)

負(fù)載均衡HDFS的架構(gòu)支持?jǐn)?shù)據(jù)均衡策略

客戶端緩存HDFS客戶端先把數(shù)據(jù)緩存到本地的一個(gè)臨時(shí)文件，程序的寫(xiě)操作透明地重定向到這個(gè)臨時(shí)文件流水線復(fù)制DataNode從前一個(gè)節(jié)點(diǎn)接收數(shù)據(jù)的同時(shí)，即時(shí)把數(shù)據(jù)傳給后面的節(jié)點(diǎn)，這就是流水線復(fù)制訪問(wèn)接口

HadoopAPI（1）org.apache.hadoop.conf（2）org.apache.hadoop.dfs（3）org.apache.hadoop.fs（4）org.apache.hadoop.io（5）org.apache.hadoop.ipc（6）org.apache.hadoop.mapred（7）org.apache.hadoop.metrics（8）org.apache.hadoop.record（9）org.apache.hadoop.tools（10）org.apache.hadoop.util瀏覽器接口典型HDFS安裝會(huì)配置一個(gè)Web服務(wù)器開(kāi)放自己的命名空間，其TCP端口可配；默認(rèn)配置下http://namenode-name:50070這個(gè)頁(yè)面列出了集群里的所有DataNode和集群的基本狀態(tài)

提綱Hadoop簡(jiǎn)介Hadoop分布式文件系統(tǒng)HDFSHDFS使用Overview2015/10/17Writing

Data2015/10/17Writing

Data2015/10/17Writing

Data2015/10/17Reading

Data2015/10/17Fault2015/10/17Fault2