1.Flink原理（角色分工）
2.Flink执行流程
on yarn版：
3.相关概念
1）DataFlow：Flink程序在执行的时候会被映射成一个数据流模型；
2）Operator：数据流模型中的每一个操作被称作Operator，Operator分为：Source，Transform，Sink；
3）Partition：数据流模型是分布式和并行的，执行中会形成1-n个分区
4）Subtask：多个分区任务可以并行，每一个都是独立运行在一个线程中的，也就是一个SubTask子任务；
5）Parallelism：并行度，就是可以同时真正执行的子任务数/分区数。
6）Operator传递模式
6-1）One to One模式：两个operator用此模式传递的时候，会保持数据的分区数和数据的排序（类似于spark中的窄依赖），多个one to one 的operator可以合并为一个operator chain。
6-2）Redistributing模式：此模式会改变数据的分区数（类似于Spark中的宽依赖）
7）TaskSlot and Slot Sharing
7-1）TaskSlot（任务槽）
每个TaskManager是一个JVM进程，为了控制一个TaskManager（worker）能接收多少task，Flink通过Task slot来进行控制。TaskSlot数量是用来限制一个TaskManager工作进程中可以同时运行多少个工作线程，TaskSlot是一个TaskManager中的最小资源分配单位，一个TaskManager中有多少个TaskSlot就意味着能支持多少并发的Task处理。
7-2）Slot Sharing（槽共享）
前面的Task Slot跑完一些线程任务之后，Task Slot可以给其他线程任务使用，这就是槽共享，这样的好处是可以避免线程的重复创建和销毁。
8）ExecutionGraph（Flink执行图）
解释上图：
（流程化）StreamGraph：最初的程序执行逻辑，也就是算子之间的前后顺序 ---- 在Client上生成
（优化合并）JobGraph：将One to One的Operator合并为OperatorChain ---- 在Client上生成
（并行化）ExecutionGraph：将JobGraph根据代码中设置的并行度和请求的资源进行并行化规划 ---- 在JobManager上生成
（将任务分配给具体的TaskSlot执行---落实执行线程化）物理执行图：将ExecutionGraph的并行计划，落实到具体的TaskManager上，将具体的SubTask落实到具体的TaskSlot内进行运行。
4.Flink流批一体API
前置知识：
{
Flink把流分为：
有边界的流（bounded Stream）：批数据
无边界的流（unbounded Steam）：真正的流数据
流计算和批计算对比：
数据时效性：流式计算实时，批计算非实时，高延迟；
数据特征不同：流式计算的数据一般是动态的，没有边界的，而批处理的数据一般则是静态数据。
应用场景不同：流式计算应用在实时场景，时效性要求比较高的场景，如实时推荐，业务监控等，批处理应用在实时性要求不高，离线计算的场景下，数据分析，离线报表等。
运行方式不同：流式计算的任务持续进行的，批量计算的任务则一次性完成。
}
4-1）Source（数据从哪来）
File-based基于文件：
java
env.readTextFile(本地/HDFS文件/文件夹);Socket-based基于Socket连接：
java
env.socketTextStream(主机名,端口号);Collection-based基于集合：
java
env.fromElemnts();
env.fromCollection();
env.generateSequence();
env.fromSequence();Custom自定义：
Flink还提供了数据源接口，我们实现了这些接口就可以实现自定义数据源获取数据，不同接口有不同的功能，接口如下：
SourceFunction：非并行数据源（并行度=1）
RichSourceFunction：多功能非并行数据源（并行度=1）
ParallelSourceFunction：并行数据源（并行度可以 > 1）
RichParallelSourceFunction：多功能并行数据源（并行度可以 > 1）--- kafka数据源就使用该接口
---------------------------------------------------------------------------------------------------------------------------------
4-2）Transformation（数据做怎样的操作处理）
Transformation基本操作：
map：j将函数作用在集合中的每一个元素上，并返回作用后的结果。
flat Map：将集合中的每个元素变成一个或者多个元素，并返回扁平化之后的结果
keyBy：按照指定的key来对流中的数据进行分组。注意：流中没有groupBy，而是keyBy
filter：按照指定的条件对集合中的元素进行过滤，过滤出返回true/符合条件的元素
sum：按照指定的字段对集合中的元素进行求和
reduce：对集合中的元素进行聚合
Transformation合并和拆分：
union：union算子可以合并多个同类型的数据流，并生成同类型的数据流，即可以将多个DataStream[T]合并成为一个新的DataStream[T]。数据按照先进先出FIFO的模式合并。
connect：
和union类似，用来连接两个数据流，区别在于：connect只可以连接两个数据流，union可以连接多个；connect所连接的两个数据流的数据类型可以不一样，unions所连接的两个数据流的数据类型必须一样
split（已废除），select，side output：
split就是将一个流分成多个流；
select就是获取分流后对应的数据；
side output：可以使用process方法对流中的数据进行处理，并针对不同的处理结果将数据收集到不同的OuputTag中。
rebalance（重平衡分区）：
类似于Spark中的repartition算子，功能更强，可以直接解决数据倾斜（Flink也有数据倾斜的情况，如下图），在内部使用round robin方法将数据均匀打散。
其他分区API：
dataStream.global(); 全部发往第一个Task
dataStream.broadcast(); 广播
dataStream.forward(); 上下游并发度一样时一对一发送
dataStream.shuffle(); 随即均匀分配
dataStream.rebalance(); 轮流分配
dataStream.recale(); 本地轮流分配
dataStream.partitionCustom(); 自定义单播
--------------------------------------------------------------------------------------------------------------------------------
4-3）Sink（数据做怎样的输出）
基于控制台和文件的Sink：
ds.print(); 直接输出到控制台
ds.printErr(); 直接输出到控制台，用红色
ds.writeAsText().setParallelism(); 以多少并行度输出到某个文件路径
自定义的Sink。
--------------------------------------------------------------------------------------------------------------------------------
4-4）Connectors（连接外部的工具）
Connectors-JDBC
Flink内已经提供了一些绑定的Connector，例如Kafka source和sink，Es sink等。读写Kafka，es，rabiitMQ时可以直接使用相应的connector的API就可以了。
同样Flink内也提供了专门操作redis的RedisSink。查询接口文档使用就行了。
5.Flink高级API
Flink四大基石
Flink流行的原因，就是这四大基石：CheckPoint，State，Time，Window。
a.Flink-Windows操作
使用场景：在流式处理中，数据是源源不断的，有时候我们需要做一些聚合类的处理。例如，在过去一分钟内有多少用户点击了网页。此时我们可以定义一个窗口/window，用来收集1分钟内的数据，并对这个窗口内的数据进行计算。
Flink支持按照
（用的多）时间time：每xx分钟统计最近xx分钟的数据
数量count：每xx个数据统计最近xx个数据
两种类型的窗口形式
按照窗口的形式进行组合有四种窗口：
基于时间的滑动窗口，基于时间的滚动窗口，基于数量的滑动窗口，基于数量的滚动窗口。
---------------------------------------------------------------------------------------------------------------------------------
b.Flink-Time和Watermark
在Flink的流式处理中，会涉及到时间的不同概念
事件时间EventTime：事件真真正正发生/产生的时间（重点关注事件时间）
摄入时间IngestionTime：事件到达Flink的事件
处理时间ProcessingTime：事件真正被处理/计算的时间
事件时间能够真正反映/代表事件的本质！所以一般在实际开发中会以事件时间作为计算标准。
总结：
实际开发中我们希望基于事件时间来处理数据，但因为数据可能因为网络延迟等原因，出现了乱序或延迟到达，那么可能处理的结果不是我们想要的甚至出现数据丢失的情况，所以需要一种机制来解决一定程度上的数据乱序或延迟到底的问题!也就是Watermaker水印机制/水位线机制。
什么是Watermark？
就是给数据额外的加的一个时间列，也就是个时间戳。
Watermark = 当前窗口的最大事件事件 - 最大允许的延迟时间或者乱序时间
这样可以保证Watermaker水位线会一直上升（变大），不会下降。
Watermark的作用：用来触发窗口计算，通过改变触发窗口计算的时机，从而在一定程度上解决数据乱序的问题。
---------------------------------------------------------------------------------------------------------------------------------
c.Fink-状态管理
Flink支持状态的自动管理。在绝大多数情况下使用Flink提供的自动管理就行了，极少数使用手动的状态管理。
无状态计算是什么意思：就是不需要考虑历史的数据，相同的输入得到相同的输出。
有状态计算（Flink有自动状态管理了，就少手动去维护状态管理了吧）就是要考虑历史的数据，相同而输入不一定得到相同的输出。
---------------------------------------------------------------------------------------------------------------------------------
d.Flink-容错机制
State和CheckPoint的区别：
State：
维护/存储的是某一个Operator的运行的状态/历史值,是维护在内存中!
一般指一个具体的Operator的状态(operator的状态表示一些算子在运行的过程中会产生的一些历史结果如前面的maxBy底层会维护当前的最大值,也就是会维护一个keyedOperator,这个State里面存放就是maxBy这个Operator中的最大值)
CheckPoint：
某一时刻,Flink中所有的Operator的当前State的全局快照,一般存在磁盘上（一般放HDFS上）。
表示了一个Flink Job在一个特定时刻的一份全局状态快照，即包含了所有Operator的状态可以理解为Checkpoint是把State数据定时持久化存储了。
比如KafkaConsumer算子中维护的Offset状态,当任务重新恢复的时候可以从Checkpoint中获取。
6.状态恢复和重启策略
重启策略分类：
默认重启策略：配置了Checkpoint的情况下不做任务配置，默认是无限重启并自动恢复，可以解决小问题，但是可能会隐藏掉真正的bug。
无重启策略：使用API配置不重启即可。
固定延迟重启策略（开发中使用）：调用API，配置固定时间or多少次数重启
失败率重启策略（开发偶尔使用）：调用API，可以选择每个测量阶段内最大失败次数；失败率测量的时间间隔；两次连续重启的时间间隔来重启。
7.SavePoint（本质就是手动的CheckPoint）
实际开发中，如果要对集群进行停机维护/扩容，这个时候需要执行一次SavePoint，也就是执行一次手动的CheckPoint，那么这样的话，程序所有的状态都会被执行快照并保存。当扩容/维护完毕后，可以从上一次的checkpoint的目录中恢复。
8.Flink Table API 和 SQL（重点）
和Hive，Spark SQL一样，Flink也选择用SQL语言来进行业务程序的编写，为什么？
因为Java，Scala等开发语言难度较高，SQL语言简单，能迅速上手，因此Flink也是将Flink Table API & SQL作为未来的核心API。
Flink Table API & SQL的特点：
声明式 --- 用户只关心做什么，不用关心怎么去做
高性能 --- 支持查询优化，可以获取更好的执行性能
流批统一 --- 相同的统计逻辑，既可以支持流模式运行，也可以支持批模式运行
标准稳定 --- 语音遵循SQL标准，不易变动
易理解 --- 语义明确，所见即所得
9.动态表和连续查询
动态表：就是源源不断地数据不断地添加到表的末尾
连续查询：连续查询需要借助state状态管理
10.Spark vs Flink
1）应用场景
Spark主要做离线批处理，对延时要求不高的实时处理（微批）
Flink主要用于实时处理，Flink 1.12支持流批一体
2）API上
Spark：RDD（不推荐）/ DSteam（不推荐）/ DataFrame和DataSet
Flink：DataSet（软弃用）和DataSteam / Tabel API & SQL
3）核心角色和原理
Spark：
Flink：
4）时间机制
Spark：SparkSteaming只支持处理时间，StructuredSteaming开始支持事件时间
Flink：直接支持事件时间/处理时间/摄入时间
5）容错机制
Spark：缓存/ 持久化+ checkpoint（应用级别）
Flink：State + CheckPoint（Operator级别，颗粒度更小） + 自动重启策略 + SavePoint
6）窗口
Spark中支持时间，数量的滑动和滚动窗口，要求windowDuration和SlideDuration必须是batchDuration的倍数
Flink中的窗口机制更加灵活/功能更多，支持基于时间/数量的滑动/滚动 和 会话窗口