hadoop / yarn和非并行任务并行化
我已经实例化了一个Hadoop 2.4.1集群，并且我发现运行MapReduce应用程序将根据输入数据所在的文件系统的不同而并行化。
使用HDFS，MapReduce作业将产生足够的容器以最大限度地利用所有可用内存。 例如，具有172GB内存的3节点集群，每个映射任务分配2GB，将创建约86个应用程序容器。
在不是HDFS的文件系统上（例如NFS或在我的使用案例中，并行文件系统），MapReduce作业只会分配一部分可用任务（例如，使用相同的3节点群集，大约25-40个容器创建）。 由于我使用的是并行文件系统，因此我不太关心如果使用NFS时会遇到的瓶颈问题。
是否有YARN（yarn-site.xml）或MapReduce（mapred-site.xml）配置，可以使我有效地最大化资源利用率？
这取决于文件系统。
局部性的工作方式是，您必须在Hadoop FileSYstem接口内实现给定文件的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可能会将一个拆分流式传输到可能抢夺的非本地机器很多任务。）
链接地址: http://www.djcxy.com/p/22359.html