Hadoop 体系架构
Yarn架构
Hadoop 和MRv1 简单介绍
Hadoop 集群可从单一节点（其中所有Hadoop 实体都在同一个节点上运行）扩展到数千个节点（其中的功能分散在各个节点之间，以增加并行处理活动）。图1 演示了一个Hadoop 集群的高级组件。
图 1. Hadoop 集群架构的简单演示
一个Hadoop 集群可分解为两个抽象实体：MapReduce 引擎和分布式文件系统。MapReduce 引擎能够在整个集群上执行Map 和Reduce任务并报告结果，其中分布式文件系统提供了一种存储模式，可跨节点复制数据以进行处理。Hadoop 分布式文件系统(HDFS) 通过定义来支持大型文件（其中每个文件通常为64 MB 的倍数）。
当一个客户端向一个Hadoop 集群发出一个请求时，此请求由JobTracker 管理。JobTracker 与NameNode 联合将工作分发到离它所处理的数据尽可能近的位置。NameNode 是文件系统的主系统，提供元数据服务来执行数据分发和复制。JobTracker 将Map 和Reduce 任务安排到一个或多个TaskTracker 上的可用插槽中。TaskTracker 与DataNode（分布式文件系统）一起对来自DataNode 的数据执行Map 和Reduce 任务。当Map 和Reduce 任务完成时，TaskTracker 会告知JobTracker，后者确定所有任务何时完成并最终告知客户作业已完成。
InfoSphere BigInsights Quick Start Edition
InfoSphere BigInsights Quick Start Edition 是IBM 基于Hadoop 的产品InfoSphere BigInsights 的一个免费可下载版本。使用Quick Start Edition，您可尝试IBM 开发的特性来扩大开源Hadoop 的价值，比如Big SQL、文本分析和BigSheets。引导式学习可让您的体验尽可能顺畅，包括按部就班、自定进度的教程和视频，可以帮助开始让Hadoop 为您所用。没有时间或数据限制，您可自行安排时间在大量数据上进行试验。请观看视频、学习教程(PDF)和下载BigInsights Quick Start Edition。
从图1 中可以看到，MRv1 实现了一个相对简单的集群管理器来执行MapReduce 处理。MRv1 提供了一种分层的集群管理模式，其中大数据作业以单个Map 和Reduce 任务的形式渗入一个集群，并最后聚合成作业来报告给用户。但这种简单性有一些隐秘，不过也不是很隐秘的问题。
MRv1 的缺陷
MapReduce 的第一个版本既有优点也有缺点。MRv1 是目前使用的标准的大数据处理系统。但是，这种架构存在不足，主要表现在大型集群上。当集群包含的节点超过4,000 个时（其中每个节点可能是多核的），就会表现出一定的不可预测性。其中一个最大的问题是级联故障，由于要尝试复制数据和重载活动的节点，所以一个故障会通过网络泛洪形式导致整个集群严重恶化。
但MRv1 的最大问题是多租户。随着集群规模的增加，一种可取的方式是为这些集群采用各种不同的模型。MRv1 的节点专用于Hadoop，所以可以改变它们的用途以用于其他应用程序和工作负载。当大数据和Hadoop 成为云部署中一个更重要的使用模型时，这种能力也会增强，因为它允许在服务器上对Hadoop 进行物理化，而无需虚拟化且不会增加管理、计算和输入/输出开销。
我们现在看看YARN 的新架构，看看它如何支持MRv2 和其他使用不同处理模型的应用程序。
YARN (MRv2) 简介
为了实现一个Hadoop 集群的集群共享、可伸缩性和可靠性。设计人员采用了一种分层的集群框架方法。具体来讲，特定于MapReduce 的功能已替换为一组新的守护程序，将该框架向新的处理模型开放。
可在何处找到YARN？
YARN 是在hadoop-0.23 版本时引入Hadoop 中的。随着彻底检查的不断完善，您将会发现此框架也在不断更新。
回想一下，由于限制了扩展以及网络开销所导致的某些故障模式，MRv1 JobTracker 和TaskTracker 方法曾是一个重要的缺陷。这些守护程序也是MapReduce 处理模型所独有的。为了消除这一限制，JobTracker 和TaskTracker 已从YARN 中删除，取而代之的是一组对应用程序不可知的新守护程序。
图 2. YARN 的新架构
YARN 分层结构的本质是ResourceManager。这个实体控制整个集群并管理应用程序向基础计算资源的分配。ResourceManager 将各个资源部分（计算、内存、带宽等）精心安排给基础NodeManager（YARN 的每节点代理）。ResourceManager 还与ApplicationMaster 一起分配资源，与NodeManager 一起启动和监视它们的基础应用程序。在此上下文中，ApplicationMaster 承担了以前的TaskTracker 的一些角色，ResourceManager 承担了JobTracker 的角色。
ApplicationMaster 管理一个在YARN 内运行的应用程序的每个实例。ApplicationMaster 负责协调来自ResourceManager 的资源，并通过NodeManager 监视容器的执行和资源使用（CPU、内存等的资源分配）。请注意，尽管目前的资源更加传统（CPU 核心、内存），但未来会带来基于手头任务的新资源类型（比如图形处理单元或专用处理设备）。从YARN 角度讲，ApplicationMaster 是用户代码，因此存在潜在的安全问题。YARN 假设ApplicationMaster 存在错误或者甚至是恶意的，因此将它们当作无特权的代码对待。
NodeManager 管理一个YARN 集群中的每个节点。NodeManager 提供针对集群中每个节点的服务，从监督对一个容器的终生管理到监视资源和跟踪节点健康。MRv1 通过插槽管理Map 和Reduce 任务的执行，而NodeManager 管理抽象容器，这些容器代表着可供一个特定应用程序使用的针对每个节点的资源。YARN 继续使用HDFS 层。它的主要NameNode 用于元数据服务，而DataNode 用于分散在一个集群中的复制存储服务。
要使用一个YARN 集群，首先需要来自包含一个应用程序的客户的请求。ResourceManager 协商一个容器的必要资源，启动一个ApplicationMaster 来表示已提交的应用程序。通过使用一个资源请求协议，ApplicationMaster 协商每个节点上供应用程序使用的资源容器。执行应用程序时，ApplicationMaster 监视容器直到完成。当应用程序完成时，ApplicationMaster 从ResourceManager 注销其容器，执行周期就完成了。
通过这些讨论，应该明确的一点是，旧的Hadoop 架构受到了JobTracker 的高度约束，JobTracker 负责整个集群的资源管理和作业调度。新的YARN 架构打破了这种模型，允许一个新ResourceManager 管理跨应用程序的资源使用，ApplicationMaster 负责管理作业的执行。这一更改消除了一处瓶颈，还改善了将Hadoop 集群扩展到比以前大得多的配置的能力。此外，不同于传统的MapReduce，YARN 允许使用Message Passing Interface 等标准通信模式，同时执行各种不同的编程模型，包括图形处理、迭代式处理、机器学习和一般集群计算。
随着YARN 的出现，您不再受到更简单的MapReduce 开发模式约束，而是可以创建更复杂的分布式应用程序。实际上，您可以将MapReduce 模型视为YARN 架构可运行的一些应用程序中的其中一个，只是为自定义开发公开了基础框架的更多功能。这种能力非常强大，因为YARN 的使用模型几乎没有限制，不再需要与一个集群上可能存在的其他更复杂的分布式应用程序框架相隔离，就像MRv1 一样。甚至可以说，随着YARN 变得更加健全，它有能力取代其他一些分布式处理框架，从而完全消除了专用于其他框架的资源开销，同时还简化了整个系统。
开发YARN 应用程序
使用YARN 提供的强大的新功能和在Hadoop 之上构建自定义应用程序框架的能力，您还会面临新的复杂性。为YARN 构建应用程序，比在YARN 之前的Hadoop 之上构建传统MapReduce 应用程序要复杂得多，因为您需要开发一个ApplicationMaster，这就是在客户端请求到达时启动的
ResourceManager。ApplicationMaster 有多种需求，包括实现一些需要的协议来与ResourceManager 通信（用于请求资源）和NodeManager（用于分配容器）。对于现有的MapReduce 用户，MapReduce ApplicationMaster 可最大限度地减少所需的任何新工作，从而使部署MapReduce作业所需的工作量与YARN 之前的Hadoop 类似。
在许多情况下，YARN 中一个应用程序的生命周期类似于MRv1 应用程序。
YARN 在一个集群中分配许多资源，执行处理，公开用于监视应用程序进度的接触点，且最终在应用程序完成时释放资源并执行一般清理。这个生命周期的一种样板实现可在一个名为Kitten的项目中获得（参见参考资料）。Kitten 是一组工具和代码，可简化YARN 中的应用程序开发，从而使您能够将精力集中在应用程序的逻辑上，并在最初忽略协商和处理YARN 集群中各种实体的局限性的细节。但是，如果希望更深入地研究，Kitten 提供了一组服务，可用于处理与其他集群实体（比如ResourceManager）的交互。Kitten 提供了自己的
ApplicationMaster，很适用，但仅作为一个示例提供。Kitten 大量使用了Lua 脚本作为其配置服务。
YARN架构简析
集中式架构
集中式调度器(Monolithic Schuduler)的特点是，资源的调度和应用程序的管理功能全部放到一个进程中完成，开源界典型的代表是MRv1 JobTracker的实现。这样设计的缺点很明显，扩展性差：首先，集群规模受限；其次，新的调度策略难以融入到现有代码中，比如之前仅支持MapReduce作业，现在要支持流式作业，而将流式作业的调度策略嵌入到中央调度其中是一项很难的工作。[2]
双层调度架构
为了客服集中式调度器的不足，双层调度器是一种很容易被想到的解决之道，它可看作是一种分而治之的机制或者是策略下放机制：双层调度器仍保留一个经简化的集中式资源调度器，但具体任务相关的调度策略则下方到各个应用程序调度器完成。这种调度器的典型代表是Mesos或YARN。Mesos调度器由两部分组成，分别是资源调度器和框架(应用程序)调度器,其中，资源调度器负责将集群中的资源分配给各个(应用程序),而框架(应用程序)调度器负责将资源进一步分配给内部的各个任务，用户很容易将一种框架或者系统接入Mesos.
双层调度器的特点是：各个框架调度器并不知道整个集群资源使用情况，只是被动地接受资源；资源调度器仅将可用的资源推送给各个框架，而由框架自己选择是使用还是拒绝这些资源；一旦框架接受到新资源，再进一步将资源分配给其内部的任务，进而实现双层调度。然而这种调度器也是有缺点，主要表现在以下两个方面:1.各个框架无法知道整个集群的实时资源使用情况；采用悲观锁，并发粒度小
典型节点分配
Hadoop 典型硬件需求
硬件配置-内存
用户可以通过简单地叠加相应服务需要的内存要求来计算推荐的内存要求：
如下服务：
HDFS DataNode 2GB
MapReduce TaskTracker 2GB HBase Region Server 16GB
计划的slot数量（包括map slots 和reduce slots）为16.*512MB
这样需要的内存为2+2+16+0.5*16=28GB
硬件配置-硬盘
硬件配置-网络
https://www.doczj.com/doc/9814657239.html,/developerworks/cn/data/library/bd-hadoopyarn/index.html
https://www.doczj.com/doc/9814657239.html,/
https://www.doczj.com/doc/9814657239.html,/link?url=1lLWeO-iD4NbqKOxlTis7tJI9aHmQu2tVNxcOwt64bHUWKL_Vz6
yorCTM2csQFLRWQWAiqFnB8Yjq4mIAaNi2oBiFZFHUoM5qQQIx86vy47
中高端网络配置推荐
小规模硬件配置
中规模硬件推荐
高端硬件推荐
软件环境要求
Hadoop 集群规划
构建步骤
角色分配
小规模测试集群
小规模生产集群
大规模生产集群
深入剖析阿里巴巴云梯YARN集群
发表于2013-12-04 18:21| 20923次阅读| 来源《程序员》| 21条评论| 作者沈洪
《程序员》杂志2013年11月刊HadoopYARNMapReduceHDFS阿里巴巴云梯集群Spark
摘要：阿里巴巴是国内使用Hadoop最早的公司之一，已开启了Apache Hadoop 2.0时代。本文将详细介绍阿里巴巴如何充分利用YARN的新特性来构建和完善其多功能分布式集群——云梯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应用外另一个重要的应用。