spark原理

yarn 资源动态调度和资源共享

运行多种作业（spark MapReduce）运行在yarn上的两个角色（application master 程序 worker资源，worker数量就是excutor数量）

 

spark

一个程序只有一个driver（application master集成driver yarncluster模式 yarnclient模式则是运行在client端） excutor运行task

 

 

HDFS无法进行修改，如果有修改的需求可以进行追加。

 

stage划分由shuffle进行划分的。

 

shuffle 相同的key的值shuffle到同一个分区，减少每个机器的数量。hash的思想就是散列。混洗的作用。对key进行hash取模进行分发。

 

 

merge sort 归并排序

 

 

1Tb数据 1g内存进行排序 每个小文件内部为有序。

presto整个流程是在内存中的，因此比较耗费资源，但是快。

 

 

物理上是每一行执行完一个stage内所有算子，stage与stage之间会有落盘（优化的话可以放在内存中，数据量足够小的时候）。

 

reducebykey可以指定并行度

colese分区数只能减少，因为没有shuffle。repartition可以输入任何分区数，可以减少也可以增加。

 

 

core数量对应task的数量

action操作对应一个job，job顺序执行。

 

 

task>=excutor 避免资源浪费

 

shuffle write端是要做排序的shuffle read不做排序。

 

 

jobhistoryserver 启动才可以看日志历史记录

 

 

fsck 可以查看block数量

 

如何确定excutor大小，多尝试，期待的运行时间

 

excutor中task不均匀，task如果比较少，stage执行分先后的

 

stage skip掉是由于有的stage已经执行过，shuffle时候已落盘可以重用。

 

 

 

推测执行 （ 写数据库时候 和 数据倾斜 不适用）

 

 

数据倾斜解决方案：对倾斜的key加随机数后缀，打散后重新分布，最后map把后缀去掉

 

输入本身不均匀就可以用repatition减轻倾斜（轮询），如果shuffle操作之后就不适用了。

 

存储与计算分离

 

 

 

bin/spark-submit \

  --master yarn-cluster \

 --class org.training.spark.core.Java8WordCount\

  --name "Java8WordCount"\

  --driver-memory 1g \

  --executor-memory 1g \

  --executor-cores 1 \

  --num-executors 2 \

/home/bigdata/datasource/AuraSparkTraining-1.0-SNAPSHOT-jar-with-dependencies.jar\

/data/Hamlet.txt /data/input

 

 

 

调优：

colesce 可以减少task数量，repatition不可以。尽量避免使用repatition

避免使用笛卡尔积，容易造成数据膨胀。

join什么时候不需要shuffle？

 

core的数量不是越多越好，多了反而资源浪费。

并行执行的时候的时候rdd就不能共享了。并行执行可以提高集群资源利用率。

 

hdfs fsck blocks 查看block的分

 

查看sparkjob运行情况前必须要启动 Hadoop 下的 ./mr-jobhistory-daemon.sh start historyserver

同时要启动spark下 ./start-history-server.sh