Flink入门教程

﹏ヽ暗。殇╰゛Y 2024-04-08 11:41 89阅读 0赞

### 什么是Flink？ ###

在Flink的官网上，可以把官方文档语言设置为中文，于是我们可以看到官方是这样介绍的：

![9a86324e44044b4b825faf74a340e2b8.png][]

上面的图我们每个字都能看得懂，但连起来就看不懂了。

不管怎么样，我们可以了解到：**Flink是一个分布式的计算处理引擎**

*  分布式：「它的存储或者计算交由**多台服务器上**完成，最后汇总起来达到最终的效果」。
 *  实时：处理速度是毫秒级或者秒级的
 *  计算：可以简单理解为对数据进行处理，比如清洗数据（对数据进行规整，取出有用的数据）

![bb6722f60b6c42a08d078d70b878a098.png][]

基于官网的**一句话介绍**，我们就可以**联想出很多东西**。

这篇文章可以带你简单认识一下Flink的一些基础概念，等你真正用到的时候就可以依据这篇文章来对Flink进行入门，现在Storm都被很多人给抛弃掉了，那么Flink**优于**Storm的地方有哪些呢？接下来我们一起来看看Flink吧。

#### 什么是有边界和无边界？ ####

> Apache Flink 是一个框架和分布式处理引擎，用于在**无边界和有边界数据流**上进行有状态的计算。

官方其实也有介绍，但对初学者来说不太好理解，我来**幼儿园化**一下。

大家学到Flink了，消息队列肯定有用过吧？那你们是怎么用消息队列的呢？`Producer`生产数据，发给`Broker`，`Consumer`消费，完事。

在消费的时候，我们需要管什么Producer什么时候发消息吗？不需要吧。反正来一条，我就处理一条，没毛病吧。

这种没有做任何处理的消息，默认就是**无边界**的。

那有边界就很好理解了：无边界的基础上**加上条件**，那就是有边界的。加什么条件呢？比如我要加个时间：我要消费从8月8号到8月9号的数据，那就是有边界的。

![5e196ac043d743dca8567053d9615a2f.png][]

什么时候用无边界，什么时候用有边界？那也很好理解。我做数据清洗：来一条，我处理一条，这种无边界的就好了。我要做数据统计：每个小时的`pv`(page view)是多少，那我就设置1小时的边界，**攒着**一小时的数据来处理一次。

在`Flink`上，设置“边界”这种操作叫做开窗口(`Windows`)，窗口可简单分为两种类型：

*  时间窗口(`TimeWindows`)：按照时间窗口进行聚合，比如上面所讲得攥着一个小时的数据处理一次。
 *  计数窗口(`CountWindows`)：按照指定的**条数**来进行聚合，比如每来了10条数据处理一次。

看着就非常人性化（妈妈再也不用担心我需要聚合了）...

不仅如此，在`Flink`使用窗口聚合的时候，还考虑到了**数据的准确性**问题。比如说：现在我在`11:06分`产生了`5`条数据，在`11:07分` 产生了`4条数据`，我现在是按**每分钟**的维度来进行聚合计算。

理论上来讲：`Flink`应该是在`06分`聚合了`5条`数据，在`07分`聚合了`4条`数据。但是，可能由于网络的延迟性等原因，导致`06分`的`3条`数据在`07分`时`Flink`才接收到。如果不做任何处理，那`07分`有可能处理了`7条`条数据。

某些需要准确结果的场景来说，这就不太合理了。所以`Flink`可以给我们指定”**时间语义**“，不指定默认是「数据到Flink的时间」`Processing Time`来进行聚合处理，可以给我们指定聚合的时间以「事件发生的时间」`Event Time`来进行处理。

事件发生的时间指的就是：**日志真正记录的时间**

2020-11-22 00:00:02.552 INFO  [http-nio-7001-exec-28] c.m.t.rye.admin.web.aop.LogAspect

虽然指定了聚合的时间为「事件发生的时间」`Event Time`，但还是没解决**数据乱序**的问题（06分产生了5条数据，实际上06分只收到了3条，而剩下的两条在07分才收到，那此时怎么办呢？在06分时该不该聚合，07分收到的两条06分数据怎么办？）

`Flink`又可以给我们设置水位线(`waterMarks`)，Flink意思就是：存在网络延迟等情况导致数据接收不是有序，这种情况我都能理解。你这样吧，**根据自身的情况**，你可以设置一个「延迟时间」，等延迟的时间到了，我再聚合统一聚合。

比如说：现在我知道数据有可能会延迟一分钟，那我将水位线`waterMarks`设置延迟一分钟。

解读：因为设置了「事件发生的时间」`Event Time`，所以`Flink`可以检测到每一条记录发生的时间，而设置了水位线`waterMarks`设置延迟一分钟，等到`Flink`发现`07分:59秒`的数据来到了`Flink`，那就确信`06分`的数据都来了（因为设置了1分钟延迟），此时才聚合`06分`的窗口数据。

![ad4fcccc9bd64762b4453def2853bcb6.png][]

#### 什么叫做有状态？ ####

> Apache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行**有状态的**计算。

什么是有状态，什么是无状态？

**无状态**我们可以简单认为：每次的执行都**不依赖**上一次或上N次的执行结果，每次的执行都是**独立**的。

**有状态**我们可以简单认为：执行**需要依赖**上一次或上N次的执行结果，某次的执行需要依赖前面事件的处理结果。

![f252f2c08e4b473db5dfd793c6626f27.png][]

比如，我们现在要统计文章的阅读`PV`(page view)，现在只要有一个点击了文章，在`Kafka`就会有一条消息。现在我要在**流式处理平台**上进行统计，那此时是有状态的还是无状态的？

假设我们要在`Storm`做，那我们**可能**将每次的处理结果放到一个“外部存储”中，然后基于这个“外部存储”进行计算（这里我们不用`Storm Trident`），那此时`Storm`是无状态的。

比如说：我存储将每次得到的数据存储到 `Redis`中，来一条数据，我就先查一下Redis目前的值是多少，跟`Redis`的值和现在的值做一次累加就完事了。

假设要在`Flink`做，`Flink`**本身**就提供了这种功能给我们使用，我们可以依赖`Flink`的“存储”，将每次的处理结果交由`Flink`管理，执行计算的逻辑。

![34aef128fb78444a80bcc6d892c40fb0.png][]

可以简单的认为：Flink**本身**就给我们提供了”存储“的功能，而我们每次执行是可以依赖Flink的”存储”的，所以它是**有状态**的。

![c821d451e8e34909abe17b9144ba28be.png][]

那`Flink`是把这些有状态的数据存储在哪的呢？

主要有三个地方：

*  内存
 *  文件系统（HDFS）
 *  本地数据库

![3ab8a846d7964523b2db11c9b1c83b32.png][]

如果假设`Flink`挂了，可能内存的数据没了，磁盘可能存储了部分的数据，那再重启的时候（比如消息队列会重新拉取），就不怕会丢了或多了数据吗？

看到这里，你可能在会在别的地方看过`Flink`的另外一个比较出名的特性：**精确一次性**

（简单来说就是：`Flink`遇到意外事件挂了以后，有什么机制来尽可能保证处理**数据不重复和不丢失**的呢）

#### 什么是精确一次性（exactly once）？ ####

众所周知，流的语义性有三种：

*  精确一次性（exactly once）：有且只有一条，不多不少
 *  至少一次（at least once）：最少会有一条，只多不少
 *  最多一次（at most once）：最多只有一条，可能会没有

Flink实现了**精确一次性**，这个精确一次性是什么意思呢？

Flink的精确一次性指的是：状态**只持久化一次**到**最终**的存储介质中（本地数据库/HDFS...)

![121fc2edccbe45338e63b9af3d81d61e.png][]

以上面的图为例：`Source`数据流有以下数字`21,13,8,5,3,2,1,1`，然后在`Flink`需要做**累加**操作（求和）

现在处理完`2,1,1`了，所以累加的值是`4`，现在`Flink`把累积后的状态`4`**已经**存储起来了（认为前面`2,1,1`这几个数字**已经完全**处理过了）。

程序一直往下走，处理了`5,3`，现在累加的值是`12`，但现在`Flink`还没来得及把`12`存储到最终的介质，此时系统挂掉了。

Flink重启后会重新把系统恢复到累加的值是`4`的状态，所以`5,3`得继续计算一遍，程序继续往下走。

看文章有的同学可能会认为：精确一次性指的不是某一段代码**只会执行一次**，不会执行多次或不执行。这`5`和`3`这两个数，你不是重复计算了吗？怎么就精确一次了？

**显然，代码只执行一次肯定是不可能的嘛**。我们无法控制系统在哪一行代码挂掉的，你要是在挂的时候，当前方法还没执行完，你还是得重新执行该方法的。

所以，状态**只持久化一次**到**最终**的存储介质中（本地数据库/HDFS)，在Flink下就叫做`exactly once`（计算的数据可能会重复（无法避免），但**状态在存储介质**上只会存储一次）。

那么`Flink`是在多长时间存储一次的呢？这个是我们自己**手动**配置的。

![f535b2f9a6c2479db3dc50534510fa9d.png][]

所谓的`CheckPoint`其实就是`Flink`会在指定的时间段上保存状态的信息，假设`Flink`挂了可以将**上一次**状态信息再捞出来，重放还没保存的数据来执行计算，最终实现`exactly once`。

那`CheckPonit`是怎么办到的呢？想想我们在`Kafka`在业务上实现「至少一次」是怎么做的？我们从`Kafka`把数据拉下来，处理完业务了以后，手动提交`offset` (告诉`Kafka`我已经处理完了)

![623aee8cc05244d1a34db86c24d96a1f.png][]

我们是**做完了**业务规则才将`offset`进行`commit`的，`checkponit`其实也是一样的（等拉下来该条数据所有的流程走完，才进行真正的`checkponit`）。

问题又来了，那`checkpoint`是怎么知道拉下来的数据已经走完了呢？`Flink`在流处理过程中插入了`barrier`，每个环节处理到`barrier`都会上报，等到`sink`都上报了`barrier`就说明这次`checkpoint`已经走完了。

![48d0d58dede740398f886ce7a0a0bf40.png][]

要注意的是，`Flink`实现的精确一次性只是保证**内部的状态**是精确一次的，如果想要端到端精确一次，需要端的支持

*  数据源需要可回放，发证故障可以重新读取未确认的数据
 *  `Flink`需要把数据存到磁盘介质（不能用内存），发生故障可以恢复
 *  发送源需要支持事务（从读到写需要事务的支持保证中途不失败）

![8a91138665bd466ea7b8897a2c4d5341.png][]

### 最后 ###

这篇文章对`Flink`做了一次简单的介绍，希望对大家在入门的时候有所帮助。后续打算会再写一篇`Flink`文章对`CheckPoint`机制做更加深入的了解，有兴趣的同学可以**点个关注**第一时间能接收到。

[9a86324e44044b4b825faf74a340e2b8.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/197e7e78b3d84722870cd76303008358.png
[bb6722f60b6c42a08d078d70b878a098.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/79b639853bcb4103bee1481147cc84cc.png
[5e196ac043d743dca8567053d9615a2f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/313c6e73a1974ee2aa674dd73c6abc6b.png
[ad4fcccc9bd64762b4453def2853bcb6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/75eeb694702e46708ebf619010cc7259.png
[f252f2c08e4b473db5dfd793c6626f27.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/baa5de9f6faf4cfeb1ee31336de36773.png
[34aef128fb78444a80bcc6d892c40fb0.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/a2d1d0f1abcc4a3bba3e588ec46959eb.png
[c821d451e8e34909abe17b9144ba28be.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/0dfb3fd599f547caba9f4658cd769520.png
[3ab8a846d7964523b2db11c9b1c83b32.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/f13d5b14a48a407098408ffcc6868b0e.png
[121fc2edccbe45338e63b9af3d81d61e.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/d3d26a55bc17486f921759002e20d3ed.png
[f535b2f9a6c2479db3dc50534510fa9d.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/64888fd6b5b64e18b857bc0a7bd4e638.png
[623aee8cc05244d1a34db86c24d96a1f.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/91b9b825b85044b6b62689b13d513662.png
[48d0d58dede740398f886ce7a0a0bf40.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/0d45887a7c6c42d3be82553b74b51aff.png
[8a91138665bd466ea7b8897a2c4d5341.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/08/50286f4b8c054dc6bd65f02330cd9a28.png