hadoop/yarn 和非 hdfs 文件系统上的任务并行化

Question

我已经实例化了一个 Hadoop 2.4.1 集群，我发现运行 MapReduce 应用程序的并行化取决于输入数据所在的文件系统类型。

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

在非 HDFS 的文件系统上(如 NFS 或在我的用例中，并行文件系统)，MapReduce 作业将仅分配可用任务的子集(例如，对于相同的 3 节点集群，大约 25-创建了 40 个容器)。由于我使用的是并行文件系统，因此我不太关心使用 NFS 时会发现的瓶颈。

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

Answer 1

这取决于文件系统。

局部性的工作方式是您必须在 Hadoop FileSYstem 接口(interface)内为给定文件实现 getBlockLocations。例如，您可以看到:

一个示例实现，来自 glusterfs-hadoop filesystem implementation ，在这里:

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[] 数组然后作为作业调度程序的提示，它将尝试将任务定位到拆分确定其 block 位置所在的本地。

但归根结底，调度程序的工作是处理拆分，而不是 block 。因此，拆分可以小于或大于文件系统 block 。如果它更大，则很可能部分拆分将通过网络流式传输。如果它小很多，那么您可能会获得更多的局部性，但可能会以拥有更多的总体任务数为代价。

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

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

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

增加 block 的数量可以提高特定 block 能够在本地上下文中运行的可能性。

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