CDA數據分析 出品
在搭建僞分佈集羣或者搭建分佈式集羣過程中經常提到HDFS，HDFS到底是什麼東東呢？今天我們就給小夥伴們詳細介紹一下。
1、 HDFS簡介
HDFS（Hadoop Distributed File System）是hadoop項目的核心子項目，是分佈式計算中數據存儲管理的基礎。是基於流數據模式訪問和處理超大文件的需求而開發的， 可以運行於廉價的商用服務器上。
它所具有的高容錯、 高可靠性、 高可擴展性、 高獲得性、 高吞吐率等特徵爲海量數據提供了不怕故障的存儲， 爲超大數據集（Large Data Set） 的應用處理帶來了很多便利。
HDFS是開源的，存儲着Hadoop應用將要處理的數據，類似於普通的Unix和linux文件系統，不同的是它是實現了google的GFS文件系統的思想，是適用於大規模分佈式數據處理相關應用的、可擴展的分佈式文件系統。
2、 HDFS與Hadoop之間的關係
Hadoop是一個以一種可靠、高效、可伸縮的方式進行處理的，能夠對大量數據進行分佈式處理的系統框架。
HDFS是hadoop兼容最好的標準級文件系統。
所以可以理解爲hadoop是一個框架， HDFS 是Hadoop中的一個部件。
3、 爲什麼需要HDFS
小量的數據，單機的磁盤是能夠很好地處理面對的數據，但當數據量巨大（PB）時，磁盤開始糾結處理我們需要的海量信息。我們無法提升單個磁盤的傳輸速度， 因爲這個技術已經沒有空間了• 只能將大任務分解成小任務 ， 一塊磁盤分解成多個磁盤。• 對多個磁盤上的文件進行管理， 就是分佈式文件管理系統—HDFS
4、 HDFS系統架構 及主要組件
在之前分步啓動Hadoop集羣時大家應該注意到了，集羣中與HDFS相關的進程有兩類，分別是namenode與datanode。HDFS是一個主從架構的系統，其中namenode作爲主節點管理着多個從工點datanode。其架構圖如下所示：
Namenode：
管理維護着文件系統樹以及整個文件樹內所有的文件和目錄即文件系統的元數據； 控制客戶端對文件的訪問； 它還執行文件系統操作， 如重命名,關閉和打開文件/目錄。DateNode：
管理所存儲的數據；按照客戶端的請求， 執行在文件系統上的讀寫操作；還根據NameNode的指令執行操作如block的創建、 刪除和備份。
Block
通常用戶的數據存儲在HDFS上的文件中；該文件將被拆分爲一個或多個片段， 並存儲在單個的數據節點；這些文件片段稱爲blocks。 換句話說， HDFS可讀寫的最小數據量叫做Block。 默認的block大小是64MB/128M(可根據配置增加)。
Rack
安裝集羣計算機的機架，一個機架可以安裝幾臺計算機，在整個Hadoop集羣中又會有幾個這樣的機架組成。
5、 HDFS的優缺點
優點：
1） 處理超大文件
這裏的超大文件通常是指百MB、設置數百TB大小的文件。目前在實際應用中，HDFS已經能用來存儲管理PB級的數據了。
2） 流式的訪問數據
HDFS的設計建立在更多地響應"一次寫入、 多次讀寫"任務的基礎上。這意味着一個數據集一旦由數據源生成， 就會被複制分發到不同的存儲節點中， 然後響應各種各樣的數據分析任務請求。 在多數情況下，分析任務都會涉及數據集中的大部分數據， 也就是說， 對HDFS來說，請求讀取整個數據集要比讀取一條記錄更加高效。
3） 運行於廉價的商用集羣上（硬件故障是常態）
Hadoop設計對硬件需求比較低， 只須運行在低廉的商用硬件集羣上，而無需昂貴的高可用性機器上。 廉價的商用機也就意味着大型集羣中出現節點故障情況的概率非常高。 這就要求設計HDFS時要充分考慮數據的可靠性， 安全性及高可用性。
缺點：
1） 不適合低延遲數據訪問
如果要處理一些用戶要求時間比較短的低延遲應用請求，則HDFS不適合。 HDFS是爲了處理大型數據集分析任務的，主要是爲達到高的數據吞吐量而設計的，這就可能要求以高延遲作爲代價。
改進策略：對於那些有低延時要求的應用程序，HBase是一個更好的選擇。
2） 無法高效存儲大量小文件
因爲Namenode把文件系統的元數據放置在內存中， 所以文件系統所能容納的文件數目是由Namenode的內存大小來決定。 一般來說， 每一個文件、 文件夾和Block需要佔據150字節左右的空間， 所以， 如果你有100萬個文件， 每一個佔據一個Block， 你就至少需要300MB內存。 當前來說， 數百萬的文件還是可行的， 當擴展到數十億時，對於當前的硬件水平來說就沒法實現了。
改進策略： 利用SequenceFile、 MapFile、 Har等方式歸檔小文件， 這個方法的原理就是把小文件歸檔起來管理， HBase就是基於此的。 對於這種方法， 如果想找回原來的小文件內容， 那就必須得知道與歸檔文件的映射關係。 橫向擴展， 一個Hadoop集羣能管理的小文件有限， 那就把幾個Hadoop集羣拖在一個虛擬服務器後面， 形成一個大的Hadoop集羣。 google也是這麼幹過的。
多Master設計， 這個作用顯而易見了。 正在研發中的GFS II也要改爲分佈式多Master設計， 還支持Master的Failover， 而且Block大小改爲1M， 有意要調優處理小文件啊。
3）不支持多用戶寫入及任意修改文件
在HDFS的一個文件中只有一個寫入者， 而且寫操作只能在文件末尾完成， 即只能執行追加操作。 目前HDFS還不支持多個用戶對同一文件的寫操作， 以及在文件任意位置進行修改。
疫情當下，昔日匆匆的步伐終於放慢了些，也是時候好好想想自己的職業計劃和人生規劃了。提前做好準備，未雨綢繆，爲未來蓄能——蓄勢待發！
