大数据科学与技术面试题（大数据面试题parkStreaming知识点总结）
大数据科学与技术面试题（大数据面试题parkStreaming知识点总结）Kill 命令：yarn application -kill 后面跟 applicationid把spark.streaming.stopGracefullyOnShutdown参数设置成ture Spark会在JVM关闭时正常关闭StreamingContext 而不是立马关闭通过spark.streaming.kafka.maxRatePerPartition参数来设置Spark Streaming从kafka分区每秒拉取的条数把spark.streaming.backpressure.enabled 参数设置为ture 开启背压机制后Spark Streaming会根据延迟动态去kafka消费数据 上限由spark.streaming.kafka.maxRatePerPartition参数控制，所以两个参数一般会一起使用Spark Streaming stage耗时由最慢的task决
kafka参数 auto.offset.reset 参数设置成earliest 从最初始偏移量开始消费数据
2 Spark Streaming精准一次消费1. 手动维护偏移量
2. 处理完业务数据后，再进行提交偏移量操作
极端情况下，如在提交偏移量时断网或停电会造成spark程序第二次启动时重复消费问题，所以在涉及到金额或精确性非常高的场景会使用事物保证精准一次消费
3 Spark Streaming控制每秒消费数据的速度通过spark.streaming.kafka.maxRatePerPartition参数来设置Spark Streaming从kafka分区每秒拉取的条数
4 Spark Streaming背压机制把spark.streaming.backpressure.enabled 参数设置为ture 开启背压机制后Spark Streaming会根据延迟动态去kafka消费数据 上限由spark.streaming.kafka.maxRatePerPartition参数控制，所以两个参数一般会一起使用
5 Spark Streaming 一个stage耗时Spark Streaming stage耗时由最慢的task决定 所以数据倾斜时某个task运行慢会导致整个Spark Streaming都运行非常慢。
6 Spark Streaming 优雅关闭把spark.streaming.stopGracefullyOnShutdown参数设置成ture Spark会在JVM关闭时正常关闭StreamingContext 而不是立马关闭
Kill 命令：yarn application -kill 后面跟 applicationid
7 Spark Streaming 默认分区个数Spark Streaming默认分区个数与所对接的kafka topic分区个数一致，Spark Streaming里一般不会使用repartition算子增大分区，因为repartition会进行shuffle增加耗时
8 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方式
9 简述SparkStreaming窗口函数的原理（重点）窗口函数就是在原来定义的SparkStreaming计算批次大小的基础上再次进行封装，每次计算多个批次的数据，同时还需要传递一个滑动步长的参数，用来设置当次计算任务完成之后下一次从什么地方开始计算。
图中time1就是SparkStreaming计算批次大小，虚线框以及实线大框就是窗口的大小，必须为批次的整数倍。虚线框到大实线框的距离（相隔多少批次），就是滑动步长。
