Hadoop較小的輸入文件

我以一種不同的方式使用hadoop。就我而言，輸入大小非常小。但是，計算時間更多。我有一些複雜的算法，我將在每一行輸入上運行。所以即使輸入尺寸小於5mb，整體計算時間也會超過10小時。所以我在這裏使用hadoop。我正在使用NLineInputFormat通過行數而不是塊大小拆分文件。在我最初的測試中，我有大約1500行（分割200行），我發現在四節點集羣中，與在一臺機器上串行運行相比，只有1.5倍的改進。我正在使用虛擬機。這可能是問題，或者對於較小規模的輸入，那麼hadoop會帶來很多好處？任何見解都會非常有幫助。Hadoop較小的輸入文件

來源

2013-03-10 CRS

對我而言，您的工作量類似於SETI @ Home工作量 - 小型有效負載，但需要幾小時的處理時間。

Hadoop（或更具體地說HDFS）並不適用於許多小文件。但我懷疑這是MapReduce的問題 - 您正在使用的處理框架。

如果你想保持你的工作負載在一起： 1）如果文件小於塊大小，將它們分成單獨的文件（一個工作負載，一個文件），然後它將轉到一個映射器。典型的塊大小爲64MB或128MB

2）爲FileInputFormat創建包裝，並將'isSplitable（）'方法重寫爲false。這將確保整個文件內容被送入一個映射，而不是Hadoop的努力逐行拆呢

參考：http://hadoopilluminated.com/hadoop_book/HDFS_Intro.html

來源

2013-03-11 02:59:11

感謝您的意見。逐行分割是否有缺點？總之，你的意思是我應該把輸入文件分割成更小的文件。可以說我創建了8個文件，每個文件有n/8行。回答那麼我應該做你上面提到的第二點？我不是通過這樣做來理解這種優勢，而是一條一條地分割它。在我的情況下，我把它分成（總行數/總節點）的形式。它並不是單線。 – CRS 2013-03-12 08:43:52

1）一個'記錄'是否適合一行？如果是的話，讓hadoop做分裂。如果你的'記錄'跨越多行，那麼你需要控制分裂。 2）如果你讓hadoop做分裂，那麼讓你的輸入不是在一個文件中，而是在多個文件中。這樣，處理將在節點（更具體地爲映射器）之間並行 - 無需您執行任何特殊工作希望這有助於 – 2013-03-13 15:17:20

-1

Hadoop是不是在處理萬噸的小文件確實不錯，因此，通常希望將大量較小的輸入文件合併爲較少數量的較大文件，從而減少映射器的數量。

作爲Hadoop MapReduce過程的輸入被抽象爲InputFormat。 FileInputFormat是一個處理HDFS文件的默認實現。使用FileInputFormat，每個文件被分割成一個或多個InputSplits，通常以block size爲界。這意味着輸入分割的數量更低，以輸入文件的數量爲界。在處理大量小文件時，這不是一個理想的MapReduce過程環境，因爲協調分佈式進程的開銷遠遠大於存在大量小文件時的開銷。

驅動吐痰尺寸的基本參數是mapred.max.split.size。

使用CombineFileInputFormat和此參數我們可以控制映射器的數量。

檢出我的另一個回答here。

來源

2013-03-11 19:22:26 Amar

謝謝Amar。但正如我所提到的，在我的情況下，我只有一個輸入文件。即使這個尺寸非常小，小於5mb。但是，執行時間很長，這就是爲什麼我使用MapReduce在一組節點之間分配的原因。爲了更清楚，我有4萬行輸入文件和4個節點集羣。不是按塊大小拆分文件，而是按行數進行。我把它作爲10k。通過這樣做，每個節點將獲得10k條線路。但問題在於整體表現。與連續運行相比，我在4節點集羣中只看到1.5倍的改進。 – CRS 2013-03-12 08:52:26

Hadoop較小的輸入文件

回答

相關問題