Dataproc集群PySpark+spaCy报错：No more replicas available

1. 广播副本不足的核心问题：No more replicas available for broadcast_0_python说白了就是你广播的spaCy模型副本在Executor节点上丢了或者加载失败，任务找不到可用副本继续跑。spaCy模型本身就不小（哪怕是轻量版都有几十MB），大数据量下Executor压力陡增，要么副本同步跟不上，要么Executor直接崩溃，就会触发这个警告，进而引发Executor丢失。
2. Executor内存顶不住：100万行数据处理时，每个Executor要扛的数据量暴增，再加上加载spaCy模型，内存直接被撑爆。n1-standard-4是4核15GB内存，默认Spark给Executor分配的内存可能不够，一旦出现OOM（内存溢出），Yarn就会把Executor杀死，自然就出现节点丢失的情况。
3. GCS读取与分区不合理：大数据量读取GCS时，如果分区太少，单个Executor要处理的数据块过大，直接被压垮；或者GCS读取带宽跟不上，任务超时，Executor被标记为丢失。

• 调优广播变量配置：
  • 修改spark.broadcast.blockSize（默认4MB），如果模型体积大就适当调大，比如设为32m，减少广播分片数，降低副本同步压力，启动集群时添加参数--conf spark.broadcast.blockSize=32m。
  • 调大spark.broadcast.replication，默认值是3，你有10个工作节点，可以改成5-10，比如--conf spark.broadcast.replication=8，保证每个节点都能拿到足够的模型副本。
• 给Executor扩容内存：
  • 调整Executor的内存分配，比如给每个Executor分配10GB堆内存，再预留2GB堆外内存，启动参数添加--conf spark.executor.memory=10g --conf spark.executor.memoryOverhead=2g（n1-standard-4总内存15GB，剩余3GB留给系统进程）。
  • 去Spark UI的Executor页面查看内存使用情况，再到Yarn日志里搜索OutOfMemoryError，确认是不是真的内存溢出导致的问题。
• 优化数据并行度：
  • 读取GCS CSV时，要么用repartition(100)手动增加分区数，要么调小spark.sql.files.maxPartitionBytes（默认128MB），比如改成64MB，让每个分区的数据量变小，Executor的压力更均匀。
  • 尽量用批量处理的方式调用spaCy，别单条数据挨个处理，减少重复计算开销。
• 排查Executor丢失的具体诱因：
  • 到Cloud Logging里筛选集群的Executor日志（关键词选resource.type="cloud_dataproc_cluster"和executor），看是OOM、网络卡顿还是磁盘IO过高导致节点崩溃。
  • 检查工作节点的磁盘IO和CPU负载，标准磁盘的IOPS有限，大数据量处理时可能拖后腿，不行就换成SSD磁盘试试。
• 优化spaCy模型加载方式：
  • 别直接广播nlp对象，序列化容易出问题，改成把模型上传到GCS，广播模型路径，让Executor自己延迟加载，减少广播的体积。
  • 用轻量版spaCy模型，比如en_core_web_sm，别用大体积的en_core_web_lg，能省不少内存。

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