详细介绍云梯YARN集群的 技术实现与发展状况

阿里巴巴作为中国最早使用Hadop的公司之一，已经开启了ApacheHadop2.0时代。阿里巴巴的Hadoop集群，即梯形集群，分为存储和计算两个模块。计算模块包括MRV1和YARN集群，共享存储HDFS集群。云梯YARN集群不仅支持Mapreduce，还支持Spark、MPI、RHive、计算模型，如RHadoop。本文将详细介绍云梯YARN集群的技术实现和发展。MRV1和YARN集群共享HDFS存储技术以服务为起点，云梯集群将Hadoop分为存储（HDFS）服务与计算(MRV1和YARN)。这两个计算集群共享HDFS存储集群，这是怎么做到的？在引入YARN之前，基于ApacheHadoop0.19.1-dc版本的云梯Hadoop，并添加了许多新功能。此外，它还兼容了ApacheHadop0.19、0.20、客户端CDH3版。为了保持对客户端的友好，云梯服务端升级总是保持与原客户端的兼容性。此外，为了方便访问数据，阿里巴巴的存储集群是一个单一的大集群。YARN的引入不应迫使HDFS集群被拆分，但YARN是基于社区0.23系列版本，不能直接访问梯子HDFS集群。因此，实现YARN集群访问云梯的HDFS集群是引入YARN后需要解决的第一个技术问题。Hadoop代码主要分为Comon、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包中运行。hack用于云梯Common包的通信部分，使其与0.23Common兼容。图1Hadoop代码架构新的云梯代码结构如图1所示，如下所示。原HDFS用于服务端存储部分。在MRV1计算集群中提供原MRV1服务。YARN集群提供更丰富的应用服务。客户端云梯现有客户端不做任何修改，继续使用原有服务。使用YARN服务需要使用新的客户端。为YARN切换云梯MR服务，服务端只有MRV1，客户端只有老版本的客户端。MRV1与YARN共存(MRV1资源逐渐转移到YARN)，如果客户端需要使用MRV1服务，则保持客户端不变；如果需要使用YARN服务，则需要使用新的客户端。YARN只留在服务端，客户端只有新版本的客户端。通过以上修改，云梯开发人员以较小的修改实现了YARN对云梯HDFS的访问。云梯版YARN集群实现了SparkonyARN、Hive、Spark、MPI、RHive、支持RHadoop等应用。云梯集群目前的结构如图2所示。Spark已成为YARN集群除Mapreduce应用外的另一个重要应用。Spark是一个分布式数据快速分析项目。其核心技术是弹性分布式数据集（ResilientDistributedDatasets），它提供了比Mapreduce更丰富的模型，可以在内存中快速迭代数据集，以支持复杂的数据挖掘算法和图形计算算法。Spark的计算调度模式，从Mesos到Standalone，即自建Spark计算集群。虽然Standalone的性能和稳定性有所提高，但毕竟自建集群资源少，需要从梯子集群复制数据，无法满足数据挖掘和计算团队的业务需求。SparkonyARN允许Spark计算模型在云梯YARN集群上运行，直接读取云梯上的数据，充分享受云梯YARN集群丰富的计算资源。理论上，Sparkonyarn功能从Spark0.6.0版本开始支持，但实际上还远未成熟。经过长时间的数据挖掘和计算团队压力测试，修复了一些相对关键的bug，以确保Sparkonyarn的稳定性和正确性。SparkonYARN的操作执行机制显示在图3中。图3Sparkonyarn框架基于Yarn的Spark操作首先由客户端生成操作信息，并提交给resourcemanager。resourcemanager在nodemanager报告时将appmaster分配给nodemanager，nodemanager启动sparkappmaster，Sparkappmaster启动后的初始化作业，然后向Resourcemanager申请资源，Sparkappmaster通过RPC让Nodemanager启动相应的Sparkexecutor，Sparkexecutor向Sparkappmaster汇报并完成相应的任务。另外，SparkClient将通过AppMaster获得工作状态。此外，Sparkclient还将通过Appmaster获得操作状态。目前，数据挖掘和计算团队已经通过SparkonyARN实现了MLR、Pagerank和JMeans算法，其中MLR已作为生产操作运行。云梯YARN集群维护经验分享云梯YARN维护过程中遇到的问题很多，很有可能在YARN集群维护中遇到。这里有两个典型的问题及其解决方案。问题1问题描述：社区的CPU隔离和调度功能需要在每台NodeManager所在的机器上创建与用户帐户相对应的Linux帐户。但是阿里云梯集群有5000多个账户，是否需要在每台Nodemanager机器上创建这么多Linux账户；此外，每次创建或删除Hadop用户时，还应在每台Nodemanager机器上创建或删除相应的Linux账户，这将大大增加操作和维护的负担。问题分析：我们发现CPU的隔离并不依赖于Linux账户，这意味着即使同一账户创建了两个过程，Cgroup也可以隔离CPU，但为什么社区要在每台Nodemanager机器上创建账户呢？原来这是为了让每一个Container都以提交aplication的账户执行，防止Container的Linux账户权限过大，保证安全。然而，云梯集群很久以前就分为账户。启动container的Linux账户统一为普通账户。该账户权限小，用户为公司内部员工，安全性能满足需求。解决方案：修改container-executor.c文件，防止其修改container的启动账户，并使用统一的普通Linux账户(无sudo权限)运行container。这样既能保证安全，又能减少运维工作量。问题2问题描述:MRAplicationMaster初始化缓慢，部分作业MRAplicationMaster启动需要一分钟以上。问题分析:通过检查MRAplication-Master的日志，发现分析Rack上消耗了一分钟的初始化时间。从代码分析来看，MRAplicationMaster启动时需要初始化Taskatempt，然后需要分析split信息中的Host，生成相应的Rack信息。目前，云梯分析Host的方法是通过调用外部Python脚本进行分析，每次调用约需20ms。由于云梯HDFS集群非常大，有4500多台机器。如果输入数据分布在每个Datanode上，则需要4500台分析Host×20ms=90s；若作业输入数据较大，且文件备份数为3，那么输入数据很可能会分布在集群的大多数Datanode上。解决方案：开发人员通过在Node-Manager上添加配置文件，包括所有Datanode的Rack信息，MRApp-LicationMaster启动后，加载此文件，防止外部脚本分析频繁调用。解决方案：开发人员通过在Node-Manager上添加配置文件，包括所有Datanode的Rack信息，MRApp-LicationMaster启动后，加载此文件，防止外部脚本分析频繁调用。这大大加快了MRAplicationMaster的初始化。此外，云梯开发人员还解决了一些会让ResourceManager不工作的bug，并将其贡献给ApacheHadop社区。在云梯YARN集群的建设和维护中，云梯开发人员遇到并解决了许多问题。分析和解决这些问题首先需要熟悉代码，但代码量巨大。我们如何快速熟悉它们？这需要团队的合作。团队中的每个人都负责不同的模块，阅读后轮流分享，可以加快熟悉代码的速度。此外，Hadoop的优势在于它可以利用社区的力量。当你遇到问题时，你可以先去社区找到答案，因为社区已经解决了很多问题，充分利用社区可以大大提高工作效率。目前，云梯YARN集群已试运行，并拥有MRV2、Hive、Spark、RHive、RHadop等应用。云梯YARN集群的优点是支持更丰富的计算模型；共享云梯最大的存储集群，访问方便快捷；AppHistory信息存储在HDFS上，可以方便查看各种应用程序的操作历史；与MRV1集群相比，云梯YARN可以支持更大的集群； 与MRV1集群相比，云梯YARN集群支持内存和CPU调度，资源利用将更加合理。未来，云梯将把大部分业务转移到云梯YARN集群。未来，云梯将将大部分业务转移到云梯YARN集群。对于YARN版本，云梯将增加资源隔离和调度，增加Storm、支持Tez等计算模型，优化YARN性能。