1、MapReduce與分佈式文件系統
前面的討論中，我們已經得知，Hadoop中實現的MapReduce是一個編程模型和運行框架，它能夠通過JobTracker接收客戶提交的作業而後將其分割爲多個任務後並行運行在多個TaskTracker上。而問題是，這些TaskTracker如何高效獲取所要處理的數據？
在傳統的高性能集羣中，計算節點和存儲節點是各自獨立的，它們之間通過高速網絡完成互聯，然而，在面臨海量數據處理的問題時，網絡必然會成爲整個系統的性能瓶頸，這就需要引入超高速的網絡如萬兆以太網或Infiniband。然而，對大數場景來講它們屬於“奢侈品”，且昂貴的投入並不能帶來網絡性能的線性提升，因此性價比不高。面對這種問題，MapReduce採取了將計算節點與存儲節點合二爲一的集羣模型，它利用分佈式文件系統將數據存儲於多個節點上，而後讓處理過程在各數據節點本地直接進行，從而極大地降低了數據通過網絡傳送的需求。不過，這裏仍然需要說明的是，MapReduce並非依賴於分佈式文件系統，只不過運行在非分佈式文件系統的MapReduce的諸多高級特性將無用武之地。
事實上，分佈式文件系統並非MapReduce帶來的新生事物，只不過，MapReduce站在前人的基礎上將分佈式文件系統進行了改造以使得它更能夠適用於在MapReduce中完成海量數據處理。Google爲在他們的MapReduce中實現的分佈式文件系統爲GFS(Google File System)，而Hadoop的實現稱作HDFS(Hadoop Distributed File System)。
2、HDFS的設計理念
HDFS的許多設計思想與傳統的文件系統(如ext3、XFS等)是類似的，比如文件數據存儲於“數據塊(block)”中、通過“元數據”將文件名與數據塊建立映射關係、文件系統基於目錄實現樹狀組織結構、通過元數據保存文件權限及時間戳等。
但二者也有不同之處，比如傳統文件系統實現爲系統內核(尤其是Linux系統)中內核模塊，可通過用戶空間的相關工具進行管理操作，並能夠在掛載後供用戶使用；但HDFS是一種“用戶空間文件系統”，其文件系統代碼運行於內核之外並以用戶空間進程的形式存在，故不需要在VFS(Virtual FileSystem)註冊後向用戶空間輸出，也不能掛載使用。同時，HDFS還是一個分佈式文件系統，這意味着其工作於集羣模式中，數據塊分佈存儲於各“存儲節點(DataNode)”上，存儲空間的整體大小爲所有存儲節點貢獻出的空間之和，但元數據存儲於集羣中一個稱之爲“名稱節點(NameNode)”專用的節點上。
但二者還有着更進一步的聯繫。HDFS是用戶空間的文件系統，其存儲空間是通過數據節點(datanode)上的DataNode進程將本地某文件系統輸出爲HDFS實現的。這意味着，在配置數據節點時，需要首先準備一個本地文件系統，其可以是某文件系統上一個目錄或者是一個獨立的已經掛載的文件系統，如/hadoop/storage，而後通過DataNode進程的配置文件將出輸出爲HDFS即可。當客戶端存儲文件時，DataNode進程接收進來的數據會存儲在/hadoop/storage目錄中；不過，需要注意的是，不能通過/hadoop/storage直接訪問這些文件。
此外，傳統文件系統的“塊大小(block size)”通過爲1KB、2KB或4KB等，而HDFS的塊大小爲64MB，且在生產環境中使用時，此塊大小通常還會被調整爲128MB、256MB甚至是512MB等。HDFS使用塊抽象層管理文件，可以實現將分塊分爲多個邏輯部分後分佈於多個存儲節點，也能夠有效簡化存儲子系統。而對於存儲節點來說，較大的塊可以減少磁盤的尋道次數，進而提升I/O性能。
因此，HDFS專爲存儲大文件而設計，通常以集羣模型運行於普通的商業服務器上，基於流式數據訪問模型完成數據存取。HDFS將所有文件的元數據存儲於名稱節點(NameNode)的內存中，能夠利用分佈式特性高效地管理“大”文件(GB級別甚至更大的文件)，對於有着海量小文件的應用場景則會給名稱節點的內存空間帶去巨大壓力並使得其很可能成爲系統性能瓶頸。再者，HDFS爲MapReduce的計算框架而設計，存儲下來數據主要用於後續的處理分析，其訪問模型爲“一次寫入、多次讀取”；因此，數據在HDFS中存儲完成後，僅能在文件尾部附加新數據，而不能對文件進行修改。另外，HDFS專爲了高效地傳輸大文件進行了優化，其爲了完成此目標，在“低延遲”特性上做出了很大讓步，因此，其不適用於較小訪問延遲的應用。
圖：HDFS架構
3、HDFS的名稱節點(NameNode)和數據節點(DataNode)
HDFS集羣中節點的工作模型爲“master-worker”，其也屬於主從架構，包含一個名稱節點(master)和多個數據節點(worker)。
名稱節點負責管理HDFS的名稱空間，即以樹狀結構組織的目錄及文件的元數據信息，這些信息持久存儲於名稱節點本地磁盤上並保存爲名稱“空間鏡像(namespace image)”和“編輯日誌(edit log)”兩個文件。名稱節點並不存儲數據塊，它僅需要知道每個文件對應數據塊的存儲位置，即真正存儲了數據塊的數據節點。然而，名稱節點並不會持久存儲數據塊所與其存儲位置的對應信息，因爲這些信息是在HDFS集羣啓動由名稱節點根據各數據節點發來的信息進行重建而來。數據節點的主要任務包括根據名稱節點或客戶的要求完成存儲或讀取數據塊，並週期性地將其保存的數據塊相關信息報告給名稱節點。
默認情況下，HDFS會在集羣中爲每個數據塊存儲三個副本以確保數據的可靠性、可用性及性能表現。在一個大規模集羣中，這三個副本一般會保存至不同機架中的數據節點上以應付兩種常見的故障：單數據節點故障和導致某機架上的所有主機離線的網絡故障。另外，如前面MapReduce運行模型中所述，爲數據塊保存多個副本也有利於MapReduce在作業執行過程中透明地處理節點故障等，併爲MapReduce中作業協同處理以提升性能提供了現實支撐。名稱節點會根據數據節點的週期性報告來檢查每個數據塊的副本數是否符合要求，低於配置個數要求的將會對其進行補足，而多出的將會被丟棄。
Hadoop Operations
本文出自 “馬哥教育Linux運維培訓” 博客，轉載請與作者聯繫！