转载

[原]Spark on Mesos: 粗粒度与细粒度实现分析

背景

顺着昨天spark standalone实现那篇文章继续扯淡，看看Mesos Scheduler的两种实现的异同。

对我来说，回过头再仔细看Spark在这一层的实现，思路又清晰了许多。

Mesos粗粒度

CoarseMesosSchedulerBackend，是mesos的粗粒度scheduler backend实现。

简单说一下mesos的Scheduler，提供的回调函数，及spark实现的逻辑：

Mesos Scheduler回调接口一览
Mesos Scheduler接口	触发场景	spark实现逻辑
void registered( SchedulerDriver driver, FrameworkID frameworkId, MasterInfo masterInfo);	当Scheduler成向mesos master注册之后回调，会返回唯一的framework id	得到framework的id，作为appId
void reregistered( SchedulerDriver driver, MasterInfo masterInfo)	是mesos换了个新选举出来的master的时候触发，前提是该scheduler之前已经注册过了	没有实现。
void resourceOffers( SchedulerDriver driver, List<Offer> offers)	mesos提供了一批可用的资源，让scheduler可以使用或拒绝这些资源。每个Offer是以slave为单位的，即以slave为单位的资源列表。	得到mesos的Offers列表，只要已经启动的executor还不足够，那么从资源列表里继续获取资源，启动CoarseGrainedExecutorBackend。
void offerRescinded( SchedulerDriver driver, OfferID offerId)	当请求的offer不可用时回调(可能是slave lost了之类的原因导致的)，如果在这上面继续起task的话会报Task Lost的状态。	没有实现。spark在task scheduler层面对lost的task有自己的处理，。
void statusUpdate( SchedulerDriver driver, TaskStatus status)	task状态更新回调，可能是finish了，可能是lost了，可能是fail了等等	得到finished、failed、lost等task状态，更新内存里维护的task状态，并触发新一轮的reviveOffers，即通过task scheduler继续把resource分配给需要的task并执行它们。
void frameworkMessage( SchedulerDriver driver, ExecutorID executorId, SlaveID slaveId, byte[] data)	用于接收executor主动发的消息	没有实现。mesos虽然在内部提供了这种msg接口，貌似不是很稳定。使用方可以使用自己的RPC来做executor与scheduler的通信，如果真的需要的话。
void disconnected(SchedulerDriver driver)	当scheduler与master断开的时候触发，原因可能是master挂了，或者master换了等等。	没有实现。spark前面就没有实现master新选举的接口。
void slaveLost( SchedulerDriver driver, SlaveID slaveId)	通知某个slave lost了，以便framework进行任务的rescheduler或其他逻辑	spark把slave lost和executor lost一起处理了。处理逻辑就是执行RemoveExecutor操作，最终调用TaskScheduler的executorLost方法，把executor的状态移除，并且会继续向上调用DAGScheduler的handleExecutorLost方法。因executor lost可能会影响到shuffle数据，这部分还需要BlockManager感知。
void executorLost( SchedulerDriver driver, ExecutorID executorId, SlaveID slaveId, int status)	通知某个slave上的executor挂了。	同上
void error( SchedulerDriver driver, String message)	scheduler或scheduler driver发送错误触发	没有实现

另一方面，要说明一下mesos的SchedulerDriver。

它相当于是Scheduler与mesos通信的一个连接人，一方面是管理Scheduler的生命周期，二方面是与mesos交互，让它启停task。

在初始化SchedulerDriver的时候，向里面传入spark自己实现的Scheduler就可以了，即CoarseMesosSchedulerBackend或MesosSchedulerBackend。在每个mesos的Scheduler接口的回调方法里，都会传回SchedulerDriver，以对应可以进行scheduler的启停和task的启停管理。

CoarseMesosSchedulerBackend内部主要维护的信息为：slave与executor的对应关系，executor与task的对应关系，task与slave的对应关系。

Mesos细粒度

翻译下注释：

细粒度模式下，允许多个app共享nodes，包括空间，即不同app的tasks可以跑同几个core，和时间，即一个core可以切换ownership。

这块共享的控制，在mesos端，所以spark在实现的时候，其实差别和难度都不大。

MesosSchedulerBackend的实现：

在resourceOffers逻辑里，获得mesos提供的slave资源后，直接在里面调用scheduler的resourceOffers，即TaskSchedulerImpl的分配task的逻辑。也就是说，会按优先级，从active task sets(来自多个app)里选择并直接launch task。而粗粒度里的做法，是先启动executorbackend，把资源准备好，进程先拉起，供app去launch task。

其他回调接口的逻辑是大同小异的。

还有一点不同之处，粗粒度模式下executor的实现使用的是与standalone模式相同的CoarseGrainedExecutorBackend。在细粒度模式下，executor的实现是MesosExecutorBackend，实现了spark的ExecutorBackend和mesos的MesosExecutor。实际上，在类里面，还是使用的spark的executor，在对应的回调里执行start/kill task这样的操作。另外，mesos的ExecutorDriver用于负责与mesos通信，比如传递一些状态更新的消息，或有特殊的msg要发送。executor这块的差别无关紧要。

在我看来，executor这块最终一定是落到了spark的executor上，里面有一个线程池，可以跑spark的ShuffleMapTask或ResultTask。而mesos粗、细粒度的Scheduler实现，最大区别在于resourceOffers的逻辑，是怎么处理分配的进程资源：粗粒度是预先拉起执行进程，而细粒度是直接通过TaskScheduler来摆放执行线程了。

粗细粒度分别适合跑什么样的任务，可以具体见官方文档这一节

全文完 :)

正文到此结束