背景
Flink通常被用来处理流式数据,有着众多的应用场景,比方说实时的ETL、检测报警等业务场景。这些场景通常会涉及到规则的更新,比如对解析规则和报警规则进行更改后,流任务应能够实时感知到,并用新的规则继续检测,避免因为规则更改而重启任务造成的开销。一般来说流式任务的重启是比较重的。
方案选择
接下来分别介绍下两种可行的方案与选型
1.广播变量与广播流
广播变量通常被运用到以下场景中:一个流中的一些数据需要被广播到所有的下游任务,被下游任务缓存在本地并用于处理另一个流上的所有传入数据。例如,一个低吞吐量的流包含了一组规则,我们希望根据这些规则对另一个流的所有数据进行检测。因此,广播变量(broadcast state)和其他的state相比有以下不同:(1)目前只支持map格式(2)算子需要同时包含广播流和普通的数据流才可用(3)一个算子可以使用多个广播变量并用名称进行区分
2.异步IO
流计算中经常会需要跟外部存储系统交互,如mysql、redis等。众所周知,在流处理中查询外部存储系统并等结果返回等待时间相对来说是比较长的,若数据量较大则导致会吞吐量会大大降低,使流任务基本处于阻塞不可用状态。同步处理与异步处理
Flink的异步IO可以使得流任务在不阻塞运算的情况下异步请求外部系统,并且支持超时处理,以及返回结果有序或无序处理等。关于异步IO的详细原理介绍已存在较多资料不在展开。通过异步IO获取规则的原理就是在数据到来之后查询外部系统获取规则,并根据规则检测或解析数据。比方将规则存放在redis、mysql等等。
理论上两种方式都是可以完成从外部系统获取规则并进行更新的。现分析下量两种方式的差别与特点。对于异步IO来说若对于每条数据查一次外部