怎么实现数据的实时更新_大数据专家教你学Flink：BroadcastState实现流处理配置实时更新...

前言

Broadcast State是Flink支持的一种Operator State。使用Broadcast State，可以在Flink程序的一个Stream中输入数据记录，然后将这些数据记录广播(Broadcast)到下游的每个Task中，使得这些数据记录能够为所有的Task所共享，比如一些用于配置的数据记录。这样，每个Task在处理其所对应的Stream中记录的时候，读取这些配置，来满足实际数据处理需要。另外，在一定程度上，Broadcast State能够使得Flink Job在运行过程中与外部的其他系统解耦合。比如，通常Flink会使用YARN来管理计算资源，使用Broadcast State就可以不用直接连接MySQL数据库读取相关配置信息了，也无需对MySQL做额外的授权操作。因为在一些场景下，会使用Flink on YARN部署模式，将Flink Job运行的资源申请和释放交给YARN去管理，那么就存在Hadoop集群节点扩缩容的问题，如新加节点可能需要对一些外部系统的访问，如MySQL等进行连接操作授权，如果忘记对MysQL访问授权，Flink Job被调度到新增的某个新增节点上连接并读取MySQL配置信息就会出错。

Broadcast State API

通常，我们首先会创建一个Keyed或Non-Keyed的Data Stream，然后再创建一个Broadcasted Stream，最后通过Data Stream来连接(调用connect方法)到Broadcasted Stream上，这样实现将Broadcast State广播到Data Stream下游的每个Task中。如果Data Stream是Keyed Stream，则连接到Broadcasted Stream后，添加处理ProcessFunction时需要使用KeyedBroadcastProcessFunction来实现，下面是KeyedBroadcastProcessFunction的API，代码如下所示：

public abstract class KeyedBroadcastProcessFunction extends BaseBroadcastProcessFunction {    public abstract void processElement(final IN1 value, final ReadOnlyContext ctx, final Collector out) throws Exception;    public abstract void processBroadcastElement(final IN2 value, final Context ctx, final Collector out) throws Exception;}

上面泛型中的各个参数的含义，说明如下：

• KS：表示Flink程序从最上游的Source Operator开始构建Stream，当调用keyBy时所依赖的Key的类型；
• IN1：表示非Broadcast的Data Stream中的数据记录的类型；
• IN2：表示Broadcast Stream中的数据记录的类型；
• OUT：表示经过KeyedBroadcastProcessFunction的processElement()和processBroadcastElement()方法处理后输出结果数据记录的类型。

如果Data Stream是Non-Keyed Stream，则连接到Broadcasted Stream后，添加处理ProcessFunction时需要使用BroadcastProcessFunction来实现，下面是BroadcastProcessFunction的API，代码如下所示：

public abstract class BroadcastProcessFunction extends BaseBroadcastProcessFunction {    public abstract void processElement(final IN1 value, final ReadOnlyContext ctx, final Collector out) throws Exception;    public abstract void processBroadcastElement(final IN2 value, final Context ctx, final Collector out) throws Exception;}

上面泛型中的各个参数的含义，与前面KeyedBroadcastProcessFunction的泛型类型中的后3个含义相同，只是没有调用keyBy操作对原始Stream进行分区操作，就不需要KS泛型参数。具体如何使用上面的BroadcastProcessFunction，接下来我们会在通过实际编程，来以使用KeyedBroadcastProcessFunction为例进行详细说明。

使用场景实践

用户购物路径长度跟踪场景描述

我们先描述一下使用Broadcast State的场景：针对用户在手机App上操作行为的事件，通过跟踪用户操作来实时触发指定的操作。假设我们关注一个用户在App上经过多次操作之后，比如浏览了几个商品、将浏览过的商品加入购物车、将购物车中的商品移除购物车等等，最后发生了购买行为，那么对于用户从开始到最终达成购买所进行操作的行为的次数，我们定义为用户购物路径长度，通过这个概念假设可以通过推送优惠折扣权限、或者适时地提醒用户使用App等运营活动，能够提高用户的复购率，这个是我们要达成的目标。事件均以指定的格式被实时收集上来，我们统一使用JSON格式表示，例如，一个用户在App上操作行为我们定义有如下几种：

• VIEW_PRODUCT
• ADD_TO_CART
• REMOVE_FROM_CART
• PURCHASE

可以很容易根据上面的事件类型定义，理解每种类型的含义。用户在最终达成下单购买操作过程中，会经过一系列操作：VIEW_PRODUCT、ADD_TO_CART、REMOVE_FROM_CART的不同组合，每个也可以重复操作多次，最终发生购买类型PURCHASE的行为，然后我们对该用户计算其购物路径长度，通过计算该度量来为外部业务系统提供运营或分析活动的基础数据，外部系统可以基于该数据对用户进行各种运营活动。例如，下面是几个示例事件的记录，如下所示：

{"userId":"d8f3368aba5df27a39cbcfd36ce8084f","channel":"APP","eventType":"VIEW_PRODUCT","eventTime":"2018-06-12_09:27:11","data":{"productId":196}}{"userId":"d8f3368aba5df27a39cbcfd36ce8084f","channel":"APP","eventType":"ADD_TO_CART","eventTime":"2018-06-12_09:43:18","data":{"productId":126}}{"userId":"d8f3368aba5df27a39cbcfd36ce8084f","channel":"APP","eventType":"VIEW_PRODUCT","eventTime":"2018-06-12_09:27:11","data":{"productId":126}}{"userId":"d8f3368aba5df27a39cbcfd36ce8084f","channel":"APP","eventType":"PURCHASE","eventTime":"2018-06-12_09:30:28","data":{"productId":196,"price":600.00,"amount":600.00}}

另外，因为App注册用户很多，不可能所有的用户发生的购物行为路径都能满足特定条件，假设对于购物路径长度很短的，很可能该用户使用App时目的性很强，很快就下单购买，对于这类用户我们暂时先不想对他们做任何运营活动，所以进行流数据处理时需要输入对应的路径长度的配置值，来限制这种情况。