Hadoop生態系統各元件與Yarn的相容性如何？

作為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（）的專案中，最重要的變化涉及繞過MapReduce並使用Tez（一個Yarn DAG處理框架）來執行工作。Apache Drill是另一個SQL-on-Hadoop解決方案，它承諾能夠處理許多永續性儲存問題，例如Cassandra和MongoDB（）。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叢集提供彈性，幫助其快速配置額外資源。有關該專案的更多詳細資訊，請訪問。

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中的工作（），完成此項整合工作的專案是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時期出現的眾多元件形成了良好的互補合作模式，這一點是毋庸置疑的。

相關文章：

1、《第一章：Hadoop生態系統及執行MapReduce任務介紹！》連結： http://blog.itpub.net/31077337/viewspace-2213549/

2、《學習Hadoop生態第一步：Yarn基本原理和資源排程解析！》連結： http://blog.itpub.net/31077337/viewspace-2213602/

3、《MapReduce如何作為Yarn應用程式執行？》連結： http://blog.itpub.net/31077337/viewspace-2213676/