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

[[243598]]

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時期出現的眾多組件形成了良好的互補合作模式，這一點是毋庸置疑的。