1. 程式人生 > >從零開始學Hadoop----淺析HDFS(一)

從零開始學Hadoop----淺析HDFS(一)

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

一、基礎概念

1、是什麼

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

2、相關概念

  • block(資料塊)

      提供真實檔案資料的儲存服務。是最基本的儲存單位。對於檔案內容而言,一個檔案的長度大小是size,那麼從檔案的0偏移開始,按照固定的大小,順序對檔案進行劃分並編號,劃分好的每一個塊稱一個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的執行原理。