从Spark Runtime的角度来讲由五大核心对象：Master、Worker、Executor、Driver、CoarseGrainedExecutorBacked；
Spark在做分布式集群系统设计的时候，最大化功能独立、模块化封装具体独立的对象、强内聚、松耦合。
Spark集群的启动及任务提交大致步骤：
1. 首先启动Master进程，负责整个集群资源的管理和分配，并接收作业的提交，且为作业分配计算资源。
2. 每个工作结点默认情况下都会启动一个Worker Process来管理当前结点的Memory，CPU等计算资源(实际上是通过Master来管理每台机器上的计算资源)，并且向Master汇报当前结点还可以正常工作。
3. 当用户提交作业给Master的时候，Master会为作业分配ID并分配 计算资源， 默认情况下，会为当前的应用程序在每个Worker Process下面分配一个CoarseGrainedExecutorBackend进程， 该进程默认情况下会最大化的使用当前结点上的内存和CPU
当Driver中的SparkContext初始化的时候会提交程序给Master，Master如果接受该程序在Spark中运行的话，就会为当前的程序 分配AppID，同时会分配具体的计算资源，需要特别注意的是，Master是根据当前提交程序的配置信息来给集群中的Worker发指令分配具体的计算资源。但是，Master发出指令后并不关心具体的资源是否已经分配 ，也就是说master是发指令后就记录了分配 的资源，以后客户端再次提交其它的程序的话就不能使用该资源了。其弊端是可能会导致其它要提交的程序无法分配 到本来应该可以分配到的计算资源。最重要的优势在于Spark分布式系统功能弱耦合的基础上最快的运行系统（否则，如果Master要等到资源最终分配成功后才通知Driver的话，就会造成Driver阻塞，不能够最大化并行计算资源的使用率）。Spark默认情况下由于集群中一般都只有一个Application在运行，所有Master分配 资源策略的弊端就没有那么明显了。
Job提交过程：
1. 一个技巧是通过在Spark-shell中运行一个Job来了解Job提交的过程。然后用源码来验证
2. 在Spark中所有的Action都会触发至少一个Job
3. SparkContext在实例化的时候会构造SparkDeploySchedulerBackend、DAGScheduler、TaskSchedulerImpl等对象，其中
3.1 SparkDeploySchedulerBackend 负责集群计算资源的管理和调度，
3.2 DAGScheduler 负责高层调度(例如Job中Stage的划分，数据本地性内容)；
3.2 TaskSchedulerImpl 负责具体Stage内部的底层调度（例如每个Task的调度、Task容错）；
3.4 MapOutputTrackerMaster 负责Shuffle中数据输出和读取的管理。
Task运行解密：
1. Task是运行在 Executor 中的，而 Executor 又是位于 CoarseGrainExecutorBackend 中的，且 CoarseGrainExecutorBackend 和 Executor 是一 一对应 的。
2. 当CoarseGrainExecutorBackend接收到TaskManager发过来的LaunchTask（这是一个case class）消息后会反序列化TaskDescription，然后使用executor去执行任务
Spark Job具体的物理执行：
Spark Application里面可以产生一个或者多个Job，例如Spark-shell默认启动的时候内部就没有Job，只是作为资源的分配程序，可以在里面写代码产生若干个Job。普通程序中一般而言可以有不同的Action，每个Action一般也会触发一个Job.
Spark是MapReduce思想的一种更加精致和高效的实现。
Spark算法构造和物理执行时最最基本的核心是：最大化Pipeline.
基于Pipeline的思想，数据被使用的时候才开始计算，从数据流的视角来说，是数据流动到计算的位置。实质上，从逻辑的角度来看，是算子在数据上流动。