Flink作业超大规则集广播流替代方案咨询

一、针对广播状态内存超限的替代方案 #

1. 按规则分类拆分状态 #

既然业务流可以通过自身字段筛选所需规则（如字段值为X时仅用rule1, rule2, rule5），可以把规则流按规则所属的业务分类维度（即业务流的筛选字段）进行keyBy，同时业务流也按相同字段keyBy，之后执行Keyed Join：

• 每个Task的状态仅存储对应分类下的规则，而非全部90条，能大幅降低单Task的状态规模
• 规则变更时，仅更新对应分类的状态，不会影响其他分类的规则处理

2. 自定义RocksDB作为广播状态后端 #

官方Flink确实未支持广播状态使用RocksDB后端，但可以通过自定义实现绕过限制：

• 自定义BroadcastState实现类，底层用RocksDB替代默认的内存哈希表存储规则
• 必须实现状态的序列化、快照、恢复逻辑，保证Flink容错机制正常工作
• 优势：将超大状态从内存转移到磁盘，解决内存容量限制；需注意优化RocksDB读写缓存，避免磁盘IO成为性能瓶颈

3. 规则本地缓存+外部存储同步 #

由于规则变更频率较低（每小时100-200次），可以放弃流模式同步规则，改用外部存储（如Redis、HBase）存储规则集合：

• 业务流处理时，根据筛选字段从外部存储拉取对应规则，同时在Task本地设置缓存（比如5分钟过期），减少外部存储访问压力
• 完全规避广播状态的内存问题，但存在规则更新延迟，适合对规则实时性要求不极高的场景

二、不广播规则流直接连接的差异 #

根据连接方式不同，效果差异极大：

1. Keyed Join（推荐） #

将规则流和业务流按相同的规则分类字段keyBy后执行Join：

• 状态仅存储对应key的规则，状态规模可控
• 需配置状态TTL清理过期规则，避免状态长期膨胀
• 若业务流数据在规则更新前到达，会使用旧规则计算，需评估是否符合业务逻辑

2. 非Keyed普通Join #

不做keyBy直接执行Join会导致所有数据路由到单个Task处理，完全丧失Flink的并行处理能力，性能极低，不适合大数据量的业务流场景，基本不可用。

3. Lookup Join #

将规则流作为维度表使用Lookup Join连接业务流：

• 本质是业务流去外部存储查询规则，Flink内置了缓存机制，适合规则变更频率低的场景
• 无需维护流模式的规则状态，但同样存在规则更新延迟的问题

内容的提问来源于stack exchange，提问作者sparkless