SparkStreaming面试题

1. SparkStreaming第一次运行不丢失数据

kafka参数auto.offset.reset设置为earliest从最初的偏移量开始消费数据。

2. SparkStreaming精准一次性消费

1. 导致非精准一次性消费的原因：
   - 偏移量写入，但消费数据时宕机（丢失数据）
   - 消费数据，但写入偏移量时宕机（重复消费数据）
2. 解决：
   事务。将消费数据和偏移量写入绑定为原子性操作，一起成功或失败。

3. SparkStreaming控制每秒消费数据的速度

设置spark.streaming.kafka.maxRatePerPartition参数来控制每秒从kafka拉取的条数

4. SparkStreaming背压机制

spark.streaming.backpressure.enabled参数为true，此时SparkStreaming会动态消费kafka中的数据，spark.streaming.kafka.maxRatePerPartition为上限。一般会同时设置这两个参数。

5. SparkStreaming一个stage的耗时

SparkStreaming中stage的耗时时长由最慢的task决定。因此数据倾斜时某个task运行慢会导致整个SparkStreaming运行慢。

6. 关闭SparkStreaming

流失任务需要7*24小时运行，但有时需要升级需要主动停止程序，分布式程序又无法做到一个个杀死进程。因此可以通过设置spark.streaming.stopGracefullyOnShutdown为true来根据JVM关闭而关闭StreamingContext。

7. SparkStreaming默认分区个数

SparkStreaming默认分区个数与所对接的kafka分区个数一致。SparkStreaming中一般不会使用repartition算子增加分区，因为会涉及到shuffle操作。

8. SparkStreaming消费kafka中数据的两种方式

1. Receiver方式
   - revicer从kafka中获取的数据都是存储在Spark Executor的内存中（如果数据量暴增，很容易发生OOM），然后Spark会启动job去处理这些数据。
   - 然而默认配置下，这种方式可能会因为底层的失败或宕机丢失数据。如果要启用高可用机制，就必须启用SparkStreaming的预写机制（WAL）。该机制会同步的将接收到的kafka的数据写入分布式文件系统。当出现意外时，可以通过预写日志进行恢复。
2. Direct方式
   - 这种方式会周期性的查询kafka来获得每个topic+partition的最新的offset，从而定义每个batch的offset范围。当处理数据的job启动后，使用低阶consumer api来获取Kafka指定offset范围的数据。
   - 优点1：简化并行读取。若读取多个partition数据，不需要创建多个DStream然后对数据进行合并操作，Spark会创建和Kafka分区数一样多的RDD partition，然后并行从kafka中读取数据；
   - 优点2：高性能。在基于Reciver的方式中，保证零数据丢失的方式时开启WAL机制，这种机制性能不高，相当于存储了两份数据，kafka本身就有高可用机制，会默认对数据复制一次，而WAL又复制一份。而Direct不需要对数据进行备份，直接通过Kafka副本进行恢复。
   - 一次且仅一次的事务机制。
3. 对比
   - receiver方式是kafka高阶API在zookeeper中保存offset，配合WAL可以保证数据零丢失，但是无法保证数据被处理一次，可也能两次。因为Spark和zookeeper可能不同步。
   - direct使用kafka低阶API，SparkStreaming自动追踪消费的offset，并保存在checkpoint中。Spark自己是同步的，因此可以保证数据消费一次且仅消费一次。因此在实际生产环节使用Direct。

9. 简述SparkStreaming窗口函数的原理

窗口函数就是在原来的SparkStreaming计算批次大小的基础上再次进行封装，每次计算多个批次的数，同时还需要传递一个滑动步长的参数，用来设置当次计算任务完成后下一次从什么地方开始计算。需要注意的是，滑动步长必须是采集周期大小的整数倍。