使用Spark Structured Streaming跨多Kafka Broker消费同主题的最佳方案

结合你使用的AWS技术栈，这里直接给出两个方案的优劣势对比和最优选择建议：

方案1：每个数据中心部署独立Spark作业 #

优势 #

• 故障隔离能力强：单个数据中心的Kafka集群故障、跨区网络波动只会影响对应作业，其他数据中心的消费链路完全不受影响，不会出现单点故障导致全局消费中断的问题
• 弹性配置灵活：不同数据中心的业务流量差异较大时，可以单独调整对应作业的资源配额、消费限流规则，不需要全局调整配置
• 运维门槛低：每个作业的Checkpoint独立存储在S3上，单作业故障后恢复速度快，修改单数据中心的消费位点、Kafka连接参数等配置不会影响其他作业，非常适合Spark使用经验较少的团队
• 写入兼容性好：Delta Lake和Iceberg都原生支持多作业并发写入同一张表，只需开启对应并发配置即可，不会出现数据冲突或写入失败问题

劣势 #

• 作业数量随数据中心数量增长，需要配置统一的监控告警规则，总资源占用略高于单作业方案

方案2：单个Spark作业多流Union合并 #

优势 #

• 作业管理成本低，仅需要维护一个作业的配置和运行状态
• 计算资源利用率理论上更高，流合并后的写入、分区等计算逻辑可以全局复用资源

劣势 #

• 故障影响范围极大：任意一个数据中心的Kafka集群不可达、网络延迟过高，都会导致整个作业卡滞甚至失败，所有数据中心的消费都会中断
• 运维复杂度高：多流Union后Checkpoint是全局绑定的，单个数据中心的配置修改、故障恢复都需要调整全局作业，操作不当很容易导致消费位点错乱、数据重复/丢失，对Spark运维经验要求很高
• 扩缩容不灵活：单个数据中心流量突增时需要给整个作业扩容，低流量数据中心的资源会出现闲置浪费

适配AWS技术栈的最优推荐 #

优先选择方案1，配合AWS服务做以下优化即可大幅降低运维成本：

• 作业运行：使用EMR Serverless部署每个数据中心的Structured Streaming作业，无需维护固定EMR集群，按实际消耗的计算资源计费，不同作业可以单独配置资源上限，支持自动弹性扩缩容
• 写入配置：统一使用Glue作为Delta Lake/Iceberg的元数据Catalog，写入时开启并发写入参数即可：
  • Delta Lake配置：spark.databricks.delta.concurrentWrites.enabled true
  • Iceberg配置：spark.sql.iceberg.concurrent-writes.enabled true
• 监控告警：所有作业的运行指标、消费延迟指标统一上报到CloudWatch，配置单作业失败、消费延迟超过阈值的告警即可
  如果后续数据中心数量超过10个、总流量规模很大，也可以选择前置Kafka MirrorMaker 2.0集群，将所有数据中心的DATA_TOPIC统一镜像到AWS托管的MSK集群的同一个Topic中，再用单个Structured Streaming作业消费MSK数据写入数据湖，进一步降低作业管理成本。

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