张包峰的博客

Spark可以搭建在Mesos上或YARN上，两个都是资源管理系统。了解资源管理系统的话，可以先参看以下几篇文章：浅谈Borg/YARN/Mesos/Torca/Corona一类系统 多集群下资源共享方案介绍 统一资源管理与调度平台(系统)介绍 淘宝借助自己的第二代集群——云梯系统，把Spark部署在了YARN上，里面是淘宝技术部对Spark的一些实战小结，也算是在捣鼓阶段。关于Mesos的论文，可以在这里下载。他的官网上文档没有github的wiki上多。Mesos搭建在了解了资源管理

现在处于从3进入4的阶段，而关于Spark的构想，也还有一些东西需要去实践，新的技术需要去调研和了解。大致是有了Spark集群之后，对Mesos和YARN有一个选择问题，从Spark读取另一个Hadoop的HDFS上文件，这件事的网络延迟影响究竟有多大，毕竟现在的情况是hadoop和spark肯定是部署两套机器上，存储节点和计算节点分离，特别是基于Mesos的话，肯定是这种状态。像豆瓣的Dpark可能是和MFS上的数据打交道的，可能会比较好地解决本地化的问题，可能能检测到目标数据存在某个节点上，而把这次任务

本文面向对Spark，Mesos和Zookeeper有一点了解的读者，介绍下Run Spark on Mesos with Zookeeper的方法和一些注意点。因为Spark和Mesos的相关文档里，关于结合Zookeeper之后应该怎么改写相应URL和参数这块讲得不太清楚。版本信息Zookeeper 3.4.5 stableSpark 0.8Mesos 0.13

我们使用Mesos也有一段时间了，目前有两个项目使用Mesos作为底层资源管理系统，各自部了一套集群。这中间对比Mesos的论文和源码实现，到底哪些功能实现了，哪些功能未实现，版本是否稳定，使用是否顺畅，有哪些坑会遇到等等这些问题，同组的同事们都遇到了不少。大致总结一下使用过程中的感受吧。Mesos使用方式Mesos Master在给framework分配资源的时候采用的是多资源下的最大最小公平算法，即DRF算法，对于Mesos的第一层调度来说，使用方实现的Scheduler应该实现自己的调度策略和

我觉得资源管理器所要处理的问题无外乎几块：资源分配的策略，资源分配的粒度，资源分配的方式，不同类型任务的调度等。看了Google新一代资源管理器Omega的论文之后，对比Mesos和YARN总结了下面一些内容。其实Google的Omega的实现是很类似于双层调度器的，只是省略了第一层，或者说是进化掉了这第一层，把它变成了一个全局可访问和修改的状态维护起来，增大了并发性。实际意义上的调度器们就类似于双层调度器里的第二层，可以实现自己的调度策略，可以遵循自己的分配方式去执行Task。个人认为增量的分配模式的确

Slave模块三种Executor的设计，主要考虑的是各个Executor挂掉之后，怎样保证数据处理的不重复和不遗漏。我们依赖Zookeeper的可靠性，记录、更新、判断Bundle的状态，做到Input、Cache、Output各司其职，最到最小粒度的容错。Executor本身的失败和重启则由Mesos保障，Mesos作为资源管理系统，由Master监控Slave上各个Executor的执行状况，通过回调，可以在合适的Slave上再次启动挂掉的Executor进程，保证业务Task的顺利进行。

本文描述了在OS X上安装使用Marathon的过程。Marathon简介Marathon是Mesosphere公司为Mesos生态圈打造的一个轻量级、扩展性很强的调度long-running service的调度框架。支持RESTful api来创建和管理app，自动为app做容错迁移，凡是能用shell起的任务，理论上都可以通过Marathon在mesos上简单地启动和管理起来。下图为Mesos