【Flink知识汇总】【Join专题】

视频地址：https://www.bilibili.com/video/av92215954/
文档地址：https://files.alicdn.com/tpsservice/e4356097e11364edadb5627a892ee53b.pdf

Join 的应用场景

几乎所有公司的 APP 都会涉及到的曝光关联点击；两条流数据之间的维度拼接；将表打宽等等
电商场景中的退单的订单关联下单的订单分析退单的单的特点等

批Join和流Join的区别

在这里插入图片描述

在批式计算中，Join 的左右表都是 “全集”，所以在全集上面做关联操作是非常简单的，比如目前离线中的技术方案有 sort-merge、hash join 等，这些方案都非常成熟了，哪怕博主自己写个 Java 代码也能实现一个极简版本的批 Join。
在流式计算中，左右表的数据都是无界的，而且是实时到来的。这就会引起流式计算中的 2 个问题 + 大数据中的 2 个核心问题（我们以 A left join B 举例）：

流式计算中的 2 个问题

流式数据到达计算引擎的时间不一定：比如 A 流的数据先到了，A 流不知道 B 流对应同 key 的数据什么时候到，没法关联 （数据质量问题）
流式数据不知何时、下发怎样的数据：A 流的数据到达后，如果 B 流的数据永远不到，那么 A 流的数据在什么时候以及是否要填充一个 null 值下发下去 （数据时效问题）

Flink 双流Join

1. Window Join

认识Window Join

就是将两条流的数据从无界数据变为有界数据，即划分出时间窗口，然后将同一时间窗口内的两条流的数据做 Join（这里的时间窗口支持 Tumbling、Sliding、Session）

在这里插入图片描述
那么该方案怎么解决第 3 节说的两个问题呢？

流式数据到达计算引擎的时间不一定：数据已经被划分为窗口，无界数据变为有界数据，就和离线批处理的方式一样了，两个窗口的数据简单的进行关联即可
流式数据不知何时、下发怎样的数据：窗口结束就把数据下发下去，关联到的数据就下发 [A, B]，没有关联到的数据取决于是否是 outer join 然后进行数据下发

Flink API

Inner Join
此方案只支持 inner join，即窗口内能关联到的才会下发，关联不到的则直接丢掉。

在这里插入图片描述

Outer Join
如果你想实现 window 上的 outer join，可以使用 coGroup 算子

public class CogroupFunctionDemo02 {

    public static void main(String[] args) throws Exception {
        final StreamExecutionEnvironment env=StreamExecutionEnvironment.getExecutionEnvironment();

        // A 流
        DataStream<Tuple2<String,String>> input1=env.socketTextStream("",9002)
                .map(new MapFunction<String, Tuple2<String,String>>() {

                    @Override
                    public Tuple2<String,String> map(String s) throws Exception {

                        return Tuple2.of(s.split(" ")[0],s.split(" ")[1]);
                    }
                });

        // B 流
        DataStream<Tuple2<String,String>> input2=env.socketTextStream("",9001)
                .map(new MapFunction<String, Tuple2<String,String>>() {

                    @Override
                    public Tuple2<String,String> map(String s) throws Exception {

                        return Tuple2.of(s.split(" ")[0],s.split(" ")[1]);
                    }
                });

        // A 流关联 B 流
        input1.coGroup(input2)
                // A 流的 keyby 条件
                .where(new KeySelector<Tuple2<String,String>, Object>() {

                    @Override
                    public Object getKey(Tuple2<String, String> value) throws Exception {
                        return value.f0;
                    }
                }).equalTo(new KeySelector<Tuple2<String,String>, Object>() {
                // B 流的 keyby 条件

            @Override
            public Object getKey(Tuple2<String, String> value) throws Exception {
                return value.f0;
            }
        })
                // 窗口
                .window(ProcessingTimeSessionWindows.withGap(Time.seconds(3)))
                .apply(new CoGroupFunction<Tuple2<String,String>, Tuple2<String,String>, Object>() {

                // 可以自定义实现 A 流和 B 流在关联不到时的输出数据格式

                    @Override
                    public void coGroup(Iterable<Tuple2<String, String>> iterable, Iterable<Tuple2<String, String>> iterable1, Collector<Object> collector) throws Exception {
                        StringBuffer buffer=new StringBuffer();
                        buffer.append("DataStream frist:\n");
                        for(Tuple2<String,String> value:iterable){
                            buffer.append(value.f0+"=>"+value.f1+"\n");
                        }
                        buffer.append("DataStream second:\n");
                        for(Tuple2<String,String> value:iterable1){
                            buffer.append(value.f0+"=>"+value.f1+"\n");
                        }
                        collector.collect(buffer.toString());
                    }
                }).print();

        env.execute();
    }
}

SQL API

SELECT 
    L.num as L_Num
    , L.id as L_Id
    , R.num as R_Num
    , R.id as R_Id
    , L.window_start
    , L.window_end
FROM (
    SELECT * 
    FROM TABLE(TUMBLE(TABLE LeftTable, DESCRIPTOR(row_time), INTERVAL '5' MINUTES))
) L
FULL JOIN (
    SELECT * 
    FROM TABLE(TUMBLE(TABLE RightTable, DESCRIPTOR(row_time), INTERVAL '5' MINUTES))
) R
ON L.num = R.num 
AND L.window_start = R.window_start 
AND L.window_end = R.window_end;

解决方案的特点

产出数据质量：低
产出数据时效性：中

当我们的窗口大小划分的越细时，在窗口边缘关联不上的数据就会越多，数据质量就越差。窗口大小划分的越宽时，窗口内关联上的数据就会越多，数据质量越好，但是产出时效性就会越差。所以小伙伴萌在使用时要注意取舍。

举个例子：以曝光关联点击来说，如果我们划分的时间窗口为 1 分钟，那么一旦出现曝光在 0:59，点击在 1:01 的情况，就会关联不上，当我们的划分的时间窗口 1 小时时，只有在每个小时的边界处的数据才会出现关联不上的情况。

解决方案的适用场景

该种解决方案适用于可以评估出窗口内的关联率高的场景，如果窗口内关联率不高则不建议使用。

注意：这种方案由于上面说到的数据质量和时效性问题在实际生产环境中很少使用。

2. Interval Join

2.1 认识Interval Join

Interval Join 又叫做区间Join
Interval Join 其也是将两条流的数据从无界数据变为有界数据，但是这里的有界和上节说到的 Flink Window Join 的有界的概念是不一样的，这里的有界是指两条流之间的有界

以 A 流 join B 流举例，interval join 可以让 A 流可以关联 B 流一段时间区间内的数据，比如 A 流关联 B 流前后 5 分钟的数据

在这里插入图片描述
Interval Join特点

限定Join的窗口时间，对超出时间范围的数据进行清理，避免保留全量State
仅支持 event time

那么该方案怎么解决第 3 节说的两个问题呢？

流式数据到达计算引擎的时间不一定：数据已经被划分为窗口，无界数据变为有界数据，就和离线批处理的方式一样了，两个窗口的数据简单的进行关联即可
流式数据不知何时、下发怎样的数据：窗口结束（这里的窗口结束是指 interval 区间结束，区间的结束是利用 watermark 来判断的）就把数据下发下去，关联到的数据就下发 [A, B]，没有关联到的数据取决于是否是 outer join 然后进行数据下发

2.2 Flink API

Interval Join算子

使用方式：

stream.join(otherStream)
.where(<KeySelector>)
.equalTo(<KeySelector>)
.window(<WindowAssigner>)
.apply(<JoinFunction>) //实现元素匹配后的处理逻辑
//JoinFunction 或者 FlatJoinFunction

package No12_Join.DoubleStreamJoin;

import No12_Join.Bean.JoinBean;
import org.apache.flink.api.common.eventtime.SerializableTimestampAssigner;
import org.apache.flink.api.common.eventtime.WatermarkStrategy;
import org.apache.flink.api.common.functions.MapFunction;
import org.apache.flink.api.java.tuple.Tuple2;
import org.apache.flink.streaming.api.datastream.DataStreamSource;
import org.apache.flink.streaming.api.datastream.SingleOutputStreamOperator;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.streaming.api.functions.co.ProcessJoinFunction;
import org.apache.flink.streaming.api.windowing.time.Time;
import org.apache.flink.util.Collector;

/**
 * 只支持eventTime 和 keyedStream
 */
public class NonWindowJoin01_IntervalJoin {
    public static void main(String[] args) throws Exception {
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
        env.setParallelism(1);


        //todo 1.准备两个流
        DataStreamSource<String> DS1 = env.socketTextStream("hadoop102", 9999);
        SingleOutputStreamOperator<JoinBean> joinBeanDS1 = DS1.map(new MapFunction<String, JoinBean>() {
            @Override
            public JoinBean map(String s) throws Exception {
                String[] fields = s.split(",");
                return new JoinBean(fields[0], fields[1], Long.parseLong(fields[2]));
            }
        }).assignTimestampsAndWatermarks(
                WatermarkStrategy.<JoinBean>forMonotonousTimestamps()
                        .withTimestampAssigner(new SerializableTimestampAssigner<JoinBean>() {
                            @Override
                            public long extractTimestamp(JoinBean joinBean, long l) {
                                return joinBean.getTs() * 1000;
                            }
                        })
        );

        DataStreamSource<String> DS2 = env.socketTextStream("hadoop102", 8888);
        SingleOutputStreamOperator<JoinBean> joinBeanDS2 = DS2.map(new MapFunction<String, JoinBean>() {
            @Override
            public JoinBean map(String s) throws Exception {
                String[] fields = s.split(",");
                return new JoinBean(fields[0], fields[1], Long.parseLong(fields[2]));
            }
        }).assignTimestampsAndWatermarks(
                WatermarkStrategy.<JoinBean>forMonotonousTimestamps()
                        .withTimestampAssigner(new SerializableTimestampAssigner<JoinBean>() {
                            @Override
                            public long extractTimestamp(JoinBean joinBean, long l) {
                                return joinBean.getTs() * 1000;
                            }
                        })
        );
        
        //todo 双流join
        SingleOutputStreamOperator<Tuple2<JoinBean, JoinBean>> joinDS = joinBeanDS1.keyBy(x -> x.getName())
                .intervalJoin(joinBeanDS1.keyBy(x -> x.getName()))
                .between(Time.seconds(-5), Time.seconds(5))//ds2等ds1 ds1等ds2
                //.lowerBoundExclusive()
                //.upperBoundExclusive()
                .process(new ProcessJoinFunction<JoinBean, JoinBean, Tuple2<JoinBean, JoinBean>>() {
                    @Override
                    public void processElement(JoinBean joinBean, JoinBean joinBean2, ProcessJoinFunction<JoinBean, JoinBean, Tuple2<JoinBean, JoinBean>>.Context context, Collector<Tuple2<JoinBean, JoinBean>> collector) throws Exception {
                        collector.collect(new Tuple2<>(joinBean, joinBean2));
                    }
                });

        joinDS.print();

        env.execute();
        //8888           9999
        //1001  1
        //               1001  1    =>输出 1001 1 , 1001  1
        //               1001  2    =>输出 1001 1 ,  1001 2
        //1002 10
        //               1001 3     =>输出 1001 1 ,  1001 3
        //               1002 10    =>输出 1002 10,  1000 10
        //               1001 3     =>不输出  因为watermark已经到10了
    }
}

Connect 算子实现

package No12_Join.DoubleStreamJoin;

import No07_案例.Bean.OrderEvent;
import No07_案例.Bean.TxEvent;
import No07_案例.demo01._13_支付到账_keyBy后connect;
import No12_Join.Bean.JoinBean;
import org.apache.flink.api.common.functions.CoGroupFunction;
import org.apache.flink.api.common.functions.FlatMapFunction;
import org.apache.flink.api.common.functions.MapFunction;
import org.apache.flink.api.common.state.ValueState;
import org.apache.flink.api.common.state.ValueStateDescriptor;
import org.apache.flink.api.java.functions.KeySelector;
import org.apache.flink.api.java.tuple.Tuple2;
import org.apache.flink.configuration.Configuration;
import org.apache.flink.streaming.api.datastream.*;
import org.apache.flink.streaming.api.environment.StreamExecutionEnvironment;
import org.apache.flink.streaming.api.functions.co.CoProcessFunction;
import org.apache.flink.streaming.api.functions.co.KeyedCoProcessFunction;
import org.apache.flink.streaming.api.functions.timestamps.AscendingTimestampExtractor;
import org.apache.flink.streaming.api.functions.timestamps.BoundedOutOfOrdernessTimestampExtractor;
import org.apache.flink.streaming.api.windowing.assigners.TumblingEventTimeWindows;
import org.apache.flink.streaming.api.windowing.time.Time;
import org.apache.flink.util.Collector;
import org.apache.flink.util.OutputTag;

import java.util.Iterator;

/**
 *  coGroup 算子
 *  可以实现 inner join 、 outer join
 */
public class NonWindowJoin02_Connect {
    public static void main(String[] args) throws Exception {
        StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment();
        env.setParallelism(1);

        DataStreamSource<String> order = env.readTextFile("D:\\IdeaProjects\\bigdata\\flink\\src\\main\\resources\\Data\\OrderLog.csv");
        DataStreamSource<String> receipt = env.readTextFile("D:\\IdeaProjects\\bigdata\\flink\\src\\main\\resources\\Data\\ReceiptLog.csv");


        //todo 1.两个流转成JavaBean  提取时间戳
        SingleOutputStreamOperator<OrderEvent> orderEventDS = order.flatMap(new FlatMapFunction<String, OrderEvent>() {
            @Override
            public void flatMap(String s, Collector<OrderEvent> collector) throws Exception {
                String[] fields = s.split(",");
                OrderEvent orderEvent = new OrderEvent(Long.parseLong(fields[0]),
                        fields[1],
                        fields[2],
                        Long.parseLong(fields[3]));

                if ("pay".equals(orderEvent.getEventType())) {
                    collector.collect(orderEvent);
                }
            }
        }).assignTimestampsAndWatermarks(new AscendingTimestampExtractor<OrderEvent>() {
            @Override
            public long extractAscendingTimestamp(OrderEvent orderEvent) {
                return orderEvent.getEventTime() * 1000;
            }
        });

        SingleOutputStreamOperator<TxEvent> txDS = receipt.map(new MapFunction<String, TxEvent>() {
            @Override
            public TxEvent map(String s) throws Exception {
                String[] fields = s.split(",");
                return new TxEvent(fields[0], fields[1], Long.parseLong(fields[2]));
            }
        }).assignTimestampsAndWatermarks(new AscendingTimestampExtractor<TxEvent>() {
            @Override
            public long extractAscendingTimestamp(TxEvent txEvent) {
                return txEvent.getEventTime() * 1000;
            }
        });


        KeyedStream<OrderEvent, String> orderEventKeyedDS = orderEventDS.keyBy(new KeySelector<OrderEvent, String>() {
            @Override
            public String getKey(OrderEvent orderEvent) throws Exception {
                return orderEvent.getTxId();
            }
        });

        KeyedStream<TxEvent, String> txEventKeyedStream = txDS.keyBy(new KeySelector<TxEvent, String>() {
            @Override
            public String getKey(TxEvent txEvent) throws Exception {
                return txEvent.getTxID();
            }
        });


        //todo 3.连接两个流 connect 实现
        SingleOutputStreamOperator<Tuple2<OrderEvent, TxEvent>> result = orderEventKeyedDS.connect(txEventKeyedStream).process(new _13_支付到账_keyBy后connect.OrderReceiptKeyProFunc());

        result.print();
        result.getSideOutput(new OutputTag<String>("支付数据没到"){}).print();
        result.getSideOutput(new OutputTag<String>("支付了 没到账"){}).print();

        env.execute();


    }

    private static class OrderReceiptKeyProFunc extends KeyedCoProcessFunction<String,OrderEvent,TxEvent,Tuple2<OrderEvent,TxEvent>> {
        ValueState<OrderEvent> orderValue;
        ValueState<TxEvent> TxValue;

        // 只要涉及删除定时器的都需要保存定时器时间
        ValueState<Long> ts;

        @Override
        public void open(Configuration parameters) throws Exception {
            orderValue = getRuntimeContext().getState(new ValueStateDescriptor<OrderEvent>(
                    "orderState",
                    OrderEvent.class
            ));

            TxValue = getRuntimeContext().getState(new ValueStateDescriptor<TxEvent>(
                    "TxState",
                    TxEvent.class
            ));

            ts = getRuntimeContext().getState(
                    new ValueStateDescriptor<Long>(
                            "timestamp",
                            long.class
                    )
            );
        }


        //todo 处理订单数据

        @Override
        public void processElement1(OrderEvent orderEvent, KeyedCoProcessFunction<String, OrderEvent, TxEvent, Tuple2<OrderEvent, TxEvent>>.Context context, Collector<Tuple2<OrderEvent, TxEvent>> collector) throws Exception {

            TxEvent Tx = TxValue.value();

            // 到账数据还没到，保存状态 注册定时器 10s
            if (Tx == null) {
                orderValue.update(orderEvent);
                long timestamp = (orderEvent.getEventTime() + 10) * 1000;
                context.timerService().registerEventTimeTimer(timestamp);

                ts.update(timestamp);

            } else {
                // 到账数据已经到
                // 1.输出
                collector.collect(new Tuple2<>(orderEvent, Tx));
                // 2.删除定时器
                context.timerService().deleteEventTimeTimer(ts.value());
                // 3.清空状态
                TxValue.clear();
                ts.clear();
            }
        }


        // todo 处理到账数据
        @Override
        public void processElement2(TxEvent txEvent, KeyedCoProcessFunction<String, OrderEvent, TxEvent, Tuple2<OrderEvent, TxEvent>>.Context context, Collector<Tuple2<OrderEvent, TxEvent>> collector) throws Exception {
            OrderEvent order = orderValue.value();
            //下单数据没到
            if (order == null) {
                TxValue.update(txEvent);
                long time = (txEvent.getEventTime() + 5) * 1000;
                context.timerService().registerEventTimeTimer(time);
                ts.update(time);
            } else {
                collector.collect(new Tuple2<>(order, txEvent));
                // 2.删除定时器
                context.timerService().deleteEventTimeTimer(ts.value());
                // 3.清空状态
                orderValue.clear();
                ts.clear();
            }
        }

        @Override
        public void onTimer(long timestamp, OnTimerContext ctx, Collector<Tuple2<OrderEvent, TxEvent>> out) throws Exception {
            OrderEvent order = orderValue.value();
            TxEvent tx = TxValue.value();

            //支付的数据超时了
            if (order == null) {
                ctx.output(
                        new OutputTag<String>("支付数据没到") {
                        },
                        tx.getTxID() + "收到钱了 但是没收到支付数据"
                );
            } else {
                ctx.output(
                        new OutputTag<String>("支付了 没到账") {
                        },
                        order.getTxId() + "支付了 但没到账"
                );
            }
        }
    }
}

2.3 SQL API

select
*
from Orders o,Shipments s
where	o.id = s.id
and s.shiptime between o.ordertime 
and o.ordertime + INTERVAL '4' HOUR

2.4 解决方案的特点

产出数据质量：中
产出数据时效性：中

interval join 的方案比 window join 方案在数据质量上好很多，但是其也是存在 join 不到的情况的。并且如果为 outer join 的话，outer 一测的流数据需要要等到区间结束才能下发。

2.5 解决方案的适用场景

该种解决方案适用于两条流之间可以明确评估出相互延迟的时间是多久的，这里我们可以使用离线数据进行评估，使用离线数据的两条流的时间戳做差得到一个分布区间。

比如在 A 流和 B 流时间戳相差在 1min 之内的有 95%，在 1-4 min 之内的有 4.5%，则我们就可以认为两条流数据时间相差在 4 min 之内的有 99.5%，这时我们将上下界设置为 4min 就是一个能保障 0.5% 误差的合理区间。

注意：这种方案在生产环境中还是比较常用的。

3. Regular Join

3.1 认识Regular Join

window join 和 interval Join 都是基于划分窗口，将无界数据变为有界数据进行关联
regular join 则还是基于无界数据进行关联

以 A 流 left join B 流举例

在这里插入图片描述
A 流数据到来之后，直接去尝试关联 B 流数据：

如果关联到了则直接下发关联到的数据
如果没有关联到则也直接下发没有关联到的数据，后续 B 流中的数据到来之后，会把之前下发下去的没有关联到数据撤回，然后把关联到的数据数据进行下发。由此可以看出这是基于 Flink SQL 的 retract 机制，则也就说明了其目前只支持 Flink SQL

那么该方案怎么解决第 2节说的两个问题呢？

流式数据到达计算引擎的时间不一定：两条流的数据会尝试关联，能关联到直接下发，关联不到先下发一个目前的结果数据
流式数据不知何时、下发怎样的数据：两条流的数据会尝试关联，能关联到直接下发，关联不到先下发一个目前的结果数据

RegularJoin特点

join的流的数据都会存在flink的状态中Forever
流中所有的数据对对方来说都是可见的
只能用于有界流
只能用于等值连接
支持 Flink SQL

Regular Join支持的Join方式

在这里插入图片描述

3.2 SQL API

CREATE TABLE show_log_table (
    log_id BIGINT,
    show_params STRING
) WITH (
  'connector' = 'datagen',
  'rows-per-second' = '1',
  'fields.show_params.length' = '3',
  'fields.log_id.min' = '1',
  'fields.log_id.max' = '10'
);

CREATE TABLE click_log_table (
  log_id BIGINT,
  click_params     STRING
)
WITH (
  'connector' = 'datagen',
  'rows-per-second' = '1',
  'fields.click_params.length' = '3',
  'fields.log_id.min' = '1',
  'fields.log_id.max' = '10'
);

CREATE TABLE sink_table (
    s_id BIGINT,
    s_params STRING,
    c_id BIGINT,
    c_params STRING
) WITH (
  'connector' = 'print'
);

INSERT INTO sink_table
SELECT
    show_log_table.log_id as s_id,
    show_log_table.show_params as s_params,
    click_log_table.log_id as c_id,
    click_log_table.click_params as c_params
FROM show_log_table
LEFT JOIN click_log_table ON show_log_table.log_id = click_log_table.log_id;

3.3 解决方案的特点

⭐ 产出数据质量：高
⭐ 产出数据时效性：高
数据质量和时效性高的原因都是因为 regular join 会保障目前 Flink 任务已经接收到的数据中能关联的一定是关联上的，即使关联不上，数据也会下发，完完全全保障了当前数据的客观性和时效性。

3.4 解决方案的适用场景

该种解决方案虽然是目前在产出质量、时效性上最好的一种解决方案，但是在实际场景中使用时，也存在一些问题：

⭐ 基于 retract 机制，所有的数据都会存储在 state 中以判断能否关联到，所以我们要设置合理的 state ttl 来避免大 state 问题导致的任务不稳定
⭐ 基于 retract 机制，所以在数据发生更新时，会下发回撤数据、最新数据 2 条消息，当我们的关联层级越多，则下发消息量的也会放大
⭐ sink 组件要支持 retract，我们不要忘了最终数据是要提供数据服务给需求方进行使用的，所以我们最终写入的数据组件也需要支持 retract，比如 MySQL。如果写入的是 Kafka，则下游消费这个 Kafka 的引擎也需要支持回撤\更新机制。

4. Join的优化思路

Join存在的问题

针对上面 3 节说到的 Flink Join 的方案，各自都有一些优势和劣势存在。

但是我们可以发现，无论是哪一种 Join 方案，Join 的前提都是将 A 流和 B 流的数据先存储在状态中，然后再进行关联。

即在实际生产中使用时常常会碰到的问题就是：大状态的问题。

两种大Key状态优化方案

关于大状态问题业界常见两种解决思路：

⭐ 减少状态大小：在 Flink Join 中的可以想到的优化措施就是减少 state key 的数量。在未优化之前 A 流和 B 流的数据往往是存储在单独的两个 State 实例中的，那么我们的优化思路就是将同 Key 的数据放在一起进行存储，一个 key 的数据只需要存储一份，减少了 key 的数量

⭐ 转移状态至外存：大 State 会导致 Flink 任务不稳定，那么我们就将 State 存储在外存中，让 Flink 任务轻量化，比如将数据存储在 Redis 中，A 流和 B 流中相同 key 的数据共同维护在一个 Redis 的 hashmap 中，以供相互进行关联

接下来看看这两种方案实际需要怎样落地。讲述思路也是按照以下几点进行阐述：
⭐ 优化方案说明
⭐ 优化方案 Flink API
⭐ 优化方案的特点
⭐ 优化方案的适用场景

Flink Join 优化方案：同 key 共享 State

优化方案说明

将两条流的数据使用 union、connect 算子合并在一起，然后使用一个共享的 state 进行处理

优化方案 Flink API

FlinkEnv flinkEnv = FlinkEnvUtils.getStreamTableEnv(args);

flinkEnv.env().setParallelism(1);

flinkEnv.env()
    .addSource(new SourceFunction<Object>() {
        @Override
        public void run(SourceContext<Object> ctx) throws Exception {

        }

        @Override
        public void cancel() {

        }
    })
    .keyBy(new KeySelector<Object, Object>() {
        @Override
        public Object getKey(Object value) throws Exception {
            return null;
        }
    })
    .connect(flinkEnv.env().addSource(new SourceFunction<Object>() {
        @Override
        public void run(SourceContext<Object> ctx) throws Exception {

        }

        @Override
        public void cancel() {

        }
    }).keyBy(new KeySelector<Object, Object>() {
        @Override
        public Object getKey(Object value) throws Exception {
            return null;
        }
    }))
    // 左右两条流的数据
    .process(new KeyedCoProcessFunction<Object, Object, Object, Object>() {
        // 两条流的数据共享一个 mapstate 进行处理
        private transient MapState<String, String> mapState;

        @Override
        public void open(Configuration parameters) throws Exception {
            super.open(parameters);
            
            this.mapState = getRuntimeContext().getMapState(new MapStateDescriptor<String, String>("a", String.class, String.class));
        }

        @Override
        public void processElement1(Object value, Context ctx, Collector<Object> out) throws Exception {
            
        }

        @Override
        public void processElement2(Object value, Context ctx, Collector<Object> out) throws Exception {

        }
    })
    .print();

优化方案的特点

在此种优化方案下，我们可以自定义：
⭐ state 的过期方式
⭐ 左右两条流的数据的 state 中的存储方式
⭐ 左右两条流数据在关联不到对方的情况下是否要输出到下游、输出什么样的数据到下游的方式

优化方案的适用场景

该种解决方案适用于可以做 state 清理的场景，比如在曝光关联点击的情况下，如果我们能明确一次曝光只有一次点击的话，只要这条曝光或者点击被关联到过，那么我们就可以在 KeyedCoProcessFunction 中自定义逻辑将已经被关联过得曝光、点击的 state 数据进行删除，以减小 state，减轻任务压力。

Flink Join 优化方案：外存 State 之 Redis

此种方案就是完全不使用 Flink 的 state，直接将来的数据存储到 Redis 中进行维护，A 流的数据过来之后，去 Redis 中找 B 流的数据，B 流的数据过来之后，去 Redis 中找 A 流的数据。
在这里插入图片描述

优化方案 Flink API

比如常用的 Redis HashMap 结构等

优化方案的特点

在此种优化方案下：

⭐ Flink 是轻量级的，不需要担心大状态问题
⭐ 外存容量可以随时扩容，理论上多大的 state 都可以存储，适合某些不能对 state 做清除的场景

优化方案的适用场景

⭐ 某些金融公司内的关联，state 是不能被清理的，比如存储了借款信息之后，这些信息后续还是可能被修改的。所以这种场景下需要存储全量的 state
⭐ 比如某东的交易场景下，A 流的数据和 B 流的数据生成的时间相差很大的，比如 A 流数据先生产之后，B 流数据在 1 天之后才会被生产出来，那么这种场景就非常适合使用 redis 存储 A 流数据，后续提供给 B 流使用

Flink 维表join

常见的维表Join方式有四种：

预加载维表
热存储维表
广播维表
Temporal table function join

维表Join 和双流Join的区别：

维表Join是单流驱动，维度表流称之为BuildTable，实时流称之为ProbeTable
双流join是双流驱动

方案1 - 预加载维表

方式1：预加载维表到内存

实现步骤：

定义RichFlatMapFunction实现类，在open()中读取维度数据库，将数据全量加载到内存
在Probe流上使用FlatMap、Map算子，运行时和内存中的维度数据进行关联

优点：实现简单
缺点：仅支持小数据量维表，维表更新需要重启作业
使用场景：小维表、更新频率低

方式2：预加载数据文件到内存

实现步骤：

通过env.registerCachedFile 注册文件
实现RichFunction，在open()中通过RunimeContext获取cache文件
解析和使用文件数据

优点：不需要外部数据库
缺点：支持维表数据量小，更新需要更改文件并启动作业
适用场景：维度数据是文件形式、数据量小、更新频率极低；