只有知道内核架构的基础上，才知道为什么要这样写程序？
手工绘图来解密Spark内核架构
通过案例来验证Spark内核架构
Spark架构思考
==========Spark Runtime的几个概念============
下载下来运行，基本都是standalone模式，如果掌握了standalone，则yarn和mesos，以后不做特别说明，一律是standalone模式
application=driver+executor，executor是具体处理数据分片，里面是线程池并发的处理数据分片
Drvier(代码部分就是SparkConf+SparkContext)：运行程序的时候，具有main方法，并且创建了SparkContext这样的一个环境对象，是整个程序运行调度的核心，它不是资源调度。有高层调度，底层调度。运行对象的时候，会向Master注册当前的程序。Master会分配资源，会有一系列的job，产生stage，交给task scheduler，发给executor，运行之后把结果返回给Drvier，然后关闭SparkContext。
executor：运行在Worker所在的节点，为当前应用程序开启的进程里面的对象，通过线程池并发执行和线程复用。分布在各个集群上的代码，但是要运行的话，这个代码得发过去。一个Worker一般只开辟一个executor，当然也可以配置多个。具体多少excutor，在优化的时候再讲解。
下面的代码是Drvier，里面有DAG
val conf = new SparkConf()//创建SparkConf对象
conf.setAppName("My First Spark App!")//设置应用程序的名称，在程序运行的监控界面可以看到名称
conf.setMaster("local")//此时程序在本地运行，不需要安装Spark集群
val sc = new SparkContext(conf)//通过创建SparkContext对象，通过传入SparkConf实例来定制Spark运行的具体参数和配置信息
然后是产生RDD，就是executor具体执行的代码，就是下面的代码
val lines = sc.textFile("F:/安装文件/操作系统/spark-1.6.0-bin-hadoop2.6/README.md", 1)
==========Spark Cluster的几个概念============
Cluster Manager：集群中获取资源的外部服务，Spark Application的运行不依赖于Cluster Manager。Spark应用程序注册给Cluster Manager，比如Master注册成功，Cluster Manager已经给Master分配好资源。此时运行程序根本不需要Cluster Manager。这是粗粒度的运行方式。
Master的机器配置要很好。
Woker：可以具体运行操作代码的节点。Woker本身不会运行程序的代码，它是管理当前node的内存CPU等资源的使用状况的，它会接受Master分配计算资源(executor，在新的进程中分配 )指令，通过executor runner启动新进程，进行里面有excutor，Worker是工头，Cluster Manager是项目经理，Worker下面有好多人干活的。
Worker会不会在发心跳的时候向Master汇报当前机器的内存和CPU信息？
不会！Worker向Master发心跳只有WorkerID。
如果不发，Master怎么知道它的资源呢？
应用程序注册成功，Master分配资源的时候就知道了
Job：就是包括了一些列Task的并行计算。一般需要Action触发。Action不会产生RDD。Action前面有RDD，是transfoemation，是lazy级别的。
Spark快不是因为基于内存。最基本是调度，然后是容错，才是精髓，还有其它好多内容。
窄依赖，除了一对一，range级别的，固定个数，不会随着规模的大小而变化，比如原来3个，就算加到100台，还是3个MapPartitionRDD。
Stage内部计算逻辑完全一样，只是计算的数据不同罢了。这就是分布式并行计算，是大数据的基本精髓点。
一个Partition是不是固定128M？不是，因为最后的一条数据跨两个Block。
一个application里面可以有多个jobs，一般一个action操作对应一个job。其它情况比如checkpoint也会导致job。
==========Spark内核架构解密绘图============
~~~1、Driver~~~
专门提交Spark程序的机器（Driver，它的核心是SparkContext），这台机器一定和Spark Cluster在同样的网络环境中，且其配置和普通的Worker一致。因为会不停的交互，所以网络在一起。该机器可能会有其它企业级的J2EE程序等。这个机器有appication、各种依赖的外部资源（例如.so、file等等）。在此基础上，使用spark-submit来运行，可以配置各种运行时的参数，比如memory、cores等等。实际生产环境下不会手工spark-submit来运行，一般会写脚本，用crontab自动化配置和提交程序。提交Spark程序的机器，必须要安装Spark，只不过是这里安装的Spark不属于集群！！！Driver单列的时候一般不做HA，但是Master形式的时候，用--supervise模式，它会自动启动Driver。
（Spark程序的运行有两种模式，client模式和cluster模式，默认建议使用client模式，因为可以看到很多日志信息，但是实际运用，Cluster）
之前写程序提交给Master，因为现在只有3台机器，所以，一般Driver和Worker是分开的。
~~~2、SparkContext~~~
最重要做三件事情：创建DAGScheduler、TaskScheduler、SchedulerBackend
在实例化的的过程Register当前的程序给Master，Master接受注册，如果没有问题，Master会为当前程序分配AppID并分配计算资源
~~~3、SparkCluster~~~
Master接受当前用户提交的作业，给Worker为当前程序的资源，每个Worker所在节点默认为当前程序分配一个Executor，在Executor中通过线程池并发执行
slaves老师机器配置的Worker1、2、3、4就是这个意思
我的配置的是Master、Woker1、2，因为我的电脑配置低
Master分配多少资源来源：1、spark-env.sh和spark-defaults.sh设置的参数；2、submit提供的参数；3、程序中SparkConf提供的参数
Worker通过一个Proxy为ExecutorRunner的对象实例远程启动ExecutorBackend
ExecutorBackend里面有Executor的线程池ThreadPool
实际在工作的时候会通过TaskRunner来封装Task
TaskRunner是一个runner的接口，然后从ThreadPool中获取一条线程执行Task，执行完后，线程被回收复用
上面就是分配资源的部分，然后通过Action来触发Job，这个时候DAGScheduler登场了
~~~4、Job~~~
一般情况下当通过Action触发Job时，SparkContext会通过DAGScheduler来把Job中的RDD构成的DAG划分成不同的Stage，每个Stage内部是一系列内部逻辑完全相同，但是处理数据不同的Tasks构成了TaskSet
~~~5、TaskScheduler ~~~
TaskScheduler和SchedulerBacked具体Task运行（遵循数据本地性）
~~~5、Task类型~~~
最后Stage的Task称为ResultTask，产生Job结果
其它前面的Stage的Task都是ShuffleMapTask为下一阶段的Stage做数据准备，相当于MapReduce的Mapper，知识 是更精致和高效的实现
整个Spark运行的精髓就是DAGScheduler把Job划分成不同的Stage，提交TaskSet给TaskScheduler，进而提交给Executor进行（符合数据本地行），每个Task会计算RDD中的一个Partition，基于该Partition来具体执行我们定义的一系列同一个Stage内部的函数，以此类推，直到整个程序运行完成！
王家林老师名片：
中国Spark第一人
新浪微博：http://weibo.com/ilovepains
微信公众号：DT_Spark
博客：http://blog.sina.com.cn/ilovepains
手机：18610086859
QQ：1740415547
邮箱：[email protected]