建行采用Flink的第二个方案是什么？

第二个方案是采用 Flink 自带的 interval join。Interval join 是 Flink 框架自带的特性，使用 RocksDB 做状态存 储，相当于用它替换掉 Redis。

使用这个方案的初衷一方面是希望能够降低运维压力，另一方面，随着数据量 增大它可以很方便地做横向扩展。 第一个优化是数据到达之后，根据配置做一些过滤，把不需要的数据提前过滤掉，使得需要处理的数据量下 降很多。第二是使用 interval join，对请求响应做一次 join，然后把 join 上的数据跟埋点再做一次 join。这里 面的逻辑跟前面的 1.0 方案保持一致。同时，为了达到容忍一个小时左右数据延迟的要求，我们设置一个 30 分钟的上下限区间。

但这个方案的问题在于经常出现 OOM。由于使用的是 Flink on K8s，分析起来比较复杂，后来通过阅读源码， 发现 Flink 的 interval join 会将它上下限时间区间内的数据全部保留在状态里面，直到数据过期才会删除，这 也导致了一些新的问题。

以上内容摘自《Apache Flink 案例集（2022版）》电子书，点击https://developer.aliyun.com/ebook/download/7718 可下载完整版