手记

一百页的《Flink基础教程》能教会我们什么?

前言

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控制台手动触发。保存点与检查点背后的工作方式完全相同。

2人推荐
随时随地看视频
慕课网APP