Myriad開始由eBay、MapR和 Mesosphere合作了一個新項目，之後又把這個項目轉交給了Mesos，“Project development has moved to: https://github.com/mesos/myriad.”再之後又把它移交給了Apache，真是項目大遷移啊！
一、介紹Myriad（從概念理解Myriad）
Myriad名字的意思是無數或及其很大的數字。
以下由github官網截取過來的，翻譯水平有限哪個有錯還請多多指教。
1、Myriad is a Mesos framework designed for scaling a YARN cluster on Mesos.
1、Myriad是爲在Mesos上擴展YARN集羣而設計的Mesos框架。
2、Myriad can expand or shrink the resources managed by a YARN cluster in response to events as per configured rules and policies.
2、Myriad可以針對每一項配置的規則和策略來擴展或縮放資源由YARN集羣管理。
本人理解Myriad和其作用：
它是Mesos框架和YARN調度器的結合，它使得Mesos可以管理YARN的資源請求。當YARN中有作業請求資源時，YARN的資源管理器會先通過Myriad的調度器來調度，這樣就可以和Mesos的資源申請和提供匹配起來。Mesos Master接下來會把調度請求發給Mesos的工作節點（Mesos Slave）。Mesos的工作節點會和Myriad的執行器（executor）進行通信併發送請求， Myriad執行器的作用是運行YARN的節點管理器（Node Manager）。當Myriad在Mesos分配的資源上加載YARN節點管理器後，YARN節點管理器就會和YARN的資源管理器通信來確定作業可用的資源。YARN可以以自己認爲適合的方法來使用資源，Myriad則在Mesos可用的資源池和YARN的有資源需求的任務間提供了無縫的橋樑。
這種做法的優點是，它不僅讓你在共享的集羣中彈性的使用YARN，使得YARN比最初設計時更具活力和彈性。而且，它使得數據中心的運維團隊在給YARN資源擴容時無需重新配置YARN集羣。整個數據中心的擴容變得十分容易。該模型提供了一種簡單的方式運行和管理多個YARN的實現，甚至在同一個集羣上運行多個不同版本的YARN。
Myriad使得在使用Mesos時，資源利用和跨數據中心的資源管理得以統一。在這種情況下，YARN的工作負載是運行在共享的集羣上，相比獨立的YARN集羣來說，更加動態和彈性。這個方法也使得數據中心維護團隊可以擴展其資源以供給YARN（或者，從YARN拿走）而無須去重新配置集羣。
二、Myriad的由來
當下比較火的兩個資源統一管理與調度平臺YARN與Mesos，比較他們兩個的文字有很多在此就不多說其各異了。我只分下一個使用的場景：
YRAN：當一個作業請求提交到YARN的資源管理器，YARN會對可用的資源進行評估，並放置作業到相應的位置。這事一個作業應該去哪兒的決定。YARN並不是爲長時間服務，或者短生命週期的交互式查詢來設計的，雖然有可能讓YARN去調度其它這些工作負載，但顯然這不是個理想的模型。在沒有大數據任務在隊列中時，這些資源常常是未被充分使用的。當一個大數據任務運行時，這些資源迅速被用到極限，並且在請求更多資源。
Mesos：利用了兩級調度機制，即資源的請求和提供是針對框架而不是作業，可以把框架視爲在Mesos上面運行的應用。Mesos的master節點決策提供每個框架多少資源，每個框架接着決策它能接受的資源申請以及哪種應用可以在這些資源上運行。當集羣中的節點共享多個框架時，這種資源分配方法可以獲得近似最佳的數據本地化（data locality）。
當你把如何管理數據中心作爲整體來評估時，一方面使用Mesos來管理數據中心的所有資源，另一方面使用YARN來安全的管理Hadoop任務，但它並不具有管理整個數據中心的能力。數據中心運營商傾向於把集羣劃分爲的不同區域（Hadoop集羣和非Hadoop集羣）來應對這兩個場景。
在同一個數據中心使用Mesos和YARN，爲了受益於資源管理器，目前需要創建兩個靜態分區。此時意味着當指定資源被Hadoop的YARN管理時，Mesos就無法起作用。這也許過於簡化了，儘管這麼做確實有效。但本質上，我們是想避免這種情況。
能否讓企業和數據中心受益於YARN和Mesos的協調工作？答案是Myriad。