Hadoop學習（一）：分佈式文件系統HDFS

HDFS （Hadoop Distributed File System）是 Hadoop 下的分佈式文件系統，具有高容錯、高吞吐量等特性，可以部署在低成本的硬件上。

HDFS特性

超大文件
適合存放MB-PB級別的數據
一次寫入，多次讀取
一次寫入，多次讀取是HDFS最高效的訪問模式
低成本硬件
HDFS可以運行在低成本的硬件中
吞吐量優先於低延時
對於低延時數據訪問的應用，不適合在HDFS上運行。
HDFS是爲高數據吞吐量應用優化的，所以高吞吐量 > 低延時
不適合大量小文件（好像所有文件系統都不適合= =）
每個文件、目錄、數據塊的存儲信息大概在150B左右，由於NameNode（NN）存在內存中，大量小文件會佔內存空間，同樣一次讀取大量小文件來說，總的尋址代價也會變的很高。
單用戶寫入
支持append不支持隨機讀寫
對於一個文件來說，在文件末尾追加操作小的效率要比隨機讀寫的效率高的多。

HDFS基本架構

HDFS的基礎架構分爲Client、NameNode、DataNode三部分，其中

Client爲用戶交互的接口，處理用戶讀寫請求
NameNode運行在內存中，存儲文件的元數據Metadata等信息
DataNode存儲在磁盤中，每個Datanode包含若干block，每個block大小爲128M，同時block副本數爲3。
Client與NameNode通過Metadate ops心跳來通信，NameNode與DataNode通過Block ops心跳來通信

HDFS知識點總結

數據塊
文件系統都會有塊的概念，HDFS同樣有block的設計。 HDFS block默認大小爲128M，默認塊副本爲3個（爲了保證容錯性），但當小文件（例如1M）存入HDFS中，並不會佔用一個塊128M，而只會佔1M。
如果數據塊設計的太小，文件的尋址時間佔比就會比較大，或者說尋址代價就比較高。由於HDFS爲高吞吐量設計，所以傳輸優於定位
如果數據塊設計的太大，那麼作業執行速度就會變慢（例如MR中的map任務通常一次只處理一個塊的中的數據，如果塊太大，作業執行速度就會變慢）。
塊緩存是對於磁盤頻繁訪問的文件，緩存到datanode的堆外內存中。
主/從架構
HDFS 遵循主/從架構，由單個 NameNode(NN) 和多個 DataNode(DN) 組成：
NameNode : 負責執行有關文件系統命名空間的操作，例如打開，關閉、重命名文件和目錄等。它同時還負責集羣元數據的存儲，記錄着文件中各個數據塊的位置信息，以上信息存放在（FSImage與EditLog文件中）
DataNode：負責提供來自文件系統客戶端的讀寫請求，執行塊的創建，刪除等操作，並定期（心跳機制）向NameNode發送所存儲塊信息
主/備架構
對於NameNode來說，如果運行NameNode的機器損壞，那麼整個集羣將無法使用（NameNode存放數據塊的信息，沒有了NameNode，客戶端將找不到DN中的數據）。因此對於NN實現容錯非常重要。
Hadoop提供兩種機制，一種是遠程掛載網絡文件系統NFS。另外一種是運行備用NameNode。
備用NameNode通常運行在另外一臺單獨的機器上，且主NameNode做的工作，備用NameNode也都做（寫FSImage與EditLog文件）。但對於備用NameNode來說，它的操作始終要滯後於主NameNode（網絡傳輸、或定期寫入造成），所以當主NameNode損壞而啓用備用NameNode後，往往會丟失一部分數據。一般採取的做法是將NFS的NN元數據複製到備用NameNode中然後作爲新的主NameNode運行。
華爲大數據課程：
Hadoop生態中很多組件都保證了HA，利用了Zookeeper來協調組件之間的服務，達到集羣的容錯性。
HDSF的HA：
NameNode主備模式（actice-standby）：集羣中只有一個主NameNode（active），主備之間的切換是由Zookeeper的ZKFC實例來操控的
JN：存儲EditLog（元數據操作的日誌文件）
數據複製與實現原理
由於 Hadoop 被設計運行在廉價的機器上，這意味着硬件是不可靠的，爲了保證容錯性，HDFS 提供了數據複製機制。HDFS 將每一個文件存儲爲一系列塊，每個塊由多個副本來保證容錯，塊的大小和複製因子可以自行配置（默認情況下，塊大小是 128M，默認複製因子是 3）。
大型的 HDFS 實例在通常分佈在多個機架的多臺服務器上，不同機架上的兩臺服務器之間通過交換機進行通訊。在大多數情況下，同一機架中的服務器間的網絡帶寬大於不同機架中的服務器之間的帶寬。因此 HDFS 採用機架感知副本放置策略，對於常見情況，當複製因子爲 3 時，HDFS 的放置策略是：
在寫入程序位於 datanode 上時，就優先將寫入文件的一個副本放置在該 datanode 上，否則放在隨機 datanode 上。之後在另一個遠程機架上的任意一個節點上放置另一個副本，並在該機架上的另一個節點上放置最後一個副本。此策略可以減少機架間的寫入流量，從而提高寫入性能。

如果複製因子大於 3，則隨機確定第 4 個和之後副本的放置位置，同時保持每個機架的副本數量低於上限，上限值通常爲（複製係數 - 1）/機架數量 + 2，需要注意的是不允許同一個 dataNode 上具有同一個塊的多個副本。
爲了最大限度地減少帶寬消耗和讀取延遲，HDFS 在執行讀取請求時，優先讀取距離讀取器最近的副本。如果在與讀取器節點相同的機架上存在副本，則優先選擇該副本。如果 HDFS 羣集跨越多個數據中心，則優先選擇本地數據中心上的副本。
副本機制（華爲大數據課程）：
讀採用就近原則，優先選擇 0 -> 2 -> 4
寫先選擇同服務器上的節點，然後選擇不同機架上的節點，最後選擇同機架不同服務器的節點0 -> 4 -> 2
元數據持久化：
元數據存於內存中，元數據持久化就是將主NameNode中的元數據通過備NameNode存儲到磁盤中：
首先生成EditLog.new文件，用來保存元數據持久化過程中新出現的讀寫操作
備NameNode獲取快照文件fsimage與editlog日誌文件，併合並生成爲fsimage.ckpt文件（持久化到磁盤中）
將fsimage.ckpt回滾到主NameNode中，將EditLog.new記錄的日誌再回滾爲Editlog
聯邦特性（可擴展）
若干個NameNode獨立，共同操作dataNode
當數據量很大時的使用（100PB）
架構的穩定性
心跳機制和重新複製：每個 DataNode 定期向 NameNode 發送心跳消息，如果超過指定時間沒有收到心跳消息，則將 DataNode 標記爲死亡。NameNode 不會將任何新的 IO 請求轉發給標記爲死亡的 DataNode，也不會再使用這些 DataNode 上的數據。由於數據不再可用，可能會導致某些塊的複製因子小於其指定值，NameNode 會跟蹤這些塊，並在必要的時候進行重新複製。
數據的完整性：由於存儲設備故障等原因，存儲在 DataNode 上的數據塊也會發生損壞。爲了避免讀取到已經損壞的數據而導致錯誤，HDFS 提供了數據完整性校驗機制來保證數據的完整性，具體操作如下：
當客戶端創建 HDFS 文件時，它會計算文件的每個塊的校驗和，並將校驗和存儲在同一 HDFS 命名空間下的單獨的隱藏文件中。當客戶端檢索文件內容時，它會驗證從每個 DataNode 接收的數據是否與存儲在關聯校驗和文件中的校驗和匹配。如果匹配失敗，則證明數據已經損壞，此時客戶端會選擇從其他 DataNode 獲取該塊的其他可用副本。
元數據的磁盤故障：FsImage 和 EditLog 是 HDFS 的核心數據，這些數據的意外丟失可能會導致整個 HDFS 服務不可用。爲了避免這個問題，可以配置 NameNode 使其支持 FsImage 和 EditLog 多副本同步，這樣 FsImage 或 EditLog 的任何改變都會引起每個副本 FsImage 和 EditLog 的同步更新。
支持快照：快照支持在特定時刻存儲數據副本，在數據意外損壞時，可以通過回滾操作恢復到健康的數據狀態。