Kafka 1-to-many join场景下数据处理及GlobalKTable使用相关问题

1. join后多匹配结果的处理 #

你完全可以在按key关联之后再对topic2的结果追加过滤规则，这也是1对多join场景下缩小结果范围的标准实现方式。后续处理可以根据你的业务需求选择两种路径：

• 若仅需要生成实时输出流，不需要持久化为状态表供后续查询：join操作完成后直接链式调用filter()方法，在方法中写入你需要的精确匹配规则过滤不符合要求的配置条目即可。如果过滤后仍存在同key对应多值的情况，可以按需选择后续处理逻辑：
  • 需要合并多值输出时，调用groupByKey() + aggregate()方法，将同key的多个配置值聚合为自定义的集合类结构输出
  • 仅需要保留最高优先级的一条配置时，直接在聚合逻辑中按照业务规则保留优先级最高的条目即可
• 若需要将结果持久化为KTable：如果业务允许同key对应多值，可直接将value定义为集合类型存储；如果要求单key唯一值，需先完成上述groupByKey() + 聚合操作去重/选优后，再将聚合结果转为KTable。

2. 配置Topic是否需要用GlobalKTable #

可以根据你的Topic分区规则判断：

• 当以下两个条件同时满足时，使用普通KTable即可：
  • topic2的分区key就是你关联用的用户key，同一个用户的所有配置数据都落在topic2的同一个分区
  • topic1和topic2的分区数保持一致
    这种情况下Kafka Streams会自动保证同key的事件流数据和配置表数据分配到同一个流任务实例上处理，不会出现跨分区匹配不到的问题。
• 只要不满足上述任意一个条件，就必须使用GlobalKTable。GlobalKTable会将topic2的全量数据同步到每个流任务实例的本地，保证任意实例处理任意用户的事件时都能查到全量配置数据，不会出现匹配遗漏。它的缺点是会占用更多实例内存，适合配置数据量级不大的场景。

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