小文件是 Hadoop 集群運維中的常見挑戰(zhàn)，尤其對于大規(guī)模運行的集群來說可謂至關(guān)重要。如果處理不好，可能會導致許多并發(fā)癥。Hadoop集群本質(zhì)是為了TB,PB規(guī)模的數(shù)據(jù)存儲和計算應運而生的。為啥大數(shù)據(jù)開發(fā)都說小文件的治理重要，說HDFS 存儲小文件效率低下，比如增加namenode負載等，降低訪問效率等？究竟本質(zhì)上為什么重要？以及如何從本質(zhì)上剖析小文件，治理小文件呢？今天就帶你走進小文件的世界。

1.什么是小文件？

日常生產(chǎn)中HDFS上小文件產(chǎn)生是一個很正常的事情，有些甚至是不可避免，比如jar，xml配置文件，tmp臨時文件，流式任務等都是小文件的組成部分。當然更多的是因為集群設置不合理，造成一些意料之外的小文件產(chǎn)生。實際公司生產(chǎn)中對于小文件的大小沒有一個統(tǒng)一的定義。一般公司集群的blocksize的大小在128/256兩者居多。首先小文件大小肯定是要遠小于blocksize的文件。一般公司小文件的大小定義如1Mb，8Mb,甚至16Mb，32Mb更大。根據(jù)公司實際集群狀態(tài)定義，因為有些情況合并小文件需要消耗額外的資源。

既然剖析小文件，那么不可避免的要先剖析hdfs的存儲原理。眾多周知了，HDFS上文件的數(shù)據(jù)存儲分為namenode元數(shù)據(jù)管理和實際數(shù)據(jù)文件。hdfs上的數(shù)據(jù)文件被拆分成塊block，這些塊block在整個集群中的datanode的本地文件系統(tǒng)上存儲和復制，每個塊也維護者自己的blockmeta信息。namenode主要維護這些文件的元數(shù)據(jù)信息，具體namenode的解析參考我的其他博客。

如下一個某個文件的某個block在data上存儲的情況。

2.小文件的產(chǎn)生

1.流式數(shù)據(jù)，如flume,kafak,sparkstreaming,storm,flink等，流式增量文件，小窗口文件，如幾分鐘一次等。

2.MapReduce引擎任務：如果純map任務，大量的map；如果mapreduce任務，大量的reduce；兩者都會造成大量的文件。出現(xiàn)這種情況的原因很多，果分布表的過度分區(qū)，輸入大量的小文件，參數(shù)設置的不合理等，輸出沒有文件合并等。

3.spark任務過度并行化，Spark 分區(qū)越多，寫入的文件就越多。

4.文件的壓縮與存儲格式不合理；一般生產(chǎn)公司很少使用textfile這種低效的文件格式了。

使用壓縮，降低文件的大小，同時也會降低文件的總塊數(shù)。注意文件存儲格式和壓縮不合理只是加劇小文件問題，不是產(chǎn)生小文件的本質(zhì)。

3.小文件的危害

3.1小文件對namenod的影響

如下圖1，一個文件192Mb，默認blocksize=128Mb，副本個數(shù)為3,存儲為2個block。

圖1

如下圖2,同樣一個文件192Mb，默認blocksize=128Mb，副本個數(shù)為3,存儲為192個block

圖2

namenode的namespace中主要占存儲對象是文件的目錄個數(shù)，文件（文件名長度）以及文件block數(shù)。根據(jù)namenode實際使用經(jīng)驗來看，一個存儲對象大概占用150字節(jié)的空間。HDFS上存儲文件占用的namenode內(nèi)存計算公式如下：

Memory=150bytes*(1個文件inode+(文件的塊數(shù)*副本個數(shù)))

如上圖1 ，一個文件192Mb，默認blocksize=128Mb，副本個數(shù)為3,存儲為2個block,需要namenode內(nèi)存=150*（1+2*3）=1050 Bytes

同理，圖2 一個文件192Mb，默認blocksize=128Mb，副本個數(shù)為3,存儲為192個block，需要namenode內(nèi)存=150 x (192 + (192 x 3)) = 115200 Bytes

尖叫總結(jié)：

1 .從上面可以看出，同樣的一個文件，大小不同形態(tài)的存儲占用namenode的內(nèi)存之比相差了109倍之多。所以如果對于單namenode的集群來說，大量的小文件的會占用大量的namenode堆內(nèi)存空間，給集群的存儲造成瓶頸。有些人可能會說我們聯(lián)邦，多組namenode不就沒有這個問題了，其實不然，且往下看

2.當 NameNode 重新啟動時(雖然生產(chǎn)上這種情況很少)，它必須將文件系統(tǒng)元數(shù)據(jù)fsimage從本地磁盤加載到內(nèi)存中。這意味著如果 namenode 元數(shù)據(jù)很大，重啟會更慢（以我們公司3億block，5萬多個文件對象來說，重啟一次1.5小時，期間應用不可用）其次，datanode 還通過網(wǎng)絡向 NameNode 報告塊更改；更多的塊意味著要通過網(wǎng)絡報告更多的變化，等待時間更長。

3.更多的文件，更多的block,意味著更多的讀取請求需要由 NameNode 提供服務,這將增加 RPC 隊列和處理延遲，進而導致namenode性能和響應能力下降。官方介紹說接近 40K~50K RPCs/s 人為是極高的負載。實際使用來看比這低時對于namenode來說性能都會打很大的折扣。

3.2 小文件對datanode影響

文件的block存儲是存儲在datanode本地系統(tǒng)上，底層的磁盤上，甚至不同的掛載目錄，不同的磁盤上。大量的小文件，意味著數(shù)據(jù)著尋址需要花費很多時間，尤其對于高負載的集群來說，磁盤使用率50%以上的集群，花費在尋址的時間比文件讀取寫入的時間更多。這種就違背了blocksize大小設計的初衷（實踐顯示最佳效果是：尋址時間僅占傳輸時間的1%）。這樣會造成磁盤的讀寫會很慢，擁有大量小文件會導致更多的磁盤搜索。如下磁盤延遲：

3.3小文件對計算的影響

基于HDFS文件系統(tǒng)的計算，blokc塊是最小粒度的數(shù)據(jù)處理單元。塊的多少往往影響應用程序的吞吐量。更多的文件，意味著更多的塊，以及更多的節(jié)點分布。

比如以MapReduce任務為例（hive等），在 MapReduce 中，會為每個讀取的塊生成一個單獨的 Map 任務，如果大量小文件，大量的塊，意味著著更多任務調(diào)度，任務創(chuàng)建開銷，以及更多的任務管理開銷（MapReduce 作業(yè)的 application master 是一個 Java 應用，它的主類是 MRAppMaster。它通過創(chuàng)建一定數(shù)量的bookkeeping object跟蹤作業(yè)進度來初始化作業(yè)，該對象接受任務報告的進度和完成情況）。雖然可以開啟map前文件合并，但是這也需要不停地從不同節(jié)點建立連接，數(shù)據(jù)讀取，網(wǎng)絡傳輸，然后進行合并，同樣會增加消耗資源和增加計算時間，成本也很高。

同樣，如果是spark計算引擎，executor的一次讀取和處理一個分區(qū)，默認情況下，每個分區(qū)是一個 HDFS 塊，如果大量的小文件，每個文件都在不同的分區(qū)中讀取，這將導致大量的任務調(diào)度開銷，同時每個 CPU 內(nèi)核的吞吐量降低。

簡單總結(jié)一下：小文件對于計算的影響就是需要大量節(jié)點之間頻繁建立聯(lián)系，數(shù)據(jù)傳輸?shù)?，浪費資源，消耗時間長。其次小文件相關(guān)大量的任務初始化時間甚至比計算時間還長，造成計算資源的使用浪費，降低集群的吞吐量。

本文轉(zhuǎn)載自微信公眾號「滌生大數(shù)據(jù)」，作者「滌生大數(shù)據(jù)」，可以通過以下二維碼關(guān)注。

轉(zhuǎn)載本文請聯(lián)系「滌生大數(shù)據(jù)」公眾號。