從零開始學Hadoop----淺析HDFS（一）

      之前，我們簡單介紹了一下Hadoop，知道他是一個處理大數據的框架。今天我們來看看Hadoop的核心構成之一—-HDFS.

一、基礎概念

1、是什麼

      HDFS是Hadoop Distribute File System 的簡稱，也就是Hadoop的一個分佈式文件系統。
      分佈式文件系統（Distributed File System）是指文件系統管理的物理存儲資源不一定直接連接在本地節點上，而是通過計算機網絡與節點相連。分佈式文件系統的設計基於客戶機/服務器模式。一個典型的網絡可能包括多個供多用戶訪問的服務器。另外，對等特性允許一些系統扮演客戶機和服務器的雙重角色

2、相關概念

• block（數據塊）

      提供真實文件數據的存儲服務。是最基本的存儲單位。對於文件內容而言，一個文件的長度大小是size，那麼從文件的０偏移開始，按照固定的大小，順序對文件進行劃分並編號，劃分好的每一個塊稱一個Block。每一個block會在多個datanode上存儲多份副本，默認是3份。

• namenode（元數據節點）

      namenode負責管理文件目錄、文件和block的對應關係以及block和datanode的對應關係。

文件結構

      fsimage:元數據鏡像文件。存儲某一時段NameNode內存元數據信息。
edits:操作日誌文件。
fstime:保存最近一次checkpoint的時間

處理過程

      Namenode始終在內存中保存metedata，用於處理“讀請求”到有“寫請求”到來時，namenode會首先寫editlog到磁盤，即向edits文件中寫日誌，成功返回後，纔會修改內存，並且向客戶端返回

      Hadoop會維護一個fsimage文件，也就是namenode中metedata的鏡像，但是fsimage不會隨時與namenode內存中的metedata保持一致，而是每隔一段時間通過合併edits文件來更新內容。Secondary namenode就是用來合併fsimage和edits文件來更新NameNode的metedata的。

• datanode（數據節點）

      datanode就負責存儲了，當然大部分容錯機制都是在datanode上實現的。

• secondarynamenode（從元數據節點）

      不是我們所想象的元數據節點的備用節點，其實它主要的功能是主要功能就是週期性將元數據節點的命名空間鏡像文件和修改日誌合併，以防日誌文件過大。

處理過程：

1、secondary通知namenode切換edits文件

2、secondary從namenode獲得fsimage和edits(通過http)

3、secondary將fsimage載入內存，然後開始合併edits

4、secondary將新的fsimage發回給namenode

5、namenode用新的fsimage替換舊的fsimage

3、優缺點

• 優點

處理超大文件

      這裏的超大文件通常是指百MB、設置數百TB大小的文件。目前在實際應用中，HDFS已經能用來存儲管理PB級的數據了。

流式的訪問數據

      HDFS的設計建立在更多地響應”一次寫入、多次讀寫”任務的基礎上。這意味着一個數據集一旦由數據源生成，就會被複制分發到不同的存儲節點中，然後響應各種各樣的數據分析任務請求。在多數情況下，分析任務都會涉及數據集中的大部分數據，也就是說，對HDFS來說，請求讀取整個數據集要比讀取一條記錄更加高效。

運行於廉價的商用機器集羣上

      Hadoop設計對硬件需求比較低，只須運行在低廉的商用硬件集羣上，而無需昂貴的高可用性機器上。廉價的商用機也就意味着大型集羣中出現節點故障情況的概率非常高。這就要求設計HDFS時要充分考慮數據的可靠性，安全性及高可用性。

• 缺點

不適合低延遲數據訪問

      如果要處理一些用戶要求時間比較短的低延遲應用請求，則HDFS不適合。HDFS是爲了處理大型數據集分析任務的，主要是爲達到高的數據吞吐量而設計的，這就可能要求以高延遲作爲代價。

      改進策略：對於那些有低延時要求的應用程序，HBase是一個更好的選擇。通過上層數據管理項目來儘可能地彌補這個不足。在性能上有了很大的提升，它的口號就是goes real time。使用緩存或多master設計可以降低client的數據請求壓力，以減少延時。還有就是對HDFS系統內部的修改，這就得權衡大吞吐量與低延時了，HDFS不是萬能的銀彈。

無法高效存儲大量小文件

      因爲Namenode把文件系統的元數據放置在內存中，所以文件系統所能容納的文件數目是由Namenode的內存大小來決定。一般來說，每一個文件、文件夾和Block需要佔據150字節左右的空間，所以，如果你有100萬個文件，每一個佔據一個Block，你就至少需要300MB內存。當前來說，數百萬的文件還是可行的，當擴展到數十億時，對於當前的硬件水平來說就沒法實現了。還有一個問題就是，因爲Map task的數量是由splits來決定的，所以用MR處理大量的小文件時，就會產生過多的Maptask，線程管理開銷將會增加作業時間。舉個例子，處理10000M的文件，若每個split爲1M，那就會有10000個Maptasks，會有很大的線程開銷；若每個split爲100M，則只有100個Maptasks，每個Maptask將會有更多的事情做，而線程的管理開銷也將減小很多。

不支持多用戶寫入及任意修改文件

      在HDFS的一個文件中只有一個寫入者，而且寫操作只能在文件末尾完成，即只能執行追加操作。目前HDFS還不支持多個用戶對同一文件的寫操作，以及在文件任意位置進行修改。

總結：

      這次我們知道了HDFS是一個分佈式的文件存儲系統，它的一些基本的概念和優缺點我們已經知道了，下次我們將給大家分享一下HDFS的運行原理。