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小檔案的**，一篇是中科院計算所2023年發表的，用以解決hdfs上儲存地理資訊小檔案的方案；另一篇是ibm於2023年發表的，用以解決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中資料相關性特徵，將儲存相鄰地理位置資訊的小檔案合併成乙個大的檔案，並為這些小檔案建立索引以便對小檔案進行訪問。

該**將size小於16mb的檔案當做小檔案，需將它們合併成64mb(預設的block size)，並建立索引，索引結構和檔案儲存方式見上圖。索引方式是一般的定長hash索引。

下圖展示的是在bluesky中上傳檔案的過程：

下圖展示的是在bluesky中閱覽檔案的過程：

5、總結

hadoop目前還沒有乙個系統級的通用的解決hdfs小檔案問題的方案。它自帶的三種方案，包括hadoop archive，sequence file和combinefileinputformat，需要使用者根據自己的需要編寫程式解決小檔案問題；而第四節提到的**均是針對特殊應用提出的解決方案，沒有形成乙個比較通用的技術方案。

6、參考資料

（1）有關小檔案問題的表述：

（2）hadoop sequence file：

（3）英文書籍《hadoop：the definitive guide》，第七章190頁

（4）xuhui liu, jizhong han, yunqin zhong, chengde han, xubin he: implementing webgis on hadoop: a case study of improving small file i/o performance on hdfs. cluster 2009: 1-8

HDFS小檔案問題及解決方案

HDFS小檔案問題及解決方案

HDFS小檔案問題及解決方案

HDFS小檔案危害以及解決方案

相關推薦