day23:从物理执行的角度透视Spark Job
2016-02-26 14:27
393 查看
以下内容整理来源于DT大数据梦工厂,微博地址:http://weibo.com/ilovepains
Scheduler Optimizations
本次学习内容:1、再次思考pipeline
2、宅依赖物理执行内幕
3、宽依赖物理执行内幕
4、Job提交流程
一:再次思考pipeline
即使采用pipeline的方式,函数f对依赖的RDD中的数据的操作也会有2种方式:
1:f(record), f作用于集合的每一条记录,每次只作用于一条记录
2、f(redord), f一次性作用于集合的全部数据。
spark采用的是第一种方式,原因:
1、spark无需等待,可以最大化的使用集群计算资源。
2、减少OOM的发生
3、最大化的有利于开发
4、可以精准的控制每一个Partition本身(Dependency)及内部的计算(computer)
5、基于lineage的算子流动函数式编程,节省了中间结果的产生,并可以最快的恢复
疑问:会不会增加网络通信?当然不会, 因为在pipeline
二: 思考Spark Job 具体的物理执行
Spark Application 里面可以产生1个或者多个job,例如spark-shell默认启动的时候内部就没有Job,只是作为资源的分配程序,可以在spark-shell里面写代码
产生若干个Job,普通程序中一般而言可以有不同的Action,每一个Action一般也就触发一个/job.
Spark 是 MapReduce思想的一种更加精致和高效的实现,MapReduce有很多具体不同的实现,例如Hadoop 的Mapreduce基本计算流程如下
:首先是以JVM为对象的并发 执行Mapper,Mapper中map的执行会产生输出数据,输出数据会经过Partition指定的规则放在Local FileSystem中,然后
经由Shuffle、 sort、Aggreate变成Reducer中的reduce的输入,执行reduce产生最终的执行结果:Hadoop Mapreduce执行的流程虽然很简单,但是过于死板,尤其
在构造复杂算法(迭代)的时候非常不利于算法的实现。且执行效率极为低下。
Spark算法构造和物理执行是最基本核心算法:最大化pipeline!
基于Pipeline的思想,数据被使用的时候才开始计算,从数据流动的角度来讲,是数据流动到计算的位置!!!实际上从逻辑的角度来看, 是算子在数据上流动。
从算法构建的角度而言:肯定是算子作用于数据,所以是算子在数据上流动,方便算法的构建!
从物理执行的角度而言:是数据流动到计算的位置。
对于pipeline而言,数据计算的位置就是每个Stage中最后的RDD, 每个Stage中除了最后一个RDD 算子是真实的外,前面的算子都是假的。
由于计算的Lazy特性,导致计算从后往前回溯形成Computing Chain,导致的结果就是需要首先计算出具体一个Stage内部左侧的RDD中本次计算依赖的Partiton。
三:窄依赖的物理执行内幕
1、 一个Stage内部的RDD都是窄依赖,窄依赖计算本身是逻辑上看是从Stage内部最左侧的RDD开始立即计算的,根据Computing Chain,数据
从一个计算步骤流动到下一个结算步骤,以此类推(算的时候从前往后), 直到计算到Stage内部的最后一个RDD产生计算结果。
Computiing Chain 的构建是从后往前回溯构建而成,而实际的物理计算则是让数据从前往后在算子上流动,直到流动到不能在流动位置才开始计算下一个Record。这就导致一个美好的结果,后面的RDD 对前面RDD的依赖虽然是Partition级别数据集合的依赖,但是并不需要父RDD把partition中所有Records计算完毕才整体往后流动数据进行计算,这就极大的 提高了计算速率!
四: 宽依赖物理执行内幕
提示:写代码的时候尽量减少宽依赖
必须等待依赖的父Stage中的最后一个RDD把全部数据彻底计算完成,才能够经过shuffle来计算当前的Stage
遇到 shuffle级别的就是形成stage
所有依赖父Stage,是拿所有Stage的数据还是拿一部分数据:拿一部分数据,算一部分。
计算数据是从Dependency来的;
spark作业提交都是触发Action
源码分析类:
ShuffleDependency --->MapPartitionRDD override def compute(split : org.apache.spark.Partition, context : org.apache.spark.TaskContext) : scala.Iterator[U]
-->RDD (count,--runJob-onReceive-doOnReceive)
作业: 我理解中的Spark Job
DT大数据梦工厂
新浪微博:www.weibo.com/ilovepains/
微信公众号:DT_Spark
博客:http://.blog.sina.com.cn/ilovepains
TEL:18610086859
Email:18610086859@vip.126.com
Scheduler Optimizations
本次学习内容:1、再次思考pipeline
2、宅依赖物理执行内幕
3、宽依赖物理执行内幕
4、Job提交流程
一:再次思考pipeline
即使采用pipeline的方式,函数f对依赖的RDD中的数据的操作也会有2种方式:
1:f(record), f作用于集合的每一条记录,每次只作用于一条记录
2、f(redord), f一次性作用于集合的全部数据。
spark采用的是第一种方式,原因:
1、spark无需等待,可以最大化的使用集群计算资源。
2、减少OOM的发生
3、最大化的有利于开发
4、可以精准的控制每一个Partition本身(Dependency)及内部的计算(computer)
5、基于lineage的算子流动函数式编程,节省了中间结果的产生,并可以最快的恢复
疑问:会不会增加网络通信?当然不会, 因为在pipeline
二: 思考Spark Job 具体的物理执行
Spark Application 里面可以产生1个或者多个job,例如spark-shell默认启动的时候内部就没有Job,只是作为资源的分配程序,可以在spark-shell里面写代码
产生若干个Job,普通程序中一般而言可以有不同的Action,每一个Action一般也就触发一个/job.
Spark 是 MapReduce思想的一种更加精致和高效的实现,MapReduce有很多具体不同的实现,例如Hadoop 的Mapreduce基本计算流程如下
:首先是以JVM为对象的并发 执行Mapper,Mapper中map的执行会产生输出数据,输出数据会经过Partition指定的规则放在Local FileSystem中,然后
经由Shuffle、 sort、Aggreate变成Reducer中的reduce的输入,执行reduce产生最终的执行结果:Hadoop Mapreduce执行的流程虽然很简单,但是过于死板,尤其
在构造复杂算法(迭代)的时候非常不利于算法的实现。且执行效率极为低下。
Spark算法构造和物理执行是最基本核心算法:最大化pipeline!
基于Pipeline的思想,数据被使用的时候才开始计算,从数据流动的角度来讲,是数据流动到计算的位置!!!实际上从逻辑的角度来看, 是算子在数据上流动。
从算法构建的角度而言:肯定是算子作用于数据,所以是算子在数据上流动,方便算法的构建!
从物理执行的角度而言:是数据流动到计算的位置。
对于pipeline而言,数据计算的位置就是每个Stage中最后的RDD, 每个Stage中除了最后一个RDD 算子是真实的外,前面的算子都是假的。
由于计算的Lazy特性,导致计算从后往前回溯形成Computing Chain,导致的结果就是需要首先计算出具体一个Stage内部左侧的RDD中本次计算依赖的Partiton。
三:窄依赖的物理执行内幕
1、 一个Stage内部的RDD都是窄依赖,窄依赖计算本身是逻辑上看是从Stage内部最左侧的RDD开始立即计算的,根据Computing Chain,数据
从一个计算步骤流动到下一个结算步骤,以此类推(算的时候从前往后), 直到计算到Stage内部的最后一个RDD产生计算结果。
Computiing Chain 的构建是从后往前回溯构建而成,而实际的物理计算则是让数据从前往后在算子上流动,直到流动到不能在流动位置才开始计算下一个Record。这就导致一个美好的结果,后面的RDD 对前面RDD的依赖虽然是Partition级别数据集合的依赖,但是并不需要父RDD把partition中所有Records计算完毕才整体往后流动数据进行计算,这就极大的 提高了计算速率!
四: 宽依赖物理执行内幕
提示:写代码的时候尽量减少宽依赖
必须等待依赖的父Stage中的最后一个RDD把全部数据彻底计算完成,才能够经过shuffle来计算当前的Stage
遇到 shuffle级别的就是形成stage
所有依赖父Stage,是拿所有Stage的数据还是拿一部分数据:拿一部分数据,算一部分。
计算数据是从Dependency来的;
spark作业提交都是触发Action
源码分析类:
ShuffleDependency --->MapPartitionRDD override def compute(split : org.apache.spark.Partition, context : org.apache.spark.TaskContext) : scala.Iterator[U]
-->RDD (count,--runJob-onReceive-doOnReceive)
作业: 我理解中的Spark Job
DT大数据梦工厂
新浪微博:www.weibo.com/ilovepains/
微信公众号:DT_Spark
博客:http://.blog.sina.com.cn/ilovepains
TEL:18610086859
Email:18610086859@vip.126.com
相关文章推荐
- jQuery插件ajax图片上传插件
- GCD中的dispatch_apply的用法及作用
- ArcGISServer集群注册文件夹时的路径问题
- Visual Studio2015 publish Could not find file *****
- 十三、Android UiAutomator Junit 断言函数的使用
- 逻辑漏洞(二)
- 初识Python
- Git的诞生(转)
- day47:DT大数据梦工厂性能优化day47
- linux 睡眠函数——sleep(),usleep()
- c程序是如何跑起来的?
- eclipse里面debug时step into 和step over有什么差别?
- 【Linux C中文函数手册】文件内容控制函数
- bzoj1034 泡泡堂
- iOS 中 cell和 label 的自适应高度
- Android APP界面标注、尺寸换算和APP标注工具
- linux下shell显示-bash-4.1#不显示路径解决方法
- hibernate笔记: 关于懒加载和load()方法
- 实现Bootstrap导航条可点击和鼠标悬停显示下拉菜单
- Linux下安装openldap