问题总结：

hadoop三大组件

hdfs

1. 组成架构：client、namenode、datanode、secondaryNode
2. 读流程
3. 写流程

hive

1. hive sql怎么去调优

Yarn

1. 工作流程

spark

1. 血缘
2. 和flink的区别

Mapreduce

1. 流程：input
2. splitting
3. recorder reader
4. shuffle
5. reduce
6. reduce task 是自己可以改的
7. map task

kafka

1. 各个组件
2. 和zookeeper的关系
3. kafka为什么快：https://blog.youkuaiyun.com/zl1zl2zl3/article/details/107963699
4. ack 0 1 -1什么意思
   https://note.youdao.com/ynoteshare1/index.html?id=ea901adeabc27a7042a673eefa93fbd6&type=note
5. 读写分离
6. 消息顺序
7. 选举策略
8. 可重复、高可用性
9. kafka的事务怎么理解的，怎么实现的
10. kafka丢消息的情况，发送消息失败
11. 并行度不一样会造成数据堆积，溢出的数据去哪里了
12. kafka更新的频率是多少

flink

1. 数据倾斜
2. 数据反压
3. 数据不丢失
4. 数据不重复
5. state
6. flink、spark steaming区别
7. flink组件
8. 常用算子
9. 重启策略
10. 窗口
11. flink时间
12. flink水印 watermark
13. flink sql
14. flink数据不丢失：checkpoint state
    flink快照之间，节点挂了怎么办：https://zhuanlan.zhihu.com/p/43536305
    https://zhuanlan.zhihu.com/p/34358365
    https://zhuanlan.zhihu.com/p/263831130
    内部eos：所以当应用程序故障时，为了保证数据消费 Exactly Once， Flink 是通过周期性进行 Checkpoint 机制来解决这个问题。每次做 Checkpoint 的时候，会把当前消费 Kafka 的 offset，计算结果等写入到状态后端中。任务挂了的时候，只需要从最近的一次成功的Checkpoint 中，拿到 offset 和 计算结果，从这个地方接着开始消费和计算就行了。

外部eos：Flink 将二阶段提交的逻辑放在 Checkpoint 的过程之中。
实现类为：TwoPhaseCommitSinkFunction
Flink 的 JobManager 对应到 2PC 的协调者，Operator 实例对应到 2PC 的参与者。

第一个阶段： invoke() 和 preCommit() 全部成功了，才表示第一个阶段成功了。
第二个阶段：所有实例，都快照完成，并执行完preCommit 时，会把快照完成的消息发送给 JobManager，JobManager 收到后会认为本次 Checkpoint 完成了，会向所有的实例发送 Checkpoint 完成的通知（Notify Checkpoint Completed），当 Sink 算子收到这个通知之后，就会执行 commit 方法正式提交。

flink消费kafka的offset，存在哪里：
1、http://wuchong.me/blog/2018/11/04/how-apache-flink-manages-kafka-consumer-offsets/
2、https://www.ververica.com/blog/kafka-flink-a-practical-how-to

flink这边用过哪些state，处理的过程当中有哪些状态
什么情况下存这个状态，以及这个状态是做什么用的

flink消费kafka到数据库，怎么保证数据仅有一次
flink+checkpoint+事务
flink+checkpoint+幂等

1. flink任务启动，如果启动失败，要怎么办，比如输入量增大，上游scamper有一个变动，或者出现其它情况，任务挂了，怎么保证消费正常启动，数据不丢失，offset保存在哪里？

2. flink里面有哪些算子、有哪些窗口、状态

3. flink的优势，相比spark来说

4. flink的内存模型，怎么管理内存的，分为三个部分，主要用堆内内存，还是堆外内存

5. flink怎么保证有且只有一次的

6. flink处理反压的机制，比如外边接收端来不及接受了，怎么处理

7. flink对flink sql怎么执行，对flink api是怎么执行的流程，怎么解析，怎么执行

8. 分布式锁，分布式算法这种

9. flink是基于什么搭建的，yarn集群搭建

10. flink原理：flink重启策略，固定延迟重启策略是什么样的，默认值是什么，你是怎么设置的

11. flink的task slot原理：http://wuchong.me/blog/2016/05/09/flink-internals-understanding-execution-resources/

12. flink的内存调优：https://zhuanlan.zhihu.com/p/360240036

13. flink重启策略：https://www.jianshu.com/p/4be0fa07f29d
    https://zhuanlan.zhihu.com/p/180478618

14. flink的水印：https://www.cnblogs.com/starzy/p/11439997.html

15. flink的state：https://blog.youkuaiyun.com/lzxlfly/article/details/108687266
    Flink是一个默认就有状态的分析引擎，为避免Task在处理过程中挂掉了，而导致内存中的数据丢失，Flink引入了State和CheckPoint机制，其中State就是Flink的一种基于内存的状态机制，Flink提供了两种基本的状态类型。
    Keyed States：记录每个Key对应的状态值一个Task上可能包含多个Key不同Task上不会出现相同的Key ，常用的 MapState, ValueState
    Operator States：记录每个Task对应的状态值数据类型
    https://cloud.tencent.com/developer/article/1792720
    https://toutiao.io/posts/tmf92or/preview

16. Flink集群的角色：TaskManager，JobManager，Client三种角色
    https://blog.youkuaiyun.com/GabrielCP/article/details/112688794

17. flatmap和map的区别：map：
    map方法返回的是一个object，map将流中的当前元素替换为此返回值；
    flatMap：flatMap方法返回的是一个stream，flatMap将流中的当前元素替换为此返回流拆解的流元素；
    https://blog.youkuaiyun.com/catoop/article/details/105987386
    map是对一级元素进行操作，flatmap是对二级元素操作。
    map自动返回stream对象，flatmap处理后的元素依然要是stream对象（可以用stream.of，Arrays.stream将元素转为stream对象）。
    https://blog.youkuaiyun.com/jarniyy/article/details/105234748?utm_medium=distribute.pc_relevant.none-task-blog-2_defaultbaidujs_baidulandingword~default-1.control&spm=1001.2101.3001.4242
    https://www.huaweicloud.com/articles/d077fbd452986f06aba6ffe5e9db5449.html
    https://cloud.tencent.com/developer/ask/37501

18. flink算子：https://cloud.tencent.com/developer/article/1559998
    reduce算子：reduce算子是flink流处理中的一个聚合算子，可以对属于同一个分组的数据进行一些聚合操作。
    https://blog.youkuaiyun.com/ASN_forever/article/details/106687007

19. flink算子：union 和connect算子的区别：union合并两个以上的数据流，类型必须相同；connect合并两个，类型可以不同

20. flink算子：shuffle 将随机分发数据，而 rebalance 将以循环方式分发数据。后者效率更高，因为您不必计算随机数。此外，根据随机性，您最终可能会得到某种不那么均匀的分布。

21. flink state的存储方式：
    StateBackend的意思是状态后端。
    状态后端定义了流式应用程序状态如何存储和checkpoint的。不同的状态后端以不同的方式来存储其状态，并且使用不同的数据结构来保存正在运行的应用程序的状态。
    MemoryStateBackend、FsStateBackend、RocksDBStateBackend
    https://blog.youkuaiyun.com/u010002184/article/details/106974208

22. flink的容错机制：https://segmentfault.com/a/1190000008129552

23. flink一致性：内部和端到端的一致性：
    AT-MOST-ONCE（最多一次）
    当任务故障时，最简单的做法是什么都不干，既不恢复丢失的状态，也不重播丢失的数据。At-most-once 语义的含义是最多处理一次事件。
    AT-LEAST-ONCE（至少一次）
    在大多数的真实应用场景，我们希望不丢失事件。这种类型的保障称为 at-least-once，意思是所有的事件都得到了处理，而一些事件还可能被处理多次。
    EXACTLY-ONCE（精确一次）
    恰好处理一次是最严格的保证，也是最难实现的。恰好处理一次语义不仅仅意味着没有事件丢失，还意味着针对每一个数据，内部状态仅仅更新一次
    https://blog.youkuaiyun.com/sghuu/article/details/103705177

24. 在flink中主要在于：
    1.source端 - 可重设数据的读取位置
    2.内部计算处理的保证 - 检查点的状态一致性保证
    3.sink端-从故障恢复时，数据不会重复写入到外部的系统
    1）幂等性写入 ：可以重复执行很多次，但是只会导致一次结果的更改，后面的操作不起作用
    2）事务写入 :应用程序中一系列严密操作，所有操作要么成功完成，否在每个操作都会被撤销
    具有原子性，一个事务中的一系列操作要么全部成功，要么一个都不成功
    构建的事务对应上flink的checkpoint，等到checkpoint成功时才把该checkpoint对应的数据写入到外部
    事务的实现方式：
    一.预写日志的形式
    把结果数据先当成状态保存，然后收到checkPoint完成的通知时，一次性写入到sink系统中
    简单易于实现，由于数据提前做了缓存交给了状态后端管理，所有物料说明sink系统都能用这种方式实现 flink提供了GenericWriteAheadSink模板来实现这种事务性的sink
    https://www.hnbian.cn/posts/6adf75db.html
    https://segmentfault.com/a/1190000022891333
    https://www.jianshu.com/p/02d6d1103746

25. flink的水位线：https://zhuanlan.zhihu.com/p/342271617

26. flink整个流程提交的时候，是什么结果，提交一个任务，发到哪里，怎么样去执行

27. Flink转化，怎么重推数据

28. 每天flink的数据量级，大概是多少级别，pb级左右，
    当flink流式处理之后，做数据重推，对实时指标计算，做怎样的操作，
    回滚包括哪些信息，位置，量级
    Flink从kafka里消费数据，到最后数据罗盘，是怎么保证数据的gapt once，保证数据不丢失
    Offset 写到es，写入失败，幂等怎么保持一致性，这样的数据流怎么保证它不能多不能少
    Offset怎么去控制，还是有其它机制去保证这个事务的执行
    flink提交kafka的offset，是在哪一步提交的
    是计算完之后提交，还是存到es之后提交
    落地写入失败，这部分数据怎么办，对kafka而言，这份数据已经消费完成了，
    怎么判断落地未成功，kafka消费完以后的数据怎么追查，不知道有哪些数据没存在，重推，从哪里重推，哪个位置少了
    Flink的checkpoint机制，故障排除的机制，怎么存的，怎么维护状态
    幂等，数据一致性，flink反压，流量暴增，由于某个逻辑出现问题

29. Flink参数调优：看资源来定，数据量级，几个partition，qps，数据是否有积压

30. flink日常问题解决：https://zhuanlan.zhihu.com/p/149147987

31. flink提交作业流程：1、Session 模式；2、Per-Job 模式；3、application方式

32. 1. 集群生命周期以及资源隔离保证不同。
    2. application的main方法是在客户端执行还是在集群执行。

https://www.hnbian.cn/posts/382bcbe0.html
session模式：这种方式需要先启动集群，然后再提交作业, 接着会向yarn申请一块空间, 初始化一个session服务常驻在这块空间, 后续提交的任务都运行在这个session上, 如果session资源使用到达上限则接下来的作业无法提交，只能等待到正在运行的某个作业执行完成,释放了部分资源, 接下来的作业才能正常提交，在session模式下多个 Flink jobmanager 会共享Dispatcher 和 YARN ResourceManager。
per-job模式：Per-Job 模式下，每次提交任务都会创建一个新的的 Flink Yarn-session，不同的 Job之间是资源隔离的，不会互相影响，同样Dispatcher和YarnResourceManager也是该任务独享的，任务完成后释放资源。除非是集群资源用尽，否则不会影响新任务的提交。在线上环境一般采用 Per-Job 模式。

33. Flink窗口延迟数据丢失
    流计算在支持Event Time的时候，引入了Watermark的概念（MillWheel提出这个概念的时候是叫Low Watermark，即低水位，鄙视翻译成水印的：），所有早于Watermark的数据都被认为是延迟数据。而在Flink的窗口计算当中，允许用户指定数据延迟的最大时间，即设置allowedLateness，超过这个时间的数据将会被丢弃，不参与窗口计算。Flink会将被丢弃的数据用SideOutput输出。
    窗口的介绍：https://flink.apache.org/news/2015/12/04/Introducing-windows.html
    原文链接：https://blog.youkuaiyun.com/kisimple/article/details/106073788
34. 配置派送怎么管理
35. flink下沉是怎么两阶段提交
36. flink的背压，怎么定位
37. flink的处理失败
38. 怎么确定flink产出的数据是准确还是不准确，怎么反查flink有没有丢数据，以及怎么判断flink是因为什么问题导致数据产出不准确
39. flink内存管理