玩過大數據的人，肯定都遇到過小文件問題。這也是玩大數據，必須跨過去的一個坎，要不然，大數據玩不轉。

一，怎么定義小文件

hadoop1，默認存儲64M。hadoop2，hadoop3默認是128M，當然這些都是可調的。那問題來了，多小的文件算小呢，1M，10M，100M？個人認為，應當是以設置的默認存儲塊為基準來判定。

那么問題又來了：如果默認存儲128M，那么100M算小文件嗎？120M算小文件嗎？

其實這個問題，很難回答，不同的人有不同的回答。個人覺得，小文件的解決是有一個范圍值 ，并且是自己設定的范圍值，每個人都不一樣。從小到大，越是接近默認存儲塊，小文件解決的就是越好，反之越差。

二，小文件是怎么產生的？

1，hadoop設計之初是為了OLAP用的，后來越來越多的人，希望hadoop能朝著OLTP的方向發展，并產生了很多工具，例如spark,flink等。實時性要求越高，小文件就會越多。當然這也根量也有關系，量越大，小文件越少，小文件問題越小。

2，在離線計算時，如果沒有設置reduce tasks，每個reduce都會生成一個獨立的文件。這也會導致小文件的增多。

3，直接copy文件到hdfs，而導致的小文件。

三，為什么小文件是問題？

舉個例子：

現在有100懷水，每杯水500ml，而給你裝水的工具是N多個水桶，每個水桶容量是5L，現在要利用這些桶把水運到另外一個地方去。并且運一桶水消耗的資源根運一杯水消耗的一樣。怎么運最節省資源。

這不就是小學的數學應用題嗎?只要小學畢業了，就知道怎么去運水。

四，怎么解決小問題

官方給了三個解決方案：

1，Hadoop Archive

2，Sequence File

3，CombineFileInputFormat

而這三個方案，我沒有用，關鍵是不知道，怎么用，哈哈。

我的解決辦法：

1，利用hdfs命令，用appendToFile合并文件，或者getmerge合并文件到本地，然后在傳hdfs。配合bash操作，還是可行的。該方案局限性較大。

json，txt試過，可以這樣合。parquet肯定不行。orc沒試，估計也不行。

數據量不大的話，這種處理方案，還是不錯。可以做為補漏方案。

2，利用flume。flume從kafka中，消費數據到hdfs中，設置好rollSize和rollInterval，還是一個不錯的方案。該方案也是有局限性的，

一般來說flume獲取的數據都ETL前的數據，或者說都是源數據。源數據是要清洗的，清洗的過程中，要洗掉多少數據其實是不可控的。

如果量比較小，并且實時性要求比較高的話，這種方案是不合適的。

3，利用hive的分桶表。設置分桶的數量，可以控制小文件的。該方案也有局限性

如果量很大的情況下，為了接近我們設置默認存儲值。就要不斷的調整分桶數量。

4，通過程序的方式來合并。例如：spark streaming 準實時的生成了很多小文件，我們可以通過每隔一段時間，把新增的數據，進行數據清洗和合并。如果是json,txt格式，還要用appendToFile，進行補漏。

5，利用hbase，小文件交給hbase的mapfile。

推薦，方法4和方法5，這二種辦法也是我現在用的方法。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的hdfs合并块_hdfs 小文件合并 问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。