RDD是Spark中的核心数据模型，一个RDD代表着一个被分区(partition)的只读数据集。
RDD的生成只有两种途径：
一种是来自于内存集合或外部存储系统；
另一种是通过转换操作来自于其他RDD；
一般需要了解RDD的以下五个接口：
| partition | 分区，一个RDD会有一个或者多个分区 |
| dependencies() | RDD的依赖关系 |
| preferredLocations(p) | 对于每个分区而言，返回数据本地化计算的节点 |
| compute(p,context) | 对于分区而言，进行迭代计算 |
| partitioner() | RDD的分区函数 |
一个RDD包含一个或多个分区，每个分区都有分区属性，分区的多少决定了对RDD进行并行计算的并行度。
窄依赖:
每一个父RDD的分区最多只被子RDD的一个分区所使用，(只有一个独子)
宽依赖:
子 RDD 多个分区会依赖同一个 RDD 分区, 父RDD 的一个分区被多次依赖
RDD 分区函数:
目前Spark中实现了两种类型的分区函数，HashPartitioner(哈希分区)和RangePartitioner(区域分区)。
保存到hadoop
saveAsHadoopFile,saveAsHadoopDataset
saveAsTextFile、saveAsSequenceFile、saveAsObjectFile
aggregate
def aggregate[U](zeroValue: U)(seqOp: (U, T) ⇒ U, combOp: (U, U) ⇒ U)(implicit arg0: ClassTag[U]): U
aggregate用户聚合RDD中的元素，先使用seqOp将RDD中每个分区中的T类型元素聚合成U类型，再使用combOp将之前每个分区聚合后的U类型聚合成U类型，特别注意seqOp和combOp都会使用zeroValue的值，zeroValue的类型为U。
fold
def fold(zeroValue: T)(op: (T, T) ⇒ T): T
fold是aggregate的简化，将aggregate中的seqOp和combOp使用同一个函数op。
first
def first(): T
first返回RDD中的第一个元素，不排序。
reduce
def reduce(f: (T, T) ⇒ T): T
根据映射函数f，对RDD中的元素进行二元计算，返回计算结果
collect
def collect(): Array[T]
collect用于将一个RDD转换成数组。
注册类到 kryo
val conf = new SparkConf().setMaster(...).setAppName(...)
conf.registerKryoClasses(Array(classOf[MyClass1], classOf[MyClass2]))
val sc = new SparkContext(conf)
任务的并行度由分区数(Partitions)决定，一个Stage有多少分区，就会有多少Task。每个Task默认占用一个Core，一个Executor上的所有core共享Executor上的内存，一次并行运行的Task数等于num_executor*executor_cores，如果分区数超过该值，则需要运行多个轮次，一般来说建议运行3～5轮较为合适，否则考虑增加num_executor或executor_cores。由于一个Executor的所有tasks会共享内存executor_memory，所以建议executor_cores不宜过大。executor_memory的设置则需要综合每个分区的数据量以及是否有缓存等逻辑。
1.num-executors 执行器个数,一般设置在50-100之间，必须设置，不然默认启动的executor非常少，不能充分利用集群资源，运行速度慢
2.executor-memory 线程内存：执行器内存 参考值4g-8g,num-executor乘以executor-memory不能超过队列最大内存，申请的资源最好不要超过最大内存的1/3-1/2
3.executor-cores 线程, 执行器 cpu 个数. CPU core数量：core越多，task线程就能快速的分配，参考值2-4，num-executor*executor-cores的1/3-1/2
1.spark-submit spark提交
2.--queue spark 在spark队列
3.--master yarn 在yarn节点提交
4.--deploy-mode client 选择client模型，还是cluster模式；在同一个节点用client,在不同的节点用cluster
5.--executor-memory=4G 线程内存：参考值4g-8g,num-executor乘以executor-memory不能超过队列最大内存，申请的资源最好不要超过最大内存的1/3-1/2
6.--conf spark.dynamicAllocation.enabled=true 是否启动动态资源分配
7.--executor-cores 2 线程CPU core数量：core越多，task线程就能快速的分配，参考值2-4，num-executor*executor-cores的1/3-1/2
8.--conf spark.dynamicAllocation.minExecutors=4 执行器最少数量
9.--conf spark.dynamicAllocation.maxExecutors=10 执行器最大数量
10.--conf spark.dynamicAllocation.initialExecutors=4 若动态分配为true,执行器的初始数量
11.--conf spark.executor.memoryOverhead=2g 堆外内存：处理大数据的时候，这里都会出现问题，导致spark作业反复崩溃，无法运行；此时就去调节这个参数，到至少1G（1024M），甚至说2G、4G）
12.--conf spark.speculation=true 推测执行：在接入kafaka的时候不能使用，需要考虑情景
13.--conf spark.shuffle.service.enabled=true 提升shuffle计算性能
--total-executor-cores
--conf spark.driver.extraJavaOptions 配置的是Driver的 JVM 参数
--confi spark.executor.extraJavaOptions 配置Driver的 JVM 参数
此参数用于设置每个stage经TaskScheduler进行调度时生成task的数量，此参数未设置时将会根据读到的RDD的分区生成task，即根据源数据在hdfs中的分区数确定，若此分区数较小，则处理时只有少量task在处理，前述分配的executor中的core大部分无任务可干。通常可将此值设置为num-executors*executor-cores的2-3倍为宜，如果与其相近的话，则对于先完成task的core则无任务可干。2-3倍数量关系的话即不至于太零散，又可是的任务执行更均衡。
Spark Streaming提供了两类内置的流媒体源。
- 基本来源：可直接在StreamingContext API中获得的来源。示例：文件系统和套接字连接。
- 高级资源：可通过额外的实用程序类获得诸如Kafka，Kinesis等资源。如链接部分所述，这些要求针对额外的依赖项进行 链接
File Streams
streamingContext.fileStream[KeyClass, ValueClass, InputFormatClass](dataDirectory)
For text files
streamingContext.textFileStream(dataDirectory)
Spark Streaming将监视目录dataDirectory并处理在该目录中创建的所有文件, 忽略更新
groupBykey yu reduceByKey的区别
/*
groupByKey：groupByKey会对每一个RDD中的value值进行聚合形成一个序列(Iterator)，
此操作发生在reduce端，所以势必会将所有的数据通过网络进行传输，造成不必要的浪费。
同时如果数据量十分大，可能还会造成OutOfMemoryError。
*/
//reduceByValue，先进行局部聚合，再进行全局聚合
val res14 = res11.reduceByKey(_ + _)
/*reduceByKey：reduceByKey会在结果发送至reducer之前会对每个mapper在本地进行merge，
有点类似于在MapReduce中的combiner。这样做的好处在于，在map端进行一次reduce之后，
数据量会大幅度减小，从而减小传输，保证reduce端能够更快的进行结果计算。
*/
MapReduce和Spark一个本质的区别：
在MapReduce里，每一个task都在它自己的进程里，map对应maptask，reduce对应reducetask，这些都是进程，当一个task完成（maptask或者reducetask）后，这个task进程就结束了。
但是在Spark里面是不一样的，在Spark里面，它的task能够并发的运行在一个进程里，就是说一个进程里面可以运行多个task，而且这个进程会在Spark Application的整个生命周期一直存在，Spark Application是包含一个driver和多个executor的，即使你的作业不再运行了，job运行完了，没有作业在running，它的executor还是一直在的，
对比MapReduce和Spark可知，MapReduce是基于进程的base-process，Spark是基于线程的base-thread。
这样的话，Spark带来的好处就是：
如果是MR的话，你跑task的进程资源都要去申请，用完之后就销毁；但是Spark的话，只要一开始拿到了这些进程资源，后面所有的作业，不需要申请资源，就可以直接快速的启动，是非常的快。用内存的方式进行计算。
一些概念:
一个Spark应用程序包含一个driver和多个executor。
Driver program是一个进程，它运行应用程序application里面的main()函数，并在main函数里面创建SparkContext。
在main函数里面创建了一堆RDD，遇到action的时候会触发job，所以程序会有很多job。
job：由Spark action触发的由多个tasks组成的并行计算。当一个Spark action（如save, collect）被触发，一个包含很多个tasks的并行计算的job将会生成。
每个job被切分成小的任务集，这些小的任务集叫做stages。
task是被发送给一个executor的最小工作单元。每个executor上面可以跑多个task。
Executor：在worker node上启动应用程序的进程，这个进程可以运行多个任务并将数据保存在内存或磁盘存储中。每个Spark应用程序都有它自己的一组executors。executor运行在Container里面。
executor是进程级别，一个进程上面可以并行的跑多个线程的，所以每个executor上面可以跑多个task。
ApplicationMaster：AM
每一个YARN上面的Application都有一个AM，这个AM进程，是在第一个Container里运行的，就是说第一个Container就是来运行AM的，AM去和RM互相通信请求资源，然后拿到资源后告诉NM，让NM启动其它的Container，给我们的进程使用，比如去跑executor。
是所有executor总共使用的cpu核数 standalone default all cores