一、重点比较reduceByKey和groupByKey:
相同点：
1,都作用于 RDD[K,V]
2，都是根据key来分组聚合
3， 默认，分区的数量都是不变的，但是都可以通过参数来指定分区数量
不同点：
1， groupByKey默认没有聚合函数，得到的返回值类型是RDD[ k,Iterable[V]]
2， reduceByKey 必须传聚合函数 得到的返回值类型 RDD[(K,聚合后的V)]
3， groupByKey().map() = reduceByKey
最重要的区别：
reduceByKey 会进行分区内聚合，然后再进行网络传输
groupByKey 不会进行局部聚合
结论：
如果这两个算子，都可以使用， 优先使用reduceByKey
二、checkpoint是啥
简单点说，就是将正在运行的任务的状态保存下来。这个状态包括任务中每个算子的state，缓存的数据（比如processFunction）等。可以保存在hdfs，磁盘等。
为什么需要checkpoint
当flink的任务或者机器挂掉了，重新启动任务时需要将任务恢复到原来的状态。
三、在flink中定义了三类时间：
事件时间（Event Time）：即事件实际发生的时间。
处理时间（Processing Time）：事件被处理的时间。
进入时间（Ingestion Time）：事件进入流处理框架的时间
四、时间窗口
窗口主要有两种，一种基于时间（Time-based Window），一种基于数量（Count-based Window）。本文主要讨论Time-based Window，在Flink源码中，用TimeWindow表示。每个TimeWindow都有一个开始时间和结束时间，表示一个左闭右开的时间段
滚动窗口下窗口之间之间不重叠，且窗口长度是固定的。
滑动窗口以一个步长（Slide）不断向前滑动，窗口的长度固定。使用时，我们要设置Slide和Size。Slide的大小决定了Flink以多大的频率来创建新的窗口，Slide较小，窗口的个数会很多。Slide小于窗口的Size时，相邻窗口会重叠，一个事件会被分配到多个窗口；Slide大于Size，有些事件可能被丢掉。
会话窗口根据Session gap切分不同的窗口，当一个窗口在大于Session gap的时间内没有接收到新数据时，窗口将关闭。在这种模式下，窗口的长度是可变的，每个窗口的开始和结束时间并不是确定的。
五、ack有3个可选值，分别是1，0，-1。
ack=1，简单来说就是，producer只要收到一个分区副本成功写入的通知就认为推送消息成功了。这里有一个地方需要注意，这个副本必须是leader副本。只有leader副本成功写入了，producer才会认为消息发送成功。
ack=0，简单来说就是，producer发送一次就不再发送了，不管是否发送成功。
ack=-1，简单来说就是，producer只有收到分区内所有副本的成功写入的通知才认为推送消息成功了。
六、Hive建模
1.1 星型
多张维度表，一张事实表，维度表之间没有关系。查询性能要好些,存储有冗余的。星型模型使用的比较多。
1.2 雪花型
雪花型是星型建模的扩展，维度表之间有关系。存储减少冗余，查询性能有损失，需要多级连接。和星型模型的共性就是只有一张是事实表。
1.3 星座型
星座型也是星型模型的扩展，存在多张事实表。
七、spark对于kafka的偏移量
前提是设置手工提交偏移量 “enable.auto.commit” -> (false: java.lang.Boolean)
进入RDD获取
val offsetRanges = rdd.asInstanceOf[HasOffsetRanges].offsetRanges
手工提交偏移量
stream.asInstanceOf[CanCommitOffsets].commitAsync(offsetRanges)
1、kafka的偏移量保存在哪里?
以前是保存在kafka里面,但是kafka用于做持久化没问题,但是频繁写入并不合适,现在是保存在一个topic里面(__consumer_offsets)
2、auto.offset.reset配置
earliest
当各分区下有已提交的offset时,从提交的offset开始消费,无提交的offset时,从头开始消费
latest
当各分区下有已提交的offset时,从提交的offset开始消费,无提交的offset时,消费新产生的该分区下的数据
none
topic各分区都存在已提交的offset时,从offset后开始消费,只要有一个分区不存在已提交的offset,则跑出异常
3、SpparkStreaming第一次运行不丢失数据
kafka参数auto.offset.reset设置为earliest从最初的偏移量开始消费数据
4、SparkStreaming精准一次性消费
导致非精准一次性消费的原因:
偏移量写入,但消费数据时宕机(丢失数据)
消费数据,但是写入是宕机(重复消费数据)
精确一次消费（Exactly-once）是指消息一定会被处理且只会处理一次。不多不少就一次处理。
如果达不到精确一次消费，可能会达到另外两种情况：
至少一次消费（at least once） 主要是保证数据不会丢失,但是可能存在数据重复
最多一次消费(at most once) 主要是保证数据不会重复,但是有可能存在数据丢失问题
如果同时解决了数据丢失和数据重复的问题,就实现了精准一次消费.
首先解决数据丢失问题,办法是等数据保存成功后在提交偏移量,必须手工来控制偏移量的提交时机.
但是如果数据保存了,没等偏移量提交进程挂了,数据就会被重复消费.所以开发的时候要保证同一批数据反复保存多次,数据不会翻倍,保存一次和多次效果是一样的.
在实际中,并不能保证不重复消费,所以优先保证数据不丢失,即保证至少一次消费
5、flink的 checkpoint 机制对比spark 有什么不同和优势?
sparkStreaming 的checkpoint 仅仅是针对driver 的故障恢复做了数据和元数据的 checkpoint.
flink的checkpoint ,它采用的是轻量级的分布式快照,实现了每个算子的快照,以及流动中的数据快照.
6、默认情况下，flink在checkpoint 上提交偏移量.
kafkaConsumer.setCommitOffsetsonCheckpoints(true); 设置为true,flink会把offset 提交给kafka.
乱序问题,在后面通过offset对数据进行排序
7、说说分区表和分桶表的区别?
分区表:hive数据表可以根据某些字段进行分区操作,细化数据管理,让部分查询更快,不同分区对应不同目录.
分桶表:表和分区也可以进一步被划为桶,分桶是相对分区进行更细粒度的划分.分桶将整个数据内容按照某列属性值的hash值进行区分,不同的桶对应不同的文件.
