Hadoop/YARN及在非HDFS文件系统上的任务并行化

Question

Hadoop/YARN及在非HDFS文件系统上的任务并行化

7

我已经创建了一个 Hadoop 2.4.1 集群，并发现运行 MapReduce 应用程序会根据输入数据所在的文件系统类型而有不同的并行方式。

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

在不是 HDFS 的文件系统上（如 NFS 或我的情况下，使用的是并行文件系统），MapReduce 作业将只分配可用任务的子集（例如，对于相同的 3 节点集群，仅创建约 25-40 个容器）。由于我使用的是并行文件系统，因此我不太关心使用 NFS 时可能遇到的瓶颈问题。

是否有 YARN （yarn-site.xml）或 MapReduce （mapred-site.xml）配置可以让我有效地最大化资源利用？

- calvin

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- jayunit100 · Accepted Answer

这取决于文件系统。

数据本地化的实现方式是，在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;
}

在上面的内容中，您可以看到文件的元数据是通过Gluster特定的包装器提供的，这些包装器调用Gluster特定的命令来确定哪些节点存储文件的实际内容。然后，BlockLocation []数组作为提示提供给作业调度程序，它将尝试使任务落在与拆分确定其块位置的本地位置相同的位置。

但最终，调度程序的工作是处理拆分而不是块。因此，拆分可以比文件系统块小或大。如果它更大，则很可能会通过网络流式传输拆分的某个部分。如果它很小，则可能会获得更多的本地性，但可能会以增加总任务数的代价。

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

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

通过在您的Hadoop兼容文件系统中实现更细粒度的阻止（getBlockLocations），您可以增加块的数量，并增加这些块的复制。

增加块的数量可以使特定块能够以本地环境运行的概率更高。

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