Hadoop之YARN相关知识点汇总
一、yarn的基本概念
最近一段时间，经常看到有人在微博上说，“很多公司暂时用不到YARN，因为一般公司的集群规模并未像Yahoo、Facebook那样达到几千台，甚至将来几万台”。这完全是一种错误的观念，在Hadoop高速发展的时代，必须更正。
实际上，上述观念只看到了YARN的扩展性（Scalability），扩展性是可用可不用的特性，中小型公司将YARN部署到小集群（按照IBM观点，集群规模小于200台的称为中小规模集群，这样的公司找到90%以上）上，可能享受不到扩展性带来的优势，但至少可以获取以下几个收益：
（1） 更快地MapReduce计算
MapReduce仍是当前使用最广泛的计算框架。YARN利用异步模型对MapReduce框架的一些关键逻辑结构（如JobInprogress、TaskInProgress等）进行了重写，相比于MRv1，具有更快地计算速度。当然，YARN具有向后兼容性，用户在MRv1上运行的作业，无需任何修改即可运行在YARN之上。
（2） 对多框架支持
与MRv1相比，YARN不再是一个单纯的计算框架，而是一个框架管理器，用户可以将各种各样的计算框架移植到YARN之上，由YARN进行统一管理和资源分配，由于将现有框架移植到YARN之上需要一定的工作量，当前YARN仅可运行MapReduce这种离线计算框架。
我们知道，不存在一种统一的计算框架适合所有应用场景，也就是说，如果你想设计一种计算框架，可以高效地进行离线计算、在线计算、流式计算、内存计算等，是不可能的。既然没有全能的计算框架，为什么不开发一个容纳和管理各种计算框架的框架管理平台（实际上是资源管理平台）呢，而YARN正是干这件事情的东西。
YANR本质上是一个资源统一管理系统，这一点与几年前的mesos（http://www.mesosproject.org/），更早的Torque（http://www.adaptivecomputing.com/products/open-source/torque/）基本一致。将各种框架运行在YARN之上，可以实现框架的资源统一管理和分配，使他们共享一个集群，而不是“一个框架一个集群”，这可大大降低运维成本和硬件成本。
如果你还没有意识到当前已经进入多计算框架纵横捭阖的新时代，那让我来给你细数一下当前出现的，已小有名气的计算框架吧：
1） MapReduce: 这个框架人人皆知，它是一种离线计算框架，将一个算法抽象成Map和Reduce两个阶段进行处理，非常适合数据密集型计算。
2） Spark: 我们知道，MapReduce计算框架不适合（不是不能做，是不适合，效率太低）迭代计算（常见于machine learning领域，比如PageRank）和交互式计算（data mining领域，比如SQL查询），MapReduce是一种磁盘计算框架，而Spark则是一种内存计算框架，它将数据尽可能放到内存中以提高迭代应用和交互式应用的计算效率。官方首页：http://spark-project.org/
3） Storm: MapReduce也不适合进行流式计算、实时分析，比如广告点击计算等，而Storm则更擅长这种计算、它在实时性要远远好于MapReduce计算框架。官方首页：http://storm-project.net/
4） S4: Yahoo开发的流式计算框架，与Storm较为类似。官方首页：http://incubator.apache.org/s4/
5） Open MPI: 非常经典的消息处理框架，非常适合高性能计算，现在仍被广泛使用。
6） HAMA: 基于BSP（bulk-synchronous parallel model）模型的分布式计算框架，与Google的Pregel类似，可用于大规模科学计算，如矩阵，图算法，网络算法等，官方首页：http://hama.apache.org/。
7） Cloudera Impala/ Apache Drill: 基于Hadoop的更快的SQL查询引擎（比Hive快得多），Google Dremel的模仿者。Cloudera Impala官方首页：https://github.com/cloudera/impala，Apache Drill官方首页：http://incubator.apache.org/drill/
8） Giraph：图算法处理框架，采用BSP模型，可用于计算pagerank，shared connections, personalization-based popularity等迭代类算法。官方首页：http://giraph.apache.org/
上面很多框架正在或正准备往YARN上迁移，具体见：http://wiki.apache.org/hadoop/PoweredByYarn/
（3） 框架升级更容易
在YARN中，各种计算框架不再是作为一个服务部署到集群的各个节点上（比如MapReduce框架，不再需要部署JobTracler、TaskTracker等服务），而是被封装成一个用户程序库（lib）存放在客户端，当需要对计算框架进行升级时，只需升级用户程序库即可，多么容易！
总结
YARN是在Hadoop 1.0基础上衍化而来的，它具有比Hadoop 1.0更为先进的理念和思想，它充分吸取了Hadoop 1.0的优势，但同时增加了很多新的特性和改进点。即使你不使用YARN，研究YARN对于改进你们当前Hadoop版本仍有巨大的帮助。
需要说明的是，YARN是一个崭新的系统，它完全不同于Hadoop 1.0。对于一般公司而言，将旧Hadoop系统往YARN上移植将是一件十分困难的事情，因为不同公司对内部Hadoop进行了或多或少的改造，这些改造或许已经不再兼容于主流的Hadoop版本。当向YARN升级时，你需要对兼容性进行充分的测试，以确保当前运行的作业仍可以正常地运行在移植后的系统上。 另外，需要引起注意的是，YARN会给运维人员带来巨大的麻烦，毕竟它是一个新系统。
当然，当前YARN还不成熟，仍处于高速酝酿阶段，讨论如何在线上使用它仍为时过早。不过，开始研究和学习它，作为一名有进取心和前瞻眼光的hadoopor，仍是十分必要的。
转自：http://dongxicheng.org/mapreduce-nextgen/what-can-we-benifit-from-yarn/
二、Yet Another Resource Negotiator 简介
大数据不断在演变，因而它的处理框架也在不断演变。Apache Hadoop 于 2005 年推出，提供了核心的 MapReduce 处理引擎来支持大规模数据工作负载的分布式处理。7 年后的今天，Hadoop 正在经历着一次彻底检查。通过这次检查，得到了一个更加通用的 Hadoop 框架，不仅支持 MapReduce，还支持其他分布式处理模型。本文介绍全新的 Hadoop 架构，并确定您在切换到该架构之前需要知道的信息。
带有 MapReduce 的 Apache Hadoop 是分布式数据处理的骨干力量。借助其独特的横向扩展物理集群架构和由 Google 最初开发的精细处理框架，Hadoop 在大数据处理的全新领域迎来了爆炸式增长。Hadoop 还开发了一个丰富多样的应用程序生态系统，包括 Apache Pig（一种强大的脚本语言）和 Apache Hive（一个具有类似 SQL 界面的数据仓库解决方案）。
不幸的是，这个生态系统构建于一种编程模式之上，无法解决大数据中的所有问题。MapReduce 提供了一种特定的编程模型，尽管已通过 Pig 和 Hive 等工具得到了简化，但它不是大数据的灵丹妙药。我们首先介绍一下 MapReduce 2.0 (MRv2) — 或 Yet Another Resource Negotiator (YARN) — 并快速回顾一下 YARN 之前的 Hadoop 架构。
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 的新架构
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 相对于 MRv1 的效率提升，可考虑蛮力测试旧版本的 LAN Manager Hash 的并行问题，这是旧版 Windows® 用于密码散列运算的典型方法。在此场景中，MapReduce 方法没有多大意义，因为 Mapping/Reducing 阶段涉及到太多开销。相反，更合理的方法是抽象化作业分配，以便每个容器拥有密码搜索空间的一部分，在其之上进行枚举，并通知您是否找到了正确的密码。这里的重点是，密码将通过一个函数来动态确定（这确实有点棘手），而不需要将所有可能性映射到一个数据结构中，这就使得 MapReduce 风格显得不必要且不实用。
归结而言，MRv1 框架下的问题仅是需要一个关联数组，而且这些问题有专门朝大数据操作方向演变的倾向。但是，问题一定不会永远仅局限于此范式中，因为您现在可以更为简单地将它们抽象化，编写自定义客户端、应用程序主程序，以及符合任何您想要的设计的应用程序。
开发 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 脚本作为其配置服务。
下一步计划
尽管 Hadoop 继续在大数据市场中发展，但它已开始了一场演变，以解决有待定义的大规模数据工作负载。YARN 仍然在积极发展且可能不适合生产环境，但 YARN 相对传统的 MapReduce 而言提供了重要优势。它允许开发 MapReduce 之外的新分布式应用程序，允许它们彼此同时共存于同一个集群中。YARN 构建于当前 Hadoop 集群的现有元素之上，但也改进了 JobTracker 等元素，可以提高可伸缩性和增强许多不同应用程序共享集群的能力。YARN 很快会来到您近旁的 Hadoop 集群中，带来它的全新功能和新复杂性。
转自：http://www.ibm.com/developerworks/cn/data/library/bd-hadoopyarn/