阿里YARN平台升级到2.2.0了

文章导读：

1.RM使用FairScheduler，对于MR的appmaster去向rm申请资源时如何处理的？

2.阿里的hadoop是跨机房的，宽带是如何解决的？

前天，阿里巴巴的YARN版本从0.23.6升级到2.2.0,也就是目前社区最新的release版本。我们基本把阿里巴巴的关于YARN的所有的patch全部应用到社区的2.2.0版本上，大约有120多个patch。
主要涉及以下方面：

下面就每一个方面说明下：

1.安全 安全分为两块，认证和授权。 认证是保持和阿里1.0版本的hadoop一样的机制，修改ugi，用账户和密码的方式。账户和密码封装在ugi中，会随着RPC请求的消息头传服务端，服务端来完成认证。在近期阿里正在结合内部的认证体系 使用证书的方式登陆，证书由一个统一的认证中心颁发。关于授权，在yarn中基本就是能不能提交app，阿里添加了在哪些时段如许提交job等。对于hive的表格式的授权，目前也正在实现中。

2.关于稳定性，主要是长时间运行集群挂不挂，磁盘挂了，磁盘坏了，NM挂了等出现异常怎么办的问题。
0.23.6版本在阿里已经运行6个月了。2.2.0刚上线，还没有出现特别的稳定性问题。

3.viewfs，因为我们的NN是有多个的，所以需要viewfs。

4.hive，此点社区的hive版本也已经支持yarn了。


5.调度，RM使用FairScheduler，对于MR的appmaster去向rm申请资源时还是比较复杂的。
我们引入了一个绝对的优先级的感念，也就是当一个app的level高时，他就会优先拿到所有的资源。这就存在一个问题：建设是MR，如果一个jobA正在跑map，通过启动了一些reduce。如果此时高优先级的jobB来了，那此时jobA申请不到资源（因为所有的资源给jobB了），此时，jobA的reduce就会释放，最后相当于把jobA的已经申请到的reduce资源也释放给了jobB。但是如果不释放又不知jobB运行多久，占着container也不合适，所以就悲剧了。 我们改进就是 当此job的所有map都已经申请到资源后，才开始分配此job reduce。这样对于整体的吞吐量有一定的提高，但是对于此job的运行时间肯定延长了。

6.运维支持 对于一些 添加节点、下架节点等最起码需求需要支持。另外 由于线上的 端口有一定的限制。
所以appmaster的ipc端口的端口必须在一段开放的范围内。

7.Cgroups：
此点麻烦点在于我们是用一个普通的账户启动container，cgroups要求需要有sudo的权限。我们改进的版本就是把权限设置为：—Sr-s— 1 root   mapred  91510 Jan 15 11:00 container-executor

8.跨机房，阿里的hadoop是跨机房的。
实现的方案是基于一个app只会在一个机房内运行。如果出现跨机房的app，那app内部的数据交换是跨机房之间的带宽吃不消的。改动就是修改FairScheduler调度器，提交到这几个queue的app只会在指定的机房分配资源就可以了。

9.支持MPI、Rhive等


10.spark目前是阿里YARN平台支持的除支持MR以外的最重要的框架。
这快支持主要是spark需要支持yarn。为了支持0.23.7和2.2.0系列，他分别写了两个工程，一个是yarn，一个是new-yarn。如果再出现一个yarn的不兼容的版本，估计是new-new-yarn了。


据我所知，目前很多公司都在尝试YARN平台，阿里目前也已经正式在社区最新的YARN-2.2.0上跑起来了。2014年，YARN必将替换JT成为越来越多的公司的海量平台。SPARK等基于内存的准实时计算框架必将在YARN上绽放青春。



fengshenwu