Mesos和YARN的区别以及它们如何协同和共同的区别工作

Spark有三种集群部署模式或者叫做集群管理模式。分别是standaloneYARN和Mesos。这三种模式其实都是master/slave模式

那么在实际的项目中,我们该如何对比选择呢?下面是我的一些总结主要参考了:

作为Spark的一部分,Standalone是一个简单的集群管理器。它具有master的HA弹性应对WorkerFailures,对每个应用程序的管理资源的能力并且可以在现有的Hadoop一起运行和访问HDFS嘚数据。该发行版包括一些脚本可以很容易地部署在本地或在AmazonEC2云计算。它可以在LinuxWindows或Mac OSX上运行。欢迎加入大数据学习交流分享群:

Mesos的资源調度能力描述

Mode):每个应用程序的运行环境由一个Dirver和若干个Executor组成其中,每个Executor占用若干资源内部可运行多个Task(对应多少个“slot”)。应用程序的各个任务正式运行之前需要将运行环境中的资源全部申请好,且运行过程中要一直占用这些资源即使不用,最后程序运行结束后回收这些资源。举个例子比如你提交应用程序时,指定使用5个executor运行你的应用程序每个executor占用5GB内存和5个CPU,每个executor内部设置了5个slot则Mesos需要先为executor分配资源并启动它们,之后开始调度任务另外,在程序运行过程中mesos的master和slave并不知道executor内部各个task的运行情况,executor直接将任务状态通过内部的通信機制汇报给Driver从一定程度上可以认为,每个应用程序利用mesos搭建了一个虚拟集群自己使用

Mesos还提供了另外一种调度模式:细粒度模式,这种模式类似于现在的云计算思想是按需分配。与粗粒度模式一样应用程序启动时,先会启动executor但每个executor占用资源仅仅是自己运行所需的资源,不需要考虑将来要运行的任务之后,mesos会为每个executor动态分配资源每分配一些,便可以运行一个新任务单个Task运行完之后可以马上释放對应的资源。每个Task会汇报状态给Mesos slave和Mesos Master便于更加细粒度管理和容错,这种调度模式类似于MapReduce调度模式每个Task完全独立,优点是便于资源控制和隔离但缺点也很明显,短作业运行延迟大

从对比上看,mesos似乎是Spark更好的选择也是被官方推荐的。欢迎加入大数据学习交流分享群:    一起吹水交流学习

但如果你同时运行hadoop和Spark,从兼容性上考虑Yarn似乎是更好的选择,毕竟是亲生的Spark on Yarn运行的也不错。

如果你不仅运行了hadoopspark。还在资源管理上运行了dockerMesos似乎更加通用。

standalone小规模计算集群似乎更适合!

感谢您的观看,如有不足之处欢迎批评指正。

如果有对大数据感兴趣的尛伙伴或者是从事大数据的老司机可以加群:

里面整理了一大份学习资料全都是些干货,包括大数据技术入门海量数据高级分析语言,海量数据存储分布式存储以及海量数据分析分布式计算等部分,送给每一位大数据小伙伴这里不止是小白聚集地,还有大牛在线解答!欢迎初学和进阶中的小伙伴一起进群学习交流共同进步!

最后祝福所有遇到瓶颈的大数据程序员们突破自己,祝福大家在往后的工莋与面试中一切顺利

1、最大的不同点在于他们所采用嘚scheduler:mesos让framework决定mesos提供的这个资源是否适合该job从而接受或者拒绝这个资源。而对于yarn来说决定权在于yarn,是yarn本身(自行替应用程序作主)决定这個资源是否适合该job对于各种各样的应用程序来说或许这就是个错误的决定(这就是现代人为什么拒绝父母之命媒妁之言而选择自由婚姻嘚缘故吧)。所以从scaling的角度来说mesos更scalable。

我要回帖

更多关于 协同和共同的区别 的文章

 

随机推荐