从零搭建个人大数据集群：Spark安装与Standalone实战

从零开始搭建个人大数据集群（6）——SPARK安装

个人大数据集群搭建系列走到第6篇，终于轮到Spark了。前面我们搞定了存储和资源调度，HDFS里能存数据，YARN上能跑MapReduce任务，但说实话，MapReduce那套开发和调试体验，是真的磨人。写个WordCount都要继承一堆类，提交一次任务好几分钟，迭代一版改个逻辑又得重新打包上传。所以这篇我们给集群加装Spark，把内存计算的威力引进来，日常的数据清洗、分析、临时查询都能快好几个量级。

这篇适合已经完成前面基础组件安装、准备让集群具备真正的计算能力的朋友阅读。我会从版本选型讲起，到目录规划、配置文件、启动验证，再到我踩过的几个典型坑，全程基于个人集群的实际环境：三台物理机，一个Master，两个Worker，操作系统是常见的Linux分发版本，Java和Hadoop环境已就绪。装完Spark，你就能直接用它跑SQL、写PySpark脚本，也能作为独立计算框架跑算法任务。个人集群的Spark安装，其实没那么多玄学，关键是把版本对应关系和内存规划想清楚，其他都是机械操作。

1. 版本选型：装之前先把三件事想清楚

1.1 为什么我选Spark 3.3.2

Spark的版本迭代这两年非常快，3.0出来以后就一路狂奔，3.1、3.2、3.3、3.4、3.5，到2024年4.0都进入预览阶段了。个人集群装哪个版本，很多人第一反应是"装最新版"，但真不是越新越好。我选3.3.2是考虑了三件事：稳定性、生态兼容性、参考资料完整度。

3.3.x这个版本发布于2022年中下旬，到现在经历了大量生产环境的检验，网上踩坑案例、博客、社区回复都非常充足。一个人折腾集群，最大的成本不是安装，而是出问题之后能不能快速找到答案。你装个最新刚发布的版本，遇到报错去搜，可能连Stack Overflow上都只有两三条讨论，心态会很崩。而3.3.2可以刚好避开这个问题：它有新版本的核心能力（比如Adaptive Query Execution已经成熟），又不至于老到跟新版Hadoop生态产生兼容问题。

再一个是Python版本兼容。Spark 3.3系列对Python 3.6到3.9支持良好，还能兼容3.10。如果你像我一样日常用PySpark比较多，这个兼容区间很舒服。过于新的版本有时候会对Python版本有严格限制，反而带来不必要的麻烦。

1.2 Hadoop版本和Spark预编译包的对应关系

这就是个人集群安装Spark最容易翻车的地方。Spark有源码包，也有预编译包，预编译包还针对不同Hadoop版本做了不同分支。下载页面上一堆选项，很容易眼花。关键的区分点是：

• 标识hadoop2的包，对应旧版Hadoop 2.x
• 标识hadoop3的包，对应Hadoop 3.x
• without-hadoop的包，是把Hadoop相关依赖完全抽离，靠外部环境提供

个人集群如果是新搭建的，大概率装的是Hadoop 3.x，那就直接选spark-3.3.2-bin-hadoop3这个系列。我见过不止一个朋友，套件版本是Hadoop 3.3.x，结果SPARK包下成了hadoop2版本，启动没问题，一提交任务就各种NoSuchMethodError，查来查去最后才发现是包选错了。

还有一种特殊情况是without-hadoop包，它适合那些想严格复用现有Hadoop环境的场景。使用这种包，需要在Spark的配置里显式指定HADOOP_HOME和相关依赖路径，稍麻烦一些。对于个人集群，我不建议用这个变体。预编译的hadoop3版本已经内嵌了所有Spark运行时需要的Hadoop客户端依赖，跟外部的HDFS、YARN通信完全没障碍，省心。

1.3 部署模式选standalone还是yarn？个人集群怎么选

Spark支持多种部署模式：本地模式、Standalone、YARN、Kubernetes、Mesos等。个人集群最常用的两个选择是YARN模式和Standalone模式。两者没有绝对的优劣，取决于你想怎么用。

YARN模式的意思是，Spark任务跑在已有的YARN资源调度体系上，跟MapReduce共享同一个资源池。好处是资源统一管理，不会出现一个框架把集群资源全占了的情况。代价是配置较复杂，涉及HADOOP_CONF_DIR设置、Spark和YARN的交互调优，排查问题时链路更长。

Standalone模式是Spark自带的简易集群管理器，由一个Master进程和若干Worker进程组成，安装配置极简，资源管理逻辑清晰一眼能看懂，非常适合个人集群。个人集群通常不会有几百个并发任务抢资源的情况，Standalone完全够用。而且它自带Web UI，端口8080，集群状态、任务执行情况一目了然，对学习和调试都很友好。

我的建议：如果是自己搭着学技术、跑日常分析，先用Standalone。等真正需要跟历史MapReduce任务共享集群的时候，再配置YARN模式也不迟。一套Spark安装包两种模式都能启用，并不冲突。

2. 下载与目录规划：干净的第一步省掉后面很多事

2.1 下载哪个具体文件

确定版本之后，去官网下载页面。找到spark-3.3.2-bin-hadoop3.tgz这个文件，体积大概290MB左右。注意别下带src标识的源码包，源码包还需要额外执行Maven构建，费时费力完全没必要。

下载命令可以直接在Master节点执行：

cd /opt wget https://archive.apache.org/dist/spark/spark-3.3.2/spark-3.3.2-bin-hadoop3.tgz

2.2 目录结构与解压后的软链接

我把所有大数据组件统一放在/opt目录下，并且坚持用软链接。什么意思？就是解压后实际目录名带版本号（比如spark-3.3.2-bin-hadoop3），然后创建一个不带版本号的软链接指向它，比如这样：

tar -zxvf spark-3.3.2-bin-hadoop3.tgz -C /opt ln -s /opt/spark-3.3.2-bin-hadoop3 /opt/spark

为什么要多此一举？因为以后的升级、换版本都只需要改软链接指向，配置文件里的路径完全不用动。这种小细节，在学习阶段觉得无所谓，等集群组件多了以后，体会到的好处会翻倍。

2.3 环境变量与JAVA_HOME定位

在所有节点（Master和Worker）上都配置环境变量，编辑/etc/profile.d/spark.sh：

export SPARK_HOME=/opt/spark export PATH=$SPARK_HOME/bin:$SPARK_HOME/sbin:$PATH

配置完执行source /etc/profile.d/spark.sh让环境变量生效。这里有个容易忽略的点：Spark进程定位Java不是靠系统的java命令，而是强制读取JAVA_HOME。很多报错"找不到Java"或者"Unsupported class file major version"，根子就是JAVA_HOME没设好或者指向了错误的JDK版本。

我的集群里用的是JDK 1.8（也就是Java 8），这在Spark 3.x中是受支持的。有人用JDK 11，也没问题。但如果你之前装的Hadoop就需要某个特定JDK版本，Spark的JAVA_HOME解析最好跟它保持一致，避免两个框架混用不同JDK版本导致的奇怪问题。

2.4 同步与分发

三台机器的目录结构必须一致。最省事的办法是把解压好的Spark目录直接用scp分发到各Worker节点：

scp -r /opt/spark-3.3.2-bin-hadoop3 root@worker1:/opt/ scp -r /opt/spark-3.3.2-bin-hadoop3 root@worker2:/opt/

分发后分别在Worker节点建立软链接。注意，环境变量文件也要一并分发，确保每一台机器的SPARK_HOME都能正确解析。这一步做完，先别急着启动集群，我们还有几个配置文件要处理。

3. 配置文件与启动：Standalone集群的关键字段

Spark的配置核心在$SPARK_HOME/conf目录下。模板文件都在，我们要基于模板生成实际配置。

3.1 三个最重要的配置文件

第一个是spark-env.sh，由模板spark-env.sh.template复制而来。这个文件主要设置JVM、环境变量和集群级别的资源参数。我的配置如下：

# 指定Java环境 export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 # 指定Master节点主机名 export SPARK_MASTER_HOST=master # 每个Worker上分配的CPU核数 export SPARK_WORKER_CORES=4 # 每个Worker上分配的可用内存 export SPARK_WORKER_MEMORY=8g # 每个Worker上可运行的最大Executor数量 export SPARK_WORKER_INSTANCES=2

第二个是workers文件，由workers.template复制而来。注意文件名在新版本里通常是workers，老版本是slaves，别搞混了。内容很简单，一行一个Worker节点主机名：

master worker1 worker2

这里我写了一个我自己的选择：把Master也作为Worker加入集群。个人集群只有三台机器，如果Master只做调度不干活，计算资源直接少三分之一，非常不划算。但如果你后续要跑的生产负载比较重，建议Master与其他节点职责分离，否则Master既要跑Driver又要跑Executor，压力会很大。

第三个是spark-defaults.conf，由模板复制而来。这个文件配置Spark任务的默认行为：

spark.master spark://master:7077 spark.driver.memory 2g spark.driver.cores 2 spark.executor.memory 2g spark.executor.cores 2 spark.serializer org.apache.spark.serializer.KryoSerializer spark.sql.shuffle.partitions 4

3.2 资源参数背后的计算逻辑

这部分很多新人容易一台机器给多少就配多少，完全不考虑和Worker层级的关系，后面就容易出问题。SPARK_WORKER_MEMORY设置的是Worker进程能用来分配给所有Executor的总量上限，而spark.executor.memory设置的是单个Executor的内存大小。如果把SPARK_WORKER_MEMORY降到不合理的低值，比如2g，那无论你的Executor参数填多大，Worker也分配不出来。

打个比方：Worker是一个房东，它手里的房源总量是固定的（SPARK_WORKER_MEMORY）。Executor是租客，每个租客签的合同（spark.executor.memory）决定了它能租多大面积。房东手里总共只有8g，就不可能同时签十个2g的租客。

我机器是16G内存。系统本身要占用一部分，NameNode、DataNode、HDFS相关进程还要各占一部分，所以给Spark Worker的8g已经是个相对宽裕的数值。同时设了SPARK_WORKER_INSTANCES=2，意思是每台机器上起两个Worker进程，每个进程4g。这样是有好处的：即使一个Worker进程异常崩溃，另一个还能继续接受任务，减小单点故障对集群的冲击。你如果内存紧张，完全可以只设一个Worker实例，不设这个参数即可。

3.3 启动顺序与校验

先启动Master，再启动workers。使用sbin/start-all.sh脚本可以一步到位：

$SPARK_HOME/sbin/start-all.sh

这个脚本会读取workers文件，通过SSH免密登录到各节点逐一启动Worker进程。假如之前Hadoop配置时已经打通了Master到各Worker的SSH免密，这里就不用再做额外设置。如果没打通，就得先配好，否则启动会卡在密码输入处。

启动后，检查进程：

jps

Master上应该能看到Master进程，Worker节点上能看到Worker进程。然后打开浏览器访问http://master:8080，能看到Web UI页面，显示集群的总内存、总CPU核数、活跃Worker列表。到这里，Spark Standalone集群就算起来了。

之前我每次装完，都会犯一个懒：既然Web UI正常，就直接开始跑任务。但真正严谨的做法是核对页面上的"Total Resources"和你的配置参数是否一致。如果页面上的总内存跟期望值差很多，基本都是某个Worker的配置没生效，或者Worker进程没有正常注册。

4. 验证集群：跑单词统计还不够

很多教程验证Spark安装会直接跑spark-shell，写一段WordCount代码。这只能证明Spark进程能启动，证明不了集群真的在工作。我习惯用两种方式来验证：一是跑一次正式的spark-submit任务，二是用Python脚本模拟一个贴近实际的小任务。

4.1 用自带样例做提交验证

Spark自带了一些example JAR包，是最稳的验证材料。先看它在不在：

ls $SPARK_HOME/examples/jars/spark-examples*.jar

如果打包时没有包含样例JAR，可以在解压包中找。有它的话，我们直接用spark-submit跑一个官方范例，例如计算圆周率：

$SPARK_HOME/bin/spark-submit \ --class org.apache.spark.examples.SparkPi \ --master spark://master:7077 \ --executor-memory 2g \ --total-executor-cores 4 \ $SPARK_HOME/examples/jars/spark-examples*.jar 100

这个任务会用蒙特卡洛方法估算圆周率，参数100表示模拟的次数规模。任务跑起来后，日志里会出现很多INFO信息，最终在结尾附近能看到类似Pi is roughly 3.142233的输出。到这里，至少说明：Spark集群能被客户端正确连接，Master成功调度任务，Worker拉起了Executor，Executor之间的Shuffle通信没有问题。

把这段跑通之后，可以再跑一个每个节点都参与计算的、带数据读取的验证任务：

$SPARK_HOME/bin/spark-submit \ --class org.apache.spark.examples.SparkWordCount \ --master spark://master:7077 \ $SPARK_HOME/examples/jars/spark-examples*.jar \ hdfs://master:8020/user/test_dir/data.txt

这个任务会读HDFS上的文件做词频统计。如果输出成功，就说明Spark不仅集群内部通信正常，连和HDFS的对接也没有问题。我现在跑集群，这一条基本是必做的，相当于给整个链条做了个全链路体检。

4.2 用PySpark模拟一个贴近实际的小任务

既然个人集群常用于跑数据分析，我建议做一次PySpark层面的验证，贴近之后的真实用法。这里写了一个小脚本test_spark.py，作用是读一个CSV文件，按某个字段分组，做一个简单的count聚合：

from pyspark.sql import SparkSession spark = SparkSession.builder \ .appName("pyspark_smoke_test") \ .master("spark://master:7077") \ .getOrCreate() # 造一点测试数据 data = [("zhang", 1), ("zhang", 2), ("li", 3), ("li", 4), ("wang", 5)] df = spark.createDataFrame(data, ["name", "value"]) df.groupBy("name").count().show() spark.stop()

执行方式：

$SPARK_HOME/bin/spark-submit test_spark.py

如果能看到按name分组的结果输出，说明Python开发的链路通了。这个脚本虽然简单，但已经覆盖了SparkSession初始化、数据分片分发到各Worker、结果聚合返回、Driver端收集结果这几个核心环节。

个人开发的话，还可以在spark-defaults.conf里把spark.master默认设好，这样跑PySpark脚本时连--master都不用带，代码里也不用手写master地址，更接近生产环境的使用习惯。

4.3 从Web UI推断配置生效情况

Spark的Web UI不止一个页面。除了主页面展示集群资源以外，任务运行时点进某个Active Application，能看到每个Executor的日志、Stages的进度。我经常用这个页面检查：

• 每个任务的Executor个数是否和预期一致
• 每个Executor的内存和核数是否对得上
• 数据Shuffle的量是否异常巨大（如果数据量很小但Shuffle很大，说明分区设置不合理）

这些判断不用太早依赖命令行，页面上的信息就足够直观。

5. 个人集群上的Spark排错笔记：五个经典事故

Spark安装本身不难，难的是装好以后跑任务时零零碎碎暴露的问题。我把自己实际踩过的五个坑记录下来，每一个都对应一个具体的现象，你可以对照排查。

5.1 Executor无法启动：worker内存配置与Executor内存的关系

我先遇到的一个典型故障是：任务提交后一直卡在WAITING状态，点开Web UI看，Executor个数始终是0，没有任何Executor被创建。查看日志发现，反复出现“Not enough space to launch executor”或“Failed to allocate memory for executor”的英文提示。

逐层排查后，定位到是自己把spark.executor.memory设成了4g，SPARK_WORKER_MEMORY也设成了4g，Worker上还有Master进程、NameNode、DataNode占用，根本腾不出4g给Executor。Executor申请内存时，Spark还会额外预留一部分开销（默认是Executor内存的10%左右，叫spark.executor.memoryOverhead），所以实际需要的内存比参数值更大。

调整思路很简单：把spark.executor.memory调低到2g，同时适当减小Worker上其他组件的内存占用。这个坑最大的教训是：不要只看一个参数，要把整台机器所有的常驻内存进程加起来算一笔总账。

5.2 所有任务都卡在“resolving”阶段：hostname解析问题

有一次所有任务提交后都卡在等待状态，Web UI上显示一个Executor都没有，而且Master日志中一直出现“Failed to include worker”或者类似字样。这就不是内存的问题，而是Worker向Master注册时失败了，大概率是hostname反解出了问题。

个人集群为了省事，很多人会在/etc/hosts里写死IP和主机名的映射，这本身没有错。但如果某个节点的/etc/hostname和/etc/hosts中的配置不一致，网络通信时就可能出现一台机器用A名字注册、另一台机器用B名字回话，导致对不上。

我的经验是：所有节点的主机名都用纯短名称，不要带域名后缀；/etc/hosts里统一写清每个节点的IP和短名对应关系；同时在spark-env.sh里用SPARK_MASTER_HOST明确指定Master的hostname，把潜在歧义消除掉。改完这些以后，start-all.sh重启整个集群，问题就消失了。

5.3 java.lang.NoClassDefFoundError：目录结构与环境变量不一致

某次在worker2上启动Worker进程时，日志里报出一堆NoClassDefFoundError，指向某个Spark核心类。第一反应是JAR包损坏，重新解压一遍还是不行。后来发现不是包的问题，而是worker2上的SPARK_HOME指向了一个不存在的路径。

原来我之前只在worker2上解压了带版本号的目录，但忘记做软链接，环境变量依然指向/opt/spark。由于Spark的启动脚本依靠SPARK_HOME定位所有类和配置，这个路径一旦失效，整个进程就完全起不来。这个问题的排查方法就是在出问题的节点上执行：

echo $SPARK_HOME ls -l $SPARK_HOME/conf jps

一对比，路径问题马上就暴露了。很基础，但实际出问题时手忙脚乱就容易忽略。

5.4 任务结果正确但写入HDFS报错：写权限与临时目录

还有一次跑WordCount，最后结果collect到Driver端正常，但把结果写到HDFS时报Permission denied。原因很朴实：当前用户对目标目录没有写权限，HDFS的权限控制默认开启。解决办法有两个：

hdfs dfs -chmod -R 777 /user/当前用户

或者在spark-defaults.conf里给每个任务指定HDFS目录归属。个人集群一般直接建好用户目录然后把owner改成自己就行。这类问题跟Spark本身关系不大，更多是HDFS权限带来的连锁反应，排查时要学会分辨报错是属于Spark层还是HDFS层的。

另外还遇到过临时目录写满的情况。Spark执行shuffle时会写大量临时文件到spark.local.dir指定的目录，默认是系统临时目录/tmp。如果系统盘空间不大，跑大任务很容易把它占满。安装时就要提前规划好，在spark-env.sh里加一行：

export SPARK_LOCAL_DIRS=/data/spark-local,/tmp

让自己准备一个独立的磁盘空间来做shuffle落盘，既避免占满系统盘，又能提升I/O性能。

5.5 版本不匹配产生的诡异报错

最后聊一个比较隐蔽的问题：如果前面阶段不是全新建的集群，之前有过旧版本的Spark或不同版本依赖，你在同一个Spark目录里跑了多个不同版本项目的任务，可能会遇到版本不兼容的怪异问题。比如Spark 2.4的代码直接扔到Spark 3.3的环境里，很多API已经废弃，编译期看不出问题，运行期却会报错。

我自己遇到过最典型的例子：之前用Spark 2.4跑过一个结构化流任务，后来升级到3.3后没有重新编译就直接提交，结果在Runtime出现了关于“MicroBatchExecution”的类找不到或方法签名不匹配的问题。排查了半天，最终的根源就是旧代码依赖打包时指向了旧版本Spark API，杀头的不是版本，而是"代码打包时用的Spark版本"和"运行时Spark版本"不一致。

解决这个问题的方法是统一依赖：用3.3.2对应的依赖重新构建应用。如果你在写项目前不确定当前集群的Spark版本，可以在应用代码里打印：

print(spark.version)

或者在客户端执行：

$SPARK_HOME/bin/spark-submit --version

确认提交的代码版本与集群版本兼容，避免神秘报错浪费大量时间。

6. 按需扩展：启动模式和其他组件的小建议

Spark装完不算结束，很多朋友装完就急着跑大量任务。个人集群的意义，在于你随时可以上手实验，不必为资源调度担忧。接下来还有几个值得深挖的方向。

6.1 开启动态资源分配

Standalone模式下，默认是固定资源占用，任务提交时申明多少资源，整个运行期就占着不放。对于个人集群这种任务密度不高的场景，其实可以开启动态资源分配，让任务结束后迅速释放资源给其他任务：

spark.dynamicAllocation.enabled=true spark.dynamicAllocation.minExecutors=0 spark.dynamicAllocation.maxExecutors=6 spark.shuffle.service.enabled=true

注意开启动态分配时，需要额外部署Shuffle External Shuffle Service，否则Executor销毁后shuffle文件就丢了。如果是纯学习用途，不大规模并行跑任务，也可以不开，保持默认也足够。

6.2 历史服务与SQL的引入

Spark自带的HistoryServer可以把任务的历史日志持久化到HDFS或本地目录，重启集群后依然能看到之前的任务记录。个人集群一旦开了这个功能，排查问题的体验会提升一个档次：

$SPARK_HOME/sbin/start-history-server.sh

另外我建议后续装一个Spark SQL ThriftServer，这样你可以直接拿类似数据库客户端的工具连接Spark，跑标准SQL查询，体验不比查询一个数据库差。做数据分析和临时探索非常方便。当然，这属于进阶玩法，先把核心安装和任务提交跑顺了，再逐步扩展不迟。

6.3 与现有HDFS、YARN的配合方式

Spark只用Standalone模式时，和YARN之间的关系是并行的——这是两套独立的资源调度系统。如果你想在Spark里访问HDFS的数据，直接写hdfs://master:8020/...路径就能读，因为Spark内置了Hadoop客户端。但如果你在YARN模式下跑Spark，就需要确保每台机器都有HADOOP_CONF_DIR环境变量指向Hadoop的配置文件目录，这样Spark应用提交后，Spark Executor才能正确访问Hadoop集群的服务。

个人集群我的建议是：先保持Standalone，专注体验Spark本身的计算抽象和优化机制。等对资源管理和任务提交的流程消化透了，再切到YARN上跑几天，你会更深刻地理解两个调度框架各自擅长的领域。两套模式都跑通，集群的使用弹性会非常大。

Spark装好以后，这台个人集群的主要价值才真正释放出来。从前期的数据存储，到现在的内存计算，算是一个里程碑。接下来你可以考虑继续搭建数据仓库工具，或者接入调度框架，让集群能真正干活。如果安装过程中遇到上面没覆盖的问题，也可以从Web UI的日志入手，一层层剥开看，大部分问题都能在里面找到线索。