Hi~朋友，关注置顶防止错过消息
- Flink是什么？
- 为什么需要Flink？
- Flink的API分层是什么？
- 流的划分是什么？
- Flink的时间种类
- Flink的状态容错
- Flink的状态维护
- Watermarks是什么？
作者本人之所以写Flink是因为最近在做一些实时监控的东西，需要对数据流进行实时处理并计算然后投递到后续的存储，因此最近一段时间会持续研究Flink和监控的一些东西，也希望有Flink开发经验、监控系统开发经验的或对其感兴趣的读者朋友加我微信，互相交流学习。
什么是Flink？
Flink是一个流式计算的分布式处理引擎。
为什么需要Flink？
- Flink可以处理有界和无界流
- 部署灵活，支持多种资源调度器，包括Yarn、Kubernetes以及自身所携带的Standlone
- 高性能的流失处理，支持本地状态读取，避免网络IO，极大提升状态存取性能
- 精确一次处理，保证结果的可靠性
- 精准的时间控制，引入Event Time、WaterMarks等时间概念
- 状态的容错和恢复功能
Flink的API分层
对于使用Flink的开发者来说，Flink的API是我们直接面向，也是使用最多的东西，Flink的API按照可表达能力以及使用难易上大体可以分为三层：
- ProcessFunction
- DataStream API
- SQL或者Table API
如图所示，从下往上，API的使用的复杂度依次递减，同时表达能力上也是依次递减的。
流的划分有几类？
Flink中，流的划分大体可以分为两类，一类是有界流，一类是无界流，当然在这下面我们可以通过一些函数将流转换成KeyedStream或者其他流，但是站在数据源的角度上来说只划分为有界和无界。
Flink时间种类？
在流式处理框架中，时间是非常重要的一个状态，通过时间我们可以判断业务状态是否滞后，数据处理是否及时。Flink中提供了更为精细的时间控制，时间主要分为三类：
- Event Time：数据发生时的时间戳
- Ingestion Time：Flink读取事件时记录的时间
- Processing Time：Flink中具体算子处理事件的时间
Flink状态容错
在我们的Flink程序运行时，或许会发生各种各样的错误，导致程序中断，那我们在程序重启时需要找到一个状态并且从这个状态（可以称之为快照）进行恢复，使得程序可以从这个状态重新运行，该机制称之为Checkpoint。
我们的Flink程序很多时候都是7*24小时不间断的运行，需要不间断的过程中源源不断的产生快照（Global consistent snapshot，全局一致性快照）。
Checkpoint是由JobManager触发，假设我们现在需要产生Checkpoint Barrier N，此次Checkpoint一旦被触发，首先会在我们的数据源安插Checkpoint Barrier N，如上图所示，CheckPoint Barrier N前面的数据和事件（红色的圆圈部分）都由Checkpoint Barrier N负责，而N后面的数据和事件（色圆圈部分）则不属于Checkpoint Barrier N的管辖范围。
数据源收到Checkpoint Barrier N时，会先保存自己的状态（假如如果是kafka，那么就是kafka partition的offset），并填入全局一致性快照表格中，当Checkpoint Barrier N流经下游的算子时，算子会暂停数据处理，立即执行Checkpoint形成快照（执行完成以后恢复数据处理），当所有的算子及数据源快照形成完毕以后，我们则认为此次全局一致性快照制作成功，否则制作失败。
Flink的状态维护
Flink状态维护指的就是我们维护一组状态值，比如我们需要统计1天的我们页面部分模块的点击PV和UV，当这些状态值非常大时并且开启checkpoint机制时，这些状态则会被持久化到存储中以便恢复，目前状态的存储后端主要有以下三种：
- MemoryStateBackend：虚拟机内存，适合状态量不大的应用，内存直接读取写入，本地开发使用
- FsStateBackend：文件系统，目前可以支持hdfs、oss等，需要从外部存储进行序列化和反序列化进行读取，适用于处理大状态、长窗口的处理任务
- RocksDBStateBackend：本地数据库，暂存在本地磁盘，当checkpoint进行时依然会存储到文件系统中，该存储后端适用于大状态，长窗口的处理任务，并且支持增量checkpoint
Watermarks是什么？
Watermarks是Flink中的特殊事件，由于现实世界的网络等原因，事件到达算子的事件是无序的，当算子收到带有时间戳T的Watermarks时表示不会再收到时间戳小于T的事件了，从而避免在某个窗口无限期的等待下去或者提前结束导致计算不准，通过Watermarks我们可以保证在特定的时间后必须触发window进行计算输出结果。
