剖析阿里巴巴的云梯YARN集群技术使用

阿里巴巴作为国内使用hadoop最早的公司之一，已开启了apache hadoop 2.0时代。阿里巴巴的hadoop集群，即云梯集群，分为存储与计算两个模块，计算模块既有mrv1，也有yarn集群，它们共享一个存储hdfs集 群。云梯yarn集群上既支持mapreduce，也支持spark、mpi、rhive、rhadoop等计算模型。本文将详细介绍云梯yarn集群的 技术实现与发展状况。

mrv1与yarn集群共享hdfs存储的技术实现

以服务化为起点，云梯集群已将hadoop分为存储（hdfs）服务与计算（mrv1和yarn）服务。两个计算集群共享着这个hdfs存储集群，这是怎么做到的呢？

在引入yarn之前，云梯的hadoop是一个基于apache hadoop 0.19.1-dc版本，并增加许多新功能的版本。另外还兼容了apache hadoop 0.19、0.20、cdh3版本的客户端。为了保持对客户端友好，云梯服务端升级总会保持对原有客户端的兼容性。另外，为了访问数据的便捷性，阿里的存 储集群是一个单一的大集群，引入yarn不应迫使hdfs集群拆分，但yarn是基于社区0.23系列版本，它无法直接访问云梯hdfs集群。因此实现 yarn集群访问云梯的hdfs集群是引入yarn后第一个需要解决的技术问题。

hadoop代码主要分为common、hdfs、mapred三个包。

common部分包括公共类，如i/o、通信等类。
hdfs部分包括hdfs相关类，依赖common包。
mapred部分包括mapreduce相关代码，依赖common包和hdfs包。
为了尽量减少对云梯hdfs的修改，开发人员主要做了以下工作。

使用云梯的hdfs客户端代码替换0.23中hdfs，形成新的hdfs包。
对0.23新的hdfs包做了少量的修改使其可以运行在0.23的common包上。
对0.23新的hdfs包做了少量修改使0.23的mapred包能运行在新的hdfs包。
对云梯的common包的通信部分做了hack，使其兼容0.23的common。

图1 云梯hadoop代码架构

新的云梯代码结构如图1所示，相应阐述如下。

服务端

存储部分使用原有的hdfs。
mrv1计算集群中提供原mrv1服务。
yarn集群提供更丰富的应用服务。
客户端

云梯现有的客户端不做任何修改，继续使用原有的服务。
使用yarn的服务需要使用新客户端。
云梯mr服务切换为yarn要经过三个阶段

服务端只有mrv1， 客户端只有老版本客户端。
服务端mrv1和yarn共存（mrv1资源逐渐转移到yarn上）， 客户端若需使用mrv1服务则保持客户端不变；若需使用yarn服务则需使用新版客户端。
服务端只剩下yarn，客户端只有新版本客户端。
通过上述修改，云梯开发人员以较小的修改实现了yarn对云梯hdfs的访问。

spark on yarn的实现

云梯版yarn集群已实现对mrv2、hive、spark、mpi、rhive、rhadoop等应用的支持。云梯集群当前结构如图2所示。

图2 云梯架构图

其中，spark已成为yarn集群上除mapreduce应用外另一个重要的应用。

spark是一个分布式数据快速分析项目。它的核心技术是弹性分布式数据集（resilient distributed datasets），提供了比mapreduce丰富的模型，可以快速在内存中对数据集进行多次迭代，来支持复杂的数据挖掘算法和图形计算算法。

spark 的计算调度方式，从mesos到standalone，即自建spark计算集群。虽然standalone方式性能与稳定性都得到了提升，但自建集群毕 竟资源较少，并需要从云梯集群复制数据，不能满足数据挖掘与计算团队业务需求。而spark on yarn能让spark计算模型在云梯yarn集群上运行，直接读取云梯上的数据，并充分享受云梯yarn集群丰富的计算资源。

spark on yarn功能理论上从spark 0.6.0版本开始支持，但实际上还远未成熟，经过数据挖掘与计算团队长时间的压力测试，修复了一些相对关键的bug，保证spark on yarn的稳定性和正确性。

图3展示了spark on yarn的作业执行机制。

图3 spark on yarn框架

基于yarn的spark作业首先由客户端生成作业信息，提交给resourcemanager，resourcemanager在某一 nodemanager汇报时把appmaster分配给nodemanager，nodemanager启动 sparkappmaster，sparkappmaster启动后初始化作业，然后向resourcemanager申请资源，申请到相应资源后 sparkappmaster通过rpc让nodemanager启动相应的sparkexecutor，sparkexecutor向 sparkappmaster汇报并完成相应的任务。此外，sparkclient会通过appmaster获取作业运行状态。

目前，数据挖掘与计算团队通过spark on yarn已实现mlr、pagerank和jmeans算法，其中mlr已作为生产作业运行。

云梯yarn集群维护经验分享

云梯yarn的维护过程中遇到许多问题，这些问题在维护yarn集群中很有可能会遇到，这里分享两个较典型的问题与其解决方法。

问题1
问题描述：社区的cpu隔离与调度功能，需要在每个nodemanager所在的机器创建用户账户对应的linux账户。但阿里云梯集群有5000多个账 户，是否需要在每个nodemanager机器创建这么多linux账户；另外每次创建或删除一个hadoop用户，也应该在每台nodemanager 机器上创建或删除相应的linux账户，这将大大增加运维的负担。

问题分析：我们发现，cpu的隔离是不依赖于linux账户的，意味着即 使同一个账户创建两个进程，也可通过cgroup进行cpu隔离，但为什么社区要在每台nodemanager机器上创建账户呢？原来这是为了让每个 container都以提交application的账户执行，防止container所属的linux账户权限过大，保证安全。但云梯集群很早前就已分 账户，启动container的linux账户统一为一个普通账户，此账户权限较小，并且用户都为公司内部员工，安全性已能满足需求。

解决方案：通过修改container-executor.c文件，防止其修改container的启动账户，并使用一个统一的普通linux账户（无sudo权限）运行container。这既能保证安全，又能减少运维的工作量。

问题2
问题描述：mrapplicationmaster初始化慢，某些作业的mrapplicationmaster启动耗时超过一分钟。

问 题分析：通过检查mrapplication-master的日志，发现一分钟的初始化时间都消耗在解析rack上。从代码上分 析，mrapplicationmaster启动时需要初始化taskattempt，这时需要解析split信息中的host，生成对应的rack信 息。云梯当前解析host的方法是通过调用外部一个python脚本解析，每次调用需要20ms左右，而由于云梯hdfs集群非常大，有4500多台机 器，假如输入数据分布在每个datanode上，则解析host需要花费4500×20ms=90s；如果一个作业的输入数据较大，且文件的备份数为3， 那么输入数据将很有可能分布在集群的大多datanode上。

解决方案：开发人员通过在node-manager上增加一个配置文件，包含所有datanode的rack信息，mrapp-licationmaster启动后加载此文件，防止频繁调用外部脚本解析。这大大加快了mrapplicationmaster的初始化速度。

此外，云梯开发人员还解决了一些会使resourcemanager不工作的bug，并贡献给apache hadoop社区。

在搭建与维护云梯yarn集群期间，云梯开发人员遇到并解决了许多问题，分析和解决这些问题首先需要熟悉代码，但代码量巨大，我们如何能快速熟悉它们呢？这 需要团队的配合，团队中每个人负责不同模块，阅读后轮流分享，这能加快代码熟悉速度。另外，hadoop的优势在于可以利用社区的力量，当遇到一个问题 时，首先可以到社区寻找答案，因为很多问题在社区已得到了解决，充分利用社区，可以大大提高工作效率。

云梯yarn集群的优势与未来之路

当前云梯yarn集群已经试运行，并有mrv2、hive、spark、rhive和rhadoop等应用。云梯yarn集群的优势在于：

支持更丰富的计算模型；
共享云梯最大的存储集群，访问便捷、快速；
apphistory信息存储在hdfs上，各种应用的作业历史都能方便查看；
相对于mrv1集群，云梯yarn能支持更大规模的集群；
 相对于mrv1集群，云梯yarn集群支持内存和cpu调度，资源利用将更加合理。
未来，云梯将会把大多业务迁移到云梯yarn集群。针对yarn版本，云梯将增加资源隔离与调度，增加对storm、tez等计算模型的支持，并优化yarn的性能。