張怡 譯 分布式實驗室
Hadoop 2.0之後把對叢集資源的管理從MapReduce v1的JobTracker中提取出來，在YARN中進行了實作。雖然YARN支援了多種不同的計算架構，但依舊沒有很好的解決叢集資源的彈性伸縮問題。本文介紹了一個新的項目- Myriad，它把YARN和Mesos兩者的優勢結合起來，不僅使YARN的運作使用更加靈活，而且讓整個資料中心的擴容變得更簡單。
這是一個關于兩個叢集的故事。第一個是Apache Hadoop叢集，其中資源與Hadoop以及程序完全隔離。另一個叢集是對所有資源的描述，這些資源并不是Hadoop叢集的一部分。通過這種方式來區分兩個叢集是因為Hadoop通過Apache YARN（Yet Another Resource Negotiator）來管理自己的資源。對于Hadoop來說，在沒有大資料任務在隊列中時，這些資源常常是未被充分使用的。當一個大資料任務運作時，這些資源迅速被用到極限，并且在請求更多資源。這對于第一種叢集而言相當困難。
盡管Hadoop有意打算消除資料壁壘，但是在拆去一些壁壘的同時，其他類型的壁壘又在同樣的地方産生。作為另一種技術方案，Apache Mesos也有意消除這些壁壘。但Mesos常被用來管理第二種叢集，這些叢集包括除去Hadoop任務之外的所有資源。
前面介紹的關于Mesos和YARN的不同點，隻是故事的開端。正如它們并不相容，經常互相競争。而我的故事，講的卻是它們協同工作。
Mesos和YARN的簡介
Mesos和YARN之間的主要差別圍繞着優先級的設計以及排程任務的方式。Mesos于2007年誕生于UC Berkeley并在Twitter和Airbnb等公司的商用下不斷被鞏固，它的設計初衷是作為整個資料中心的一個可拓展的全局資料總管。YARN出于管理Hadoop規模的需求。在YARN出現之前，資源管理（功能）內建在Hadoop MapReduce V1架構中，為了有助于MapReduce的擴充而将其移除（轉移到YARN中實作）。MapReduce的Job Tracker并不能在超過上千台的機器中有效排程MapReduce任務。YARN在下一代Hadoop生命周期中被創造，主要圍繞着資源拓展。
Mesos的排程
Mesos決定了哪些資源可用，它把配置設定請求傳回給一個應用排程器（應用排程器和執行器被稱作“架構”）。這些配置設定請求被架構接受或者拒絕。這個模型被認為是非單體模型，因為它是一個“兩級”排程器，排程算法是可拔插的。Mesos允許任何實作任何排程算法，每個算法都能根據自己的政策進行接收或是拒絕配置設定請求，并且可以容納成千上萬種排程程式以多租戶的方式運作在同一個叢集。
Mesos的兩級排程模型允許每個架構（自己）決定使用哪種算法來排程運作的工作。Mesos扮演仲裁者，在多個排程器上來排程資源，解決沖突，并且確定資源基于業務政策被公平地分發。配置設定請求到來時，架構會執行任務來消費那些提供的資源。或者架構可以選擇拒絕請求并且等待下一個配置設定請求。這種模型與在一台筆記本電腦或智能手機上如何同時運作多個App十分類似，當需要更多記憶體時會建立新的線程或請求，作業系統來仲裁管理所有的請求。多年的作業系統和分布式系統的實踐發展證明，這種模型的好處在于它具有良好的擴充性。它已被Google和Twitter證明。
YARN的排程
現在，我們再看一下YARN這邊發生了什麼。當job請求到達YARN資料總管，YARN評估所有可用的資源然後排程job。YARN以一種整體的方式，直接決定job運作的位置。在MapReduce架構演變的過程中，重申強調YARN的出現十分重要。在Hadoop任務的資源規模伸縮需求的驅動下，YARN把資源管理的模型從MR的Job Tracker中獨立出來，在Resources Manager元件中實作。
為了排程Hadoop任務，YARN進行了優化（過去一貫的Hadoop任務是持續一段時間的批處理任務）。這意味着YRAN既不是為長時間運作的服務而設計，也不是為滿足短期互動/快速響應式請求（像簡短而快速的Spark任務），盡管它可能排程其他種類的工作任務，但這并不是一個理想的模型。MapReduce的資源需求、執行模型和架構需求不同于長時間運作的服務，如Web伺服器、SOA應用程式或是像Spark和Storm那樣的實時任務。同時，YARN為了易于無狀态的腳本任務重新開機而設計。它并不能處理像分布式檔案系統或資料庫那樣的有狀态的服務。然而YARN的整體的排程器理論上可以處理不同類型的工作負載（通過把新的算法合并到排程代碼），對于支援日益複雜的排程算法，這并不是一個輕量級的模型。
在對比YARN和Mesos時，明白整體的排程能力和為什麼需要兩者選一十分重要。雖然有些人可能認為YARN和Mesos大同小異，但并非如此。差別在于使用者一開始使用時需求模型的不同。每種模型沒有明确地錯誤，但每種方法會産出不同的長期結果。我認為這就是選擇如何使用它們的關鍵。Ben Hindman和Berkeley AMP實驗室在設計Mesos時，與Google設計Omega的團隊同期進行，Mesos系統得益于Google的Omega系統設計的經驗，建構了一個更好的非單體（兩階段）的排程器。
當你把如何管理資料中心作為整體來評估時，一方面使用Mesos來管理資料中心的所有資源，另一方面使用YARN來安全的管理Hadoop任務，但它并不具有管理整個資料中心的能力。資料中心營運商傾向于把叢集劃分為的不同區域（Hadoop叢集和非Hadoop叢集）來應對這兩個場景。
在同一個資料中心使用Mesos和YARN，為了受益于資料總管，目前需要建立兩個靜态分區。此時意味着當指定資源被Hadoop的YARN管理時，Mesos就無法起作用。這也許過于簡化了，盡管這麼做确實有效。但本質上，我們是想避免這種情況。
項目Myriad介紹
這不禁讓我們發問：能否讓企業和資料中心受益于YARN和Mesos的協調工作？答案是肯定的。一些著名的公司——eBay、MapR和Mesosphere共同合作了一個項目叫做Myriad。