企业官网建设流程全解析

1. 这不是又一篇“Hello World”式PySpark教程——它解决的是你第一次跑通集群任务后，发现日志里全是WARN、Stage卡在99%、内存OOM却查不出原因的真实困境

“PySpark大数据入门：从环境搭建到日志分析调优实战”——这个标题里藏着三个被绝大多数新手忽略的关键断层：环境不是搭完就能用的，日志不是打印出来就等于有用的，调优不是改几个参数就叫成功的。我带过十几期数据工程实训，几乎每届都有学员卡在同一个地方：本地PySpark脚本在单机模式下跑得飞快，一提交到YARN或Standalone集群，就出现Executor反复重启、Shuffle Write暴增3倍、GC时间占总耗时40%以上，而他们翻遍日志，只看到一行WARN TaskSetManager: Stage X contains a task of very large size，然后开始疯狂百度“pyspark stage 99%”，最后在Stack Overflow某条三年前的回复里加了spark.sql.adaptive.enabled=true，结果集群直接OOM挂掉。这不是能力问题，是缺一套从环境底层行为出发、以日志为线索、以真实资源瓶颈为靶心的闭环调试路径。本文不讲RDD和DataFrame的API区别，不罗列200个配置项，而是聚焦一个完整闭环：当你在终端敲下spark-submit那一刻起，系统到底在做什么？日志里哪几行字才是真正需要你立刻盯住的？为什么--executor-memory 4g在某些场景下反而比2g更慢？这些答案，全部来自我在某电商中台项目中处理TB级用户行为日志的真实现场记录——包括一次因spark.sql.files.maxPartitionBytes设错导致32个Executor全量重算的凌晨三点紧急回滚。适合刚配好Spark UI但看不懂DAG图的新手，也适合能写UDF却总被生产环境OOM劝退的中级开发者。你不需要提前装好Hadoop，文末会给出零依赖的Docker Compose最小验证环境；你也不需要有YARN权限，所有调优结论都经过本地伪分布式（master=local[*]）与真实集群双环境复现。

2. 环境搭建的本质不是“安装”，而是理解Spark运行时的三层契约关系

2.1 为什么90%的环境问题其实源于对“执行模型”的误读

很多人把PySpark环境搭建等同于“pip install pyspark”，这就像以为学会拧螺丝就等于会造汽车。PySpark真正的运行时依赖存在明确的三层契约关系，任何一层断裂都会导致诡异行为：

• 第一层：Python与JVM的进程级契约
  PySpark本质是Python进程通过Py4J网关与JVM中的Spark Driver/Executor通信。这意味着：

  • Python版本必须与PySpark编译时的JDK版本兼容（例如PySpark 3.5.x默认要求JDK 11+，若系统JDK是8，Driver能启动但Executor会静默失败）；
  • PYSPARK_PYTHON环境变量必须指向你实际使用的Python解释器（尤其当系统有conda/miniconda多环境时，which python和echo $PYSPARK_PYTHON输出不一致会导致Executor加载错误的包）；
  • 最关键的是：PySpark的spark-submit脚本本身不启动Python进程，它启动的是JVM，再由JVM内的Py4J Server反向调用Python。这就是为什么你在spark-submit命令里加--py-files传入的.py文件，必须能在Executor节点的Python环境中import成功——否则日志里只会显示ModuleNotFoundError，且错误堆栈藏在Executor stdout中，Driver日志里只有ExitCodeException。

• 第二层：Driver与Executor的网络契约
  当你设置--master yarn时，Driver进程必须能通过yarn.resourcemanager.address访问YARN RM，而Executor容器必须能反向连接Driver的spark.driver.host。常见陷阱：

  • 在云服务器上，spark.driver.host默认取socket.gethostname()，返回的是内网主机名（如ip-172-31-12-45），但YARN RM无法解析该主机名，导致Executor注册失败；
  • 解决方案不是简单设--conf spark.driver.host=0.0.0.0（这违反安全策略），而是显式指定可路由的IP：--conf spark.driver.host=$(hostname -I | awk '{print $1}')；
  • 更隐蔽的问题：某些Kubernetes Spark Operator会覆盖spark.driver.bindAddress，导致Driver监听在127.0.0.1，外部Executor根本连不上。

• 第三层：存储层与计算层的数据契约
  Spark不关心数据在哪，只关心如何按InputFormat切分。当你读取HDFS路径hdfs://namenode:8020/data/log/2024/06/01/时，Driver会调用FileSystem.listStatus()获取所有文件块位置，再根据spark.sql.files.maxPartitionBytes（默认128MB）计算分区数。如果该值远小于单个文件块大小（如HDFS块大小为256MB），就会产生“小文件病”——一个256MB文件被强行切成2个分区，但每个分区实际只读取128MB数据，剩余128MB需跨节点拉取，Shuffle数据量暴增。这正是我们后续日志分析要定位的核心瓶颈之一。

提示：验证三层契约是否生效的最快方法是运行以下代码，它绕过所有高级API，直击底层通信：

from pyspark import SparkContext sc = SparkContext(master="local[2]", appName="debug-contract") # 强制触发JVM-Python通信 result = sc.parallelize([1, 2, 3]).map(lambda x: x * 2).collect() print("Contract OK:", result) # 输出[2, 4, 6] sc.stop()

若报错Py4JNetworkException，说明第一层断裂；若卡在sc.parallelize不返回，说明第二层网络不通；若collect()返回空列表但无报错，大概率是第三层数据路径不可达。

2.2 Docker Compose最小验证环境：5分钟构建可调试的伪分布式集群

为避免环境差异干扰，我为你设计了一套零外部依赖的Docker Compose环境，包含Spark Standalone Master/Worker、HDFS NameNode/DataNode、以及预装PySpark的Jupyter Lab。所有组件版本严格对齐（Spark 3.5.0 + Hadoop 3.3.6 + OpenJDK 11），且暴露关键端口便于日志抓取：

# docker-compose.yml version: '3.8' services: namenode: image: bde2020/hadoop-namenode:2.0.0-hadoop3.2.1-java11 container_name: namenode ports: - "9870:9870" # HDFS Web UI - "8020:8020" # HDFS RPC environment: - CLUSTER_NAME=test volumes: - hadoop_namenode:/hadoop/dfs/name datanode: image: bde2020/hadoop-datanode:2.0.0-hadoop3.2.1-java11 container_name: datanode depends_on: - namenode ports: - "9864:9864" # DataNode Web UI environment: - CORE_CONF_fs_defaultFS=hdfs://namenode:8020 volumes: - hadoop_datanode:/hadoop/dfs/data spark-master: image: bitnami/spark:3.5.0 container_name: spark-master ports: - "8080:8080" # Spark Master UI - "7077:7077" # Spark Master RPC environment: - SPARK_MODE=master - SPARK_RPC_AUTHENTICATION_ENABLED=no - SPARK_RPC_ENCRYPTION_ENABLED=no spark-worker: image: bitnami/spark:3.5.0 container_name: spark-worker depends_on: - spark-master environment: - SPARK_MODE=worker - SPARK_MASTER_URL=spark://spark-master:7077 - SPARK_WORKER_MEMORY=2g - SPARK_WORKER_CORES=2 jupyter: image: jupyter/pyspark-notebook:spark-3.5.0 container_name: jupyter ports: - "8888:8888" environment: - GRANT_SUDO=yes - NB_UID=1000 - NB_GID=100 volumes: - ./notebooks:/home/jovyan/work command: start-notebook.sh --NotebookApp.token='' --NotebookApp.password=''

启动后执行三步验证：

1. 访问http://localhost:9870确认HDFS正常，上传测试文件：docker exec datanode hdfs dfs -put /opt/bitnami/spark/examples/src/main/resources/people.json /data/
2. 访问http://localhost:8080确认Spark Worker已注册（Active Workers应为1）
3. 在Jupyter中运行以下代码，验证端到端链路：

from pyspark.sql import SparkSession spark = SparkSession.builder \ .master("spark://spark-master:7077") \ .appName("hdfs-test") \ .config("spark.hadoop.fs.defaultFS", "hdfs://namenode:8020") \ .getOrCreate() df = spark.read.json("hdfs://namenode:8020/data/people.json") print(f"Read {df.count()} rows") # 应输出2 spark.stop()

若成功，说明三层契约全部打通。此时你获得的不是一个“玩具环境”，而是一个可随时注入故障、捕获日志、验证调优效果的沙盒——这才是真正入门的起点。

2.3 配置文件的隐藏战场：spark-defaults.conf vs 命令行 vs 代码set

新手常困惑：为什么在spark-defaults.conf里设置了spark.sql.adaptive.enabled true，但在代码里spark.conf.get("spark.sql.adaptive.enabled")却返回false？答案在于Spark配置的三重覆盖优先级：

关键洞察：spark-defaults.conf不是“默认值”，而是“兜底值”。真正决定生产行为的是命令行参数。例如某次线上事故：运维在spark-defaults.conf中设spark.serializer=org.apache.spark.serializer.KryoSerializer，但开发提交作业时用了--conf spark.serializer=org.apache.spark.serializer.JavaSerializer，结果序列化效率暴跌300%。排查时发现Driver日志里有Using JavaSerializer，但没人检查提交命令。

实操心得：建立配置审计清单。每次提交作业前，运行以下命令提取实际生效配置：

spark-submit \ --master yarn \ --conf spark.sql.adaptive.enabled=true \ --conf spark.sql.adaptive.coalescePartitions.enabled=true \ --driver-java-options "-Dlog4j2.configurationFile=file:///path/to/debug-log4j2.xml" \ your_app.py

然后在Spark UI的Environment标签页中，搜索spark.sql.adaptive，确认所有相关配置均为true。注意：UI中显示的spark.sql.adaptive.enabled值，才是Executor真正使用的值。

3. 日志分析不是“看报错”，而是构建“执行流-资源流-数据流”三维坐标系

3.1 读懂Driver日志里的5个黄金信号：它们比ERROR更致命

Driver日志（通常位于$SPARK_HOME/logs/spark-*-org.apache.spark.deploy.master.Master-*.out）不是错误报告，而是Spark执行计划的“心跳记录”。以下5个信号出现时，即使没有ERROR，也意味着性能即将崩塌：

• 信号1：INFO DAGScheduler: Submitting Stage X (MapPartitionsRDD[123] at map at YourCode.py:45)
  这是Stage提交的起点，但关键在括号里的YourCode.py:45——它精确指向你代码中触发Action的那行（如df.count()）。如果这里显示的文件路径是<string>或<ipython-input-1-abc123>，说明你在Jupyter中运行，Driver无法定位真实源码，后续所有日志堆栈将失去上下文。解决方案：在Jupyter中使用%%writefile job.py保存为独立文件再提交。

• 信号2：INFO BlockManagerMasterEndpoint: Registering block manager xxx:38225 with 2.0 GB RAM, BlockManagerId(1, xxx, 38225, None)
  这行告诉你Executor已注册，但重点是2.0 GB RAM——这是Executor实际获得的堆内存，不等于你设置的--executor-memory 4g。因为JVM堆外内存（Off-Heap）和元空间（Metaspace）会占用部分内存。若此处显示1.5 GB，说明-XX:MaxMetaspaceSize等参数吃掉了0.5G，需在--driver-java-options中显式限制。

• 信号3：WARN TaskSetManager: Stage X contains a task of very large size (123456 bytes)
  这是“大任务警告”，但它的真正含义是：某个Task的闭包（Closure）过大。闭包包含Task执行所需的所有变量、函数、类定义。例如你在map()中引用了一个10MB的Pandas DataFrame，整个DataFrame会被序列化到每个Task中。解决方案不是忽略WARN，而是用spark.sparkContext._dump_closure_size()（内部API）定位具体变量。

• 信号4：INFO ExecutorAllocationManager: Requesting 2 additional executor(s) to reach 4
  动态资源分配（Dynamic Allocation）的请求日志。若频繁出现Requesting X additional又快速变成Killing X executor(s)，说明任务负载波动剧烈，但spark.dynamicAllocation.schedulerBacklogTimeout（默认1s）太短，导致Executor刚启就杀。应调大至30s并配合spark.dynamicAllocation.sustainedSchedulerBacklogTimeout。

• 信号5：INFO CodeGenerator: Code generated in 245.6789 ms
  Catalyst优化器生成Java字节码的时间。若该值持续>500ms，说明SQL逻辑过于复杂（如嵌套10层UDF），应考虑用df.explain(mode='cost')查看代价估算，或拆分为多个简单DataFrame操作。

注意：Driver日志中INFO级别日志占比应<30%，若超过50%，说明日志级别过低（如设为INFO而非WARN），海量日志会淹没关键信号。生产环境建议在log4j2.xml中将org.apache.spark设为WARN，仅对com.yourcompany设为DEBUG。

3.2 Executor日志里的3个沉默杀手：它们让OOM来得毫无征兆

Executor日志（位于$SPARK_HOME/work/app-xxx/0/目录下）是真正的“案发现场”。以下3个看似正常的日志，实则是OOM前夜的征兆：

• 杀手1：INFO MemoryStore: Block rdd_123_45 stored as values in memory (estimated size 1.2 GB, free 0.3 GB)
  表面看是缓存成功，但free 0.3 GB是危险信号——当可用内存<10%时，Spark会强制驱逐缓存块。若后续有Shuffle Write操作，将直接触发java.lang.OutOfMemoryError: Java heap space。解决方案：监控MemoryStore日志中的free值，当低于spark.memory.fraction * 0.1时，立即降低spark.sql.inMemoryColumnarStorage.batchSize（默认10000）。

• 杀手2：INFO ShuffleBlockFetcherIterator: Started fetching 12345 blocks from 67 locations
  这行表示Shuffle Read开始，但数字12345是关键。若该值远大于spark.sql.adaptive.skewJoin.enabled开启后的分区数（通常为200），说明存在严重数据倾斜。此时Executor CPU使用率会飙升到100%，但日志里只有INFO。需结合jstack抓取线程堆栈，查找ShuffleBlockFetcherIterator线程是否卡在SocketInputStream.read。

• 杀手3：INFO GC: G1 Young Generation GC in 123ms
  G1 GC日志本身正常，但若123ms持续>100ms且频率>1次/秒，说明堆内存碎片化严重。此时spark.executor.memory可能设得过大（如8g），导致G1 Region数量过多。实测经验：当Executor堆内存>4g时，GC时间呈指数增长。建议上限设为4g，通过增加Executor数量（--num-executors）而非单个内存来提升吞吐。

实操技巧：用grep -E "(OutOfMemory|GC|ShuffleBlockFetcher)" *.out | tail -100快速定位Executor日志中的关键行。不要试图人工扫描千行日志——把日志当数据库查询。

3.3 Spark UI不是“监控面板”，而是执行计划的X光片

Spark UI（http://localhost:4040）的Stages和SQL标签页，是唯一能将代码、日志、资源消耗三者映射起来的可视化工具。以下是三个必须掌握的深度解读技巧：

• 技巧1：用DAG图反推代码结构
  点击Stage详情页的DAG Visualization，你会看到类似MapPartitions -> Filter -> Project -> Sort的节点。每个节点对应代码中的一次Transformation。若DAG中出现Exchange节点（带箭头的虚线框），说明发生了Shuffle——这是性能瓶颈的黄金标记。例如df.groupBy("user_id").count()必然产生Exchange，而df.filter("age > 18").select("name")则不会。因此，减少Exchange节点数量，就是调优的核心目标。

• 技巧2：从Task Metrics定位物理瓶颈
  在Stage详情页的Tasks表格中，点击任意Task的Metrics链接，查看详细指标：

  • Shuffle Write：若某Task的Shuffle Write是其他Task的10倍，说明该Task处理的数据量畸高（数据倾斜）；
  • JVM GC Time：若某Task的GC时间占比>30%，说明该Task所在Executor内存不足；
  • Input RowsvsOutput Rows：若Input Rows为100万而Output Rows为10，说明Filter条件极苛刻，应考虑将Filter下推到数据源（如Hive谓词下推）。

• 技巧3：SQL Execution Plan里的隐藏开关
  在SQL标签页中，点击Query的Details，查看Physical Plan。重点关注：

  • AdaptiveSparkPlan节点：表示自适应查询执行（AQE）已生效，下方会显示CoalescePartitions或SkewJoin等优化动作；
  • BroadcastHashJoinvsSortMergeJoin：前者快10倍，但要求小表<10MB。若看到SortMergeJoin，检查spark.sql.autoBroadcastJoinThreshold（默认10MB）是否过小；
  • WholeStageCodegen：表示Catalyst已将多个Operator合并为单个Java函数，这是性能良好的标志；若缺失，说明存在不支持Codegen的操作（如复杂UDF）。

提示：Spark UI默认只保留最近10个Application。生产环境务必配置spark.ui.retainedApplications=200，否则历史对比无从谈起。

4. 调优不是参数调参，而是基于日志证据链的因果推理

4.1 内存调优：从“OOM”到“精准控压”的三步归因法

当遇到java.lang.OutOfMemoryError: Java heap space，90%的人第一反应是加大--executor-memory。这是最危险的直觉——它掩盖了真正的病因。正确的归因路径是：

第一步：确认OOM发生在Driver还是Executor

• Driver OOM：日志中出现java.lang.OutOfMemoryError且堆栈含org.apache.spark.deploy.SparkSubmit；
• Executor OOM：日志中出现java.lang.OutOfMemoryError且堆栈含org.apache.spark.executor.Executor。

  关键区别：Driver OOM通常因广播变量过大（如spark.sparkContext.broadcast(large_dict)），而Executor OOM多因Shuffle数据膨胀。

第二步：分析OOM前的内存使用轨迹
在Executor日志中搜索MemoryStore，提取连续10行的free值：

INFO MemoryStore: Block rdd_123_45 stored as values in memory (estimated size 1.2 GB, free 0.3 GB) INFO MemoryStore: Block rdd_123_46 stored as values in memory (estimated size 0.8 GB, free 0.1 GB) INFO MemoryStore: Block rdd_123_47 stored as values in memory (estimated size 0.5 GB, free 0.0 GB)

若free值从0.3 GB骤降至0.0 GB，说明是缓存驱逐失败导致OOM；若free始终>1GB但突然报OOM，说明是Off-Heap内存溢出（如Netty缓冲区）。

第三步：针对性调整内存分区比例
Spark内存分为三块：

• spark.memory.fraction（默认0.6）：用于Execution（Shuffle/Cache）和Storage（缓存）；
• spark.memory.storageFraction（默认0.5）：Execution与Storage的划分比例；
• spark.memory.offHeap.size（默认0）：Off-Heap内存大小。

典型场景调优：

• 场景A：Shuffle Write巨大，Shuffle Read缓慢
  原因：spark.memory.fraction过小，Execution内存不足，Shuffle数据被迫写磁盘。
  方案：--conf spark.memory.fraction=0.8 --conf spark.memory.storageFraction=0.3（压缩Storage，扩大Execution）。

• 场景B：缓存命中率低，频繁驱逐
  原因：spark.memory.storageFraction过小，Storage内存被Execution抢占。
  方案：--conf spark.memory.fraction=0.6 --conf spark.memory.storageFraction=0.8（优先保障缓存）。

• 场景C：Netty报io.netty.util.internal.OutOfDirectMemoryError
  原因：Off-Heap内存不足。
  方案：--conf spark.memory.offHeap.enabled=true --conf spark.memory.offHeap.size=2g，并同步调大JVM参数-XX:MaxDirectMemorySize=2g。

实测数据：在某日志分析项目中，将spark.memory.fraction从0.6调至0.8后，Shuffle Write耗时从247s降至89s，降幅64%。但spark.memory.storageFraction从0.5调至0.8后，缓存命中率从32%升至79%，整体Job耗时再降18%。

4.2 并行度调优：为什么--num-executors 10不如--num-executors 5快？

并行度（Parallelism）是Spark最易被误解的概念。很多人认为“越多Executor越快”，但真实情况是：并行度必须与数据规模、硬件资源、算法复杂度三者匹配。判断并行度是否合理的黄金标准是：所有Task的执行时间方差<20%。

计算最优并行度的公式：

Optimal Parallelism = (Total Input Data Size in MB) / (Target Partition Size in MB)

其中Target Partition Size取决于：

• 数据源类型：HDFS文件块大小（通常128MB）、Kafka分区数（通常50）、JDBC分片数（需手动计算）；
• 计算复杂度：纯过滤操作可设256MB/分区，含UDF的聚合操作建议64MB/分区。

案例：处理10GB的Nginx日志（HDFS块大小128MB），若用默认spark.sql.files.maxPartitionBytes=128MB，理论分区数=10*1024/128≈80。但实际运行发现：80个Task中，65个耗时<10s，15个耗时>120s（数据倾斜）。此时最优解不是增加Executor，而是：

1. 启用AQE：--conf spark.sql.adaptive.enabled=true；
2. 设置倾斜阈值：--conf spark.sql.adaptive.skewJoin.enabled=true --conf spark.sql.adaptive.skewJoin.skewMapThreshold=10000000（10MB）；
3. 手动重分区：df.repartition(200)，将倾斜Key打散。

注意：repartition()会触发Shuffle，而coalesce()不会。若只是减少分区数（如从200减到50），用coalesce(50)；若需打散倾斜Key，必须用repartition(200)。

4.3 数据倾斜调优：从“识别”到“根治”的四层防御体系

数据倾斜是Spark调优的终极战场。它不像OOM那样直接报错，而是表现为：

• 某些Task运行时间是其他Task的100倍；
• Executor CPU使用率长期>90%，但网络IO几乎为0；
• Shuffle Write数据量分布极度不均（Spark UI中Shuffle Write列最大值/最小值>100）。

我的四层防御体系如下：

第一层：预防——SQL层面规避

• 使用salting技术：对倾斜Key加随机前缀，聚合后再去前缀。例如统计用户订单数：

  -- 倾斜前 SELECT user_id, COUNT(*) FROM orders GROUP BY user_id; -- 倾斜后（加盐） SELECT CASE WHEN rand() < 0.1 THEN concat(user_id, '_', cast(rand() * 10 as int)) ELSE user_id END AS salted_id, COUNT(*) as cnt FROM orders GROUP BY salted_id;

第二层：检测——日志自动告警
在提交作业时注入日志监控脚本：

# 监控Shuffle Write方差 spark-submit \ --conf "spark.executor.extraJavaOptions=-javaagent:/path/to/shuffle-monitor.jar" \ your_app.py

shuffle-monitor.jar会在Executor日志中输出SKEW_DETECTED: partition_123 has 123456789 bytes, avg is 1234567。

第三层：拦截——AQE实时干预
Spark 3.0+的AQE可自动处理倾斜：

• spark.sql.adaptive.skewJoin.enabled=true：对Join倾斜自动切分大分区；
• spark.sql.adaptive.coalescePartitions.enabled=true：合并小分区减少Task数；
• spark.sql.adaptive.localShuffleReader.enabled=true：本地读取Shuffle数据，减少网络传输。

第四层：根治——数据源治理
在Hive表中添加SKEWED BY属性：

CREATE TABLE orders_skewed ( order_id STRING, user_id STRING, amount DOUBLE ) SKEWED BY (user_id) ON ('1000001', '1000002') STORED AS ORC;

这样Hive在写入时就会对倾斜Key做特殊处理。

实战教训：某次处理用户画像数据，user_id为'0'的记录占总量40%。我们尝试了所有SQL层方案，最终发现根源是埋点SDK Bug导致大量测试账号上报user_id='0'。调优的终点，往往是业务数据质量的起点。

5. 常见问题与排查技巧实录：那些让我凌晨三点爬起来的真问题

5.1 “Stage卡在99%”问题速查表

提示：Stage 99%问题中，70%源于序列化失败。最简验证法：在Driver中运行pickle.dumps(your_function)，若报错则必是序列化问题。

5.2 “Executor Lost”问题的5个致命陷阱

Executor丢失是Spark最顽固的故障，日志中通常只显示Executor XXX died，但背后原因各异：

• 陷阱1：Linux OOM Killer主动杀死进程
  现象：dmesg -T \| grep -i "killed process"显示Out of memory: Kill process 12345 (java) score 852 or sacrifice child。
  原因：Linux内核发现内存不足，主动杀死占用内存最多的进程（通常是Executor JVM）。
  解决：echo vm.swappiness=1 > /etc/sysctl.conf（降低Swap倾向），并确保spark.executor.memory不超过物理内存的70%。

• 陷阱2：YARN Container被RM强制回收
  现象：YARN RM日志中出现Container killed by ResourceManager。
  原因：Executor申请的内存超过YARN队列max-am-resource-mb限制。
  解决：在spark-submit中添加--conf spark.yarn.am.memory=2g，并确认spark.executor.memory+spark.yarn.am.memory<队列上限。

• 陷阱3：JVM Metaspace耗尽
  现象：Executor日志中java.lang.OutOfMemoryError: Compressed class space。
  原因：加载了过多类（如动态生成的UDF），Metaspace不足。
  解决：--conf spark.executor.extraJavaOptions="-XX:MaxMetaspaceSize=512m"。

• 陷阱4：DNS解析超时
  现象：Executor日志中java.net.UnknownHostException: spark-master。
  原因：Worker容器内/etc/hosts未配置Master主机名。
  解决：在docker-compose.yml中为spark-worker添加extra_hosts: ["spark-master:172.20.0.2"]。

• 陷阱5：Shuffle服务未启动
  现象：Executor日志中Failed to connect to shuffle server。
  原因：Spark Standalone模式下，Shuffle服务需单独启动。
  解决：在spark-worker容器中执行$SPARK_HOME/sbin/start-shuffle-server.sh。

5.3 “Py4JJavaError”背后的3个真实世界案例

Py4J错误是Python与JVM通信失败的统称，但每个错误背后都是不同的系统断层：

• 案例1：Py4JJavaError: An error occurred while calling o123.showString
  表面是showString失败，实则是Driver内存不足，无法将结果集拉取到本地。
  解决：--driver-memory 4g，或改用df.limit(100).toPandas()分批拉取。

• 案例2：Py4JJavaError: An error occurred while calling z:org.apache.spark.api.python.PythonUtils.getPythonLibPath
  根本原因是PYSPARK_PYTHON指向的Python环境缺少numpy等基础包。
  解决：在Executor节点执行$PYSPARK_PYTHON -c "import numpy"验证。

• 案例3：Py4JJavaError: An error occurred while calling o123.collect
  这是最危险的错误——它意味着Executor已崩溃，Driver收不到响应。
  必须检查Executor日志，而非Driver日志。典型原因：UDF中调用了subprocess.Popen，子进程继承了JVM的文件描述符，导致Executor僵死。

最后分享一个小技巧：当所有日