Flink基本概念（一）

《Flink原理、实战与性能优化》

基于有状态计算（好处：不需要将原始数据重新从外部存储中拿出来）

周期性的通过分布式快照技术checkpoints实现状态的持久化维护

优势：

1、同时支持高吞吐、低延迟、高性能

2、支持事件时间（event time）概念：即使乱序时间到达flink也能根据事件产生的时间来处理

3、支持有状态计算：把中间结果数据保存在内存或者文件系统中，不用再次从头计算

4、支持高度灵活的窗口操作：通过窗口的方式对流数据进行一定范围的聚合计算。

flink对窗口划分为基于time、count、session，以及Data-driven等类型的窗口操作

5、基于轻量级分布式快照（snapshot）实现的容错

Flink将大型计算任务的流程拆解成小的计算过程，将task分布到并行节点上进行处理。通过checkpoints将执行过程中的状态信息进行持久化存储，出现异常的时候，flink能够从checkpoints中进行任务的自动恢复，确保数据的一致性。

6、基于JVM实现独立的内存管理

7、Save Points（保存点）：

重启后可以直接从之前保存在存储介质上的savepoints来恢复

Checkpoints与savepoints的区别

原文：Flink检查点（checkpoint）、保存点（savepoint）的区别与联系_LittleMagic's Blog-CSDN博客

Checkponits是在taskmanager中存储的，而savepoints是在jobmanager中存储的。

1. Checkponits更侧重于容错机制。任务失败了从Checkponits恢复。Savepoints侧重于维护，需要手动干预下手动重启、升级、迁移或A/B测试时，现将状态整体写入可靠存储，维护完毕之后再从savepoints恢复
2. Savepoints是一种特殊的Checkponits，savepoints也会放到checkpoints中
3. Checkponits在各个taskmanager中定时触发快照并定时清理

savepoints面向用户，完全根据用户的需要触发与清理。

1. checkpoint的频率往往比较高（因为需要尽可能保证作业恢复的准确度），所以checkpoints的存储格式非常轻量级，但作为trade-off牺牲了一切可移植（portable）的东西，比如不保证改变并行度和升级的兼容性。savepoints则以二进制形式存储所有状态数据和元数据，执行起来比较慢而且“贵”，但是能够保证portability，如并行度改变或代码升级之后，仍然能正常恢复。
2. checkpoints是支持增量的（通过RocksDB），特别是对于超大状态的作业而言可以降低写入成本。savepoints并不会连续自动触发，所以savepoints没有必要支持增量。

Checkpoints与savepoints存储文件的位置都是在fink配置文件中的conf/flink-conf.yaml的state.checkpoints.dir与state.savepoints.dir设置的。

Flink基本架构

基础组件栈

API&Libaraies层、Runtime核心层以及物理部署层

基础架构

主要两个组件，JobManager（Master）和TaskManager(Worker)，通信借助于AkkaFramework。

1. Client客户端：负责将任务提交到集群，与JobManager构建Akka连接，然后将任务提交到JobManager，通过和JobManager之间进行交互获取任务执行状态。

可以通过cli或者前端网页提交任务，或者在应用程序中指定JobManager的RPC网络端口构建ExecutionEnvironment提交Flink应用。

1. JobManager

JobManager负责整个Flink集群任务的调度以及资源的管理，从客户端中获取提交的应用，根据TaskManager上TaskSlots的使用情况，为提交的应用分配相应的taskSlots资源并命令TaskManager启动从客户端获取的应用。JobManager是整个集群的Master节点，整个集群只有一个活跃的JobManager，负责整个集群的任务管理和资源管理。

JobManager和TaskManager通过Actor System进行通信，JobManager获取任务执行的情况通过Actor System将应用的执行情况发送给客户端。

在任务执行过程中，JobManager会触发checkpoints操作，每个TaskManager节点在收到checkpoint指令后，完成checkpoint操作，所有的checkpoint协调过程都是早JobManager在这个过程中完成的。

任务完成后，flink会将任务执行的信息反馈给客户端，并释放掉TaskManager中的资源以供下一次提交任务使用。

1. TaskManager

配置文件中的taskmanager.numberOfTaskSlots决定了每个TaskManager能够启动多少个任务槽。TaskManager相当于整个集群的slave节点，负责具体的任务执行和对应任务在每个节点上的资源申请与管理。

1、客户端通过提交jar包到Jobmanager，Jobmanager根据已经注册在Jobmanager中的TaskManager的资源情况，将任务分配给有资源的TaskManager，启动并运行任务。

2、TaskManager从Jobmanager接受需要部署的任务，使用slot资源启动task，建立数据接入的网络连接，接受数据并开始数据处理

各个TaskManager之间的数据交互都是通过数据流的方式进行的。

并行度是实际上的，slot*taskmanager
调节并行度和slot的值的时候，配置文件中
parallelism.default <=taskmanager.numberOfTaskSlots *taskmanager的数量
实际上的并行度一定小于等于理论上的

DataStream与DataSet(无界流与有界流)

数据集类型：

1、有界数据集：有时间边界，处理过程中数据一定会在某个时间范围内起始和结束。对有界数据集的数据处理方式被称为批计算。

2、无界数据集：数据从开始生成就一直持续不断地产生新的数据。

3、统一数据处理：有界和无界数据集可以相互转换。Eg：无界切成有界例子。将系统产生的数据接入到存储系统，按照年或月进行切割，切分成不同时间长度的有界数据集。

Flink把有界数据转换成无界数据统一进行流式，最终将批处理和流处理统一在一套流式引擎中。

DataStream转换操作分类：

Single-DataStream、Multi-DataStream、物理分区

1. Single-DataStream：

1.1 Map

1.2 FlatMap

1.3 Filter

1.4 KeyBy

1.5 Reduce

1.6 Aggregations

2、Multi-DataStream

2.1 Union

2.2 Connect 、Comap、CoFlatMap[DataStream -> DataStream]

2.3 Split

2.4 Select

2.5 Iterate 迭代计算

3、物理分区操作

3.1 随机分区

3.2 Roundrobin Partitioning 轮询调度

datastream.rebalance();

3.3 Rescaling Partitioning 重新调节(发生网络传输)

datastream.rescale ();

3.4 广播操作（Broadcasting）

小表时候使用广播

3.5自定义分区

4、DataSinks数据输出

四、时间概念与Watermark

4.1时间概念模型

时间（时间产生的位置不同）：事件生成时间、事件接入时间、事件处理时间

处理时间：数据在操作算子计算过程中获取到的所有主机时间

5.3 状态管理器

5.3.1 MemoryStateBackend(flink默认使用)

存储在内存中、使用MAX_MEM_STATE_SIZ指定每个状态最大内存的大小

聚合类算子的状态会存储在JonManager内存中，如果算子多了会对内存有一定压力

缺点：内存满了之后容易丢失数据，不建议生产使用

MemoryStateBackend适用于本地开发调试,或者job的状态比较小的情况下.或者无状态的情况.MemoryStateBackend 最适合小状态的应用场景。例如
Kafka consumer，或者一次仅一记录的函数 （Map, FlatMap，或 Filter）性能是最高的

5.3.2 FsStateBackend：基于文件系统（本地文件系统/HDFS分布式文件系统）的一种状态管理器

new FsStateBackend(path,false); --文件系统路径，同步/异步

"hdfs://node151:40010/flink/checkpoint"或者file:///data/flink/checkpoints

适用于以下情景：拥有普通状态、长窗口、是key/Value结构的状态的Job。所有高可用性部署中,性能和memory查不多.当前的状态仍然会先存在 TaskManager 中，所以状态的大小不能超过 TaskManager 的内存 

5.3.3 RocksDBStateBackend：是Flink内置的第三方状态管理器

TUMBLE(time_attr, interval)	定义翻滚时间窗口。滚动时间窗口将行分配给具有固定持续时间 ( interval) 的非重叠、连续窗口。例如，一个 5 分钟的滚动窗口以 5 分钟的间隔对行进行分组。滚动窗口可以在事件时间（流 + 批处理）或处理时间（流）上定义。
HOP(time_attr, interval, interval)	定义一个跳跃时间窗口（在 Table API 中称为滑动窗口）。跳跃时间窗口具有固定的持续时间（第二个interval参数），并按指定的跳跃间隔（第一个interval参数）跳跃。如果跳跃间隔小于窗口大小，则跳跃窗口重叠。因此，可以将行分配给多个窗口。例如，15 分钟大小和 5 分钟跳跃间隔的跳跃窗口将每一行分配给 3 个不同的 15 分钟大小的窗口，这些窗口在 5 分钟的间隔内进行评估。可以在事件时间（流 + 批处理）或处理时间（流）上定义跳跃窗口。
SESSION(time_attr, interval)	定义会话时间窗口。会话时间窗口没有固定的持续时间，但它们的界限由interval不活动的时间定义，即，如果在定义的间隙期间没有事件出现，则会话窗口关闭。例如，当在 30 分钟不活动后观察到一行时，会有 30 分钟间隔的会话窗口开始（否则该行将添加到现有窗口中），如果在 30 分钟内没有添加行，则关闭。会话窗口可以在事件时间（流 + 批处理）或处理时间（流）上工作。

一个小时的时间窗口

select user,tumple_end(                   ctime,                   interval '1' hours) --一小时的结果来进行group by一下        as endT,        count(url) as cnt        from clicks        group by        user,        tumble(          ctime,          interval '1' hours          )        select user,rank()over (order by lastlogin)        from(             select user,max(ctime) as lastAction from clicks group by user          )