大數據開發之深入HDFS_數據分析師

當數據集的大小超過一臺獨立的物理計算機的存儲能力時，就有必要對它進行分區(partition)并存儲到若干臺單獨的計算機上。管理網絡中跨多臺計算機存儲的文件系統稱為分布式文件系統(distributed filesystem)。該系統架構于網絡之上，勢必會引入網絡編程的復雜性，因此分布式文件系統比普通磁盤文件系統更為復雜。例如，使文件系統能夠容忍節點故障且不丟失任何數據，就是一個極大的挑戰。

Hadoop有一個稱為HDFS的分布式系統，即Hadoop Distributed Filesystem。在非正式文檔或舊文檔以及配置文件中，有時也簡稱為DFS，它們是一回事兒。HDFS是Hadoop的旗艦級文件系統，同時也是本章的重點，但實際上Hadoop是一個綜合性的文件系統抽象，因此下面我們也將看到Hadoop集成其他文件系統的方法(如本地文件系統和Amazon S3系統)。

3.1  HDFS的設計 

HDFS以流式數據訪問模式來存儲超大文件，運行于商用硬件集群上。讓我們仔細看看下面的描述。

• 超大文件 “超大文件”在這里指具有幾百MB、幾百GB甚至幾百TB大小的文件。目前已經有存儲PB級數據的Hadoop 集群了。
• 流式數據訪問 HDFS的構建思路是這樣的：一次寫入、多次讀取是最高效的訪問模式。數據集通常由數據源生成或從數據源復制而來，接著長時間在此數據集上進行各種分析。每次分析都將涉及該數據集的大部分數據甚至全部，因此讀取整個數據集的時間延遲比讀取第一條記錄的時間延遲更重要。
• 商用硬件 Hadoop并不需要運行在昂貴且高可靠的硬件上。它是設計運行在商用硬件(在各種零售店都能買到的普通硬件)的集群上的，因此至少對于龐大的集群來說，節點故障的幾率還是非常高的。HDFS遇到上述故障時，被設計成能夠繼續運行且不讓用戶察覺到明顯的中斷。同樣，那些不適合在HDFS上運行的應用也值得研究。目前某些應用領域并不適合在HDFS上運行，不過以后可能會有所改進。
• 低時間延遲的數據訪問要求低時間延遲數據訪問的應用，例如幾十毫秒范圍，不適合在HDFS上運行。記住，HDFS是為高數據吞吐量應用優化的，這可能會以提高時間延遲為代價。目前，對于低延遲的訪問需求，HBase(參見第12 章)是更好的選擇。
• 大量的小文件 由于namenode將文件系統的元數據存儲在內存中，因此該文件系統所能存儲的文件總數受限于namenode的內存容量。根據經驗，每個文件、目錄和數據塊的存儲信息大約占150字節。因此，舉例來說，如果有一百萬個文件，且每個文件占一個數據塊，那至少需要300 MB 的內存。盡管存儲上百萬個文件是可行的，但是存儲數十億個文件就超出了當前硬件的能力。
• 多用戶寫入，任意修改文件 HDFS中的文件可能只有一個writer，而且寫操作總是將數據添加在文件的末尾。它不支持具有多個寫入者的操作，也不支持在文件的任意位置進行修改?？赡芤院髸С诌@些操作，但它們相對比較低效。

3.2  HDFS的概念 

3.2.1  數據塊 

每個磁盤都有默認的數據塊大小，這是磁盤進行數據讀/寫的最小單位。構建于單個磁盤之上的文件系統通過磁盤塊來管理該文件系統中的塊，該文件系統塊的大小可以是磁盤塊的整數倍。文件系統塊一般為幾千字節，而磁盤塊一般為512字節。這些信息——文件系統塊大小——對于需要讀/寫文件的文件系統用戶來說是透明的。盡管如此，系統仍然提供了一些工具(如df和fsck)來維護文件系統，由它們對文件系統中的塊進行操作。

HDFS同樣也有塊(block)的概念，但是大得多，默認為64 MB。與單一磁盤上的文件系統相似，HDFS上的文件也被劃分為塊大小的多個分塊(chunk)，作為獨立的存儲單元。但與其他文件系統不同的是，HDFS中小于一個塊大小的文件不會占據整個塊的空間。如果沒有特殊指出，本書中提到的“塊”特指HDFS中的塊。

為何HDFS 中的塊如此之大？

HDFS的塊比磁盤的塊大，其目的是為了最小化尋址開銷。如果塊設置得足夠大，從磁盤傳輸數據的時間會明顯大于定位這個塊開始位置所需的時間。因而，傳輸一個由多個塊組成的文件的時間取決于磁盤傳輸速率。

我們來做一個速算，如果尋址時間約為10ms，而傳輸速率為100 MB/s，為了使尋址時間僅占傳輸時間的1%，我們要將塊大小設置約為100 MB。默認的塊大小實際為64 MB，但是很多情況下HDFS使用128 MB的塊設置。以后隨著新一代磁盤驅動器傳輸速率的提升，塊的大小將被設置得更大。

但是這個數也不會設置得過大。MapReduce中的map任務通常一次只處理一個塊中的數據，因此如果任務數太少(少于集群中的節點數量)，作業的運行速度就會比較慢。

對分布式文件系統中的塊進行抽象會帶來很多好處。第一個最明顯的好處是，一個文件的大小可以大于網絡中任意一個磁盤的容量。文件的所有塊并不需要存儲在同一個磁盤上，因此它們可以利用集群上的任意一個磁盤進行存儲。事實上，盡管不常見，但對于整個HDFS集群而言，也可以僅存儲一個文件，該文件的塊占滿集群中所有的磁盤。

第二個好處是，使用抽象塊而非整個文件作為存儲單元，大大簡化了存儲子系統的設計。簡化是所有系統的目標，但是這對于故障種類繁多的分布式系統來說尤為重要。將存儲子系統控制單元設置為塊，可簡化存儲管理(由于塊的大小是固定的，因此計算單個磁盤能存儲多少個塊就相對容易)。同時也消除了對元數據的顧慮(塊只是存儲數據的一部分——而文件的元數據，如權限信息，并不需要與塊一同存儲，這樣一來，其他系統就可以單獨管理這些元數據)。

不僅如此，塊還非常適合用于數據備份進而提供數據容錯能力和提高可用性。將每個塊復制到少數幾個獨立的機器上(默認為3個)，可以確保在塊、磁盤或機器發生故障后數據不會丟失。如果發現一個塊不可用，系統會從其他地方讀取另一個復本，而這個過程對用戶是透明的。一個因損壞或機器故障而丟失的塊可以從其他候選地點復制到另一臺可以正常運行的機器上，以保證復本的數量回到正常水平。參見4.1節對數據完整性的討論，進一步了解如何應對數據損壞。同樣，有些應用程序可能選擇為一些常用的文件塊設置更高的復本數量進而分散集群中的讀取負載。 

與磁盤文件系統相似，HDFS中fsck指令可以顯示塊信息。例如，執行以下命令將列出文件系統中各個文件由哪些塊構成(參見10.1.4.2節)： 

3.2.2  namenode和datanode 

和多個datanode(工作者)。namenode管理文件系統的命名空間。它維護著文件系統樹及整棵樹內所有的文件和目錄。這些信息以兩個文件形式永久保存在本地磁盤上：命名空間鏡像文件和編輯日志文件。namenode也記錄著每個文件中各個塊所在的數據節點信息，但它并不永久保存塊的位置信息，因為這些信息會在系統啟動時由數據節點重建。

客戶端(client)代表用戶通過與namenode和datanode交互來訪問整個文件系統?？蛻舳颂峁┮粋€類似于POSIX(可移植操作系統界面)的文件系統接口，因此用戶在編程時無需知道namenode和datanode也可實現其功能。

datanode是文件系統的工作節點。它們根據需要存儲并檢索數據塊(受客戶端或namenode調度)，并且定期向namenode發送它們所存儲的塊的列表。

沒有namenode，文件系統將無法使用。事實上，如果運行namenode服務的機器毀壞，文件系統上所有的文件將會丟失，因為我們不知道如何根據datanode的塊重建文件。因此，對namenode實現容錯非常重要，Hadoop為此提供兩種機制。

第一種機制是備份那些組成文件系統元數據持久狀態的文件。Hadoop可以通過配置使namenode在多個文件系統上保存元數據的持久狀態。這些寫操作是實時同步的，是原子操作。一般的配置是，將持久狀態寫入本地磁盤的同時，寫入一個遠程掛載的網絡文件系統(NFS)。

另一種可行的方法是運行一個輔助namenode，但它不能被用作namenode。這個輔助namenode的重要作用是定期通過編輯日志合并命名空間鏡像，以防止編輯日志過大。這個輔助namenode一般在另一臺單獨的物理計算機上運行，因為它需要占用大量CPU時間與namenode相同容量的內存來執行合并操作。它會保存合并后的命名空間鏡像的副本，并在namenode發生故障時啟用。但是，輔助namenode保存的狀態總是滯后于主節點，所以在主節點全部失效時，難免會丟失部分數據。在這種情況下，一般把存儲在NFS上的namenode元數據復制到輔助namenode并作為新的主namenode運行。

詳情參見10.1.1節對文件系統鏡像與編輯日志的討論。

3.2.3  聯邦HDFS 

namenode在內存中保存文件系統中每個文件和每個數據塊的引用關系，這意味著對于一個擁有大量文件的超大集群來說，內存將成為限制系統橫向擴展的瓶頸(參見9.4.2節)。在2.x發行版本系列中引入的聯邦HDFS允許系統通過添加namenode實現擴展，其中每個namenode管理文件系統命名空間中的一部分。例如，一個namenode可能管理/user目錄下的所有文件，而另一個namenode可能管理/share目錄下的所有文件。

在聯邦環境下，每個namenode維護一個命名空間卷(namespace volume)，包括命名空間的源數據和在該命名空間下的文件的所有數據塊的數據塊池。命名空間卷之間是相互獨立的，兩兩之間并不相互通信，甚至其中一個namenode的失效也不會影響由其他namenode維護的命名空間的可用性。數據塊池不再進行切分，因此集群中的datanode需要注冊到每個namenode，并且存儲著來自多個數據塊池中的數據塊。

要想訪問聯邦HDFS集群，客戶端需要使用客戶端掛載數據表將文件路徑映射到namenode。該功能可以通過ViewFileSystem和viewfs：//URI進行配置和管理。

3.2.4  HDFS的高可用性 

通過聯合使用在多個文件系統中備份namenode的元數據和通過備用namenode創建監測點能防止數據丟失，但是依舊無法實現文件系統的高可用性。Namenode依舊存在單點失效(SPOF)的問題。如果namenode失效了，那么所有的客戶端——包括MapReduce作業——均無法讀、寫或列 (list)文件，因為namenode是唯一存儲元數據與文件到數據塊映射的地方。在這一情況下，Hadoop系統無法提供服務直到有新的namenode上線。

在這樣的情況下，要想從一個失效的namenode恢復，系統管理員得啟動一個擁有文件系統元數據副本的新的namenode，并配置datanode和客戶端以便使用這個新的namenode。新的namenode直到滿足以下情形才能響應服務：1)將命名空間的映像導入內存中；2)重做編輯日志；3)接收到足夠多的來自datanode的數據塊報告并退出安全模式。對于一個大型并擁有大量文件和數據塊的集群，namenode的冷啟動需要30分鐘，甚至更長時間。

系統恢復時間太長，也會影響到日常維護。事實上，namenode失效的可能性非常低，所以在實際應用中計劃系統失效時間就顯得尤為重要。

Hadoop的2.x發行版本系列針對上述問題在HDFS中增加了對高可用性(HA)的支持。在這一實現中，配置了一對活動-備用(active-standby) namenode。當活動namenode失效，備用namenode就會接管它的任務并開始服務于來自客戶端的請求，不會有任何明顯中斷。實現這一目標需要在架構上做如下修改。

• namenode之間需要通過高可用的共享存儲實現編輯日志的共享。(在早期的高可用實現版本中，需要一個NFS過濾器來輔助實現，但是在后期版本中將提供更多的選擇，比如構建于ZooKeeper之上的BookKeeper這樣的系統。)當備用namenode接管工作之后，它將通讀共享編輯日志直至末尾，以實現與活動namenode的狀態同步，并繼續讀取由活動namenode寫入的新條目。
• datanode需要同時向兩個namenode發送數據塊處理報告，因為數據塊的映射信息存儲在namenode的內存中，而非磁盤。
• 客戶端需要使用特定的機制來處理namenode的失效問題，這一機制對用戶是透明的。

在活動namenode失效之后，備用namenode能夠快速(幾十秒的時間)實現任務接管，因為最新的狀態存儲在內存中：包括最新的編輯日志條目和最新的數據塊映射信息。實際觀察到的失效時間略長一點(需要1分鐘左右)，這是因為系統需要保守確定活動namenode是否真的失效了。

在活動namenode失效且備用namenode也失效的情況下，當然這類情況發生的概率非常低，管理員依舊可以申明一個備用namenode并實現冷啟動。這類情況并不會比非高可用(no-HA)的情況更差，并且從操作的角度講這是一個進步，因為上述處理已是一個標準的處理過程并植入Hadoop中。

故障切換與規避 

一個稱為故障轉移控制器(failover_controller)的系統中有一個新實體管理著將活動namenode轉移為備用namenode的轉換過程。故障轉移控制器是可插拔的，但其最初的實現是基于ZooKeeper的并由此確保有且僅有一個活動namenode。每一個namenode運行著一個輕量級的故障轉移控制器，其工作就是監視宿主namenode是否失效(通過一個簡單的心跳機制實現)并在namenode失效時進行故障切換。

管理員也可以手動發起故障轉移，例如在進行日常維護時。這稱為“平穩的故障轉移”，因為故障轉移控制器可以組織兩個namenode有序切換角色。

但在非平穩故障轉移的情況下，無法確切知道失效namenode是否已經停止運行。例如，在網速非常慢或者網絡被分割的情況下，同樣也可能激發故障轉移，但是先前的活動namenode依然運行著并且依舊是活動namenode。高可用實現做了更進一步的優化，以確保先前活動的namenode不會執行危害系統并導致系統崩潰的操作——該方法稱為“規避”(fencing)。系統引入了一系列的規避機制，包括殺死namenode進程，收回訪問共享存儲目錄的權限(通常使用供應商指定的NFS命令)，通過遠程管理命令以屏蔽相應網絡端口。訴諸的最后手段是，先前活動namenode可以通過一個相當形象的稱為STONITH(shootthe other node in the head)的技術進行規避，該方法主要通過一個特定的供電單元對相應主機進行斷電操作。

客戶端的故障切換通過客戶端類庫實現透明處理。最簡單的實現是通過客戶端的配置文件實現故障切換的控制。HDFS URI使用一個邏輯主機名，該主機名映射到一對namenode地址(在配置文件中設置)，客戶端類庫會訪問每一個namenode地址直至處理完成。

3.3  命令行接口 

現在我們通過命令行交互來進一步認識HDFS。HDFS還有很多其他接口，但命令行是最簡單的，同時也是許多開發者最熟悉的。

參照附錄A中偽分布模式下設置Hadoop的說明，我們先在一臺機器上運行HDFS。稍后介紹如何在集群上運行HDFS，以提供伸縮性與容錯性。

在我們設置偽分布配置時，有兩個屬性項需要進一步解釋。第一項是fs.default.name，設置為hdfs://localhost/，用于設置Hadoop的默認文件系統。文件系統是由URI指定的，這里我們已使用hdfs URI來配置HDFS為Hadoop的默認文件系統。HDFS的守護程序通過該屬性項來確定HDFS namenode的主機及端口。我們將在localhost默認端口8020上運行namenode。這樣一來，HDFS客戶端可以通過該屬性得知namenode在哪里運行進而連接到它。

第二個屬性dfs.replication，我們設為1，這樣一來，HDFS就不會按默認設置將文件系統塊復本設為3。在單獨一個datanode上運行時，HDFS無法將塊復制到3個datanode上，所以會持續給出塊復本不足的警告。設置這個屬性之后，就不會再有問題了。

文件系統的基本操作 

至此，文件系統已經可以使用了，我們可以執行所有常用的文件系統操作，例如，讀取文件，新建目錄，移動文件，刪除數據，列出目錄，等等?？梢暂斎雋adoop fs -help命令獲取每個命令的詳細幫助文件。

首先從本地文件系統將一個文件復制到HDFS：

該命令調用Hadoop文件系統的shell命令fs，后者提供了一系列子命令，在這個例子中，我們執行的是-copyFromLocal。本地文件quangle.txt被復制到運行在localhost上的 HDFS實例中，路徑為/user/tom/quangle.txt。事實上，我們可以簡化命令格式以省略主機的URI并使用默認設置，即省略hdfs://localhost，因為該項已在core-site.xml中指定。

我們也可以使用相對路徑，并將文件復制到HDFS的home目錄中，本例中為/user/tom： 

我們把文件復制回本地文件系統，并檢查是否一致： 

MD5鍵值相同，表明這個文件在HDFS之旅中得以幸存并保存完整。 最后，我們看一下HDFS文件列表。我們新建一個目錄看它在列表中是怎么顯示的： 

返回的結果信息與Unix命令ls -l的輸出結果非常相似，僅有細微差別。第1列顯示的是文件模式。第2列是這個文件的備份數(這在傳統Unix文件系統是沒有的)。由于我們在整個文件系統范圍內設置的默認復本數為1，所以這里顯示的也都是1。這一列的開頭目錄為空，因為本例中沒有使用復本的概念——目錄作為元數據保存在namenode中，而非datanode中。第3列和第4列顯示文件的所屬用戶和組別。第5列是文件的大小，以字節為單位，目錄為0。第6列和第7列是文件的最后修改日期與時間。最后，第8列是文件或目錄的絕對路徑。 

HDFS中的文件訪問權限

針對文件和目錄，HDFS的權限模式與POSIX 非常相似。

一共提供三類權限模式：只讀權限(r)、寫入權限(w)和可執行權限(x)。讀取文件或列出目錄內容時需要只讀權限。寫入一個文件或是在一個目錄上新建及刪除文件或目錄，需要寫入權限。對于文件而言，可執行權限可以忽略，因為你不能在HDFS中執行文件(與POSIX不同)，但在訪問一個目錄的子項時需要該權限。

每個文件和目錄都有所屬用戶(owner)、所屬組別(group)及模式(mode)。這個模式是由所屬用戶的權限、組內成員的權限及其他用戶的權限組成的。

在默認情況下，可以通過正在運行進程的用戶名和組名來唯一確定客戶端的標識。但由于客戶端是遠程的，任何用戶都可以簡單地在遠程系統上以其名義新建一個賬戶來進行訪問。因此，作為共享文件系統資源和防止數據意外損失的一種機制，權限只能供合作團體中的用戶使用，而不能用于在一個不友好的環境中保護資源。注意，最新版的Hadoop已經支持Kerberos用戶認證，該認證去除了這些限制，詳見第325頁的“安全”小節。但是，除了上述限制之外，為防止用戶或自動工具及程序意外修改或刪除文件系統的重要部分，啟用權限控制還是很重要的(這也是默認的配置，參見dfs.permissions屬性)。

如果啟用權限檢查，就會檢查所屬用戶權限，以確認客戶端的用戶名與所屬用戶是否匹配，另外也將檢查所屬組別權限，以確認該客戶端是否是該用戶組的成員；若不符，則檢查其他權限。

這里有一個超級用戶(super-user)的概念，超級用戶是namenode進程的標識。對于超級用戶，系統不會執行任何權限檢查。

3.4  Hadoop文件系統 

Hadoop有一個抽象的文件系統概念，HDFS只是其中的一個實現。Java抽象類 org.apache.hadoop.fs.FileSystem定義了Hadoop 中的一個文件系統接口，并且該抽象類有幾個具體實現，如表3-1所示。

表3-1.  Hadoop文件系統 

盡管運行的MapReduce程序可以訪問任何文件系統(有時也很方便)，但在處理大數據集時，建議你還是選擇一個有數據本地優化的分布式文件系統，如HDFS(參見2.4節)。

接口 

Hadoop是用Java寫的，通過Java API可以調用所有Hadoop文件系統的交互操作。例如，文件系統的命令解釋器就是一個Java 應用，它使用Java 的FileSystem類來提供文件系統操作。其他一些文件系統接口也將在本小節中做簡單介紹。這些接口通常與HDFS一同使用，因為Hadoop中的其他文件系統一般都有訪問基本文件系統的工具(對于FTP，有FTP客戶端；對于S3，有S3工具，等等)，但它們大多數都能用于任何Hadoop 文件系統。

1. HTTP 

通過HTTP來訪問HDFS有兩種方法：直接訪問，HDFS后臺進程直接服務于來自客戶端的請求；通過代理(一個對多個)訪問，客戶端通常使用DistributedFileSystem API訪問HDFS。這兩種方法如圖3-1所示。 

圖3-1. 通過HTTP直接訪問HDFS或者通過多個HDFS代理訪問HDFS 

在第一種情況中，由namenode內嵌的web服務器(運行在端口50070上)提供目錄服務，目錄列表以XML或者JSON格式存儲，并且文件數據由datanode的web服務器(運行在端口50075上)以數據流的形式傳輸。 

原來那個的HTTP接口(HFTP和HSFTP)是只讀的，但是新的WebHDFS實現支持所有的文件系統操作，包括Kerberos認證。WebHDFS必須通過將dfs.webhdfs.enalbe選項設置為真后才能啟用，并且只有啟用它之后，你才可以使用webhdfs URI。

第二種方法依靠一個或者多個獨立代理服務器通過HTTP訪問HDFS。(由于代理服務是無狀態的，因此可以運行在標準的負載均衡器之后。)所有到集群的網絡通信都需要經過代理。使用代理服務器后可以使用更嚴格的防火墻策略和帶寬限制策略。通常情況下通過代理服務器，實現在不同數據中心中部署的Hadoop集群之間的數據傳輸。

原來那個的HDFS代理服務器(在src/contrib/hdfsproxy)是只讀的并且客戶端使用HSFTP Filesystem實現(hsftp URI)進行訪問。從1.0.0版本開始，實現了一個稱為HttpFS的新代理服務器(具備讀和寫的能力)，并且提供了和WebHDFS的一樣的HTTP接口，因此客戶端可以通過webhdfsURI訪問這兩類接口。

在規范正式定義了WebHDFS中使用的HTTP REST API，以期望以后使用非Java語言編寫的客戶端有望直接使用這個API。

2. C語言 

Hadoop提供了一個名為libhdfs的C語言庫，該語言庫是Java，FileSystem接口類的一個鏡像(它被寫成訪問HDFS的C語言庫，但其實它可以訪問全部Hadoop文件系統)。它使用Java原生接口(Java Native Interface，JNI)調用Java 文件系統客戶端。

這個C語言API 與Java的API非常相似，但它的開發一般滯后于Java API，因此目前一些新的特性可能還不支持?？梢栽贖apdoop發行包的Libhdfs/docs/api目錄找到CAPI的相關文檔。

Hadoop 中自帶預先編譯好的32位Linux的libhdfs二進制編碼，但對于其他平臺，需要按照http://wiki.apache.org/hadoop/LibHDFS的教程自行編譯。

3. FUSE 

用戶空間文件系統(Filesystem in Userspace，FUSE)允許把按照用戶空間實現的文件系統整合成一個Unix文件系統。通過使用Hadoop的Fuse-DFS功能模塊，任何一個Hadoop 文件系統(不過一般為HDFS)均可以作為一個標準文件系統進行掛載。隨后便可以使用Unix工具(如ls和cat)與該文件系統交互，還可以通過任意一種編程語言調用POSIX 庫來訪問文件系統。

Fuse-DFS是用C語言實現的，調用libhdfs并作為訪問HDFS的接口。關于如何編譯和運行Fuse-DFS的文檔，可以在Hadoop發行版的src/contrib./fuse-dfs目錄中找到。

3.5  Java接口 

在本小節中，我們要深入探索Hadoop的Filesystem類：它是與Hadoop的某一文件系統進行交互的API。雖然我們主要聚焦于HDFS實例，即DistributedFileSystem，但總體來說，還是應該集成FileSystem抽象類，并編寫代碼，使其在不同文件系統中可移植。這對測試你編寫的程序非常重要，例如，你可以使用本地文件系統中的存儲數據快速進行測試。

3.5.1  從Hadoop URL讀取數據 

要從Hadoop 文件系統讀取文件，最簡單的方法是使用java.net.URL對象打開數據流，從中讀取數據。具體格式如下：