在Hadoop中写入HDFS中的文件

我正在寻找一个磁盘密集型的Hadoop应用程序来测试Hadoop中的I/O活动，但我找不到任何这样的应用程序可以使磁盘利用率保持在50%以上，或者一些这样的应用程序可以让磁盘保持忙碌。我尝试了randomwriter，但令人惊讶的是，它并不是磁盘I/o密集型的

所以，我编写了一个小程序，在Mapper中创建一个文件，并在其中写入一些文本。该应用程序运行良好，但仅在主节点中利用率较高，主节点也是名称节点、作业跟踪器和从属节点之一。在其他任务跟踪器中，磁盘利用率为零或可忽略不计。我无法理解为什么任务跟踪器中的磁盘I/O如此之低。如果我做错了什么，谁能帮我朝正确的方向走？提前谢谢

这是我在WordCount.java文件中编写的示例代码段，用于创建UTF字符串并将其写入文件-

Configuration conf = new Configuration();
FileSystem fs = FileSystem.get(conf);
Path outFile;
while (itr.hasMoreTokens()) {
    word.set(itr.nextToken());
    context.write(word, one);
    outFile = new Path("./dummy"+ context.getTaskAttemptID());
    FSDataOutputStream out = fs.create(outFile);

    out.writeUTF("helloworld");
    out.close();
    fs.delete(outFile);
  }

---

我认为，任何在每行的每个单元格中创建java对象，并在将java对象保存到磁盘之前运行任何java对象序列化的机制都不可能利用IO
根据我的经验，序列化的速度是每秒几MB或更高，但不是每秒100 MB
因此，您在输出路径上避免hadoop层的做法是非常正确的。 现在让我们考虑如何写HDFS。数据通过本地datanode写入本地磁盘，然后同步写入网络中的其他节点，具体取决于您的复制系数。在这种情况下，您无法将更多数据写入HDFS，而不是网络带宽。如果你的集群相对较小，那么事情就会变得有价值。对于3节点群集和三重复制，您将把所有数据路由到所有节点，这样整个群集HDFS写入带宽将大约为1 GBit—如果您有这样的网络
因此，我建议：
a） 将复制因子减少到1，从而停止被网络绑定。

---

b） 在对mapper的一次调用中写入更大的数据块

确定。我以前没有检查过，我一定很傻。实际的问题是，我的所有数据节点都没有真正运行。我重新格式化了namenode，一切都恢复正常，我得到了15-20%的利用率，这对WC来说并不坏。我将为TestDFSIO运行它，看看是否可以更充分地利用磁盘。

对于I/O基准测试，您还可以查看TestDFSIO:@LorandBendig我做到了，我发现我的14个节点的集群中TestDFSIO的最高磁盘利用率仅为2.4%，平均约为0.07%。我通过iostat命令测量磁盘利用率，作业运行了大约300秒。是否有一些我正在做却没有意识到的愚蠢的事情？你可以使用参数（文件的nr、大小），但我认为你已经这样做了。你可以尝试进一步的测试，这里描述得很好：@Lorand我确实试过了。我将复制因子更改为1，并对参数进行了调整，甚至在这之后，我看到只有主节点（也是从节点）忙于执行IO（100%利用率！），而其他节点的利用率为0%！我将复制因子更改为1，并将块大小分别更改为1KB和1MB。我的观察结果是，map reduce运行非常缓慢，并且IO仅在主节点中再次处于高水平。我也试着在mapper中写一次，不像上面的代码，我在找到每个单词时都会写文件。不过，行为还是一样的。有多少个mapper同时运行？每个节点的磁盘带宽是多少？已启动的映射任务=3，已启动的减少任务=1，mapred.tasktracker.map.tasks.max=2，mapred.tasktracker.reduce.tasks.max=2。3个节点上的磁盘利用率几乎为0，而主节点上的磁盘利用率为100%。已启动的映射任务=3看起来很低-可能没有足够的输入拆分。还请确保datanode deamons正在集群的所有从属节点上运行