作为Hadoop 2.0中出现的资源管理系统，Yarn总体上仍然是master/slave结构，在整个资源管理框架中，resourcemanager为master，nodemanager是slave。作为Hadoop生态系统的一部分，Yarn要想获得市场认可，必须学会与Hadoop生他系统中其他组件兼容。本文作为《Hadoop从入门到精通》大型专题的第二章第三节，主要介绍了Yarn如何与Hadoop生态系统中其他组件配合，这也是本专题有关Yarn概念的***一节，如果你想了解更多关于Yarn的具体信息，可以访问本专题的其他文章，详见文末。
2.3 Yarn应用程序
随着时间的推移，我们已经看到了Yarn生态系统的快速增长。如今，我们生活在多数据中心运行多个不同系统的世界，如图2.13所示。所有系统都有其存在的价值，但对系统管理员和架构师带来了***的挑战，他们需要支持这些系统并保证它们正常运转，系统之间的数据交换成本昂贵且复杂，每个系统都必须解决相同的分布式问题，例如容错、分布式存储、日志处理以及资源调度等。
图2.13
既然身在Hadoop生态之中，Yarn团队也为其融入整个生态和企业技术架构做出了很多努力，Yarn目前已经可以和多类组件或应用实现兼容。比如，Hoya的出现让HBase可以运行在Yarn之上，可灵活得将数据移入和移出， Hoya与Yarn集成也可以提供弹性按需计算，在单个Yarn集群可运行多个HBase集群。
2.3.1 NoSQL
对于NoSQL的概念，此处就不在赘述了，简而言之，这是不遵循ACID原则的实时CRUD操作系统。NoSQL的出现是为了解决单片OLAP系统的缺点，因为其阻碍了系统架构扩展和提供响应服务的能力。虽然存在很多NoSQL系统，但没有任何一个系统与Hadoop的集成比HBase更多。在Yarn出现之前，HBase的目标是使用HDFS进行存储，并从与MapReduce的紧密集成中受益，批量处理功能的加入让其得以超越竞争对手。但是，Yarn为HBase解决了两大挑战，一是HBase和MapReduce共存于集群上带来的资源管理方面的挑战，因为没有简单的方法来保证两个系统的SLA，Yarn利用Linux中cgroups提供的并发执行进程，保证访问所需资源。二是Yarn让HBase能够在同一个Hadoop集群上运行多个HBase集群，这就是上文提到的Hoya项目。
2.3.2 SQL on Hadoop
SQL on Hadoop无疑是目前的热门研究方向。在Hadoop上也可运行SQL，比如启动Hive shell，输入查询并等待几分钟之后，或许就可以得到结果，但这对于数据科学家或者分析师快速探测和试验数据来说，不是一个有利的环境。Cloudera的解决方案是创建Impala项目，该项目完全绕过MapReduce，并通过集群中的每个从节点运行守护进程。为了帮助Yarn集群实现多租户，Cloudera开发了Llama，旨在让Yarn了解Impala守护进程正在利用的集群资源。Hortonworks的策略是专注于对Hive进行改进，并在使Hive更具互动性方面迈出重要的一步，其团队将这些改进结合在了一个名为Stinger(http://hortonworks.com/labs/stinger/)的项目中，最重要的变化涉及绕过MapReduce并使用Tez(一个Yarn DAG处理框架)来执行工作。
Apache Drill是另一个SQL-on-Hadoop解决方案，它承诺能够处理许多持久性存储问题，例如Cassandra和MongoDB(https://issues.apache.org/jira/browse/DRILL-142)。Facebook Presto也在SQL-on-Hadoop阵营，但其不像Spark那样默认支持Yarn，Spark与Yarn兼容性很好， 只需要简单配置就可启动脚本，集群环境就可在Yarn上运行Spark任务。Presto则需要借助于slider，通过slider实现Prestoon Yarn。
2.3.3 图形处理
现代图形处理系统允许分布式图形算法针对包含数十亿个节点和数万亿个边缘的大规模图像执行。使用传统MapReduce图形操作需要在每次迭代时将整个图形数据结构序列化到磁盘并从磁盘序列化，整个过程繁琐而麻烦。Apache Giraph是一个流行的图形处理项目，自版本1及更早版本以来一直致力于Hadoop，并且提交者还更新了Giraph，以便作为本机Yarn应用程序运行，Apache Hama在Yarn上也有一些图形处理功能。
2.3.4 实时数据处理
实时数据处理系统是处理***数据流的计算系统。这些系统的功能类似于MapReduce，因为允许处理诸如过滤、投影、连接和聚合等操作。这些系统的典型用途是处理系统中发生的实时事件，执行聚合，然后将结果推送到NoSQL以供其他系统检索。目前比较常用的几大实时数据处理系统有Apache Storm、Spark Streaming等，在Spark Streaming流行之前，Storm几乎统治了整个流式计算江湖，其最初由Nathan Marz构建，为了将Storm带到Yarn，雅虎创建了一个名为Storm-Yarn的项目，其不仅可以让多个Storm集群在Yarn上运行，而且可以为Storm集群提供弹性，帮助其快速配置额外资源。有关该项目的更多详细信息，请访问https://github.com/yahoo/storm-yarn。
Spark Streaming作为Spark API的扩展而开发，支持消费数据源，比如HDFS，Kafka，Flume等。Yarn也支持Spark，并且如果掌握了Spark，你会很容易知道如何用Spark Streaming，反之亦然，这意味着可以使用单一编程范例进行离线和实时数据分析。其他与Yarn集成的实时数据处理系统还有Apache S4，Apache Samza(来自LinkedIn)和DataTorrent。
2.3.5 批量处理
批量同步并行(BSP)是一种分布式处理方法，多个并行工作者独立处理整个问题的子集，然后彼此交换数据，使用全局同步机制等待所有工作者在重复该过程之前完成，Apache Giraph使用类似的BSP模型进行图形迭代，Apache Hama则是一个可以在Yarn上运行的通用BSP实现，具有内置图形处理功能。
2.3.6 MPI
MPI(消息传递接口)是一种允许在主机集群上交换消息的机制，Open MPI是一个开源MPI实现。目前有一个开源项目可以完成将Open MPI支持集成到Hadoop中的工作(https://issues.apache.org/jira/browse/MAPREDUCE-2911)，完成此项集成工作的项目是mpich2-Yarn(详情可访问：https://github.com/alibaba/mpich2-yarn)。
2.3.7内存计算
内存计算使用系统中不断增加的内存占用快速执行迭代处理和交互式数据挖掘等活动。Apache Spark是一个流行的项目，是整套解决方案的关键部分，还包括用于SQL操作的Shark和用于图形处理的GraphX，Cloudera的CDH5发行包括在Yarn上运行的Spark。
2.3.8 DAG
DAG执行引擎允许将数据处理逻辑建模为DAG(有向无环图)，然后在大型数据集上并行执行。Apache Tez是DAG执行引擎的一个例子，它产生于需要提供更通用的MapReduce系统，该系统保留了MapReduce的并行性和吞吐量，同时支持MapReduce提供的额外处理模型和优化。Tez的功能示例包括不强加特定的数据模型，因此可以支持MapReduce的键/值模型以及Hive和Pig的基于元组模型。
Tez提供了许多优于MapReduce的优势，其中包括消除MapReduce中多个作业之间存在的复写障碍——这是Hive和Pig等系统的主要性能瓶颈。Tez中的应用程序不需要排序，可减少MapReduce中的排序开销，从而产生更高效的管道。Tez还支持复杂操作，比如Map-Map-Reduce或任意操作图，开发人员能够更自然地表达他们的管道。Tez还可用于在执行时选择动态数据流，例如，根据流中数据大小决定将其存储在内存、HDFS或本地磁盘中。
2.4 结语
Hadoop整个生态自Hadoop 2.0版本出现之后发生了巨大的改变，弥补了Hadoop 1.0中的诸多不足。在Hadoop 3.0及之后的几次小版本迭代中，Yarn在时间轴服务方面进行了升级，提高了时间轴服务的可伸缩性和可靠性，并通过引入流量和聚合来提高可用性。虽然不再像Hadoop 1.0时期依靠MapReduce完成大量工作，Yarn已经与Hadoop 1.0时期出现的众多组件形成了良好的互补合作模式，这一点是毋庸置疑的。
