[整理]Flink基础

⽬录

什么是Flink？

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

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

分布式：「它的存储或者计算交由多台服务器上完成，最后汇总起来达到最终的效果」。实时：处理速度是毫秒级或者秒级的

计算：可以简单理解为对数据进⾏处理，⽐如清洗数据（对数据进⾏规整，取出有⽤的数据）基于官⽹的⼀句话介绍，我们就可以联想出很多东西。

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

什么是有边界和⽆边界？

Apache Flink 是⼀个框架和分布式处理引擎，⽤于在⽆边界和有边界数据流上进⾏有状态的计算。官⽅其实也有介绍，但对初学者来说不太好理解，我来幼⼉园化⼀下。

⼤家学到Flink了，消息队列肯定有⽤过吧？那你们是怎么⽤消息队列的呢？Producer⽣产数据，发给Broker，Consumer消费，完事。在消费的时候，我们需要管什么Producer什么时候发消息吗？不需要吧。反正来⼀条，我就处理⼀条，没⽑病吧。这种没有做任何处理的消息，默认就是⽆边界的。

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

什么时候⽤⽆边界，什么时候⽤有边界？那也很好理解。我做数据清洗：来⼀条，我处理⼀条，这种⽆边界的就好了。我要做数据统计：每个⼩时的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分的窗⼝数据。

什么叫做有状态？

Apache Flink 是⼀个框架和分布式处理引擎，⽤于在⽆边界和有边界数据流上进⾏有状态的计算。什么是有状态，什么是⽆状态？

⽆状态我们可以简单认为：每次的执⾏都不依赖上⼀次或上N次的执⾏结果，每次的执⾏都是独⽴的。

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

⽐如我们现在要统计⽂章的阅读PV(page view)，现在只要有⼀个点击了⽂章，在Kafka就会有⼀条消息。现在我要在流式处理平台上进⾏统计，那此时是有状态的还是⽆状态的？

假设我们要在Storm做，那我们可能将每次的处理结果放到⼀个“外部存储”中，然后基于这个“外部存储”进⾏计算（这⾥我们不⽤StormTrident），那此时Storm是⽆状态的。

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

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

可以简单的认为：Flink本⾝就给我们提供了\"存储\"的功能，⽽我们每次执⾏是可以依赖Flink的\"存储\"的，所以它是有状态的。那Flink是把这些有状态的数据存储在哪的呢？主要有三个地⽅：

内存

⽂件系统（HDFS）本地数据库

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

看到这⾥，你可能在会在别的地⽅看过Flink的另外⼀个⽐较出名的特性：精确⼀次性

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

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

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

精确⼀次性（exactly once）：有且只有⼀条，不多不少⾄少⼀次（at least once）：最少会有⼀条，只多不少最多⼀次（at most once）：最多只有⼀条，可能会没有Flink实现了精确⼀次性，这个精确⼀次性是什么意思呢？

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

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

1. 现在处理完2,1,1了，所以累加的值是4，现在Flink把累积后的状态4已经存储起来了（认为前⾯2,1,1这⼏个数字已经完全处理过了）。2. 程序⼀直往下⾛，处理了5,3，现在累加的值是12，但现在Flink还没来得及把12存储到最终的介质，此时系统挂掉了。3. Flink重启后会重新把系统恢复到累加的值是4的状态，所以5,3得继续计算⼀遍，程序继续往下⾛。

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

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

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

那么Flink是在多长时间存储⼀次的呢？这个是我们⾃⼰⼿动配置的。

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

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

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

问题⼜来了，那checkpoint是怎么知道拉下来的数据已经⾛完了呢？

Flink在流处理过程中插⼊了barrier(['bæriə(r)]栅栏)，每个环节处理到barrier都会上报，等到sink都上报了barrier就说明这次checkpoint已经⾛完了。

要注意的是，Flink实现的精确⼀次性只是保证内部的状态是精确⼀次的，如果想要端到端精确⼀次，需要端的⽀持：1. 数据源需要可回放，发证故障可以重新读取未确认的数据

2. Flink需要把数据存到磁盘介质（不能⽤内存），发⽣故障可以恢复3. 发送源需要⽀持事务（从读到写需要事务的⽀持保证中途不失败）