Spark简记

1.spark与yarn的对比
ApplicationMAnage在spark中叫做driver
AM向RM申请的是executor资源，分配executor之后由driver来管理
executor是一个进程，里面含有很有的task，每一个task是一个线程
【注】1.executor伴随整个Application的生命周期
线程池模式，省去进程频繁启停的开销
2.MR有什么问题
启动耗时：
MR : map进程，reduce进程
spark： executor进程，10个线程：8 map task（线程）2 reduce（线程）

计算慢
MR： map->reduce的中间结果在磁盘
spark： map->reduce的中间结果也在磁盘（默认）除非，进行cache调用persist默认在内存中

API抽象
MR： 写MR需要通过脚本把map和reduce串起来，如果项目中有较多的数据处理：写脚本比较费劲，
需要画图，然后再写脚本
spark 只需要通过代码就能把很多的数据处理串在一起：
df = spark.map.reduce
df1 = df.groupBy().count（）
通过spark shell的方式查看具体的数据

3.线程池模式，省去进程频繁启停的开销【重要】
假设共有进程：8 map 1G，2个reduce 1G

MR：如果执行map执行完，去看yarn这个任务运行的资源情况这个任务会占用多少资源？占用2G，由于map是进程的形式，执行完之后会释放8G的资源
spark：1个executor 10G：8 map 1G ，2个reduce 1G，8个map执行完，资源占用情况？spark占用10G

4.小技巧：中间结果放到内存，加速迭代
spark用迭代模型：
df经过很多的数据处理之后，处理成模型输入的数据：df_n
df_n.cache加载到内存
再去输入到模型中，因为模型迭代一次，需要扫一遍数据集df_n

5.spark解决了什么问题？
1.最大化利用内存cache，中间结果放内存，加速迭代，加速后续查询和处理，解决运行慢的问题。
假如： dataFrame == hive table
df1表-> df2表
df1表-> df3表->df4表
df3表-> df5表
优化：
Hive： df1表->落一个表（凌晨任务，这是属于常用表）,df3表落一个表
Spark： df1表->内存，df3表->内存
使用情景：
依赖表其中有一个是凌晨5点，5点之后运行你的代码，需要跑3个小时线上在7点就要用。 避免重复计算，缩减执行运行时间。

2.丰富的API
写操作就是action：写磁盘，写内存
cache属于transformation，df.cache告诉任务df需要执行之后放到内存中
transformation：变换的API，比如map可对每一行做变换，filter过滤出符合条件的行，这些API实现用户算法，灵活。

3.完整的作业描述：
使用spark实现Wordcount：
Val file = sc.textFile()
Val cnt = file.flatMap(line =>line.split(“ ”)).map(word=>(word,1)).reduceByKey(+)
ReduceByKey在Scala里面没有

6.RDD怎么来？
RDD本质是只读的、可分区的分布式数据集的描述（数据集的集合）

1. 读取数据
2. 通过别的RDD转换过来
3. Dataframe过来，这样可以从hive过来数据

容错方式：1.备份数据 2.记录更新（记录对数据的操作）方式
懒操作：延迟计算，只有action的时候才执行

宽依赖（shuffing过程，一对多）和窄依赖（一对一）有什么用？：
Stage划分：是在任务和数据都没有执行的时候就生成了
1.划分stage：去掉宽依赖的边，剩下的partition部分，宽依赖划分到不同stage，窄依赖在同一stage，每个stage中无需进行shuffing操作。
2.容错
每个partation就是一个task，task是调度的基本单位

三种模式的比较
Local :本地单机的形式
Spark standalone 是spark本身集群的一个模式，不是本地模式，也不是yarn模式，系统自带的一种模式。
Yarn client ：用于交互与调试，driver在任务提交机器上执行；AM只负责向RM申请executor需要的资源；基于yarn时，spark-shell和pyspark必须使用yarn-client模式
Yarn cluster：用于生产环境