HDFS文件系統
1.HDFS特點
- HDFS文件系統可存儲超大文件
每個磁盤都有默認的數據塊大小，這是磁盤在對數據進行讀和寫時要求的最小單位，文件系統是要構建於磁盤上的，文件系統也有塊的邏輯概念，通常使磁盤塊的整數倍。
HDFS是一種文件系統，自身也有塊（block）的概念，其文件塊大小要比普通單一磁盤上文件系統大得多，1.x默認爲64MB，2.x默認爲128MB。
HDFS中塊（block）的大小爲什麼設置爲128M？
1.HDFS中平均尋址時間大概爲10ms
2.經過前人的大量測試發現，尋址時間爲傳輸時間的1%時，爲最佳狀態
所以最佳傳輸時間爲10ms/0.01=1000ms=1s
3.目前磁盤的傳輸速率普遍爲100MB/s
計算出最佳block大小：100MB/s x 1s = 100MB
所以設定爲128MB
在實際工業生產中，若磁盤傳輸速率爲200MB/s時，一般設定block大小爲256MB，
若磁盤傳輸速率爲400MB/s時，一般設定block大小爲512MB
- 一次寫入，多次讀取
一個文件經過創建、寫入和關閉之後就不需要改變，這個假設簡化了數據一致性的問題，同時提高數據訪問的吞吐量。
- 運行在普通廉價的機器上
Hadoop的設計對硬件要求低，無需昂貴的高可用性機器上，因爲在HDFS設計中充分考慮到了數據的可靠性、安全性和高可用性。
2.不適用HDFS的場景
- 低延遲
HDFS不適用於實時查詢這種對延遲要求高的場景，例如：股票實盤。往往應對低延遲數據訪問場景需要通過數據庫訪問索引的方案來解決，Hadoop生態圈中的Hbase具有這種隨機讀、低延遲等特點。
- 大量小文件
對於Hadoop系統，小文件通常定義爲遠小於HDFS中block size（1.x默認64MB，2.x默認128MB）的文件，由於每個文件都會產生各自的Metadata元數據，Hadoop通過Namenode來存儲這些信息（通常150字節），若小文件過多，容易導致Namenode存儲出現瓶頸。
- 多用戶更新
爲了保證併發性，HDFS需要一次寫入多次讀取，目前不支持多用戶寫入，若要修改，也是通過追加的方式添加到文件的末尾處，出現太多文件需要更新的情況，Hadoop是不支持的。
針對有多人寫入數據的場景，可以考慮採用Hbase的方案。
- 結構化數據
HDFS適合存儲半結構化和非結構化數據，若有嚴格的結構化數據存儲場景，也可以考慮採取Hbase的方案。
- 數據量不大
通常Hadoop使用於TB、PB數據，若待處理的數據只有幾十GB的話，不建議使用Hadoop，因爲沒有任何好處。