Spark如何实现Broadcast广播变量增量更新以降低序列化及数据库压力？

Spark原生支持情况 #

Spark原生不支持可增量更新的广播变量。广播变量的设计定位是只读的分布式共享变量，一旦在Driver端创建完成并分发到Executor，就无法修改，要更新内容必须销毁旧广播变量、创建新实例并全量分发，这也是你当前遇到的全量广播开销过高问题的根本原因。

自定义实现方案 #

你可以根据业务场景选择以下两种低实现成本的方案：

• Executor本地缓存+增量拉取方案
  放弃广播变量分发逻辑，在每个Executor的mapPartitions方法初始化阶段，先读取本地缓存的拓扑数据和对应的版本号，仅向数据库拉取该版本之后的增量变更内容，本地合并后更新缓存和版本号即可。你可以在数据库侧新增一张拓扑变更日志表，记录每次变更的操作类型、内容、版本号即可支撑该逻辑。目前你只有最多40个Executor，每次拉取的增量数据体积很小，完全不会给数据库带来可感知的压力，该方案改造成本最低，稳定性最高。
• 自定义增量广播实现
  如果不想修改数据库侧逻辑，可以基于Spark任务参数+Executor静态变量实现：
  1. Driver端每批次仅生成增量变更包，为每个变更包分配连续递增的版本号
  2. 把增量变更包作为普通任务参数随批次任务提交，因为增量内容体积小，不需要走广播流程，序列化和传输开销可以忽略
  3. Executor侧用静态变量存储全量拓扑数据和当前版本号，收到任务的增量包后先比对版本号，如果是连续增量则直接合并到本地全量数据中；如果版本不连续（比如Executor重启、缓存丢失），则一次性拉取全量最新数据后再执行任务。

额外优化建议 #

如果拓扑数据的反序列化耗时是主要瓶颈，可以将Spark序列化配置修改为Kryo序列化，提前注册拓扑数据对应的自定义类，通常可以降低70%以上的序列化/反序列化耗时，即使偶尔需要全量同步数据也能大幅降低开销。

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