Flink 六脉神剑秘诀

Flink是什么?

Flink是一款实时计算框架，能够实现ms级别甚至更低的延时计算（流式处理 -- 有状态的计算处理），不少同学肯定会提及spark streaming(可认为是批处理，类似Hive -- 无状态计算；这几个框架只能做到准实时，ms级别的延时是达不到要求)。当然，如果你对延时容忍度高，那么可以选择这两个框架

最具代表性的使用场景：阿里双11大屏交易总金额的实时刷新

Flink如何实现流式处理？

对于批处理而言，当前提条件限制之后，数据的输入是固定的；并且，在执行一次计算计划的时候，要么全部成功或者失败。

对于流处理而言，数据如流水一般由源头奔涌向下。那么通过什么准则去如何去抽取、约定你需要的数据呢？-----时间。更重要的是，由于流式计算中间也会遇到宕机、数据处理失败等等问题，时间点也能作为恢复范围点重要参考

在Flink中有三个时间定义

• Event time：事件本身发生的时间，与flink引擎无关。例如：用户在某个时刻下单一个商品，订单产生时间是事件时间
• Processing Time：Flink处理数据时间
• Ingestion Time：进入Flink框架时间。例如：订单产生在9:00，那么9:00是Event time；数据在9:00 30s时进入flink中(如果有较大延时)，那么9:00 30s这个时刻是Ingestion Time，然后数据在9:01被计算，9:01是Processing Time

                                               

Flink如何应对延时？

• 延时产生原因：网络抖动、计算资源不够等一系列的原因，会导致在整个流处理过程中有较大的延时
• 延时影响：可能导致部分计算结果不准确
  • 例如：我们用长度为1h 的时间窗口  计算 9:00 -- 10:00 交易累计金额。在9:59 40s的时候确实产生了一条交易数据，那么该条数据的事件时间是 9:59 40s。由于延时的问题，导致该条数据在 10:01 才被Flink读取，因此该数据未能被计算(不在9:00 -10:00 窗口范围内)；一般在流计算的时候会进行批计算，在核对结果的时候就会发现总金额少了 9:59 40s 这份数据
• 如何处理延时：watermark (水位)
  • watermark：基于event time，告诉窗口函数，可能有数据还没有来，你再等一等执行计算
  • watermark影响：但是watermark设置的越大，会带来更大的延时，效果会越准确(最后可理解为转成了批处理？) ，具体根据业务场景来
  • 处理延时：在进行计算之前，设置一个水位点，例如设置2min。还是看上面的例子，假如不设水位那么 9:59 40s 的数据必然会丢，那么设置会怎么样呢？
    • 设置2min之后，在10:00 窗口触发时间，窗口函数不会立马触发，而是会再等 2min，等到10:02触发窗口计算。然后看这两分钟内是否还会有event time 在窗口内的数据(这段话细品、你细品)。因此，尽管9:59 40s 延时到 10:01 ，但是10:01 < 10:02 因此该条数据不会丢

Flink窗口函数(主要讲复杂事件处理cep)

• 滑动窗口
• 滚动窗口
• 会话窗口
• cep机制(Complex event processing) -- 复杂事件处理：可认为是一种为事件窗
  • cep与前面三个窗口的区别在于：前面三个窗口是基于时间来处理流数据，而cep是根据事件定义来处理流数据。前面三个可以自行csdn 或者百度，都比较好理解，接下来主要讲cep
• cep如何工作？
  • 举个例子：你开车从 A -> B点，然后你要计算这段行程中发生了哪些不良驾驶行为，如急加速、减速等(如果有埋点数据次采集的话)。但是在这里你用不了时间窗口进行聚合累加，因为你不知道 A->B点得用多久，不同人也不一样。为什么cep可以？因为cep可以将一个事件流定义为一个窗口，如A->B，点火可以认为是行程开始，熄火可以认为是行程的结束，（这里不是很严谨，肯定有很多爱开车的同学要跟我杠了，为什么不是从刷卡开始//手动狗头）

                                                                                      

• cep 完整定义
  • 事件开始
  • 中间事件
  • 事件结束
    • 通过上面事件定义，能够将一个事件流从数据流从以窗口的方式剥离出来

   

Flink容错

由于Flink是流式计算，整个计算过程不断持续，区别于批计算(无状态计算 --- 错了整段重跑一次)。对于Flink而言，是增量计算，不可能全部重跑。一般都是在某个时间范围内重跑，那么就需要两个条件。1、出错的时间点，也就是你需要重跑的时间点  2、当时的计算状态(state)

• 针对重跑时间
  • 为了保证数据的正确性，可以选择在出错时间点更提前的位置进行重跑(比如10点的时候数据报错，你可以选择在9点进行重跑)，付出的代价就是需要去追数据。因为现在可能是下午3点了，你从上午9点跑，这期间的数据都会被刷新一次，所以会考验资源的一个配置，如果资源配置过低，很可能追不上现阶段的数据，造成大延时。如果是追数据的话，建议整个资源配比调高一点
• 针对计算状态(这里面的东西很多)
  • 为什么需要state，像之前提到的，Flink是增量计算，因此需要保存在计算过程中节点的中间计算结果或者元数据属性，这两块统称为state。State可以分类两大类
    • keyState:进行group by的字段
    • operatorState：读取数据流的offest，类似于kafka消息队列位移

有了状态跟时间，那么Flink是怎么进行容错处理的呢？下面我们仔细介绍

1. 首先对于每个增量计算过程中，需要有快照保存类似timer、connector、window、state等信息 --- 该部分可以理解为信息保存，也就是Checkpoint -- 检查点
2. 既然有了检查点，如何实现呢？
   1. 由于Flink的语法会被抽象为DAG(有向无环图)，在次过程中，由source端会下发一个叫barrier的数据标志
   2. barrier会将source下发的数据，分到不同的checkpoint中
   3. 如果是exactly_once语义，那么会需要进行barrier对齐，保证结果一致性
   4. 对齐之后进行checkpoint，生成snapshot，进行持久化存储
   5. 完成snapshot之后，下发barrier直至sink，表明此次快照结束
3. 针对Checkpoint而言，有两种模式
   • at_least_once语义：即事件消息至少被消费一次
     • 对于 at_least_once，消息在经过各个operator时，不会进行堵塞，而是来了一份数据消费一份，进行快照
   • exactly_once语义：事件消息仅被消费一次
     • 对于消费一次而言，当其他barrier在算子端未对齐的时候，消息不被消费，而是被缓存进barrierbuff，等到barrier对齐之后，数据从barrierbuff中被消费，因此该语义也会造成比较大的延时
4. 当任务在某个点fail之后，我们进行重启，比如我们重启9点的数据，进行计算，但是在flink内部，如果9点没有相应的checkpoint，那么会向前找最近的一个点，比如8.59分这种

Flink查询

• 对于流计算而言，数据查询是动态的，是持续查询。原因是因为每个时刻数据内容都在发生改变，那么流数据是如何做到结果一致性的呢？
• 接下来我们以Mysql的存储过程举例，说明Flink的持续查询是如何实现
  • Mysql的任何操作都会被记录在binlog中，将binlog转为中继日志可以实现备份的功能。我们也可以利用该日志来模型持续查询
  • 我们可以写一个触发器，一旦有新的数据进来之后，就进行查询。然后通过一条条的数据插入，对应会有一次次的查询结果
  • 对于无PK(主键)的表而言，事实上实现的是append
  • 对于有PK的表而言，实现的是update，但是Mysql
  • 需要注意：Mysql实现的是全量查询，而在Flink中实现的是增量查询Flink的持续查询也可以这样理解，当有一条数据来的时候Flink会进行一次查询，数据流源源不断，查询结果也会不断刷新，这个过程就是Flink的持续查询

Flink中文文档

https://flink.apachecn.org/#/

后续会更新flink的相关优化技巧，毕竟未来流是主要方向