我使用Hadoop示例程序WordCount處理大型小文件/網頁集（cca。2-3 kB）。由於這與hadoop文件的最佳文件大小相距甚遠，因此該程序非常慢。我想這是因爲設置和裁員的成本遠遠大於工作本身。這樣的小文件也會導致文件名的命名空間耗盡。使用Hadoop處理大量小文件集
我讀過，在這種情況下，我應該使用HDFS壓縮文件（HAR），但我不確定如何修改此程序WordCount以從此壓縮文件讀取。程序能否繼續工作而不需要修改或者需要修改？
即使我在檔案中打包了很多文件，問題仍然存在，如果這會提高性能。我讀過，即使我打包了多個文件，一個存檔內的這些文件也不會被一個映射器處理，但是很多，在我的情況下（我猜）不會提高性能。
如果這個問題太簡單了，請理解我是Hadoop的新手，對它有很少的經驗。
使用HDFS不會改變您導致hadoop處理大量小文件的情況。在這種情況下，最好的選擇可能是將文件合併到一個（或幾個大的）文件中。 這會減少你擁有的mappers的數量，這將減少需要處理的東西的數量。
如果您在分佈式系統上運行，使用HDFS可以提高性能。如果你只做虛擬分發（一臺機器），那麼HDFS不會提高性能。限制是機器。
當您處理大量小文件時，需要大量的映射器和縮減器。 setup/down可以與文件本身的處理時間相媲美，造成大量開銷。這些文件應該會減少hadoop爲這項工作運行的映射器的數量，這應該會提高性能。
使用HDFS存儲文件時可以看到的好處是使用多臺機器的分佈式模式。這些文件將跨機器以塊（默認爲64MB）存儲，並且每臺機器都能夠處理駐留在機器上的數據塊。這減少了網絡帶寬的使用，所以它不會成爲處理的瓶頸。
歸檔文件，如果hadoop打算將它們歸檔，只會導致hadoop仍然有大量的小文件。
希望這有助於你的理解。
可以在將文件提交給Hadoop之前連接文件嗎？
從我對Hadoop的理解仍然有限，我相信正確的解決方案是創建SequenceFile（s）包含您的HTML文件作爲值和可能的URL作爲關鍵。如果您通過SequenceFile（s）執行M/R作業，則每個映射器將處理許多文件（取決於拆分大小）。每個文件將作爲單個輸入呈現給地圖功能。 您可能想要使用SequenceFileAsTextInputFormat作爲InputFormat來閱讀這些文件。
另見：Providing several non-textual files to a single map in Hadoop MapReduce
我最近書籤這篇文章後來讀它，並在這裏找到了同樣的問題:)項是有點老了，不是很確定現在是如何相關的。Hadoop的變化正在以非常快的速度發生。
http://www.cloudera.com/blog/2009/02/the-small-files-problem/
博客條目是由湯姆·懷特，誰也的作者「的Hadoop權威指南（第二版）」，推薦閱讀那些誰是入門用Hadoop。
CombineFileInputFormat在這種情況下，這對於大numaber小文件的工作很好地使用。這將許多這樣的文件打包在一個分割中，因此每個映射器都有更多的處理（1 split = 1 map任務）。 由於映射器運行的次數較少，mapreduce的整體處理時間也將減少。 由於沒有歸檔感知InputFormat使用CombineFileInputFormat會提高性能。
我想我可以，但是因爲我把頁面的URL /地址放在文件的第一行，所以要識別新頁面是否有點困難，或者只是定期鏈接到其他頁面。 – Sasa 2011-05-09 00:49:09