转载注明出处谢谢~~
1.Standalone模式两种提交任务方式
1.Standalone-client提交任务方式
Ø 提交命令
./spark-submit --master spark://node1:7077 --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 1000 |
或者
./spark-submit --master spark://node1:7077 --deploy-mode client --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100 |
Ø 执行原理图解
Ø 执行流程
1.client模式提交任务后,会在客户端启动Driver进程。
2.Driver会向Master申请启动Application启动的资源。
3.资源申请成功,Driver端将task发送到worker端执行。
4.worker将task执行结果返回到Driver端。
Ø 总结
client模式适用于测试调试程序。Driver进程是在客户端启动的,这里的客户端就是指提交应用程序的当前节点。在Driver端可以看到task执行的情况。生产环境下不能使用client模式,是因为:假设要提交100个application到集群运行,Driver每次都会在client端启动,那么就会导致客户端100次网卡流量暴增的问题。
2.Standalone-cluster提交任务方式
Ø 提交命令
./spark-submit --master spark://node1:7077 --deploy-mode cluster --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100 |
Ø 执行原理图解
Ø 执行流程
1.cluster模式提交应用程序后,会向Master请求启动Driver.
2.Master接受请求,随机在集群一台节点启动Driver进程。
3.Driver启动后为当前的应用程序申请资源。
4.Driver端发送task到worker节点上执行。
5.worker将执行情况和执行结果返回给Driver端。
Ø 总结
Driver进程是在集群某一台Worker上启动的,在客户端是无法查看task的执行情况的。假设要提交100个application到集群运行,每次Driver会随机在集群中某一台Worker上启动,那么这100次网卡流量暴增的问题就散布在集群上。
¬ 总结Standalone两种方式提交任务,Driver与集群的通信包括:
1. Driver负责应用程序资源的申请
2. 任务的分发。
3. 结果的回收。
4. 监控task执行情况。
2.Yarn模式两种提交任务方式
1.yarn-client提交任务方式
Ø 提交命令
./spark-submit --master yarn --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100 |
或者
./spark-submit --master yarn–client --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100 |
或者
./spark-submit --master yarn --deploy-mode client --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100 |
Ø 执行原理图解
Ø 执行流程
1.客户端提交一个Application,在客户端启动一个Driver进程。
2.应用程序启动后会向RS(ResourceManager)发送请求,启动AM(ApplicationMaster)的资源。
3.RS收到请求,随机选择一台NM(NodeManager)启动AM。这里的NM相当于Standalone中的Worker节点。
4.AM启动后,会向RS请求一批container资源,用于启动Executor.
5.RS会找到一批NM返回给AM,用于启动Executor。
6.AM会向NM发送命令启动Executor。
7.Executor启动后,会反向注册给Driver,Driver发送task到Executor,执行情况和结果返回给Driver端。
Ø 总结
Yarn-client模式同样是适用于测试,因为Driver运行在本地,Driver会与yarn集群中的Executor进行大量的通信,会造成客户机网卡流量的大量增加.
¬ ApplicationMaster的作用:
1.为当前的Application申请资源
2.给NameNode发送消息启动Executor。
注意:ApplicationMaster有launchExecutor和申请资源的功能,并没有作业调度的功能。
2.yarn-cluster提交任务方式
Ø 提交命令
./spark-submit --master yarn --deploy-mode cluster --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100 |
或者
./spark-submit --master yarn-cluster --class org.apache.spark.examples.SparkPi ../lib/spark-examples-1.6.0-hadoop2.6.0.jar 100 |
Ø 执行原理图解
Ø 执行流程
1.客户机提交Application应用程序,发送请求到RS(ResourceManager),请求启动AM(ApplicationMaster)。
2.RS收到请求后随机在一台NM(NodeManager)上启动AM(相当于Driver端)。
3.AM启动,AM发送请求到RS,请求一批container用于启动Excutor。
4.RS返回一批NM节点给AM。
5.AM连接到NM,发送请求到NM启动Excutor。
6.Excutor反向注册到AM所在的节点的Driver。Driver发送task到Excutor。
Ø 总结
Yarn-Cluster主要用于生产环境中,因为Driver运行在Yarn集群中某一台nodeManager中,每次提交任务的Driver所在的机器都是随机的,不会产生某一台机器网卡流量激增的现象,缺点是任务提交后不能看到日志。只能通过yarn查看日志。
¬ ApplicationMaster的作用:
1.为当前的Application申请资源
2.给NameNode发送消息启动Excutor。
3.任务调度。
¬ 停止集群任务命令:yarn application -kill applicationID
3.补充部分算子
transformation
Ø join,leftOuterJoin,rightOuterJoin,fullOuterJoin
作用在K,V格式的RDD上。根据K进行连接,对(K,V)join(K,W)返回(K,(V,W))
¬ join后的分区数与父RDD分区数多的那一个相同。
Ø union
合并两个数据集。两个数据集的类型要一致。
union 后的分区数是unionRDD分区的总和
¬ 返回新的RDD的分区数是合并RDD分区数的总和。
Ø intersection
取两个数据集的交集
两个数据集的数据类型必须相同
Ø subtract
取两个数据集的差集
Ø mapPartition
与map(进一条出一条)类似,遍历的单位是每个partition上的数据。遍历的单位是RDD中一个partition数据
mapPartition()进来的是一个个的迭代器(iterator是一个分区中的数据),出去的是一个个分区中的数据转换之后的
Ø distinct(map+reduceByKey+map)
对RDD元素去重
java:
Ø cogroup
当调用类型(K,V)和(K,W)的数据上时,返回一个数据集(K,(Iterable
所有的key拿出来,(第一个数据集的所有相同key的value组成一个集合 , 第二个数据集的所有相同key的value组成一个集合)
action
Ø foreachPartition
遍历的数据是每个partition的数据。
4.术语解释
5.窄依赖和宽依赖
RDD之间有一系列的依赖关系,依赖关系又分为窄依赖和宽依赖。
Ø 窄依赖
父RDD和子RDD partition之间的关系是一对一的。或者父RDD一个partition只对应一个子RDD的partition情况下的父RDD和子RDD partition关系是多对一的。不会有shuffle的产生。
Ø 宽依赖
父RDD与子RDD partition之间的关系是一对多。会有shuffle的产生。
6.Stage
Spark任务会根据RDD之间的依赖关系,形成一个DAG有向无环图,DAG会提交给DAGScheduler,DAGScheduler会把DAG划分相互依赖的多个stage,划分stage的依据就是RDD之间的宽窄依赖。遇到宽依赖就划分stage,每个stage包含一个或多个task任务。然后将这些task以taskSet的形式提交给TaskScheduler运行。
stage是由一组并行的task组成。
Ø stage切割规则
切割规则:从后往前,遇到宽依赖就切割stage。
Ø stage计算模式
pipeline管道计算模式,pipeline只是一种计算思想,模式。
¬ 数据一直在管道里面什么时候数据会落地?
1.对RDD进行持久化。
2.shuffle write的时候。
¬ Stage的task并行度是由stage的最后一个RDD的分区数来决定的 。
¬ 如何改变RDD的分区数?
例如:reduceByKey(XXX,3),GroupByKey(4)
Ø 测试验证pipeline计算模式
valconf = new SparkConf() conf.setMaster("local").setAppName("pipeline"); valsc = new SparkContext(conf) valrdd = sc.parallelize(Array(1,2,3,4)) valrdd1 = rdd.map { x => { println("map--------"+x) x }} valrdd2 = rdd1.filter { x => { println("fliter********"+x) true } } rdd2.collect() sc.stop() |
7.Spark资源调度和任务调度
Ø Spark资源调度和任务调度的流程:
启动集群后,Worker节点会向Master节点汇报资源情况,Master掌握了集群资源情况。当Spark提交一个Application后,根据RDD之间的依赖关系将Application形成一个DAG有向无环图。任务提交后,Spark会在Driver端创建两个对象:DAGScheduler和TaskScheduler,DAGScheduler是任务调度的高层调度器,是一个对象。DAGScheduler的主要作用就是将DAG根据RDD之间的宽窄依赖关系划分为一个个的Stage,然后将这些Stage以TaskSet的形式提交给TaskScheduler(TaskScheduler是任务调度的低层调度器,这里TaskSet其实就是一个集合,里面封装的就是一个个的task任务,也就是stage中的并行度task任务),TaskSchedule会遍历TaskSet集合,拿到每个task后会将task发送到计算节点Executor中去执行(其实就是发送到Executor中的线程池ThreadPool去执行)。task在Executor线程池中的运行情况会向TaskScheduler反馈,当task执行失败时,则由TaskScheduler负责重试,将task重新发送给Executor去执行,默认重试3次。如果重试3次依然失败,那么这个task所在的stage就失败了。stage失败了则由DAGScheduler来负责重试,重新发送TaskSet到TaskSchdeuler,Stage默认重试4次。如果重试4次以后依然失败,那么这个job就失败了。job失败了,Application就失败了。
TaskScheduler不仅能重试失败的task,还会重试straggling(落后,缓慢)task(也就是执行速度比其他task慢太多的task)。如果有运行缓慢的task那么TaskScheduler会启动一个新的task来与这个运行缓慢的task执行相同的处理逻辑。两个task哪个先执行完,就以哪个task的执行结果为准。这就是Spark的推测执行机制。在Spark中推测执行默认是关闭的。推测执行可以通过spark.speculation属性来配置。
注意:
¬ 对于ETL类型要入数据库的业务要关闭推测执行机制,这样就不会有重复的数据入库。
¬ 如果遇到数据倾斜的情况,开启推测执行则有可能导致一直会有task重新启动处理相同的逻辑,任务可能一直处于处理不完的状态。
Ø 图解Spark资源调度和任务调度的流程
Ø 粗粒度资源申请和细粒度资源申请
¬ 粗粒度资源申请(Spark)
在Application执行之前,将所有的资源申请完毕,当资源申请成功后,才会进行任务的调度,当所有的task执行完成后,才会释放这部分资源。
优点:在Application执行之前,所有的资源都申请完毕,每一个task直接使用资源就可以了,不需要task在执行前自己去申请资源,task启动就快了,task执行快了,stage执行就快了,job就快了,application执行就快了。
缺点:直到最后一个task执行完成才会释放资源,集群的资源无法充分利用。
¬ 细粒度资源申请(MapReduce)
Application执行之前不需要先去申请资源,而是直接执行,让job中的每一个task在执行前自己去申请资源,task执行完成就释放资源。
优点:集群的资源可以充分利用。
缺点:task自己去申请资源,task启动变慢,Application的运行就响应的变慢了。