非HDFS文件系统上的Hadoop/Yarn和任务并行化

Question

我实例化了一个Hadoop2.4.1集群，并且发现运行的MapReduce应用程序的并行化程度将不同，这取决于输入数据所在的文件系统类型。

使用HDFS，MapReduce作业将生成足够的容器，以最大限度地利用所有可用内存。例如，一个具有172GB内存的3节点集群，每个map任务分配2GB，将创建大约86个应用程序容器。

在不是HDFS的文件系统上（比如NFS或在我的用例中是并行文件系统），MapReduce作业将只分配可用任务的子集（例如，对于相同的3节点集群，大约创建25-40个容器）。因为我使用的是并行文件系统，所以我并不关心使用NFS时会遇到的瓶颈。

是否有一个纱（yarn-site.xml）或MapReduce（mapred-site.xml）配置允许我有效地最大化资源利用率？

Answer 1

这取决于文件系统。

locality的工作方式是，必须在Hadoop文件系统接口内部实现给定文件的getBlockLocations。例如，您可以看到：

下面是来自glusterfs-hadoop文件系统实现的示例实现：

public BlockLocation[] getFileBlockLocations(FileStatus file,long start,long len) throws IOException{
    File f=pathToFile(file.getPath());
    BlockLocation[] result=null;

    result=attr.getPathInfo(f.getPath(), start, len);
    if(result==null){
        log.info("Problem getting destination host for file "+f.getPath());
        return null;
    }

    return result;
}

在优化时，请记住，每个输入拆分都是最终提供给映射器的。

在HDFS中，默认值往往比其他文件系统调优得更好。

通过在hadoop兼容的文件系统中实现更细粒度的阻塞(getBlockLocations)，您可以增加块的数量，也可以增加这些块的复制。

此外，您还可以在运行时切换输入拆分的数量（最大值和最小值），作为mapreduce作业参数的一部分。通过更新该值，您可能会提高性能（即机器的使用），但也可能会降低本地性（更多的拆分意味着，如果某些机器本身就更快，mapreduce可能会将拆分流式传送到非本地机器，这可能会占用大量任务。）