hdfs為啥不擅長存儲大量的小文件

2019/2/25 星期一

hdfs為啥不擅長存儲大量的小文件

hdfs的優點和缺點
優點：
1、可構建在廉價機器上
　　　　通過多副本提高可靠性，提供了容錯和恢復機制
　　　　服務器節點的宕機是常態 必須理性對象
2、高容錯性
數據自動保存多個副本，副本丟失后，自動恢復
　　　　HDFS的核心設計思想： 分散均勻存儲 + 備份冗余存儲
3、適合批處理
移動計算而非數據，數據位置暴露給計算框架
　　　　海量數據的計算 任務 最終是一定要被切分成很多的小任務進行
4、適合大數據處理
　　　　GB、TB、甚至 PB 級數據，百萬規模以上的文件數量，10K+節點規模
5、流式文件訪問
　　　　 一次性寫入，多次讀取，保證數據一致性
hdfs缺點
1、低延遲數據訪問
　　　　比如毫秒級 低延遲與高吞吐率
2、小文件存取
　　　　占用 NameNode 大量內存 150b* 1000W = 15E,1.5G 尋道時間超過讀取時間
3、并發寫入、文件隨機修改
　　　　一個文件只能有一個寫者 僅支持 append

FastDFS與hadoop的區別
主要是定位和應用場合不一樣。
hadoop的文件系統HDFS主要解決并行計算中分布式存儲數據的問題。其單個數據文件通常很大，采用了分塊（切分）存儲的方式；
FastDFS主要用于大中網站，為文件上傳和下載提供在線服務。所以在負載均衡、動態擴容等方面都支持得比較好，FastDFS不會對文件進行分快（切分）存儲。

hdfs為什么不適合大量小文件的存儲
namenode在內存中存儲metadata。每個小文件都占150bytes.所以很多小文件的話， 內存就吃緊了。
不是不適合存小文件，而是不適合純海量小文件。。。。 文件數不能太多。。。
管理每個文件需要占用master機器一定內存，管理文件過多，內存占用過多，會使集群運行變慢。
文件數過多 ，占用的內存也相應的多了，這樣就會影響系統的處理速度，如果是少量的大容量文件，占用內存相應較低，處理速度就會更快
HDFS無法高效存儲大量小文件，如何處理好小文件？ https://blog.csdn.net/zyd94857/article/details/79946773
hadoop SequenceFile詳解：https://blog.csdn.net/bitcarmanlee/article/details/78111289

（1）HDFS不適合大量小文件的存儲，因namenode將文件系統的元數據存放在內存中，因此存儲的文件數目受限于 namenode的內存大小。HDFS中每個文件、目錄、數據塊占用150Bytes。如果存放的文件數目過多的話會占用很大的內存
（2）HDFS適用于高吞吐量，而不適合低時間延遲的訪問。如果同時存入大量的小文件會花費很長的時間
（3） 流式讀取的方式，不適合多用戶寫入，以及任意位置寫入。如果訪問小文件，則必須從一個datanode跳轉到另外一個datanode，這樣大大降低了讀取性能。

主要是定位和應用場合不一樣。
hadoop的文件系統HDFS主要解決并行計算中分布式存儲數據的問題。其單個數據文件通常很大，采用了分塊（切分）存儲的方式；
FastDFS主要用于大中網站，為文件上傳和下載提供在線服務。所以在負載均衡、動態擴容等方面都支持得比較好，FastDFS不會對文件進行分快（切分）存儲。

參考鏈接為：https://www.cnblogs.com/qingyunzong/p/8535995.html
這是和HDFS系統底層設計實現有關系的，HDFS本身的設計就是用來解決海量大文件數據的存儲.，他天生喜歡大數據的處理，大文件存儲在HDFS中，會被切分成很多的小數據塊，任何一個文件不管有多小，都是一個獨立的數據塊，而這些數據塊的信息則是保存在元數據中的，在之前的博客HDFS基礎里面介紹過在HDFS集群的namenode中會存儲元數據的信息，這里再說一下，元數據的信息主要包括以下3部分：
　　1）抽象目錄樹
　　2）文件和數據塊的映射關系，一個數據塊的元數據大小大約是150byte
　　3）數據塊的多個副本存儲地

而元數據的存儲在磁盤（1和2）和內存中（1、2和3），而服務器中的內存是有上限的，舉個例子：

有100個1M的文件存儲進入HDFS系統，那么數據塊的個數就是100個，元數據的大小就是100*150byte，消耗了15000byte的內存，但是只存儲了100M的數據。

有1個100M的文件存儲進入HDFS系統，那么數據塊的個數就是1個，元數據的大小就是150byte，消耗量150byte的內存，存儲量100M的數據。

cdh官方的解釋：為什么hdfs不適合存儲大量的小文件 //很重要
文件和塊

在HDFS中，數據和元數據是分離的。數據文件被拆分為塊文件，這些塊文件在群集中的DataNode上存儲和復制。文件系統命名空間樹和關聯的元數據存儲在NameNode上。
命名空間對象是指向DataNode上的塊文件的文件inode和塊。這些命名空間對象在NameNode的內存中存儲為文件系統映像（fsimage），并且也在本地持久存在。元數據的更新將寫入編輯日志。當NameNode啟動時，或者采用檢查點時，將應用編輯，清除日志，并創建新的fsimage。
重要說明：NameNode將整個命名空間映像保留在內存中。輔助NameNode在其自己的JVM上，在創建映像檢查點時也是如此。

平均而言，每個文件占用1.5塊存儲空間。也就是說，平均文件被分成兩個塊文件 - 一個消耗整個分配的塊大小，另一個消耗一半。在NameNode上，這個相同的平均文件需要三個命名空間對象 - 一個文件inode和兩個塊。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
磁盤空間與命名空間

CDH默認塊大小（dfs.blocksize）設置為128 MB。 NameNode上的每個名稱空間對象消耗大約150個字節。

在DataNodes上，數據文件是通過消耗的磁盤空間（實際數據長度）來衡量的，而不一定是整個塊大小。例如，192 MB的文件占用192 MB的磁盤空間，而不是塊大小的整數倍。使用128 MB的默認塊大小，192 MB的文件被分成兩個塊文件，一個128 MB文件和一個64 MB文件。在NameNode上，命名空間對象由文件和塊的數量來度量。相同的192 MB文件由三個命名空間對象（1個文件inode + 2個塊）表示，并消耗大約450個字節的內存。

分割成較少塊的大文件通常比生成許多塊的小文件消耗更少的內存。一個128 MB的數據文件由NameNode上的兩個名稱空間對象（1個文件inode + 1個塊）表示，并消耗大約300個字節的內存。相比之下，每個1 MB的128個文件由256個命名空間對象（128個文件inode + 128個塊）表示，并消耗大約38,400個字節。然后，最佳分割大小是塊大小的一些整數倍，用于存儲器管理以及數據局部性優化。

默認情況下，Cloudera Manager為每百萬個塊（但不小于1 GB）分配1 GB的最大堆空間。實際需要多少內存取決于您的工作負載，尤其是每個命名空間中生成的文件，目錄和塊的數量。如果所有文件都以塊大小分割，則可以為每百萬個文件分配1 GB。但考慮到每個文件的歷史平均值為1.5個塊（2個塊對象），對于每百萬個塊，更保守的估計是1 GB的內存。
重要說明：Cloudera建議每百萬個塊使用1 GB的NameNode堆空間來計算命名空間對象，必要的簿記數據結構和遠程過程調用（RPC）工作負載。實際上，您的堆需求可能會低于此保守估計值。
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
復制
默認塊復制因子（dfs.replication）為3。復制影響磁盤空間但不影響內存消耗。復制會更改每個塊所需的存儲量，但不會更改塊的數量。如果DataNode上的一個塊文件（由NameNode上的一個塊表示）被復制三次，則塊文件的數量將增加三倍，但不會代表它們的塊數。

關閉復制時，一個192 MB的文件占用192 MB的磁盤空間和大約450字節的內存。
//(計算方式為：128+64 也就是1個文件inode+2個塊 大約消耗 450字節的內存)
如果你有一百萬個這樣的文件，或192 TB的數據，你需要192 TB的磁盤空間，而不考慮RPC工作負載，450 MB內存：（100萬inode + 200萬個塊） 150個字節。啟用默認復制后，您需要576 TB的磁盤空間：（192 TB 3）但內存使用率保持不變，450 MB。當您考慮簿記和RPC，并遵循每百萬個塊1 GB堆內存的建議時，對此方案更安全的估計是2 GB內存（有或沒有復制）。

提示：
很多資料上說HDFS文件系統不適用于存儲小文件。在我的經驗中，我認為hdfs文件系統不是不能存小文件，而是不擅長存儲大量的小文件。

參考鏈接：https://www.cloudera.com/documentation/enterprise/5-13-x/topics/admin_nn_memory_config.html