Spark集群分为Master节点和Worker节点,相当于Hadoop的Master和Slave节点。Master节点上常驻Master守护进程,负责管理全部的Worker节点。Worker节点上常驻Worker守护进程,负责与Master节点通信并管理executors。
Driver 官方解释是 The process running the main() function of the application and creating the SparkContext
。
- 每个application包含一个driver和多个executors,每个executor里面运行的tasks都属于同一个application。
- 每个 Worker 上存在一个或者多个ExecutorBackend进程。每个进程包含一个Executor对象,该对象持有一个线程池,每个线程可以执行一个task。
- 在Standalone版本中,ExecutorBackend被实例化成CoarseGrainedExecutorBackend进程。
- Worker通过持有ExecutorRunner对象来控制CoarseGrainedExecutorBackend的启停。
多线程模型
- 每个节点上可以运行一个或多个Executor服务
- 每个Executor配有一定数量的slot,表示该Executor中可以同时运行多少个ShuffleMapTask或者ReduceTask(就是运行多少task)
- 每个Executor单独运行在一个JVM进程中,每个Task则是运行在Executor中的一个线程(Hadoop每个Task占据一个进程)
- 同一个Executor内部的Task可共享内存,比如通过
broadcast
的文件或者数据结构只会在每个Executor中加载一次,而不会像MapReduce那样,每个Task加载一次; - Executor一旦启动后,将一直运行,且它的资源可以一直被Task复用,直到Spark程序运行完成后才释放退出
task的执行速度是跟每个Executor进程的core数量有直接关系的。一个core同一时间只能执行一个线程。而每个Executor进程上分配到的多个task,都是以每个task一个线程的方式并发运行的。如果core数量比较充足,而且分配到的task数量比较合理,那么通常来说,可以比较快速和高效地执行完这些task线程。
总体上看,Spark采用的是经典的scheduler/workers模式,每个Spark应用程序运行的第一步是构建一个可重用的资源池
,然后在这个资源池里运行所有的ShuffleMapTask和ReduceTask,而MapReduce应用程序则不同,它不会构建一个可重用的资源池,而是让每个Task动态申请资源,且运行完后马上释放资源。
尽管Spark的多线程模型带来了很多好处,但同样存在不足,主要有:
- 由于同节点上所有任务运行在一个进程中,因此,
会出现严重的资源争用
,难以细粒度控制每个任务占用资源。与之相反的是MapReduce,它允许用户单独为Map Task和Reduce Task设置不同的资源,进而细粒度控制任务占用资源量,有利于大作业的正常平稳运