Flink实时性、容错机制、窗口等介绍

问题导读

1.为什么flink实时性好？
2.flink通过什么机制保证数据既不重复，也不丢失？
3.flink采用什么机制通信？
4.flink有哪些窗口，他们的作用是什么？

最新经典文章，欢迎关注公众号


1.Flink实时性更好
1.spark只是近实时处理，Flink是真正的流处理

2.在设计上Flink认为数据是流式的，批处理只是流处理的特例。同时对数据分为有界数据和无界数据。
有界数据对应批处理，API对应Datestet
无界数据对应流处理，API对应SataStream




2.Flink窗口：

1.Flink同样产生窗口，那么窗口为什么产生？
是因为我们想看到过去一分钟，过去半小时的访问数据，这时候我们就需要窗口。

2.窗口分类
窗口分类可以分成：翻滚窗口（Tumbling Window，无重叠），滚动窗口（Sliding Window，有重叠），和会话窗口，（Session Window，活动间隙）

在没有flink的时候，滑动窗口让很多人不理解的人产生困惑。而困惑点，就是比如每隔30秒，滑动一次1分钟的窗口。这里面肯定有重复计算的数据。大家普遍第一印象认为spark的滑动窗口错误的认为是flink的滚动窗口。滑动窗口与滚动窗口的区别就是滑动窗口有重复的计算部分。

滚动窗口
滚动窗口分配器将每个元素分配给固定窗口大小的窗口。滚动窗口大小固定的并且不重叠。例如，如果指定大小为5分钟的滚动窗口，则将执行当前窗口，并且每五分钟将启动一个新窗口，如下图所示:



滑动窗口
滑动窗口分配器将每个元素分配给固定窗口大小的窗口。类似于滚动窗口分配器，窗口的大小由窗口大小参数配置。另外一个窗口滑动参数控制滑动窗口的启动频率(how frequently a sliding window is started)。因此，如果滑动大小小于窗口大小，滑动窗可以重叠。在这种情况下，元素被分配到多个窗口。例如，你可以使用窗口大小为10分钟的窗口，滑动大小为5分钟。这样，每5分钟会生成一个窗口，包含最后10分钟内到达的事件，如下图所示。



会话窗口
会话窗口分配器通过活动会话分组元素。与滚动窗口和滑动窗口相比，会话窗口不会重叠，也没有固定的开始和结束时间。相反，当会话窗口在一段时间内没有接收到元素时会关闭，例如，不活动的间隙时。会话窗口分配器配置会话间隙，定义所需的不活动时间长度(defines how long is the required period of inactivity)。当此时间段到期时，当前会话关闭，后续元素被分配到新的会话窗口。




窗口可以自定义
这是flink灵活的地方



基本操作：

window：创建自定义窗口
trigger：自定义触发器
evictor：自定义evictor
apply：自定义window function


3.Flink通信
Flink通信使用akka
spark用Netty通信框架代替Akka，是不是Akka不好。其实他们各有优缺点。
Akka：它是基于协程的，性能不容置疑；基于scala的偏函数，易用性也没有话说，但是它毕竟只是RPC通信。
Netty相比更加基础一点，可以为不同的应用层通信协议（RPC，FTP，HTTP等）提供支持
实践是检验真理的唯一标准，目前尚未发现Flink使用akka遇到性能等问题。

4.Flink容错
容错的了解：
checkpoint是很重要的机制，因为Flink的检查点是通过分布式快照实现的，所以这里我们对快照和检查点不进行区分。

分布式数据流的轻量级异步快照
分布式有状态流处理支持在云中部署和执行大规模连续计算，同时针对低延迟和高吞吐量。这种模式最基本的挑战之一是在潜在的失败下提供处理保证。现有方法依赖于可用于故障恢复的周期性全局状态快照。这些方法有两个主要缺点。首先，它们经常会停止影响摄取的整体计算。其次，他们急切地坚持传输中的所有记录以及操作状态，这导致比所需更快的快照。在这项工作中，我们提出了异步屏障快照（ABS），这是一种适用于现代数据流执行引擎的轻量级算法，可最大限度地减少空间需求。 ABS仅保留非循环执行拓扑上的运算符状态，同时保持循环数据流的最小记录日志。我们在Apache Flink上实现了ABS，这是一个支持有状态流处理的分布式分析引擎。我们的评估表明，我们的算法对执行没有太大的影响，保持线性可扩展性并且在频繁的快照中表现良好。

barriers
Flink分布式快照的核心概念之一是barriers。 这些barriers被注入数据流并与记录一起作为数据流的一部分向下流动。 barriers永远不会超过记录，数据流严格有序。 barriers将数据流中的记录分为进入当前快照的记录和进入下一个快照的记录。每个barriers都带有快照的ID，并且barriers之前的记录都进入了该快照。 barriers不会中断流的流动，非常轻量级。 来自不同快照的多个barriers可以同时在流中出现，这意味着可以同时发生各种快照。



Barrier分为两类：
BarrierBuffer通过阻塞已接收到barrier的input channel并缓存被阻塞的channel中后续流入的数据流，直到所有的barrier都接收到或者不满足特定的检查点的条件后，才会释放这些被阻塞的channel，这个机制被称之为——aligning（对齐）。正是这种机制来实现EXACTLY_ONCE的一致性（它将检查点中的数据精准得隔离开）。

而BarrierTrack的实现就要简单地多，它仅仅是对数据流中的barrier进行跟踪，但是数据流中的元素buffer是直接放行的。这种情况会导致同一个检查点中可能会预先混入后续检查点的元素，从而只能提供AT_LEAST_ONCE的一致性。

注意都备份了哪些内容？

Snapshot并不仅仅是对数据流做了一个状态的Checkpoint，它也包含了一个Operator内部所持有的状态，这样才能够在保证在流处理系统失败时能够正确地恢复数据流处理。

barrier作用：它会作为数据流的记录被同等看待，被插入到数据流中，将数据流中记录的进行分组，并沿着数据流的方向向前推进

具体排列过程如下：

• Operator从一个incoming Stream接收到Snapshot Barrier n，然后暂停处理，直到其它的incoming Stream的Barrier n（否则属于2个Snapshot的记录就混在一起了）到达该Operator接收到Barrier n的Stream被临时搁置，来自这些Stream的记录不会被处理，而是被放在一个Buffer中。
  

• 一旦最后一个Stream接收到Barrier n，Operator会emit所有暂存在Buffer中的记录，然后向Checkpoint Coordinator发送Snapshot n，继续处理来自多个Stream的记录
• 基于Stream Aligning操作能够实现Exactly Once语义，但是也会给流处理应用带来延迟，因为为了排列对齐Barrier，会暂时缓存一部分Stream的记录到Buffer中，尤其是在数据流并行度很高的场景下可能更加明显，通常以最迟对齐Barrier的一个Stream为处理Buffer中缓存记录的时刻点。在Flink中，提供了一个开关，选择是否使用Stream Aligning，如果关掉则Exactly Once会变成At least once。
  

Flink实时性、容错机制、窗口，good

感谢分享

Flink 的整体结构 运行模式 | runtime | Api
Flink的WindowFuncation 滑动 | 滚动 | 会话
Flink的容错 -- CheckPoint(Job Manager)中 使用了Chandy Lamport算法, 容错机制为流创建了有关快照的确切详细信息,这个过程是轻量级的异步的快照,如果发生问题后,Flink会从最新的一些检查点中的信息,重新开始执行
Barriers CheckPoint核心要素之一,有一个唯一ID,每个状态都会给JobManager发送快照状态信息 | 后面的还不是很清楚

学习了！！！