Hi~朋友,关注置顶防止错过消息
作者本人之所以写Flink是因为最近在做一些实时监控的东西,需要对数据流进行实时处理并计算然后投递到后续的存储,因此最近一段时间会持续研究Flink和监控的一些东西,也希望有Flink开发经验、监控系统开发经验的或对其感兴趣的读者朋友加我微信,互相交流学习。
什么是Flink?
Flink是一个流式计算的分布式处理引擎。
为什么需要Flink?
Flink的API分层
对于使用Flink的开发者来说,Flink的API是我们直接面向,也是使用最多的东西,Flink的API按照可表达能力以及使用难易上大体可以分为三层:
如图所示,从下往上,API的使用的复杂度依次递减,同时表达能力上也是依次递减的。
流的划分有几类?
Flink中,流的划分大体可以分为两类,一类是有界流,一类是无界流,当然在这下面我们可以通过一些函数将流转换成KeyedStream或者其他流,但是站在数据源的角度上来说只划分为有界和无界。
Flink时间种类?
在流式处理框架中,时间是非常重要的一个状态,通过时间我们可以判断业务状态是否滞后,数据处理是否及时。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机制时,这些状态则会被持久化到存储中以便恢复,目前状态的存储后端主要有以下三种:
Watermarks是什么?
Watermarks是Flink中的特殊事件,由于现实世界的网络等原因,事件到达算子的事件是无序的,当算子收到带有时间戳T的Watermarks时表示不会再收到时间戳小于T的事件了,从而避免在某个窗口无限期的等待下去或者提前结束导致计算不准,通过Watermarks我们可以保证在特定的时间后必须触发window进行计算输出结果。