HDFS上每個檔案都要在namenode上建立一個索引，這個索引的大小約為150byte，這樣當小檔案比較多的時候，就會産生很多的索引檔案，一方面會大量占用namenode的記憶體空間，另一方面就是索引檔案過大是的索引速度變慢，解決的方式
(1)Hadoop本身提供了一些檔案壓縮的方案
(2)從系統層面改變現有HDFS存在的問題，其實主要還是小檔案的合并，然後建立比較快速的索引。
1、 概述
小檔案是指檔案size小于HDFS上block大小的檔案。這樣的檔案會給hadoop的擴充性和性能帶來嚴重問題。首先，在HDFS中，任何block，檔案或者目錄在記憶體中均以對象的形式存儲，每個對象約占150byte，如果有1000 0000個小檔案，每個檔案占用一個block，則namenode大約需要2G空間。如果存儲1億個檔案，則namenode需要20G空間(見參考資料[1][4][5])。這樣namenode記憶體容量嚴重制約了叢集的擴充。 其次，通路大量小檔案速度遠遠小于通路幾個大檔案。HDFS最初是為流式通路大檔案開發的，如果通路大量小檔案，需要不斷的從一個datanode跳到另一個datanode，嚴重影響性能。最後，處理大量小檔案速度遠遠小于處理同等大小的大檔案的速度。每一個小檔案要占用一個slot，而task啟動将耗費大量時間甚至大部分時間都耗費在啟動task和釋放task上。
本文首先介紹了hadoop自帶的解決小檔案問題的方案(以工具的形式提供)，包括Hadoop Archive，Sequence file和CombineFileInputFormat；然後介紹了兩篇從系統層面解決HDFS小檔案的論文，一篇是中科院計算所2009年發表的，用以解決HDFS上存儲地理資訊小檔案的方案；另一篇是IBM于2009年發表的，用以解決HDFS上存儲ppt小檔案的方案。
2、 HDFS檔案讀寫流程
在正式介紹HDFS小檔案存儲方案之前，我們先介紹一下目前HDFS上檔案存取的基本流程。
(1) 讀檔案流程
1)client端發送讀檔案請求給namenode，如果檔案不存在，傳回錯誤資訊，否則，将該檔案對應的block及其所在datanode位置發送給client
2) client收到檔案位置資訊後，與不同datanode建立socket連接配接并行擷取資料。
(2) 寫檔案流程
1) client端發送寫檔案請求，namenode檢查檔案是否存在，如果已存在，直接傳回錯誤資訊，否則，發送給client一些可用namenode節點
2) client将檔案分塊，并行存儲到不同節點上datanode上，發送完成後，client同時發送資訊給namenode和datanode
3) namenode收到的client資訊後，發送确信資訊給datanode
4) datanode同時收到namenode和datanode的确認資訊後，送出寫操作。
3、 Hadoop自帶的解決方案
對于小檔案問題，Hadoop本身也提供了幾個解決方案，分别為：Hadoop Archive，Sequence file和CombineFileInputFormat。
(1) Hadoop Archive
Hadoop Archive或者HAR，是一個高效地将小檔案放入HDFS塊中的檔案存檔工具，它能夠将多個小檔案打包成一個HAR檔案，這樣在減少namenode記憶體使用的同時，仍然允許對檔案進行透明的通路。
對某個目錄/foo/bar下的所有小檔案存檔成/outputdir/ zoo.har：
hadoop archive -archiveName zoo.har -p /foo/bar /outputdir
當然，也可以指定HAR的大小(使用-Dhar.block.size)。
HAR是在Hadoop file system之上的一個檔案系統，是以所有fs shell指令對HAR檔案均可用，隻不過是檔案路徑格式不一樣，HAR的通路路徑可以是以下兩種格式：
har://scheme-hostname:port/archivepath/fileinarchive
har:///archivepath/fileinarchive(本節點)
可以這樣檢視HAR檔案存檔中的檔案：
hadoop dfs -ls har:///user/zoo/foo.har
輸出：
har:///user/zoo/foo.har/hadoop/dir1
har:///user/zoo/foo.har/hadoop/dir2
使用HAR時需要兩點，第一，對小檔案進行存檔後，原檔案并不會自動被删除，需要使用者自己删除；第二，建立HAR檔案的過程實際上是在運作一個mapreduce作業，因而需要有一個hadoop叢集運作此指令。
此外，HAR還有一些缺陷：第一，一旦建立，Archives便不可改變。要增加或移除裡面的檔案，必須重新建立歸檔檔案。第二，要歸檔的檔案名中不能有空格，否則會抛出異常，可以将空格用其他符号替換(使用-Dhar.space.replacement.enable=true 和-Dhar.space.replacement參數)。
(2) Sequence file
sequence file由一系列的二進制key/value組成，如果為key小檔案名，value為檔案内容，則可以将大批小檔案合并成一個大檔案。
Hadoop-0.21.0中提供了SequenceFile，包括Writer，Reader和SequenceFileSorter類進行寫，讀和排序操作。如果hadoop版本低于0.21.0的版本，實作方法可參見[3]。
(3)CombineFileInputFormat
CombineFileInputFormat是一種新的inputformat，用于将多個檔案合并成一個單獨的split，另外，它會考慮資料的存儲位置。
4、 小檔案問題解決方案
上一節中提到的方案均需要使用者自己編寫程式，每隔一段時間對小檔案進行merge以便減少小檔案數量。那麼能不能直接将小檔案處理子產品嵌到HDFS中，以便自動識别使用者上傳的小檔案，然後自動對它們進行merge呢？
本節介紹了兩篇論文針試圖在系統層面解決HDFS小檔案問題。這兩篇論文對不同的應用提出了解決方案，實際上思路類似：在原有HDFS基礎上添加一個小檔案處理子產品，當一個檔案到達時，判斷該檔案是否屬于小檔案，如果是，則交給小檔案處理子產品處理，否則，交給通用檔案處理子產品處理。小檔案處理子產品的設計思想是，先将很多小檔案合并成一個大檔案，然後為這些小檔案建立索引，以便進行快速存取和通路。
論文[4]針對WebGIS系統的特點提出了解決HDFS小檔案存儲的方案。WebGIS是結合web和地理資訊系統(GIS)而誕生的一種新系統。在WebGIS中，為了使浏覽器和伺服器之間傳輸的資料量盡可能地少，資料通常被切分成KB的小檔案存儲在分布式檔案系統中。論文結合WebGIS中資料相關性特征，将儲存相鄰地理位置資訊的小檔案合并成一個大的檔案，并為這些小檔案建立索引以便對小檔案進行存取。(n*n)
該論文将size小于16MB的檔案當做小檔案，需将它們合并成64MB(預設的block size)，并建立索引，索引結構和檔案存儲方式見上圖。索引方式是一般的定長hash索引。
論文[5]針對Bluesky系統的特點提出了解決HDFS小檔案存儲的方案。Bluesky是中國電子教學共享系統，裡面的ppt檔案和視訊均存放在HDFS上。該系統的每個課件由一個ppt檔案和幾張該ppt檔案的預覽快照組成。當使用者請求某頁ppt時，其他相關的ppt可能在接下來的時間内也會被檢視，因而檔案的通路具有相關性和本地性。本文主要有2個idea：第一，将屬于同一個課件的檔案合并成一個大檔案，以提高小檔案存儲效率。第二，提出了一種two-level prefetching機制以提高小檔案讀取效率，即索引檔案預取和資料檔案預取。索引檔案預取是指當使用者通路某個檔案時，該檔案所在的block對應的索引檔案被加載到記憶體中，這樣，使用者通路這些檔案時不必再與namenode互動了。資料檔案預取是指使用者通路某個檔案時，将該檔案所在課件中的所有檔案加載到記憶體中，這樣，如果使用者繼續通路其他檔案，速度會明顯提高。
下圖展示的是在BlueSky中上傳檔案的過程：
下圖展示的是在BlueSky中閱覽檔案的過程：
5、 總結
Hadoop目前還沒有一個系統級的通用的解決HDFS小檔案問題的方案。它自帶的三種方案，包括Hadoop Archive，Sequence file和CombineFileInputFormat，需要使用者根據自己的需要編寫程式解決小檔案問題；而第四節提到的論文均是針對特殊應用提出的解決方案，沒有形成一個比較通用的技術方案。