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。