关于Azure HDInsight资源调用的问题及解决办法

2.关于HDInsight资源调用的问题及解决办法

HDInsight的集群创建后，通常会根据创建时指定的节点大小来设定和资源分配相关的参数的默认值。但有些情况下，这些默认值可能无法满足客户的要求，需要在创建时指定好相关参数。
比如本次客户的环境是25个A7 的节点作为Data Node, 每台服务器的配置是8Core/56G 内存。默认创建好集群后，HDInsight 会默认设定每个Container 分配1Core/9G 内存。这样理论上每台服务器最大能分配6个Container. 在25个节点跑满的情况下，最大能分配6*25=150个Container. 考虑到系统本身会占用一部分内存，实际运行过程中按默认配置每台服务器最大能分配5个，整个集群最大能分配5*25=125个 Container.换句话说整个集群最大可分配总资源为 125 个Core / 1125G 内存。 而整个集群的实际资源总数为200个Core / 1.4T 内存。
通过调整参数，把每个Container 分配的资源数调整为 1Core/5.5G 内存，很好的解决了上述资源分配的问题，可以整个集群跑满200个Core。

另外我们在部署中遇到的一个问题是对于某一个特定的应用程序，系统永远都只能分配很少的资源，导致该应用实际运行的时间比在本地的Hadoop 集群要长很多。本地运行3-4小时，但在HDInsight 上该应用需要运行12个小时以上。这对用户来说是不能接受的。
通过分析该应用的特点，我们了解到该应用的任务的量很大（超过1万个任务）/但每个任务执行的时间都很短。
经过进一步排查，发现这个HDInsight 的资源调度模式的本地优化与延迟调度有关。以下是关于Hadoop 本地优化和延迟调度的说明：

http://tech.uc.cn/?p=1438

本地优化与延迟调度
*我们解释一下什么是本地优化和延迟调度。
Hadoop是构建在以hdfs为基础的文件系统之上的。YARN所运行的应用的绝大部分输入都是hdfs上的文件。而hdfs上的文件的是分块多副本存储的。假设文件系统的备份因子是3。则每一个文件块都会在3个机器上有副本。在YARN运行应用的时候，AM会将输入文件进行切割，然后，AM向RM申请的container来运行task来处理这些被切割的文件段。
假如输入文件在ABC三个机器上有备份，那如果AM申请到的container在这3个机器上的其中一个，那这个task就无须从其它机器上传输要处理的文件段，节省网络传输。这就是Hadoop的本地优化。所以Hadoop的文件备份数量除了和数据安全有关，还对应用运行效率有莫大关系。
YARN的实现本地优化的方式是AM给RM提交的资源申请的时候，会同时发送本地申请，机架申请和任意申请。然后，RM的匹配这些资源申请的时候，会先匹配本地申请，再匹配机架申请，最后才匹配任意申请。关于AM资源申请机制可以参考：ContainerAlloctor分析
而延迟调度机制，就是调度器在匹配本地申请失败的时候，匹配机架申请或者任意申请成功的时候，允许略过这次的资源分配，直到达到延迟调度次数上限。CapacityScheduler和FairScheduler在延迟调度上的实现稍有不同，前者的调度次数是根据规则计算的，后者的调度次数通过配置指定的，但实际的含义是一样的。
*

基于Hadoop的资源调度机制，RM在分配资源的时候，先会匹配本地申请，如果本地申请不成功或次数超过延迟调度次数的上限，才会采用机架申请。同样由机架申请到任意申请（Off-Switch） 模式，也是类似的机制。
针对对客户的应用特点，每个任务执行的时间很短，总的任务数很大。这样会导致每个任务申请资源时都可以在本地匹配，永远到不了”机架申请” 和“任意申请”. 这是导致最后该应用实际分配资源永远都很少的根本原因。
解决方法也很简单，因为HDInsight 的计算和存储是分离的，计算节点和存储之间有很好的带宽与延迟。所以上述的几种模式对于HDInsight 基本没什么影响。
所以解决方案是把系统中关于节点Topo 图的参数设置为空，换句话说HDInsight对计算节点的机架/节点分布没有感知。这样就会让RM 可以按需分配资源给AM.