前言

What is Apache Flink?

Apache Flink is a framework and distributed processing engine for stateful computations over unbounded and bounded data streams. Flink has been designed to run in all common cluster environments, perform computations at in-memory speed and at any scale.

----Apache 官网 Flink概念
从Apache对Flink的定位，我们可以看出Flink是一个分布式处理引擎，可以对无界数据（有开始无结束）或有界数据（有开始有结束）进行有状态计算。
本文主要介绍了Flink的基础概念，旨在讲解使用Flink编程流处理项目之前需要掌握的几个Flink知识点，但并不进行深入讨论。

一、Why流处理？

为什么有了批处理还需要流处理？挖掘流数据中的自然规律可以更加真实快速地反映我们的生活，比如可穿戴设备的测量结果、实时路况转发，实时流量异常检测。

Flink流处理优势：
实现低延迟、高吞吐，容错性，基于事件时间处理数据

二、什么是流处理架构？

2.1 传统架构

维护了一个中心化的数据库系统，用于存储系统的事务性数据。

缺点在于：

• 数据架构过于单一，数据库是唯一正确的数据源，随着业务的复杂化，传统的数据架构可能会变得更加缓慢
• 异常问题处理方法复杂，异常出现时难以保证系统的正确运行
• 在大型分布式系统中，难以正确保证数据全局状态的一致性

而流处理不需要一个数据库来集中存储全局状态数据，流数据是共享且永不停止的数据，且是唯一正确的数据源。在流处理架构中，各个应用程序可以自己独立处理流数据，这些数据可以采用本地数据库或分布式文件来存储。

2.2 流处理架构的历史

storm->Lambda架构->spark streaming->Flink

storm，流处理先锋，低延迟的流处理，无法实现高吞吐，通过ack保证准确性，支持exactly-once语义；

Lambda架构，结合storm和批量MapReduce来保证低延迟与正确性：通过批量MapReduce作业提供虽有些延迟但结果准确的计算，同时通过storm将最新数据的计算结果初步展示出来；这种架构的缺点也很明显，对同样的业务逻辑即需要维护批处理的api，也需要维护流处理的api；

spark streaming，将连续事件中的流数据分割成一系列微小的批量作业，这种方式也称为微批处理，这种方式可支持exactly-once语义，实现了高吞吐，但延迟性差；

Flink，包含了以上流处理架构的所有好处，同时也解决了以上所有的弊端。Flink将批处理看成是一种特殊的流处理，以此来同时实现批处理与流处理。

2.3 流处理架构的构成

1、消息传输层：从各个数据生产者中采集连续事件的数据，并传输给订阅了这些数据的消费者，常见的消息传输层技术有Kafka和MapR Streams

这一层中维护了一个事件数据的安全队列，产生的消息可以被保留起来，也可以重播给流处理层。在复杂系统中，消息传输层往往对应了多个生产者与多个消费者，生产者负责生产数据，消费者负责消费数据，两者相互解耦，即生产者生产消息后，不是由生产者向所有的消费者广播，而是消费者从消息队列中订阅消息，消息到达后，消费者并不一定需要在运行状态，即消息达到后并不一定立刻被处理，具体处理时间可由消费者根据自身业务逻辑指定。

2、流处理层：聚合并处理事件；持续地将数据在应用程序与各系统间移动；应用程序的数据状态本地化

三、Flink如何正确进行流处理？

流处理中的正确包含了多种含义，比如计算结果是否正确；数据计算顺序是否正确；数据计算异常时能否及时恢复并保持准确；数据计算结果是否按时给出。

3.1 Flink的事件时间、处理时间与摄取时间，以及各种窗口？

• 事件时间：事件实际发生的时间，时间戳
• 处理时间：事件被处理机器处理的时间
• 摄取时间：也称进入时间，事件进入流处理框架的时间

如果事件以乱序到达流处理器，那么事件时间与处理时间不一致。

如果业务对结果正确性要求不那么高，且希望尽可能得到结果，那么可以使用处理时间，不必等待迟到的时间；如果业务对准确性有要求，即只有在时间窗口内发生的事件才能进行计算，那么应该使用处理时间。

使用事件时间不仅能保证准确性，还可以通过重置事件的时间戳或水印，即可以按时间回溯并正确地重新处理数据。

那么事件的水印是什么？

水印刻画的是事件时间的进展，通常基于事件时间的数据本身带有一个时间戳，这个时间戳可能被设置为这个数据的水印，那么当这条数据到达时，flink认为所有小于这个时间戳的数据都已经到达了。

Flink中的窗口，用于将许多事件按照时间或其它特征进行特征分组，然后按组进行计算。窗口包含时间窗口、计数窗口以及会话窗口等。时间窗口支持滚动和滑动，滚动模式数据计算不重叠，滑动可能会重叠。

3.2 Flink如何保证exactly-once？

流计算分为两种情况：无状态和有状态。如果温度超过80度则报警，这是无状态计算；计算过去一小时的平均温度，这是有状态计算。

• 无状态：观察每个独立事件，并根据最后一个事件输出结果
• 有状态：基于多个事件输出结果，维护了每个独立事件对输出结果的状态（即影响），最终基于最新一个事件与当前状态输出结果

在分布式系统中引入了状态的概念，则自然想到了一致性问题，即在故障发生前后正确性是否发生变化。流计算的一致性有三个级别：

• at-most-once：事件至多影响结果一次，计算结果<=正确值，在故障发生后，计算结果可能丢失
• at-least-once：事件至少影响结果一次，计算结果>=正确值，在故障发生后，只可能会多算，不会少算
• exactly-once：事件只影响结果一次，计算结果=正确值

检查点可以保证Flink实现exactly-once，检查点是指每隔一段时间（程序自定义），系统会保存事件的位置以及事件计算的中间状态，在故障发生重启后，直接定位到发生故障时事件的位置，并从对应的事件计算的中间状态开始计算。

如果检查点保存失败，Flink会丢弃该检查点并继续计算，到下一个检查点再保存，如果一系列连续的检查点都失败，那么Flink会判断这个任务是失败的。

检查点与保存点的区别？

设置好检查点时间间隔后，检查点是Flink自动生成的，而Flink提供了用户可手动触发状态保存的接口，那就是保存点，用户可以通过Flink命令行工具或Web控制台手动触发。保存点与检查点背后的工作方式完全相同。