Spark DataFrame到Google Cloud PubSub的流批写入方案咨询

先明确前期调研的两类组件的适配边界，避免走弯路：

• Apache Bahir 提供的 PubSub 连接器仅实现了旧版 Spark DStream API 的读源逻辑，没有写入实现，也不支持 Structured Streaming 场景
• PubSub Lite 连接器是为 PubSub 轻量分区版设计的专属组件，和标准 PubSub 服务的API、消息模型、服务端点完全不兼容，无法混用

方案1：基于官方Java客户端自定义Sink（生产首选，兼容批量/流式） #

这是目前适配成本最低、灵活性最高的方案，无第三方连接器绑定，全Spark版本兼容：

1. 依赖引入：作业构建时引入GCP官方PubSub Java客户端依赖，注意排除和Spark集群内置冲突的Guava、Netty版本即可
2. 批量写入实现：对目标DataFrame调用foreachPartition算子，每个分区内仅初始化一次Publisher客户端（禁止单条数据初始化客户端，避免连接数打满PubSub配额），遍历分区数据组装消息后调用发布接口，等待分区内所有消息发送完成、收到ACK后再关闭客户端释放资源。客户端自带的BatchingSettings可直接配置攒批阈值（条数、字节数、等待延迟），不需要手动实现批量逻辑，默认配置就能打满单分区吞吐量。
3. Structured Streaming 写入实现：直接使用foreachBatch Sink，每个微批触发时复用上述批量写入逻辑即可；如果需要保证至少一次/精确一次语义，可结合Spark Checkpoint记录每个微批的写入状态，重启后跳过已完成的微批即可。

方案2：基于Apache Beam Spark Runner 写入（适合多组件联动场景） #

如果你的数据链路后续需要对接更多GCP服务，可选择Beam作为中间适配层：

• 将Spark DataFrame转换为Beam PCollection，调用Beam内置的PubSub IO连接器完成写入
• 执行引擎选择Spark Runner，可直接运行在现有Spark集群上，不需要改动集群部署
• 该方案原生支持精确一次写入语义，不需要手动实现状态对账，缺点是会引入Beam的依赖包，作业启动开销比原生Spark Sink高30%左右。

常见踩坑点 #

• 禁止在Driver端初始化PubSub客户端再序列化下发到Executor，会出现连接池失效、序列化报错、吞吐量上不去的问题
• PubSub单条消息大小上限为10MB，写入前要提前校验消息大小，超量消息建议转存GCS后传递对象引用
• 写入时要配置合理的重试策略，针对PubSub返回的流控、配额超限错误做指数退避重试，避免触发服务端限流。

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