详细介绍云梯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性能。

以上就是关于详细介绍云梯YARN集群的 技术实现与发展状况的相关介绍，更多详细介绍云梯YARN集群的 技术实现与发展状况相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对详细介绍云梯YARN集群的 技术实现与发展状况有更深的了解和认识。