关于Apache Mesos的一些想法
我关注Apache Mesos很长时间了。Apache Mesos从研究论文开始,2010年成为Apache孵化项目,后来从ASF“毕业”,并于2013年建立商业实体Mesosphere。
过去的几个月,发生了许多事,因此我想,这是个好机会来写写关于Mesos和其生态的文章。
关于Mesos和YARN已经有很多讨论了。我也看到过诸如“Mesos的资源请求模型非常落后”的评论,也注意到Mesos在过去几年变得更加流行。这里的关键因素之一也许是Docker天花乱坠般的宣传以及各自对于协作层的需要。在本篇的末尾,我们会再一次回到Mesos vs. YARN的话题。
我承认之前自己并没有完全理解Mesos的真正潜力,直到那天坐着读完Mesos研究论文,它包括设计哲学、资源分配、隔离保证和容错。
Mesos应对的核心挑战是,在不了解一个框架的前提下如何满足对框架的 约束(constraints),这也是资源分配中最难以理解的地方。Mesos处理资源的方式就像家长主持一个孩子的生日派对:好比你要为15个孩子 (==框架)提供食物(==资源),并且不可能知道他们的喜好(==安置倾向)。但你可以提供给他们一块披萨或者一碗芝麻菜,并且他们可以免费接受(现在 或一会之后)或者拒绝。而且,刚接一位客人下车的爸爸也许会告诉你,那人的小孩是素食主义者,那么提供牛肉汉堡(==过滤物)给那个小孩就说不通了。
有一个有趣的事实(虽然我认为这是公知的),Mesos和Spark有一个共同点:Matei Zaharia——来自一个靠近加拿大安大略的小镇——他是加州伯克利分校AMP实验室的学生,这个实验室为Mesos和Spark都做了巨大贡献。最近,他出任Databricks的CTO,Databricks是一家指导Spark的商业实体公司。
回到Mesos vs. YARN——幸运的是最近这不再是一个二选一的问题了:使用Myriad项目(由 eBay、Mesosphere和MapR的共同开发,现在交由ASF孵化),你可以让它们在集群中共存并调度它们。简而言之,是一个Mesos框架用来 动态扩展YARN集群,并支持运行Hadoop应用,如Spark和非Hadoop应用,如Node.js、Memcached、RoR等。激动人心的时 刻!
这就是我个人对于Apache Mesos的看法,写于2015年二月中旬。我会继续关注Myriad,作为初学者的你如果还未尝试,或许你可以试试测试驱动Mesos。
原文:https://medium.com/large-scale-data-processing/thoughts-on-apache-mesos-1e1d48270665译文:http://dockerone.com/article/211 译者: 孙科