爲什麼TeraSort映射階段在CRC32.update（）函數中花費大量時間？

Question

我正在嘗試配置哪些功能消耗TeraSort Hadoop作業的最多時間。對於我的測試系統，我使用的是基本的單節點僞分佈式設置。這意味着NameNode，DataNode，Tasktracker和Jobtracker JVM都運行在同一臺機器上。

我首先使用TeraGen數據的〜9GB，然後在其上運行的TeraSort。在執行JVM時，我使用VisualVM對它們的執行進行了抽樣。我知道這不是那裏最精確的分析器，但它免費且易於使用！我使用最新版本的Apache hadoop發行版，我的實驗在基於Intel Atom的系統上運行。

當我查看VisualVM中Hot Spots-Methods的Self time（CPU）時，我看到java.util.zip.CRC32.update（）函數佔用了總時間的近40％。當我在調用樹中查看此函數時，它由映射器的main（）函數調用，特別是當IdentityMapper.map（）從HDFS讀取輸入文件時。這實際上使得調用CRC32.update函數（）函數是org.apache.hadoop.fs.FSInputChecker.readChecksumChunk（）

我有一個關於這個三個問題：

1. 爲什麼CRC32正在更新從HDFS讀取塊的校驗和？如果我理解正確，一旦讀取了一個數據塊，從磁盤讀取的數據與數據塊的CRC的簡單比較應該是唯一的操作，不會生成和更新數據塊的CRC值。

2. 我擡起頭來的更新功能的來源，它是由java.util.zip.CRC32.java文件執行。所調用的具體函數是帶有三個參數的重載update（）方法。由於該功能是用Java實現的，有可能多層抽象（Hadoop，JVM，CPU指令）正在降低CRC計算的本地效率？

3. 最後，是有什麼嚴重毛病我VisualVM的儀器方法，或解釋的抽檢結果？

感謝，

Answer 1

你的第一個問題，我認爲答案是，CRC文件的副本，可以被破壞。例如，假設我們有2個複製因子一堆的文件/目錄，則下列情況下可能發生，CRC將需要重新計算並更新：

1. 刪除一個副本元文件
2. 截斷元在一個副本
3. 器損壞的一個副本的元文件頭
4. 會損壞任何隨機偏移和元文件的一部分
5. 交換兩個元文件，即元文件的格式是有效的，但他們的CRC沒有文件匹配其相應的數據塊

如果您查看Hadoop Common的JIRA問題，可以找到許多與CRC損壞相關的問題。

對於第二個問題，你能告訴我你正在使用哪個版本的Hadoop嗎？ CRC的效率一直在抱怨和改善。