2

我正在尝试分析哪些函数在 TeraSort Hadoop 作业中消耗的时间最多。对于我的测试系统，我使用的是基本的 1 节点伪分布式设置。这意味着 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. 为什么要为从 HDFS 读取的块更新 CRC32 校验和？如果我理解正确，一旦读取一个块，从磁盘读取的数据与块的 CRC 的简单比较应该是唯一的操作，而不是生成和更新块的 CRC 值。

  2. 我查找了更新函数的源代码，它是由 java.util.zip.CRC32.java 文件实现的。调用的特定函数是具有三个参数的重载 update() 方法。既然这个功能是用Java实现的，有没有可能多层抽象（Hadoop、JVM、CPU指令）降低了CRC计算的原生效率？

  3. 最后，我的 VisualVM 检测方法或对采样结果的解释是否存在严重问题？

谢谢，

4

1 回答 1

0

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

  1. 删除一个副本上的元文件
  2. 截断一个副本上的元文件
  3. 损坏一个副本上的元文件头
  4. 破坏元文件的任何随机偏移和部分
  5. 交换两个元文件，即元文件的格式有效但它们的CRC与其对应的数据块不匹配

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

对于第二个问题，您能告诉我您使用的是哪个版本的 Hadoop 吗？CRC的效率一再被抱怨和提高。

于 2014-01-15T20:47:47.037 回答