为什么TeraSort映射阶段在CRC32.update()函数中花费大量时间？

Question

我试图分析哪些函数花费了TeraSort Hadoop作业最多的时间。在我的测试系统中，我使用的是基本的1节点伪分布式设置。这意味着NameNode、DataNode、Tasktracker和Jobtracker JVM都在同一台机器上运行。

我首先使用TeraGen生成~9GB的数据，然后在其上运行TeraSort。当JVM执行时，我使用VisualVM对它们的执行进行示例。我知道这不是最精确的剖析器，但它是免费的，易于使用！我使用Apache发行版的最新版本，我的实验是在基于Intel Atom的系统上运行的。

当我查看VisualVM中的Hot方法的自时间(CPU)时，我看到java.util.zip.CRC32.update()函数占用了几乎40%的时间。当我在调用树中查看这个函数时，映射器的main()函数会调用它，特别是当IdentityMapper.map()从HDFS读取输入文件时。实际调用CRC32.update()函数的函数是org.apache.hadoop.fs.FSInputChecker.readChecksumChunk()

关于这一点，我有三个问题：

1. 为什么要更新从HDFS读取的块的CRC32校验和？如果我正确理解，一旦读取了一个块，那么从磁盘读取的数据与块的CRC应该是唯一的操作，而不是生成和更新块CRC值。
2. I查找更新函数的源代码，它由java.util.zip.CRC32.java文件实现。调用的特定函数是带有三个参数的重载update()方法。既然这个函数是用Java实现的，那么多层抽象(Hadoop、JVM、CPU指令)是否会降低CRC calculation?
3. Finally，的本机效率？

谢谢,

Answer 1

对于你的第一个问题，我认为答案是CRC文件有副本并且可能被破坏。例如，假设我们有一堆复制因子为2的文件/目录，那么可能会发生以下情况，需要重新计算和更新CRC：

删除一个replica

• Truncates元文件上的元文件、一个replica

• Corrupts上的元文件头--一个replica

• Corrupts上的元文件头--任意偏移量和部分元文件

• 交换两个元文件，即元文件的格式是有效的，但它们的CRCs与相应的数据块

不匹配。

如果您查看问题，就会发现许多与CRC腐败相关的问题。

关于第二个问题，你能告诉我你在使用哪种版本的Hadoop吗？儿童权利委员会的效率不断被投诉和提高。