往期推荐
一文入门大数据准流式计算引擎Spark【万字详解，全网最新】-CSDN博客
浅谈维度建模、数据分析模型，何为数据仓库，与数据库的区别_统一数仓 数据库用户名-CSDN博客数仓架构：离线数仓、实时数仓Lambda和Kappa、湖仓一体数据湖-CSDN博客
数仓分层ODS、DWD、DWM、DWS、DIM、DM、ADS_ods dwd dws ads dm-CSDN博客浅谈维度建模、数据分析模型，何为数据仓库，与数据库的区别_统一数仓 数据库用户名-CSDN博客
目次
0. Flink知识图谱
1. Flink发展
1.1 四代计算引擎
2. Flink简介
2.1 Flink特点
2.2 批处置惩罚和流处置惩罚
2.3 有界流和无界流
2.4 Flink和Spark Streaming
3. Flink三层核心架构
3.1 API & Libraries层详解
3.1.1 SQL&Table API层
3.1.2 DataStream & DataSet API层
3.1.3 Stateful Stream Processing层
4. 三种Time概念
4.1 WaterMark水印
5. Windows窗口类型
5.1 时间窗口
5.1.1 滚动窗口Tumbling Windows
5.1.2 滑动窗口Sliding Windows
5.1.3 会话窗口Session Windows
5.1.4 全局窗口Global Windows
5.2 计数窗口
6. 状态管理
6.1 状态的Flink官方界说
6.2 状态分类及状态存储类型
6.2.1 算子状态
6.2.2 键控状态
6.2.3 Broadcast State
6.3. 状态后端（长期化存储）
7. Flink算子
7.1 DataSet批处置惩罚算子
7.1.1 Source算子
7.1.2 Transform 转换算子
7.1.3 Sink 输出算子
7.2 DataStream流处置惩罚算子
8. Flink容错
8.1 Checkpoint机制
9. Flink CEP
9.1 使用场景
9.2 CEP API
10. Flink CDC
10.1 CDC种类
11. Flink SQL
0. Flink知识图谱
1. Flink发展
Apache Flink 诞生于柏林工业大学的一个研究性项目，原名 StratoSphere 。2014 年，由 StratoSphere 项目孵化出 Flink，并于同年捐赠 Apache，之后成为 Apache 的顶级项目。2019 年 1 年，阿里巴巴收购了 Flink 的母公司 Data Artisans，并公布开源内部的 Blink，Blink 是阿里巴巴基于 Flink 优化后的版本，增长了大量的新功能，并在性能和稳固性上进行了各种优化，履历过阿里内部多种复杂业务的挑战和检验。同时阿里巴巴也表示会渐渐将这些新功能和特性 Merge 回社区版本的 Flink 中，因此 Flink 成为现在最为火热的大数据处置惩罚框架。
1.1 四代计算引擎
在国外一些社区，有很多人将大数据的计算引擎分成了 4 代，当然，也有很多人不会认同。我们先姑且这么认为和讨论。
- 起首第一代的计算引擎，无疑就是 Hadoop 承载的 MapReduce。这里各人应该都 不会对 MapReduce 陌生，它将计算分为两个阶段，分别为 Map 和 Reduce。对于上层应用来说，就不得不费尽心机去拆分算法，乃至于不得不在上层应用实现 多个 Job 的串联，以完成一个完整的算法，例如迭代计算。 由于如许的弊端，催生了支持 DAG 框架的产生。
- 因此，支持 DAG 的框架被分别为第二代计算引擎。如 Tez 以及更上层的 Oozie。这里我们不去细究各种 DAG 实现之间的区别，不过对于当时的 Tez 和 Oozie 来说，大多还是批处置惩罚的使命。
- 接下来就是以 Spark 为代表的第三代的计算引擎。第三代计算引擎的特点主要 是 Job 内部的 DAG 支持（不超过 Job），以及夸大的准实时计算。在这里，很多人也会认为第三代计算引擎也能够很好的运行批处置惩罚的 Job。 随着第三代计算引擎的出现，促进了上层应用快速发展，例如各种迭代计算的性能以及对流计算和 SQL 等的支持。
- Flink 的诞生就被归在了第四代。这应该主 要表现在 Flink 对流计算的支持，以及更一步的实时性上面。当然 Flink 也可 以支持 Batch 的使命，以及 DAG 的运算。
2. Flink简介
- Flink 是一个分布式、高性能、有状态的流处置惩罚框架，它能够对有界和无界的数据流进行高效的处置惩罚。Flink 的 核心是流处置惩罚（DataStream），当然也支持批处置惩罚（DataSet），Flink 将批处置惩罚当作是流处置惩罚的一种特殊情况，即数据流是有 明确界限的。这和 Spark Streaming 的头脑是完全相反的，Spark Streaming 的核心是批处置惩罚，它将流处置惩罚当作是批处置惩罚的一种特殊情况， 即把数据流进行极小粒度的拆分，拆分为多个微批处置惩罚。
2.1 Flink特点
- 支持高吞吐、低延迟、高性能的流处置惩罚
- 结果准确，Flink提供了事件时间和处置惩罚时间，对乱序数据仍能提供一直准确的结果
- 支持高度灵活的窗口（Window）操作，支持基于 time、count、session， 以及 data-driven 的窗口操作
- 支持基于轻量级分布式快照（Snapshot）实现的容错
- 一个运行时同时支持 Batch on Streaming 处置惩罚和 Streaming 处置惩罚
- Flink 在 JVM 内部实现了自己的内存管理
- 支持迭代计算，Spark也支持
- 支持步伐自动优化：避免特定情况下 Shuffle、排序等昂贵操作，中间结果有须要进行缓存
2.2 批处置惩罚和流处置惩罚
- 批处置惩罚
有界、长期、大量，一样平常用于离线计算
- 流处置惩罚
无界、实时，流处置惩罚方式无需对整个数据集执行操作，而是对通过体系传输的每个数据项执行操作，一样平常用于实时统计
在 Spark 生态体系中，对于批处置惩罚和流处置惩罚采用了差别的技术框架，批处置惩罚由 SparkSQL 实现，流处置惩罚由 Spark Streaming 实现，这也是大部分框架采用的策略，使用独立的处置惩罚器实现批处置惩罚和流处置惩罚，而 Flink 可以同时实现批处置惩罚和流处置惩罚，Flink 将批处置惩罚（即处置惩罚 有限的静态数据）视作一种特殊的流处置惩罚，即把数据看作是有界的 ！
2.3 有界流和无界流
无界数据流：
- 有界说流的开始，但没有界说流的结束；
- 它们会无休止的产生数据
- 无界流的数据必须连续处置惩罚，即数据被摄取后须要立刻处置惩罚
- 我们不能等到所有数据都到达再处置惩罚，由于输入是无穷的。
有界数据流：
- 有界说流的开始，也有界说流的结束
- 有界流可以在摄取所有数据后再进行计算
- 有界流所有数据可以被排序，所以并不须要有序摄取
- 有界流处置惩罚通常被称为批处置惩罚。
2.4 Flink和Spark Streaming
Spark本质是批处置惩罚
- Spark数据模型：Spak采用RDD模型，Spark Streaming的DStream实际上也就是一组组小批据RDD的集合
- Spark运行时架构：Spark是批计算，将DAG分别为差别的stage,一个完成后才可以计算下一个
Flink以流处置惩罚为根本
- Flink数据模型：Flink根本据模型是数据流，以及事件(Event)序列
- Flink运行时架构：Flink是尺度的流执行模式，一个事件在一个节点处置惩罚完后可以直接发往下一个节点进行处置惩罚
3. Flink三层核心架构
下图为 Flink 技术栈的核心构成部分，由上而下分别是 API & Libraries 层、Runtime 核心层以及物理部署层。
- API & Libraries 层，提供了面向流式处置惩罚的接口（DataStream API）、面向批处置惩罚的接口（DataSet API）、用于复杂事件处置惩罚的 CEP 库、用于结构化数据查询的 SQL & Table 库、基于批处置惩罚的机器学习库 FlinkML 和 图形处置惩罚库 Gelly。
- Runtime 核心层，这一层是 Flink 分布式计算框架的核心实现层，包括作业转换，使命调度，资源分配，使命执行等功能，基于这一层的实现，可以在流式引擎下同时进行流处置惩罚和批处置惩罚。
- 物理部署层，用于支持在差别平台上部署运行 Flink 应用。
3.1 API & Libraries层详解
在API & Libraries层，有如下更细致的分别，API 的同等性由下至上依次递增，接口的表现能力由下至上依次递减。
3.1.1 SQL&Table API层
SQL & Table API 同时实用于批处置惩罚和流处置惩罚，这意味着可以对有界数据流和无界数据流以相同的语义进行查询，并产生相同的结果。除了根本查询外， 它还支持自界说的标量函数，聚合函数以及表值函数，可以满足多样化的查询需求。
3.1.2 DataStream & DataSet API层
DataStream & DataSet API 是 Flink 数据处置惩罚的核心 API，支持使用 Java 语言或 Scala 语言进行调用，提供了数据读取，数据转换和数据输出等一系列常用操作的封装。
3.1.3 Stateful Stream Processing层
Stateful Stream Processing 是最低级别的抽象，它通过 Process Function 函数内嵌到 DataStream API 中。 Process Function 是 Flink 提供的最底层 API，具有最大的灵活性，允许开发者对时间和状态进行细粒度的控制。
4. 三种Time概念
在 Flink 中，如果以时间段分别界限的话，那么时间就是一个极其紧张的字段。 Flink 中的时间有三种类型，如下图所示：
- Event Time：是事件创建的时间。它通常由事件中的时间戳描述，即事件自己就要携带时间信息，例如采集的日志数据中，每一条日志都会记录自己的生成时间，Flink 通过期间戳分配器访问事件时间戳。
- Ingestion Time：是数据进入 Flink 的时间。
- Processing Time：是每一个执行基于时间操作的算子的当地体系时间，与机器相干，默认的时间属性就是 Processing Time
在 Flink 的流式处置惩罚中，绝大部分的业务都会使用 eventTime，一样平常只在 eventTime 无法使用时，才会被迫使用 ProcessingTime
4.1 WaterMark水印
- 流处置惩罚从事件产生，到流经 source，再到 operator，中间有一个过程和时间，固然大部分情况下，流到 operator 的数据都是按照事件产生的 时间顺序来的，但是也不排除由于网络、背压等原因，导致乱序的产生，所谓乱序，就是指 Flink 接收到的事件的先后顺序不是严格按照事件的 Event Time 顺序排列的，所以 Flink 最初计划的时间，就考虑到了网络延迟，网络乱序等问题，所以提出了一个抽象概念：水印（WaterMark）
- 当出现乱序，如果只根据 EventTime 决定 Window 的运行，我们不能明确数据是否全部到位，但又不能无穷期的等下去， 此时必须要有个机制来保证一个特定的时间后，必须触发 Window 去进行计算了， 这个特别的机制，就是 Watermark。
- Watermark 是用于处置惩罚乱序事件的，通常用 Watermark 机制结合 Window 来实现。 数据流中的 Watermark 用于表示 timestamp 小于 Watermark 的数据，都已经到达了，因此，Window 的执行也是由 Watermark 触发的。 Watermark 可以理解成一个延迟触发机制，我们可以设置 Watermark 的延时时长 t ，每次体系会校验已经到达的数据中最大的 maxEventTime，然后认定 EventTime 小于 maxEventTime - t 的所有数据都已经到达，如果有窗口的停止时间即是 maxEventTime - t，那么这个窗口被触发执行。
对延迟数据的理解
- 延迟数据是指： 在当前窗口【假设窗口范围为 10-15】已经计算之后，又来了一个属于该窗口的 数据【假设事件时间为 13】，这时间仍会触发 Window 操作，这种数据就称为 延迟数据。
- 那么问题来了，延迟时间怎么计算呢？
假设窗口范围为 10-15，延迟时间为 2s，则只要 WaterMark=15+2， 10-15 这个窗口就不能再触发 Window 操作，即使新来的数据的 Event Time 属 于这个窗口时间内 。
5. Windows窗口类型
在大多数场景下，我们须要统计的数据流都是无界的，因此我们无法等待整个数据流停止后才进行统 计。通常情况下，我们只须要对某个时间范围或者数目范围内的数据进行统计分析（把无穷数据分割成块进行计算分析）：如每隔五分钟统计一次已往一小时内所有商品的点击量；或者每发生1000次点击后，都去统计一下每个商品点击率的占比。在 Flink 中，可以使用窗口 (Window) 来实现这类功能。按照统计维度的差别，Flink 中的窗口可以分为时间窗口 (Time Windows) 和计数窗口 (Count Windows) 。
5.1 时间窗口
时间窗口以时间点来界说窗口的开始（start）和结束（end），所以截取出的就是某一时间段的数据。到达结束时间时，窗口不再收集数据，触发计算输出结果，并将窗口关闭销毁。所以可以说根本思路就是“定点发车”。
5.1.1 滚动窗口Tumbling Windows
滚动窗口指相互之间没有重叠的窗口。例如：每隔1小时统计已往1小时内的商品点击量，那么 1 天就只能分为 24 个窗口，每个窗口之间是不存在重叠的。
特点：时间对齐，长度固定，窗口不重叠
5.1.2 滑动窗口Sliding Windows
滑动窗口用于滚动进行聚合分析，例如：每隔 6 分钟统计一次已往一小时内所有商品的点击量，那么1天可以分为 240 个窗口，统计窗口之间存在重叠。
特点：时间对齐，长度固定，窗口重叠
5.1.3 会话窗口Session Windows
当用户在进行连续浏览时，可能时时刻刻都会有点击数据，例如在活动区间内，用户可能频仍的将某类 商品加入和移除购物车，而你只想知道用户本次浏览最终的购物车情况，此时就等用户持有的会话结束后再进行统计。想要实现这类统计，可以通过 Session Windows 来进行实现。
特点：时间不对齐，长度不固定，窗口不重叠
5.1.4 全局窗口Global Windows
全局窗口会将所有 key 相同的元素分配到同一个窗口中，其通常配合触发器 (trigger) 进行使用。如果没有相应触发器，则计算将不会被执行。
5.2 计数窗口
计数窗口基于元素的个数来截取数据，到达固定的个数时就触发计算并关闭窗口。每个窗口截取数据的个数， 就是窗口的大小。根本思路是“人齐发车”。
Count Windows 用于以数目为维度来进行数据聚合，同样也分为滚动窗口和滑动窗口，实现方式也和 时间窗口根本同等。
注意：CountWindow 的 window_size 指的是相同 Key 的元素的个数，不是输入的所有元素的总数
- tumbling-count-window (无重叠数据)
- sliding-count-window (有重叠数据）
6. 状态管理
参考博客：Flink 状态管理详解（超全收藏）_flink状态后端的应用场景-CSDN博客
6.1 状态的Flink官方界说
当前计算流程须要依赖到之前计算的结果，那么之前计算的结果就是状态。
6.2 状态分类及状态存储类型
相对于其他流计算框架，Flink 一个比较紧张的特性就是其支持有状态计算，即你可以将中间的计算结果进行保存，并提供给后续的计算使用（Spark的RDD也可以保存计算结果供下个RDD使用，DAG）
详细而言，Flink 有两种根本类型的状态 (State) ： 键控状态（Keyed State） 与算子状态（Operator State）。这两种状态可以以两种形式存在：原始状态(raw state) 、托管状态(managed state），托管状态是由 Flink 框架管理的状态，原始状态由用户自行管理状态。
6.2.1 算子状态
算子状态是和算子进行绑定的，与Key无关，一个算子的状态不能被其他算子所访问到。官方文档上对 Operator State 的解释是：each operator state is bound to one parallel operator instance，所以更为确切的说一个算子状态是与一个并发的算子实例所绑定的，即假设算子的并行度是 2，那么其应有两个对应的算子状态：
算子状态存储类型
- ListState：存储列表类型的状态。
- UnionListState：存储列表类型的状态，与 ListState 的区别在于：如果并行度发生变化， ListState 会将该算子的所有并发的状态实例进行汇总，然后均分给新的 Task；而 UnionListState 只是将所有并发的状态实例汇总起来，详细的分别行为则由用户进行界说。
- BroadcastState：用于广播的算子状态。
6.2.2 键控状态
键控状态是一种特殊的算子状态，即状态是根据 key 值进行区分的，Flink 会为每类键值维护一个状态实例。如下图所示，每个颜色代表差别 key 值，对应四个差别的状态实例。须要注意的 是键控状态只能在 KeyedStream 上进行使用，我们可以通过 stream.keyBy(...) 来得到 KeyedStream 。
键控状态存储类型
- ValueState：存储单值类型的状态。可以使用 update(T) 进行更新，并通过 T value() 进行 检索。
- ListState：存储列表类型的状态。可以使用 add(T) 或 addAll(List) 添加元素；并通过 get() 获得整个列表。
- ReducingState：用于存储颠末 ReduceFunction 计算后的结果，使用 add(T) 增长元素。 AggregatingState：用于存储颠末 AggregatingState 计算后的结果，使用 add(IN) 添加元素。
- FoldingState：已被标识为废弃，会在未来版本中移除，官方推荐使用 AggregatingState 代 替。
- MapState：维护 Map 类型的状态。
6.2.3 Broadcast State
Broadcast State 是 Flink 1.5 引入的新特性。在开发过程中，如果碰到须要 下发/广播配置、规则等低吞吐事件流到下游所有 task 时，就可以使用 Broadcast State 特性。下游的 task 接收这些配置、规则并保存为 BroadcastState, 将这些配置应用到另一个数据流的计算中 。
6.3. 状态后端（长期化存储）
默认情况下，所有的状态都存储在 JVM 的堆内存中，在状态数据过多的情况下，这种方式很有可能导致内存溢出，因此 Flink 该提供了其它方式来存储状态数据，这些存储方式统一称为状态后端 (或状态管理器)，主要有以下三种：
- MemoryStateBackend
默认的方式，即基于 JVM 的堆内存进行存储，主要实用于当地开发和调试。
- FsStateBackend
基于文件体系进行存储，可以是当地文件体系，也可以是 HDFS 等分布式文件体系。 须要注意而是固然选择使用了 FsStateBackend ，但正在进行的数据仍然是存储在 TaskManager 的内存中的，只有在 checkpoint 时，才会将状态快照写入到指定文件体系上。
- RocksDBStateBackend
RocksDBStateBackend 是 Flink 内置的第三方状态管理器，采用嵌入式的 key-value 型数据库 RocksDB 来存储正在进行的数据。等到 checkpoint 时，再将其中的数据长期化到指定的文件体系中， 所以采用 RocksDBStateBackend 时也须要配置长期化存储的文件体系。之所以如许做是由于 RocksDB 作为嵌入式数据库安全性比较低，但比起全文件体系的方式，其读取速率更快；比起全内存的方式，其 存储空间更大，因此它是一种比较均衡的方案。
7. Flink算子
7.1 DataSet批处置惩罚算子
7.1.1 Source算子
- fromCollection：从当地集合读取数据
- readTextFile：从文件中读取
- readTextFile：遍历目次
- readTextFile：读取压缩文件
7.1.2 Transform 转换算子
Transform 算子基于 Source 算子操作，所以要起首构建 Flink 执行环境及 Source 算子。
数据源读入数据之后，就可以使用各种转换算子，将一个或多个 DataStream 转换为新的 DataStream。
根本转换算子（map/ filter/ flatMap）
- map：将 DataSet 中的每一个元素转换为别的一个元素
- flatMap：将 DataSet 中的每一个元素转换为 0...n 个元素
- filter：过滤出来一些符合条件的元素，返回 boolean 值为 true 的元素
聚合算子（Aggregation）
- reduce：可以对一个 dataset 或者一个 group 来进行聚合计算，最终聚合成一个元素reduceGroup：将一个 dataset 或者一个 group 聚合成一个或多个元素。reduceGroup 是 reduce 的一种优化方案； 它会先分组 reduce，然后在做整体的 reduce；如许做的好处就是可以减少网络 IO
- minBy 和 maxBy：选择具有最小值或最大值的元素
- Aggregate：在数据集上进行聚合求最值（最大值、最小值），注意： 使用 aggregate，只能使用字段索引名或索引名称来进行分组 groupBy(0) ，否则会报一下错误: Exception in thread "main" java.lang.UnsupportedOperationException: Aggregate does not support grouping with KeySelector functions, yet.
- .........
7.1.3 Sink 输出算子
Flink 作为数据处置惩罚框架，最终还是要把计算处置惩罚的结果写入外部存储，为外部应用提供 支持。
- collect 将数据输出到当地集合
- writeAsText 将数据输出到文件
7.2 DataStream流处置惩罚算子
流处置惩罚算子和批处置惩罚算子差不多，就不详细解释了。
参考博客：一文学完Flink流计算常用算子（Flink算子大全）_flink算子scala-CSDN博客
8. Flink容错
8.1 Checkpoint机制
Flink 的 checkpoint 机制原理来自“Chandy-Lamport algorithm”算法
为了使状态具有精良的容错性，Flink 提供了查抄点机制 (CheckPoints) 。通过查抄点机制， Flink 定期在数据流上生成 checkpoint barrier ，当某个算子收到 barrier 时，即会基于当前状态生成一份快照，然后再将该 barrier 转达到下游算子，下游算子接收到该 barrier 后，也基于当前状态生成一份快照，依次转达直至到末了的 Sink 算子上。当出现异常后，Flink 就可以根据近来的一次的快照数据将所有算子规复到先前的状态。（Spark也有Checkpoint机制）
简单理解为 checkpoint 是把 state 数据定时长期化存储了
9. Flink CEP
Complex Event Processing，复杂事件处置惩罚，Flink CEP 是一个基于 Flink 的复杂事件处置惩罚库，可以从多个数据流中发现复杂事件，识别故意义的事件（例如机会或者威胁），并尽快的做出相应，而不是须要等待几天或则几个月相当长的时间，才发现问题。
9.1 使用场景
检测恶意用户和刷屏用户
实时反作弊和风控
实时营销
实时网络攻击检测
9.2 CEP API
CEP API 的核心是 Pattern(模式) API，它允许你快速界说复杂的事件模式。每 个模式包罗多个阶段（stage）或者也可称为状态（state）。从一个状态切换到另一个状态，用户可以指定条件，这些条件可以作用在邻近的事件或独立事件上。
10. Flink CDC
- CDC 是 Change Data Capture（变更数据获取）的简称。核心头脑是，监测并捕获数据库的变更（包括数据或数据表的插入、更新以及删除等，和Flume很像，不过Flume是监控的体系日志），将这些变更按发生的顺序完整记录下来，写入到消息中间件中以供其他服务进行订阅及消费。
- 在广义的概念上，只要能捕获数据变更的技术，我们都可以称为 CDC 。通常我们说的 CDC 技术主要面向数据库的变更，是一种用于捕获数据库中数据变更的技术。
- CDC 技术应用场景非常广泛：
数据同步，用于备份，容灾；
数据分发，一个数据源分发给多个下游；
数据采集(E)，面向数据仓库/数据湖的 ETL 数据集成
10.1 CDC种类
CDC 主要分为基于查询和基于 Binlog 两种方式，我们主要相识一下这两种之间的区别：
11. Flink SQL
- Flink SQL 是 Flink 实时计算为简化计算模型，降低用户使用实时计算门槛而计划的一套符合尺度 SQL 语义的开发语言（为了降低Spark门槛，也有Spark SQL；为了降低HBase门槛，有了Phoneix；为了方便的操作HDFS文件，有了Hive SQL......）。 自 2015 年开始，阿里巴巴开始调 研开源流计算引擎，最终决定基于 Flink 打造新一代计算引擎，针对 Flink 存在的不足进行优化和改进，并且在 2019 年初将最终代码开源，也就是我们熟知 的 Blink。Blink 在原来的 Flink 底子上最明显的一个贡献就是 Flink SQL 的 实现。
- Flink SQL 是面向用户的 API 层，在我们传统的流式计算领域，比如 Storm、 Spark Streaming 都会提供一些 Function 或者 Datastream API，用户通过 Java 或 Scala 写业务逻辑，这种方式固然灵活，但有一些不足，比如具备一定门槛且调优较难，随着版本的不停更新，API 也出现了很多不兼容的地方。在这个背景下，毫无疑问，SQL 就成了我们最佳选择！
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
