HADOOP中HDFS工作原理
轉載：http://www.weixuehao.com/archives/596
http://www.cnblogs.com/iloveyouforever/p/4303903.html
http://www.cnblogs.com/iloveyouforever/p/4304355.html
HDFS（Hadoop Distributed File System ）Hadoop分散式檔案系統。是根據google發表的論文翻版的。論文為GFS（Google File System）Google 檔案系統（中文，英文）。
HDFS有很多特點：
? ? ①?儲存多個副本，且提供容錯機制，副本丟失或宕機自動恢復。預設存3份。
? ? ②?執行在廉價的機器上。（商用機）
? ? ③?適合大資料的處理。多大？多小？HDFS預設會將檔案分割成block，64M為1個block。然後將block按鍵值對儲存在HDFS上，並將鍵值對的對映存到記憶體中。如果小檔案太多，那記憶體的負擔會很重。
如上圖所示，HDFS也是按照Master和Slave的結構。分NameNode、SecondaryNameNode、DataNode這幾個角色。
NameNode：是Master節點，是大領導。管理資料塊對映；處理客戶端的讀寫請求；配置副本策略；管理HDFS的名稱空間；
SecondaryNameNode
DataNode：Slave節點，奴隸，幹活的。負責儲存client發來的資料塊block；執行資料塊的讀寫操作。
熱備份：b是a的熱備份，如果a壞掉。那麼b馬上執行代替a的工作。
冷備份：b是a的冷備份，如果a壞掉。那麼b不能馬上代替a工作。但是b上儲存a的一些資訊，減少a壞掉之後的損失。
fsimage:元資料映象檔案（檔案系統的目錄樹。）
edits：元資料的操作日誌（針對檔案系統做的修改操作記錄）
namenode記憶體中儲存的是=fsimage+edits。
SecondaryNameNode負責定時預設1小時，從namenode上，獲取fsimage和edits來進行合併，然後再發送給namenode。減少namenode的工作量。所以講secondarynamenode，單獨放置到一臺機器上，可以增大冗餘，但是有可能會丟失一小時內處理的資料。
?
?
工作原理
寫操作：
有一個檔案FileA，100M大小。Client將FileA寫入到HDFS上。
HDFS按預設配置。
HDFS分佈在三個機架上Rack1，Rack2，Rack3。
?
a. Client將FileA按64M分塊。分成兩塊，block1和Block2;
b. Client向nameNode傳送寫資料請求，如圖藍色虛線①——>。
c. NameNode節點，記錄block資訊。並返回可用的DataNode，如粉色虛線②———>。
??? Block1: host2,host1,host3
??? Block2: host7,host8,host4
??? 原理：
??????? NameNode具有RackAware機架感知功能，這個可以配置。
??????? 若client為DataNode節點，那儲存block時，規則為：副本1，同client的節點上；副本2，不同機架節點上；副本3，同第二個副本機架的另一個節點上；其他副本隨機挑選。
??????? 若client不為DataNode節點，那儲存block時，規則為：副本1，隨機選擇一個節點上；副本2，不同副本1，機架上；副本3，同副本2相同的另一個節點上；其他副本隨機挑選。
d. client向DataNode傳送block1；傳送過程是以流式寫入。
? ? 流式寫入過程，
? ? ? ? 1>將64M的block1按64k的package劃分;
? ? ? ? 2>然後將第一個package傳送給host2;
? ? ? ? 3>host2接收完後，將第一個package傳送給host1，同時client想host2傳送第二個package；
? ? ? ? 4>host1接收完第一個package後，傳送給host3，同時接收host2發來的第二個package。
? ? ? ? 5>以此類推，如圖紅線實線所示，直到將block1傳送完畢。
? ? ? ? 6>host2,host1,host3向NameNode，host2向Client傳送通知，說“訊息傳送完了”。如圖粉紅顏色實線所示。
? ? ? ? 7>client收到host2發來的訊息後，向namenode傳送訊息，說我寫完了。這樣就真完成了。如圖黃色粗實線
? ? ? ? 8>傳送完block1後，再向host7，host8，host4傳送block2，如圖藍色實線所示。
? ? ? ? 9>傳送完block2後，host7,host8,host4向NameNode，host7向Client傳送通知，如圖淺綠色實線所示。
? ? ? ? 10>client向NameNode傳送訊息，說我寫完了，如圖黃色粗實線。。。這樣就完畢了。
分析，通過寫過程，我們可以瞭解到：
? ? ①寫1T檔案，我們需要3T的儲存，3T的網路流量貸款。
? ? ②在執行讀或寫的過程中，NameNode和DataNode通過HeartBeat進行儲存通訊，確定DataNode活著。如果發現DataNode死掉了，就將死掉的DataNode上的資料，放到其他節點去。讀取時，要讀其他節點去。
? ? ③掛掉一個節點，沒關係，還有其他節點可以備份；甚至，掛掉某一個機架，也沒關係；其他機架上，也有備份。
讀操作：
?
讀操作就簡單一些了，如圖所示，client要從datanode上，讀取FileA。而FileA由block1和block2組成。?
?
那麼，讀操作流程為：
a. client向namenode傳送讀請求。
b. namenode檢視Metadata資訊，返回fileA的block的位置。
? ? block1:host2,host1,host3
? ? block2:host7,host8,host4
c. block的位置是有先後順序的，先讀block1，再讀block2。而且block1去host2上讀取；然後block2，去host7上讀取；
?
上面例子中，client位於機架外，那麼如果client位於機架內某個DataNode上，例如,client是host6。那麼讀取的時候，遵循的規律是：
優選讀取本機架上的資料。
?
HDFS中常用到的命令
1、hadoop fs
hadoop fs -ls /
hadoop fs -lsr
hadoop fs -mkdir /user/hadoop
hadoop fs -put a.txt /user/hadoop/
hadoop fs -get /user/hadoop/a.txt /
hadoop fs -cp src dst
hadoop fs -mv src dst
hadoop fs -cat /user/hadoop/a.txt
hadoop fs -rm /user/hadoop/a.txt
hadoop fs -rmr /user/hadoop/a.txt
hadoop fs -text /user/hadoop/a.txt
hadoop fs -copyFromLocal localsrc dst 與hadoop fs -put功能類似。
hadoop fs -moveFromLocal localsrc dst 將本地檔案上傳到hdfs，同時刪除本地檔案。2、hadoop fsadmin?
hadoop dfsadmin -report
hadoop dfsadmin -safemode enter | leave | get | wait
hadoop dfsadmin -setBalancerBandwidth 10003、hadoop fsck
4、start-balancer.sh
注意，看了hdfs的佈局，以及作用，這裡需要考慮幾個問題：
1、既然NameNode，儲存小檔案不太合適，那小檔案如何處理？
2、NameNode在記憶體中儲存了meta等資訊，那麼記憶體的瓶頸如何解決？
3、Secondary是NameNode的冷備份，那麼SecondaryNamenode和Namenode不應該放到一臺裝置上，因為Namenode宕掉之後，SecondaryNamenode一般也就死了，那講SecondaryNameNode放到其他機器上，如何配置？
4、NameNode宕機後，如何利用secondaryNameNode上面的備份的資料，恢復Namenode？
5、裝置宕機，那麼，檔案的replication備份數目，就會小於配置值，那麼該怎麼辦？
1、HDFS簡介
HDFS（Hadoop Distributed File System）是Hadoop專案的核心子專案，是分散式計算中資料儲存管理的基礎，是基於流資料模式訪問和處理超大文件的需求而開發的，可以運行於廉價的商用伺服器上。它所具有的高容錯、高可靠性、高可擴充套件性、高獲得性、高吞吐率等特徵為海量資料提供了不怕故障的儲存，為超大資料集合的應用帶來了很多便利。
Hadoop整合了眾多檔案系統，在其中有一個綜合性的檔案系統抽象，它提供了檔案系統實現的各類介面，HDFS只是這個抽象檔案系統的一個例項。Hadoop提供了一個高層的檔案系統抽象類org.apache.hadoop.fs.FileSystem，這個抽象類展示了一個分散式檔案系統，並有幾個具體的實現，如表1-1所示。
表1-1 Hadoop檔案系統
Hadoop提供了許多檔案系統的介面，使用者可以使用URI方案選取合適的檔案系統實現互動。
2、HDFS基礎概念
2.1 資料庫（block）
- HDFS（Hadoop Disturbbuted File System）預設的最基本的儲存單位是64M的資料塊；
- 和普通檔案系統相同的是，HDFS的檔案是被分成64M的資料塊儲存的；
- 不同於普通檔案系統的是，HDFS中，如果一個檔案小於一個數據塊的大小，並不佔用整個資料塊儲存空間；
2.2 NameNode和DataNode
HDFS體系結構中有兩類節點，一類是NameNode，又叫“元資料節點”；另一類是DataNode，又叫“資料節點”。這兩類節點分別是承擔Master和Worker具體任務的執行節點。
1）元資料節點用來管理檔案系統的名稱空間
- 其將所有的檔案和資料夾的元資料儲存在一個檔案系統樹中；
- 這些資訊也會在硬碟上儲存成以下檔案：名稱空間映象（namespace image）及修改日誌（edit log）；
- 其還儲存了一個檔案包括哪些資料塊，分佈在哪些資料節點上，然而這些資訊並不儲存在硬碟上，而是在系統啟動的時候從資料節點收集而成的；
2）資料節點是檔案系統中真正儲存資料的地方
- 客戶端（client）或者元資料資訊（namenode）可以向資料節點請求寫入或者讀出資料塊；
- 其週期性的向元資料節點彙報其儲存的資料塊資訊；
3）從元資料節點（secondary namenode）
- 從元資料節點並不是元資料節點出現問題時候的備用節點，它和元資料節點負責不同的事情；
- 其主要功能就是週期性將元資料節點的名稱空間映象檔案盒修改日誌合併，以防日誌檔案過大（這點在下面會詳細敘述）；
- 合併過後的名稱空間映象檔案也在元資料節點儲存了一份，以防元資料節點失敗的時候，可以恢復；
2.3 元資料節點目錄結構
VERSION檔案是java properties檔案，儲存了HDFS的版本號。
- layoutVersion是一個負整數，儲存了HDFS的持續化在硬碟上的資料結構的格式版本號；
- namespaceID是檔案系統的唯一識別符號，是在檔案系統初次格式化時生成的；
- Ctime此處為0；
- storageType表示此資料夾中儲存的是元資料節點的資料結構；
2.4 資料節點的目錄結構
- blk_<id>儲存的是HDFS的資料塊，其中儲存了具體的二進位制資料；
- blk_<id>.meta儲存的是資料塊的熟悉資訊：版本資訊、型別資訊、checksum；
- 當一個目錄中的資料塊到達一定數量的時候，則建立子資料夾來儲存資料塊及資料塊屬性資訊；
2.5 檔案系統名稱空間映像檔案及修改日誌
- 當檔案系統客戶端（client）進行寫操作時，首先把它記錄在修改日誌中（edit log）；
- 元資料節點在記憶體中儲存了檔案系統的元資料資訊，在記錄了修改日誌後，元資料節點在修改記憶體中的資料結構；
- 每次寫操作成功之前，修改日誌都會同步（sync）到檔案系統；
- fsimage檔案，也即名稱空間映像檔案，是記憶體中的元資料在硬碟上的checkpoint，它是一種序列化的格式，並不能在硬碟上直接修改；
- 同資料的機制相似，當元資料節點失敗時，則最新checkpoint的元資料資訊從fsimage載入到記憶體中，然後逐一重新執行修改日誌中的操作；
- 從元資料節點就是用來幫助元資料節點將記憶體中的元資料資訊checkpoint到硬碟上的；
- checkpoint的過程如下：
- 從元資料節點通知元資料節點生成新的日誌檔案，以後的日誌都寫到新的日誌檔案中；
- 從元資料節點用http get從元資料節點獲取fsimage檔案及舊的日誌檔案；
- 從元資料節點將fsimage檔案載入到記憶體中，並執行日誌檔案中的操作，然後生成新的fsimage檔案；
- 從元資料節點將新的fsimage檔案用http post傳回元資料節點；
- 元資料節點可以將舊的fsimage檔案及舊的日誌檔案，換為新的fsimage檔案盒新的日誌檔案（第一步生成的），然後更新fsimage檔案，寫入此次checkpoint的時間；
- 這樣元資料節點中的fsimage檔案儲存了最新的checkpoint的元資料資訊，日誌檔案也重新開始，不會變的很大了；
3、HDFS體系結構
HDFS是一個主/從（Master/Slave）體系結構，從終端使用者的角度來看，它就像傳統的檔案系統一樣，可以通過目錄路徑對檔案執行CRUD（Create、Read、Update、Delete）操作。但由於分散式儲存的性質，HDFS叢集擁有一個NameNode和一些DataNode。NameNode管理檔案系統的元資料，DataNode儲存實際的資料。客戶端通過同NameNode和DataNodes的互動訪問檔案系統。客戶端聯絡NameNode以獲取檔案的元資料，而真正的檔案I/O操作是直接和DataNode進行互動的。
圖3-1 Hadoop的體系結構
1）NameNode、DataNode和Client
- NameNode可以看作是分散式檔案系統中的管理者，主要負責管理檔案系統的名稱空間、叢集配置資訊和儲存塊的複製等。NameNode會將檔案系統的Metadata儲存在記憶體中，這些資訊主要包括了檔案資訊、每一個檔案對應的檔案塊的資訊和每一個檔案塊在DataNode的資訊等；
- DataNode是檔案儲存的基本單元，它將Block儲存在本地檔案系統中，儲存了Block的Metadata，同時週期性的將所有存在的Block的資訊傳送給NameNode；
- Client就是需要獲取分散式檔案系統檔案的應用程式；
2）檔案寫入
- Client向NameNode發起檔案寫入的請求；
- NameNode根據檔案大小和檔案塊配置情況，返回給Client它所管理部分DataNode的資訊；
- Client將檔案劃分為多個Block，根據DataNode的地址資訊，按順序寫入到每一個DataNode塊中；
3）檔案讀取
- Client向NameNode發起檔案讀取的請求；
- NameNode返回檔案儲存的DataNode的資訊；
- Client讀取檔案資訊；
HDFS典型的部署是在一個專門的機器上執行的NameNode，叢集中的其他機器各執行一個DataNode；也可以在執行NameNode的機器上同時執行DataNode，或者一臺機器上執行多個DataNode。一個叢集只有一個NameNode的設計大大簡化了系統架構。
4、HDFS的優缺點
4.1 HDFS的優點
1）處理超大檔案
這裡的超大檔案通常是指百MB、甚至數百TB大小的檔案。目前在實際應用中，HDFS已經能用來儲存管理PB級的資料了。
2）流式的訪問資料
HDFS的設計建立在更多地響應“一次寫入、多次讀寫”任務的基礎上。這意味著一個數據集一旦由資料來源生成，就會被複製分發到不同的儲存節點中，然後響應各種各樣的資料分析任務請求。在多數情況下，分析任務都會涉及資料集中的大部分資料，也就是說，對HDFS來說，請求讀取整個資料集要比讀取一條記錄更加高效。
3）運行於廉價的商用機器叢集上
Hadoop設計對硬體需求比較低，只須要執行在低廉的商用硬體叢集上，而無需昂貴的高可用性機器上。廉價的商用機器也就意味著大型叢集中出現節點故障情況的概率非常高。這就要求設計HDFS時要充分考慮資料的可靠性、安全性及高可用性。
4.2 Hadoop的缺點
1）不適合低延遲資料訪問
如果要處理一些使用者要求時間比較短的低延遲應用請求，則HDFS不適合。HDFS是為處理大型資料集分析任務的，主要是為達到高的資料吞吐量而設計的，這就可能要求以高延遲作為代價。
改進策略：對於那些有低延遲要求的應用程式，HBase是一個更好的選擇。通過上層資料管理專案來儘可能地補充這個不足。在效能上有了很大的提升，它的口號就是goes real time。使用快取或多master設計可以降低client的資料請求壓力，以減少延遲。還有就是對HDFS系統內部的修改，這就得權衡大吞吐量與低延遲了，HDFS不是萬能的。
2）無法高效儲存大量小檔案
因為NameNode把檔案系統的元資料放置在記憶體中，所以檔案系統所能容納的檔案數目是由NameNode的記憶體大小來決定。一般來說，每一個檔案、文件夾和Block需要佔據150位元組左右的空間，所以，如果你有100萬個檔案，每一個佔據一個Block，你就至少需要300M記憶體。當前來說，數百萬的檔案還是可行的，當擴充套件到數十億時，對於當前的硬體水平來說就沒辦法實現了。還有一個問題就是，因為Map task的資料是由splits來決定的，所以用MR處理大量的小檔案時，就會產生過多的Maptask，執行緒管理開銷將會增加作業時間。舉個例子，處理10000M的檔案，若每個split為1M，那就會有10000個Maptasks，會有很大的執行緒開銷；若每個split為100M，則只有100個Maptasks，每個Maptask將會有更多的事情做，而執行緒的管理開銷也將減少很多。
改進策略：要想讓HDFS能處理好小檔案，有不少方法。
- 利用SequenceFile、MapFile、Har等方式歸檔小檔案，這個方法的原理就是把小檔案歸檔起來管理，HBase就是基於此的。對於這種方法，如果想找回原來的小檔案的內容，那就必須得知道與歸檔檔案的對映關係；
- 橫向擴充套件，一個Hadoop叢集能管理的小檔案有限，那就把幾個Hadoop叢集拖在一個虛擬伺服器後面，形成一個大的Hadoop叢集。google也是這麼幹過的。
- 多Master設計，這個作用顯而易見了。正在研發中的GFS II也要改為分散式多Master設計，還支援Master的Failover，而且Block大小改為1M，有意要調優處理小檔案啊；
- 附帶個Alibaba DFS的設計，也是多Master設計，它把Metadata的對映儲存和管理分開了，由多個Metadata儲存節點和一個查詢Master節點組成；
3）不支援多使用者寫入及任意修改檔案
在HDFS的一個檔案中只有一個寫入者，而且寫操作只能在檔案末尾完成，即只能執行追加操作。目前HDFS還不支援多個使用者對同一個檔案的寫操作，以及在檔案任意位置進行修改。
5、HDFS常用操作