问题
为什么需要streamming,不用行不行？
streamming运行机制？
1.从Kafka拉数据
方式：1）利用Receiver接收数据（个人理解对读数据得一种封装）
*持续接收消息
*从Zookeeper中读取offset值
2）直接从kafka读取数据；
Kafka中的partition与RDD中的partition是一一对应；
高效（在Receiver的方式中，为了达到0数据丢失需要将数据存入Write Ahead Log中，这样在Kafka和日志中就保存了两份数据），精确一次（offset需要自己记录）
2.写数据到Kafka
1）需要使用底层Kafka接口进行包装
2）KafkaProducer利用lazy val的方式进行包装
duration作用？
间隔多久提交一次job,即拉取数据处理数据的程序
优化方案？
合理的批处理时间（batchDuration）：如果过小，提交的job会不断累计导致任务堆积
合理的Kafka拉取量（maxRatePerPartition重要）：
缓存反复使用的Dstream（RDD）：缓存反复使用的该数据，减少网络传输开销
设置合理的GC：垃圾回收机制
设置合理的CPU资源数：可减少excutor占用cpu的数量，增加excutor的数量来缓解
设置合理的parallelism：partition指目前数据的partition数量，而spark.default.parallelism指进行shuffle之后默认的partition数量
使用高性能的算子：
使用reduceByKey/aggregateByKey替代groupByKey
使用mapPartitions替代普通map
使用foreachPartitions替代foreach
使用filter之后进行coalesce操作
使用repartitionAndSortWithinPartitions替代repartition与sort类操作
使用Kryo优化序列化性能：1.使用外部变量；2.使用自定义RDD类型,3.使用MEMORY_ONLY_SER进行持久化可优化
其他
coalesce与repartition:
coalesce不会shuffle,如果文件有5个，想要变为4个，那么5个excutor可能有1，2，3，4个excutor不跑，则实现不shuffle,减少partition,其实减少excutor串行读数据
比较其执行效率和源partition个数，excutorNum和excutor core有关，且coalesce可能导致OOM问题
引用：
https://www.cnblogs.com/jiangxiaoxian/p/9539760.html
repartition只是coalesce接口中shuffle为true的实现
引用：https://zhuanlan.zhihu.com/p/60385803
