sparkstreaming总结
实时计算
spark是微批处理， 每隔一段时间处理一次
flink 实时处理，每一条数据都会处理
将接收过来的数据，封装成一个rdd，执行rdd的计算
有状态算子
updataStateBykey
需要开启checkpoint,(需要保存之间计算的结果)
reduceBykeyAndWindow
统计最近一段时间的数据，每隔一段时间统计一次
优化版本，需要一个减的函数
sql on stream
通过sparkSession之间创建流的DF. 在流上面写sql
SparkSession
统一spark 入口，统一api 流批统一
流 和批 join
Spark Streaming第一次运行不丢失数据
kafka参数 auto.offset.reset 参数设置成earliest 从最初始偏移量开始消费数据
精准一次消费
1.手动维护偏移量
2.处理完业务数据后，再进行提交偏移量操作
极端情况下，如在提交偏移量时断网或停电会造成spark程序第二次启动时重复消费问题，所以在涉及到金额或精确性非常高的场景会使用事物保证精准一次消费
Spark Streaming控制每秒消费数据的速度
通过spark.streaming.kafka.maxRatePerPartition参数来设置Spark Streaming从kafka分区每秒拉取的条数
Spark Streaming背压机制
把spark.streaming.backpressure.enabled 参数设置为ture,开启背压机制后Spark Streaming会根据延迟动态去kafka消费数据,上限由spark.streaming.kafka.maxRatePerPartition参数控制，所以两个参数一般会一起使用
Spark Streaming 一个stage耗时
Spark Streaming stage耗时由最慢的task决定,所以数据倾斜时某个task运行慢会导致整个Spark Streaming都运行非常慢。
Spark Streaming 优雅关闭
把spark.streaming.stopGracefullyOnShutdown参数设置成ture,Spark会在JVM关闭时正常关闭StreamingContext,而不是立马关闭
Kill 命令：yarn application -kill 后面跟 applicationid
Spark Streaming 默认分区个数
Spark Streaming默认分区个数与所对接的kafka topic分区个数一致，Spark Streaming里一般不会使用repartition算子增大分区，因为repartition会进行shuffle增加耗时
SparkStreaming有哪几种方式消费Kafka中的数据，它们之间的区别是什么？
一、基于Receiver的方式
这种方式使用Receiver来获取数据。Receiver是使用Kafka的高层次Consumer API来实现的。receiver从Kafka中获取的数据都是存储在Spark Executor的内存中的（如果突然数据暴增，大量batch堆积，很容易出现内存溢出的问题），然后Spark Streaming启动的job会去处理那些数据。
然而，在默认的配置下，这种方式可能会因为底层的失败而丢失数据。如果要启用高可靠机制，让数据零丢失，就必须启用Spark Streaming的预写日志机制（Write Ahead Log，WAL）。该机制会同步地将接收到的Kafka数据写入分布式文件系统（比如HDFS）上的预写日志中。所以，即使底层节点出现了失败，也可以使用预写日志中的数据进行恢复。
二、基于Direct的方式
这种新的不基于Receiver的直接方式，是在Spark 1.3中引入的，从而能够确保更加健壮的机制。替代掉使用Receiver来接收数据后，这种方式会周期性地查询Kafka，来获得每个topic+partition的最新的offset，从而定义每个batch的offset的范围。当处理数据的job启动时，就会使用Kafka的简单consumer api来获取Kafka指定offset范围的数据。
优点
简化并行读取：如果要读取多个partition，不需要创建多个输入DStream然后对它们进行union操作。Spark会创建跟Kafka partition一样多的RDD partition，并且会并行从Kafka中读取数据。所以在Kafka partition和RDD partition之间，有一个一对一的映射关系。
高性能：如果要保证零数据丢失，在基于receiver的方式中，需要开启WAL机制。这种方式其实效率低下，因为数据实际上被复制了两份，Kafka自己本身就有高可靠的机制，会对数据复制一份，而这里又会复制一份到WAL中。而基于direct的方式，不依赖Receiver，不需要开启WAL机制，只要Kafka中作了数据的复制，那么就可以通过Kafka的副本进行恢复。
一次且仅一次的事务机制。
对比
基于receiver的方式，是使用Kafka的高阶API来在ZooKeeper中保存消费过的offset的。这是消费Kafka数据的传统方式。这种方式配合着WAL机制可以保证数据零丢失的高可靠性，但是却无法保证数据被处理一次且仅一次，可能会处理两次。因为Spark和ZooKeeper之间可能是不同步的。
基于direct的方式，使用kafka的简单api，Spark Streaming自己就负责追踪消费的offset，并保存在checkpoint中。Spark自己一定是同步的，因此可以保证数据是消费一次且仅消费一次。
在实际生产环境中大都用Direct方式
简述SparkStreaming窗口函数的原理
窗口函数就是在原来定义的SparkStreaming计算批次大小的基础上再次进行封装，每次计算多个批次的数据，同时还需要传递一个滑动步长的参数，用来设置当次计算任务完成之后下一次从什么地方开始计算。
数据倾斜表现
hadoop中的数据倾斜表现
有一个多几个Reduce卡住，卡在99.99%，一直不能结束。
各种container报错OOM
异常的Reducer读写的数据量极大，至少远远超过其它正常的Reducer
伴随着数据倾斜，会出现任务被kill等各种诡异的表现。
hive中数据倾斜
一般都发生在Sql中group by和join on上，而且和数据逻辑绑定比较深
Spark中的数据倾斜
Executor lost，OOM，Shuffle过程出错；
Driver OOM；
单个Executor执行时间特别久，整体任务卡在某个阶段不能结束；
正常运行的任务突然失败；
数据倾斜产生原因
（1）key分布不均
（2）建表时考虑不周
两个人开发的数据表，表都没错，但是在关联的时候，也就是sql的on阶段卡死
（3）业务数据激增
订单场景：只有其中两个城市订单增长了很大，其他未增长，在group操作时，就会产生数据倾斜
以Spark和Hive的使用场景为例。
在做数据运算的时候会涉及到，count distinct、group by、join on等操作，这些都会触发Shuffle动作。一旦触发Shuffle，所有相同key的值就会被拉到一个或几个Reducer节点上，容易发生单点计算问题，导致数据倾斜。
解决数据倾斜思路
1、业务逻辑
我们从业务逻辑的层面上来优化数据倾斜，比如上面的两个城市做推广活动导致那两个城市数据量激增的例子，我们可以单独对这两个城市来做count，单独做时可用两次MR，第一次打散计算，第二次再最终聚合计算。完成后和其它城市做整合。
2、程序层面
在Hive中，经常遇到count(distinct)操作，这样会导致最终只有一个Reduce任务。 可以先group by ，再在外面包一层count
计算按用户名去重后的总用户量：
（1）优化前 只有一个reduce，先去重再count负担比较大：
select name,count(distinct name)from user;
（2）优化后
// 设置该任务的每个job的reducer个数为3个。Hive默认1，自动推断。
set mapred.reduce.tasks=3;
// 启动两个job，一个负责子查询(可以有多个reduce)，另一个负责count(1)：
select count(1) from (select name from user group by name) tmp;
3、调参方面
Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜，合理利用它们就能解决大部分问题。
4、从业务和数据上解决数据倾斜
有损的方法：找到异常数据，比如ip为0的数据，过滤掉
无损的方法：对分布不均匀的数据，单独计算
先对key做一层hash，先将数据随机打散让它的并行度变大，再汇集
数据预处理
定位数据倾斜代码1
spark数据倾斜只能发生在shuffle过程中
罗列一些常用的并且可能会触发shuffle操作的算子：distinct、groupByKey、reduceByKey、aggregateByKey、join、cogroup、repartition等。
出现数据倾斜可能就是使用了这些算子中的某一个导致的
定位数据倾斜代码2
某个task执行特别慢
1、先看数据倾斜发生在第几个Stage中（查看log）
2、看task运行时间和数据量
有的task运行特别快几秒就结束了，有的运行很慢时间很长，单从运行时间上看就确定 发生数据倾斜了
倒数第一列显示了task处理的数据量，有的task处理量小，而有的task处理量很大，相差很多倍就可以断定发生了数据倾斜
3、推断倾斜代码
知道倾斜发生在哪一个stage后，根据stage划分原理，推断倾斜的stage对应哪一段代码（肯定有一个shuffle类算子）
某个task莫名出现内存溢出
通过异常栈信息可以定位代码哪一行发生了内存溢出
