One stack to rule them all!
先来看一下:MapReduce的流程图:
首先从hdfs上取来数据,map任务加载进来解析成kv形式,通过inputformat格式进行解析,然后在
环形缓冲区进行缓存排序,然后把排好序的文件分发到磁盘上面,通过partitions进行分片,然后把一片片
已经内部排好序的分片传到下一个reduce上去,然后merge合成同一个大文件,然后reduce,到外部数据。
spark执行快的原因:1内存计算 2 DAG
RDD:resilient distributed dataset 一切以RDD为基础
通过lineage进行容错,一个挂掉 很快进行并行重新计算再次得到结果
窄依赖:一对一 适合流水化 宽依赖:一对多 遵照传统的MapReduce模式
spark内核:
每个应用都有自己对应的executor,应用代码发送到各个executor中去执行,sparkcontext发送task到executor
中去根据代码执行,executor以多线程方式执行任务
rdd被分为多个区 每个区都会生成一个task
看懂这个任务调度 就能掌握spark的80% 如图第二格中 一个stage和另一个stage 然后shuffle的时候产生另外一个stage
为每一个job来生成一个DAG,把图分为tasks的集合stage(Taskset),最后以stage为单位进行提交, 然后第三格,集群管理器(standalone,mesos,yarn)提交tasks,提交给executor,blockmanager用来管理存储于缓存
RDD:
1 分区(是一个分区的集合数组) 2 依赖 (seq依赖关系序列)
3 函数(根据每个分区进行函数处理) 4 最佳位置(选择最近的位置作为数据处理与分发)
5 分区策略(如:hashpartitioner)
当存在很多小任务或者空分区时候,可以使用coalesce 或repartition(底层调用coalesce)来重新分区
sparkstreaming:
首先看下storm
nimbus负责资源分配与调度 zk管理supervisor supervisor负责管理worker
sparkstreaming特有的transformation:
1带状态的操作:updateStateByKey
2window操作window,countByWindow,reduceByWindow,countByValueWindow,reduceByKeyAndWindow
window和stateful默认持久化
其余的transformation和spark一致
过多的reducer会造成很多的小任务,传递任务task的开销会很大,过少的reducer 会导致处理太多的东西导致内存爆掉,不能充分发挥机子资源的利用率
shark:已经被归入spark sql 2014年