作為Hadoop 2.0中出現(xiàn)的資源管理系統(tǒng)，Yarn總體上仍然是master/slave結(jié)構(gòu)，在整個(gè)資源管理框架中，resourcemanager為master，nodemanager是slave。作為Hadoop生態(tài)系統(tǒng)的一部分，Yarn要想獲得市場(chǎng)認(rèn)可，必須學(xué)會(huì)與Hadoop生他系統(tǒng)中其他組件兼容。本文作為《Hadoop從入門到精通》大型專題的第二章第三節(jié)，主要介紹了Yarn如何與Hadoop生態(tài)系統(tǒng)中其他組件配合，這也是本專題有關(guān)Yarn概念的***一節(jié)，如果你想了解更多關(guān)于Yarn的具體信息，可以訪問本專題的其他文章，詳見文末。

[[243598]]

2.3 Yarn應(yīng)用程序

隨著時(shí)間的推移，我們已經(jīng)看到了Yarn生態(tài)系統(tǒng)的快速增長(zhǎng)。如今，我們生活在多數(shù)據(jù)中心運(yùn)行多個(gè)不同系統(tǒng)的世界，如圖2.13所示。所有系統(tǒng)都有其存在的價(jià)值，但對(duì)系統(tǒng)管理員和架構(gòu)師帶來了***的挑戰(zhàn)，他們需要支持這些系統(tǒng)并保證它們正常運(yùn)轉(zhuǎn)，系統(tǒng)之間的數(shù)據(jù)交換成本昂貴且復(fù)雜，每個(gè)系統(tǒng)都必須解決相同的分布式問題，例如容錯(cuò)、分布式存儲(chǔ)、日志處理以及資源調(diào)度等。

圖2.13

既然身在Hadoop生態(tài)之中，Yarn團(tuán)隊(duì)也為其融入整個(gè)生態(tài)和企業(yè)技術(shù)架構(gòu)做出了很多努力，Yarn目前已經(jīng)可以和多類組件或應(yīng)用實(shí)現(xiàn)兼容。比如，Hoya的出現(xiàn)讓HBase可以運(yùn)行在Yarn之上，可靈活得將數(shù)據(jù)移入和移出， Hoya與Yarn集成也可以提供彈性按需計(jì)算，在單個(gè)Yarn集群可運(yùn)行多個(gè)HBase集群。

2.3.1 NoSQL

對(duì)于NoSQL的概念，此處就不在贅述了，簡(jiǎn)而言之，這是不遵循ACID原則的實(shí)時(shí)CRUD操作系統(tǒng)。NoSQL的出現(xiàn)是為了解決單片OLAP系統(tǒng)的缺點(diǎn)，因?yàn)槠渥璧K了系統(tǒng)架構(gòu)擴(kuò)展和提供響應(yīng)服務(wù)的能力。雖然存在很多NoSQL系統(tǒng)，但沒有任何一個(gè)系統(tǒng)與Hadoop的集成比HBase更多。在Yarn出現(xiàn)之前，HBase的目標(biāo)是使用HDFS進(jìn)行存儲(chǔ)，并從與MapReduce的緊密集成中受益，批量處理功能的加入讓其得以超越競(jìng)爭(zhēng)對(duì)手。但是，Yarn為HBase解決了兩大挑戰(zhàn)，一是HBase和MapReduce共存于集群上帶來的資源管理方面的挑戰(zhàn)，因?yàn)闆]有簡(jiǎn)單的方法來保證兩個(gè)系統(tǒng)的SLA，Yarn利用Linux中cgroups提供的并發(fā)執(zhí)行進(jìn)程，保證訪問所需資源。二是Yarn讓HBase能夠在同一個(gè)Hadoop集群上運(yùn)行多個(gè)HBase集群，這就是上文提到的Hoya項(xiàng)目。

2.3.2 SQL on Hadoop

SQL on Hadoop無疑是目前的熱門研究方向。在Hadoop上也可運(yùn)行SQL，比如啟動(dòng)Hive shell，輸入查詢并等待幾分鐘之后，或許就可以得到結(jié)果，但這對(duì)于數(shù)據(jù)科學(xué)家或者分析師快速探測(cè)和試驗(yàn)數(shù)據(jù)來說，不是一個(gè)有利的環(huán)境。Cloudera的解決方案是創(chuàng)建Impala項(xiàng)目，該項(xiàng)目完全繞過MapReduce，并通過集群中的每個(gè)從節(jié)點(diǎn)運(yùn)行守護(hù)進(jìn)程。為了幫助Yarn集群實(shí)現(xiàn)多租戶，Cloudera開發(fā)了Llama，旨在讓Yarn了解Impala守護(hù)進(jìn)程正在利用的集群資源。Hortonworks的策略是專注于對(duì)Hive進(jìn)行改進(jìn)，并在使Hive更具互動(dòng)性方面邁出重要的一步，其團(tuán)隊(duì)將這些改進(jìn)結(jié)合在了一個(gè)名為Stinger(http://hortonworks.com/labs/stinger/)的項(xiàng)目中，最重要的變化涉及繞過MapReduce并使用Tez(一個(gè)Yarn DAG處理框架)來執(zhí)行工作。

Apache Drill是另一個(gè)SQL-on-Hadoop解決方案，它承諾能夠處理許多持久性存儲(chǔ)問題，例如Cassandra和MongoDB(https://issues.apache.org/jira/browse/DRILL-142)。Facebook Presto也在SQL-on-Hadoop陣營(yíng)，但其不像Spark那樣默認(rèn)支持Yarn，Spark與Yarn兼容性很好， 只需要簡(jiǎn)單配置就可啟動(dòng)腳本，集群環(huán)境就可在Yarn上運(yùn)行Spark任務(wù)。Presto則需要借助于slider，通過slider實(shí)現(xiàn)Prestoon Yarn。

2.3.3 圖形處理

現(xiàn)代圖形處理系統(tǒng)允許分布式圖形算法針對(duì)包含數(shù)十億個(gè)節(jié)點(diǎn)和數(shù)萬億個(gè)邊緣的大規(guī)模圖像執(zhí)行。使用傳統(tǒng)MapReduce圖形操作需要在每次迭代時(shí)將整個(gè)圖形數(shù)據(jù)結(jié)構(gòu)序列化到磁盤并從磁盤序列化，整個(gè)過程繁瑣而麻煩。Apache Giraph是一個(gè)流行的圖形處理項(xiàng)目，自版本1及更早版本以來一直致力于Hadoop，并且提交者還更新了Giraph，以便作為本機(jī)Yarn應(yīng)用程序運(yùn)行，Apache Hama在Yarn上也有一些圖形處理功能。

2.3.4 實(shí)時(shí)數(shù)據(jù)處理

實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)是處理***數(shù)據(jù)流的計(jì)算系統(tǒng)。這些系統(tǒng)的功能類似于MapReduce，因?yàn)樵试S處理諸如過濾、投影、連接和聚合等操作。這些系統(tǒng)的典型用途是處理系統(tǒng)中發(fā)生的實(shí)時(shí)事件，執(zhí)行聚合，然后將結(jié)果推送到NoSQL以供其他系統(tǒng)檢索。目前比較常用的幾大實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)有Apache Storm、Spark Streaming等，在Spark Streaming流行之前，Storm幾乎統(tǒng)治了整個(gè)流式計(jì)算江湖，其最初由Nathan Marz構(gòu)建，為了將Storm帶到Y(jié)arn，雅虎創(chuàng)建了一個(gè)名為Storm-Yarn的項(xiàng)目，其不僅可以讓多個(gè)Storm集群在Yarn上運(yùn)行，而且可以為Storm集群提供彈性，幫助其快速配置額外資源。有關(guān)該項(xiàng)目的更多詳細(xì)信息，請(qǐng)?jiān)L問https://github.com/yahoo/storm-yarn。

Spark Streaming作為Spark API的擴(kuò)展而開發(fā)，支持消費(fèi)數(shù)據(jù)源，比如HDFS，Kafka，F(xiàn)lume等。Yarn也支持Spark，并且如果掌握了Spark，你會(huì)很容易知道如何用Spark Streaming，反之亦然，這意味著可以使用單一編程范例進(jìn)行離線和實(shí)時(shí)數(shù)據(jù)分析。其他與Yarn集成的實(shí)時(shí)數(shù)據(jù)處理系統(tǒng)還有Apache S4，Apache Samza(來自LinkedIn)和DataTorrent。

2.3.5 批量處理

批量同步并行(BSP)是一種分布式處理方法，多個(gè)并行工作者獨(dú)立處理整個(gè)問題的子集，然后彼此交換數(shù)據(jù)，使用全局同步機(jī)制等待所有工作者在重復(fù)該過程之前完成，Apache Giraph使用類似的BSP模型進(jìn)行圖形迭代，Apache Hama則是一個(gè)可以在Yarn上運(yùn)行的通用BSP實(shí)現(xiàn)，具有內(nèi)置圖形處理功能。

2.3.6 MPI

MPI(消息傳遞接口)是一種允許在主機(jī)集群上交換消息的機(jī)制，Open MPI是一個(gè)開源MPI實(shí)現(xiàn)。目前有一個(gè)開源項(xiàng)目可以完成將Open MPI支持集成到Hadoop中的工作(https://issues.apache.org/jira/browse/MAPREDUCE-2911)，完成此項(xiàng)集成工作的項(xiàng)目是mpich2-Yarn(詳情可訪問：https://github.com/alibaba/mpich2-yarn)。

2.3.7內(nèi)存計(jì)算

內(nèi)存計(jì)算使用系統(tǒng)中不斷增加的內(nèi)存占用快速執(zhí)行迭代處理和交互式數(shù)據(jù)挖掘等活動(dòng)。Apache Spark是一個(gè)流行的項(xiàng)目，是整套解決方案的關(guān)鍵部分，還包括用于SQL操作的Shark和用于圖形處理的GraphX，Cloudera的CDH5發(fā)行包括在Yarn上運(yùn)行的Spark。

2.3.8 DAG

DAG執(zhí)行引擎允許將數(shù)據(jù)處理邏輯建模為DAG(有向無環(huán)圖)，然后在大型數(shù)據(jù)集上并行執(zhí)行。Apache Tez是DAG執(zhí)行引擎的一個(gè)例子，它產(chǎn)生于需要提供更通用的MapReduce系統(tǒng)，該系統(tǒng)保留了MapReduce的并行性和吞吐量，同時(shí)支持MapReduce提供的額外處理模型和優(yōu)化。Tez的功能示例包括不強(qiáng)加特定的數(shù)據(jù)模型，因此可以支持MapReduce的鍵/值模型以及Hive和Pig的基于元組模型。

Tez提供了許多優(yōu)于MapReduce的優(yōu)勢(shì)，其中包括消除MapReduce中多個(gè)作業(yè)之間存在的復(fù)寫障礙——這是Hive和Pig等系統(tǒng)的主要性能瓶頸。Tez中的應(yīng)用程序不需要排序，可減少M(fèi)apReduce中的排序開銷，從而產(chǎn)生更高效的管道。Tez還支持復(fù)雜操作，比如Map-Map-Reduce或任意操作圖，開發(fā)人員能夠更自然地表達(dá)他們的管道。Tez還可用于在執(zhí)行時(shí)選擇動(dòng)態(tài)數(shù)據(jù)流，例如，根據(jù)流中數(shù)據(jù)大小決定將其存儲(chǔ)在內(nèi)存、HDFS或本地磁盤中。

2.4 結(jié)語

Hadoop整個(gè)生態(tài)自Hadoop 2.0版本出現(xiàn)之后發(fā)生了巨大的改變，彌補(bǔ)了Hadoop 1.0中的諸多不足。在Hadoop 3.0及之后的幾次小版本迭代中，Yarn在時(shí)間軸服務(wù)方面進(jìn)行了升級(jí)，提高了時(shí)間軸服務(wù)的可伸縮性和可靠性，并通過引入流量和聚合來提高可用性。雖然不再像Hadoop 1.0時(shí)期依靠MapReduce完成大量工作，Yarn已經(jīng)與Hadoop 1.0時(shí)期出現(xiàn)的眾多組件形成了良好的互補(bǔ)合作模式，這一點(diǎn)是毋庸置疑的。