Spark安装配置怎么做？Spark安装配置常见问题详解

Apache Spark 的安装配置是整个大数据计算体系中最基础的环节，绝大多数安装失败与性能瓶颈并非源自 Spark 本身，而是源于 Java 环境不统一、依赖包冲突以及资源配置参数与实际集群拓扑不匹配，对于生产环境，强烈建议直接使用 Spark 3.3.x 及以上版本搭配 Java 11，并采用 Local 模式验证功能 + Standalone/YARN 模式承载生产 的分阶段部署策略,这能最大程度规避踩坑风险并保障后期扩展平滑。

环境准备：第一道分水岭

在下载安装包之前，请务必完成以下三件事,这比安装动作本身更重要：

• JDK 版本锁定：Spark 3.x 系列要求 Java 8/11/17，但我们只推荐 Java 11，原因在于 Java 8 无法完整利用 G1 垃圾回收器在大堆内存下的优势，而 Java 17 对部分 Scala 2.12 生态的反射调用存在兼容性警告，建议使用 update-alternatives --config java 确认默认 Java 版本。
• SSH 免密登录：如果你计划部署集群模式，所有 Worker 节点之间以及 Master 与 Worker 之间必须配置免密登录，仅配置单向免密会导致 start-all.sh 时部分 Worker 启而不动。
• 依赖检查：切勿直接使用系统自带的 Python 3.6 或 Anaconda 5.x 旧版本，这会导致 PySpark 运行时出现 Python version requires 3.8 or above 错误，建议单独创建虚拟环境 python3 -m venv /opt/spark_py 并指向 Spark 使用的解释器。

安装步骤与核心配置解析

下载与目录规范

从 Apache 官方镜像站下载 spark-3.3.4-bin-hadoop3.tgz 后，解压至 /opt/spark 目录，这里有一个常见的认知误区：不要直接使用默认的 /root/spark 路径，因为大数据组件通常需要低权限账号运行，且后期发行版升级时路径越短越不容易出错,执行以下命令完成基础布局：

tar -zxvf spark-3.3.4-bin-hadoop3.tgz -C /opt/
mv /opt/spark-3.3.4-bin-hadoop3 /opt/spark
chown -R spark:hadoop /opt/spark

环境变量配置的精髓

编辑 /etc/profile.d/spark.sh，写入以下内容。

Spark 的 JAVA_HOME 必须独立指定，不能依赖系统默认，因为某些云主机镜像中存在多个 JDK 版本，指错路径会导致 Executor 无法启动：

export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
export SPARK_HOME=/opt/spark
export PATH=$PATH:$SPARK_HOME/bin:$SPARK_HOME/sbin
export PYSPARK_PYTHON=/opt/spark_py/bin/python

核心经验：很多人喜欢把 PYSPARK_PYTHON 写在 spark-env.sh 中，但我们更推荐写在 profile.d 中，原因在于 spark-env.sh 只对 Shell 启动的 Spark 进程生效，而通过第三方调度平台（如 Airflow）提交任务时经常丢失该变量。

spark-env.sh 中的暴力优化项

此文件是 Spark 调优的第一站,直接复制以下配置并根据实际内存调整：

SPARK_MASTER_HOST=node01
SPARK_WORKER_CORES=8
SPARK_WORKER_MEMORY=16g
SPARK_DRIVER_MEMORY=2g
SPARK_EXECUTOR_CORES=2
SPARK_EXECUTOR_MEMORY=4g
SPARK_LOCAL_DIRS=/data/spark_local,/data2/spark_local

这里必须提醒一个关键细节： SPARK_WORKER_MEMORY 并不是设置得越大越好，我们经过压测发现，当 Worker 内存超过 32g 且单个 Executor 内存为 4g 时，JVM 的 G1 堆外内存消耗会导致频繁的 Full GC，建议单个 Executor 内存控制在 4-8g 区间，如果单机内存很大，应增加 Executor 个数而非单 Executor 内存。

默认配置的颠覆性修改

打开 $SPARK_HOME/conf/spark-defaults.conf，除了默认的 spark.master 与 spark.serializer 之外，务必增加以下三项，它们能直接消灭 50% 以上的 OOM 与网络超时问题：

• spark.network.timeout：默认是 120s，在动态资源分配时会偏短，建议调整为 800s，特别是在有频繁 Shuffle 的 ETL 作业中，可防止 Executor 被误杀。
• spark.sql.shuffle.partitions：默认 200 个分区，但这个值只适合中小规模数据集，我们建议根据数据量显式设置，2 Executor 总核数 的 2 到 3 倍。
• spark.dynamicAllocation.enabled：很多教程让你开启，但在独立 Standalone 模式下我们建议设置为 false

  

  ，原因在于动态分配会导致频繁的 Executor 启停，每次启动约消耗 10-20 秒，对于 5 分钟以内的短任务反而拖慢效率。

验证安装的黄金标准

千万不要只用一个 spark-shell 跑 sc.version 就认定成功。完备的验证必须包含以下两个层面：

• 基础层验证：执行 /opt/spark/bin/run-example SparkPi 100 则能看出计算逻辑是否正确，结果在 3.14 左右即正常。
• 性能基准验证：用 spark-submit 提交一个 Shuffle 密集型作业（WordCount 对 1GB 文本进行计数），观察 Spark UI 上 Shuffle Read Size/Records 是否有异常波动。Shuffle Read 速率低于 50MB/s，则需要检查网卡 bonded 模式与磁盘 IO 调度策略（建议使用 deadline）。

酷番云经验案例：IO 瓶颈可视化

在为某制造业客户部署 Spark 集群时，我们遇到一个诡异现象：集群资源利用率仅 40%，但作业耗时为同规格物理机的 3 倍，通过 Spark UI 与 iostat 联合排查，发现所有 Executor 的 LocalDirs 都指向了同一块云硬盘，虽然配合的是酷番云高性能 SSD 云硬盘，多块磁盘支持同时挂载，但客户只初始化了一块数据盘，导致所有中间结果全部集中写入单个盘,寻道时间剧增。

解决方案：在酷番云控制台额外购买两块 SSD 数据盘并挂载到 /data2、/data3，然后修改 spark.local.dir 为多个目录并用逗号分隔，重新压测后，Shuffle 写入时间缩短 57%，整体作业耗时下降 38%，这个案例给我们的启示是：云上部署 Spark 时，首先确认存储层是否具备多个独立 I/O 通道，这远比盲目加 CPU 更有性价比。

常见故障速查

• java.lang.NoClassDefFoundError: scala/Product：这不是 Spark 的问题，是 HADOOP 环境变量中的 CLASSPATH 冲突，把 $HADOOP_HOME/lib 中的旧版 scala-library.jar 排除即可。
• Initial job has not accepted any resources：表示 Executor 无法启动，按顺序检查 spark.executor.memory

  

  是否超过节点内存，以及 spark.executor.cores 是否与 Worker 上配置的总核心数匹配。

• Py4JNetworkError：高发于 PySpark 场景，大概率是 Python 解释器版本不一致，确保 Driver 与 Executor 上的 PYSPARK_PYTHON 指向同一个虚拟环境。

总结与生产建议

Spark 安装配置的核心并不仅仅是跑通示例，而在于通过配置项让底层资源与计算框架达到匹配状态，我们最终推荐的生产环境组合是：Java 11 + Spark 3.3.4 + 多目录 LocalDir + 显式 Shuffle 分区数，每个节点内存高于 32g 时，建议分拆为多个 Worker 实例而不是加大单 Worker 内存，利用 Spark UI 的历史服务器功能（history-server.sh）记录每一次作业的指标,为后续调优提供数据依据。

相关问题解答

为什么我按教程配置了 spark.executor.memory 为 8g，但实际运行时可用内存只有 5-6g？

这是 JVM 堆内外内存分配的结果，Spark Executor 的 spark.executor.memory 属于堆内内存（On-heap），而实际进程中还包含 spark.executor.memoryOverhead（默认是 executor 内存的 10%，也有最小 384m 的限制）以及未压缩的 Java 类空间与线程栈。你可以将 spark.executor.memory 提高到 9g 并显式设置 spark.executor.memoryOverhead=2g，确保可用内存等于你的任务实际负载，注意，Executors 内存总和之和不能超过 Worker 的内存上限。

Spark 配置完 SparkR 后总是提示 R home is not set，但独立运行 R 又是正常的？

问题在于 SparkR 启动时是通过 sparkR.submit 来定位 R 的，它读取的是环境变量 R_HOME。如果你通过 RStudio 启动，它不会自动把 R_HOME 传递给 Spark，需要手动执行 Sys.setenv(R_HOME = "/usr/lib/R")，确保 R 版本在 3.5 以上，否则 SparkR 的 DataFrame API 会触发 ABI 兼容性报错。

您在实际安装中是否还遇到过奇怪的 Driver 退出码或 Executor 丢失问题？欢迎在评论区留言，我会逐一分析原因，并分享对应的参数调优补丁。