从物理执行的角度透视spark Job

一、再次思考pipeline
即使采用pipeline的方式，函数f对依赖的RDD中的数据操作也会有两种方式：
1、f(record) f作用于集合的每一条记录，每次只作用于一条记录。
2、f(records) f一次性作用于集合的全部数据。

Spark采用的是第一种方式：原因：
1.无需等待，可以最大化的使用集群的计算资源；
2.减少OOM的发生；
3.最大化的有利于并发；
4.可以精准的控制每个Partition本身（Dependency）及其内部的计算（compute）
5.基于lineage的算子流动式函数式编程，节省了中间结果的产生，并且可以最快的恢复。
疑问：会不会增加网络通信？当然不会，因为在pineline（一个stage）

二、思考Spark Job具体的物理执行
Spark Application里面可以产生1个或者多个Job,例如spark-shell默认启动是时候就没有Job，只是作为资源的分配程序，可以在里面写代码产生若干个Job，普通程序中一般而言可以有不同的Action，每一个Action一般也会触发一个Job。
Spark是MapReduce思想的一种更加精致和高效的实现，MapReduce由很多具体不同的实现，例如Hadoop的MapReduce基本的计算流程如下：首先是以JVM为对象的并发执行的Mapper,Mapper中map的执行会产生输出数据，输出数据会经过Partition指定的规则放到Local FileSystem中，然后在经由Shuffle、Sort、Aggregate变成Reducer中reduce的输入，执行reduce产生最终的执行结果；Hadoop MapReduce执行的流程虽然简单，但是过于死板，尤其是在构造复杂算法（迭代）时候非常不利于算法的实现，且执行效率极为低下！

Spark算法构造和物理执行时最最基本的核心：最大化pipeline！

基于pipeline的思想，数据被使用的时候才开始计算，从数据流动的视角说，是数据流动到计算的位置！！！实质上从逻辑的角度来看，是算子在数据上流动！
从算法构建的角度而言：肯定是算子作用于数据，所以是算子在数据上流动：方便算法的构建！
从物理执行的角度而言：是数据流动到计算的位置：方便系统最为高效的运行！
对于pipeline而言，数据计算的位置就是每个Stage中最后的RDD （每个Stage中除了最后一个RDD算子是真实的以外，其他都是假的）
由于计算的Lazy特性，导致计算从后往前回溯，形成Computing Chain,导致的结果就是需要首先计算出具体一个Stage内部左侧是RDD中本次计算依赖的Partition

三、窄依赖的物理执行内幕
一个Stage内部的RDD都是窄依赖，窄依赖计算本身从逻辑上看是从最左侧RDD开始立即计算的，根据Computing Chain,数据是从一个计算步骤流到下一个计算步骤，以此类推，直到Stage内部最后一个RDD产生计算结果。
Computing Chain的构建是从后往前回溯构建而成，而实际的物理计算则是让数据从前往后再算子上流动，直到流动到不能流动为止才开始计算下一个Record。后面的RDD对前面的RDD的依赖虽然是Partition级别的数据集合的依赖，但是不需要父RDD把Partition中所有的Records计算完毕才整体往后流动数据进行计算，这就极大的提高了效率。

四、宽依赖的物理执行内幕
必须等到依赖的父Stage中的最后一个RDD全部数据彻底计算完毕，才能够经过shuffle来计算当前的Stage!

学习于：

ＤＴ大数据梦工厂
新浪微博：www.weibo.com/ilovepains/
微信公众号：DT_Spark
博客：http://.blog.sina.com.cn/ilovepains
TEL:18610086859
Email:18610086859@vip.126.com