如何防止hadoop損壞.gz文件

我正在使用以下簡單代碼將文件上傳到hdfs。如何防止hadoop損壞.gz文件

FileSystem hdfs = FileSystem.get(config); 
hdfs.copyFromLocalFile(src, dst);

的文件由Web服務器的Java組件產生和旋轉，並且在格式。廣州通過的logback關閉。我注意到有時.gz文件已損壞。

> gunzip logfile.log_2013_02_20_07.close.gz 
gzip: logfile.log_2013_02_20_07.close.gz: unexpected end of file

但下面的命令不會顯示我的文件

> hadoop fs -text /input/2013/02/20/logfile.log_2013_02_20_07.close.gz

有這些文件的影響是相當災難的內容 - 因爲一整天聚集失敗，還有幾個從節點在這種情況下被標記爲黑名單。

在這種情況下我該怎麼辦？可以hadoop copyFromLocalFile（）實用程序損壞文件？有沒有人遇到過類似的問題？

來源

2013-02-21 Julias

謝謝，我在Amazon EMR上遇到了同樣的問題，並認爲這是一個EMR問題。 – Suman 2013-03-04 20:33:56

它不應該做的 - 這個錯誤通常是與沒有被關閉了，當最初寫入本地磁盤，或者被複制到HDFS，他們已經完成寫入之前的gzip文件關聯。

您應該能夠通過運行在原始文件和HDFS的那個的md5sum來檢查 - 如果他們匹配，則原來的文件已損壞：

hadoop fs -cat /input/2013/02/20/logfile.log_2013_02_20_07.close.gz | md5sum 
md5sum /path/to/local/logfile.log_2013_02_20_07.close.gz

如果他們不匹配，他們檢查的時間戳在兩個文件上 - HDFS中的文件應該在本地文件系統之後進行修改。

來源

2013-02-21 12:04:32

非常感謝，我如何檢查.gz文件本身的有效性（無需打開整個文件）？用java客戶端API？ – Julias 2013-02-24 11:45:59

Unforntunately你真的不能 - Gzip已不是一個裂開的格式，這意味着你不能只尋求在文件中的隨機位置並恢復流。因此，您必須在檢查有效性 – 2013-02-24 14:35:56

時再次從文件的開始處開始再次感謝。首先我找到了問題的根本原因 - 我有兩臺機器同時從相同的共享存儲文件夾上執行相同的上傳操作（某些vip問題）。我添加了代碼來防止這種情況（使用文件鎖定）。另外我發現gunzip -t可以測試gzip文件。您rihgt的GZ是defenetelly不好（althouhg我有一個小文件 - 小於64M塊）我想改變這一切。廣州到活潑的壓縮和小文件合併到大，但我需要檢查和評估，也許找有些已經存在實用程序 – Julias 2013-02-25 22:22:25

如何防止hadoop損壞.gz文件

回答

相關問題