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

Question

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

我首先使用 TeraGen 生成约 9GB 的数据，然后在其上运行 TeraSort。当 JVM 执行时，我使用 VisualVM 对它们的执行进行采样。我知道这不是目前最准确的分析器，但它是免费且易于使用的!我使用最新版本的 Apache hadoop 发行版，我的实验在基于 Intel Atom 的系统上运行。

当我查看 VisualVM 中热点方法的自用时间 (CPU) 时，我发现 java.util.zip.CRC32.update() 函数占用了近 40% 的总时间。当我在调用树中查看此函数时，它是由映射器的 main() 函数调用的，特别是当 IdentityMapper.map() 从 HDFS 读取输入文件时。实际调用 CRC32.update() 函数的函数是 org.apache.hadoop.fs.FSInputChecker.readChecksumChunk()

关于这个我有三个问题:

1. 为什么要为从 HDFS 读取的 block 更新 CRC32 校验和？如果我理解正确，一旦一个 block 被读取，从磁盘读取的数据与 block 的 CRC 的简单比较应该是唯一的操作，而不是生成和更新 block 的 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 与它们对应的数据 block 不匹配

如果您查看 Hadoop Common 的 JIRA 问题，您会发现许多与 CRC 损坏相关的问题。

关于第二个问题，您能告诉我您使用的是哪个版本的 Hadoop 吗？ CRC的效率被提示一次次，一次次提高。