企业官网建设流程全解析

这是“从零开始搭建个人大数据集群”系列的第6篇，这次轮到Spark了。前面几篇我已经把JDK、HDFS、YARN这些基础组件陆续跑起来，集群的底层存储和资源调度算是有了雏形。但说实话，光是HDFS和YARN还不够，因为真正做数据分析的时候，MapReduce的计算模型用起来太别扭，写一堆代码不说，跑迭代任务时每个Stage都要落盘，速度实在感人。Spark解决的就是这个问题，它把核心数据尽量放到内存里算，借助DAG调度和更细粒度的任务管理，很多场景下比MapReduce快一个数量级。这篇文章我不打算铺开讲理论，而是沿着我实际搭建的过程，把Spark的版本选型、安装配置、启动验证、常见故障排查、资源有限时的调优经验完整走一遍。适合已经装好Hadoop基础环境、正准备给集群加计算引擎的读者。

1. 先把Spark的定位说清楚——它解决的是什么问题

很多刚玩集群的朋友会把Spark误当成HDFS的替代品，其实它俩的职责完全不一样。HDFS负责存，Spark负责算。你在Spark里读写的文件通常落在HDFS上，但Spark本身并不负责持久化存储，它更关心的，是任务执行的效率。

1.1 MapReduce的痛点与Spark的设计思路

MapReduce是Hadoop自带的计算引擎，计算模型本身没问题，但它有一个要命的短板：每个Job、每个Stage的中间结果都会写到HDFS上，下一阶段再读回来。中间结果写盘对容错有好处，可一旦任务流程长，落盘和重复读HDFS的开销会占到整个运行时间的大头。做PageRank这类需要反复迭代的算法时，一轮迭代落一次盘，几十轮下来，绝大部分时间都耗在IO上了。

Spark的核心思路是把计算尽可能放在内存里。它提出了RDD（弹性分布式数据集）的概念，把数据切成分区分布式地放在集群各节点上，允许你在内存中反复操作这些数据，只有需要容错时才通过血统机制重新计算。

我刚接触Spark的时候也不理解RDD这层抽象解决什么问题，后来自己写了一个WordCount对比MapReduce和Spark两种写法，才体会到差异。MapReduce版本光是MR算子就要写两个类，而Spark用Scala或者Python接口，几行就能搞定。这不只是代码量的问题，更重要的是Spark会把多个操作合并成一个DAG执行计划，让数据在内存中流动，减少不必要的落盘和序列化开销。

1.2 版本选型：别在这个环节偷懒

版本选型看起来不起眼，实际是安装过程中容易埋雷的地方。

Spark版本迭代很快，现在主流是3.5.x，3.x以后的API相对稳定。我的建议是直接选当前3.x系列里的最新稳定小版本，别执着于2.4.x或者2.3.x那些老版本，很多新特性在2.x下根本跑不了，而且后续生态里的插件、官方文档都在向3.x靠拢。

选版本的时候要重点看配套关系。Spark需要Java，3.x版本支持JDK 8和11，也支持17，但我个人在3.5.x上用JDK 8跑集群和任务都很稳，没必要为了追新特意上JDK 17。Python方面，PySpark要求Python 3.8以上，这个基本都能满足。

下载包的时候有个特别容易踩的坑：Spark官方提供多种预编译包，常见的有“Pre-built for Apache Hadoop 2.7”“Pre-built for Apache Hadoop 3.3”以及“Pre-built with user-provided Apache Hadoop”这几种。很多人不管三七二十一就下载了带Hadoop 2.7的包，结果放到自建集群上，一连HDFS就报各种NoSuchMethodError、ClassNotFoundException，排查半天发现是Spark自带的Hadoop client jar和集群实际的Hadoop版本起了冲突。

我这次的自建集群Hadoop是3.3.x，所以优先选“Pre-built for Apache Hadoop 3.3”的包。如果你用的是自定义Hadoop发行版，那就选“with user-provided Apache Hadoop”，下载之后在spark-env.sh里设置一行变量，让Spark动态获取Hadoop的类路径：

export SPARK_DIST_CLASSPATH=$(hadoop classpath)

这行配置的作用是把系统里Hadoop命令输出的所有依赖jar路径交给Spark，从根本上避免打包时写死的Hadoop版本跟你真实环境不一致。

2. 安装前要确认的准备工作

Spark本身是个纯JVM应用，安装步骤看着简单，但对前置环境有隐性要求。我吃过很多次亏都是在环境上，所以单独把这一步拎出来讲。

2.1 环境变量检查

在解压Spark之前，先在每台节点上确认下面几项：

echo $JAVA_HOME java -version echo $HADOOP_HOME hdfs dfs -ls /

一次排查中我发现，集群里有一台机器JAVA_HOME没配好，Spark的Master进程在这台机器上能启动，但Worker连上来后Executor始终无法初始化。后来仔细看日志才发现是Java环境变量在spark-env.sh里没有被正确传递。所以安装之前一定要保证每台机器上JAVA_HOME指向的路径真实存在，而且hadoop命令能正常执行。

如果你还要跑PySpark，那Python版本也顺带确认一下：

python3 --version

2.2 目录与用户规划

我习惯把Spark统一放在/opt/spark目录下，方便多台机器保持一致。不推荐放在带空格或权限复杂的自定义目录，因为Spark的Daemon进程在启动时会读取一堆配置脚本，路径里有特殊字符很容易把脚本搞挂。

权限方面，虽然很多人用root用户直接跑，但正规的集群实践应该是用一个普通用户（比如数据用户）来管理所有大数据组件。如果之前装Hadoop时已经建过专用用户，那Spark也沿用同一个用户，让Spark的日志目录、临时目录都归这个用户所有，后续配合HDFS读写才不会有权限矛盾。

2.3 网络与hosts配置

Spark的节点间通信依赖主机名解析，必须确保集群所有机器能通过主机名两两互通。检查一下/etc/hosts，把每台机器的ip与主机名映射都写上，格式类似：

192.168.1.10 node01 192.168.1.11 node02 192.168.1.12 node03

有次我在某台节点上没加主机名映射，Spark Shell连接Master时一直显示超时重试，等了大半天才反应过来是解析不到node01。这种问题不会在日志里给你报“host not found”，只会表现为连接反复失败，排查起来很耗时间。

3. 安装与配置Spark核心文件

准备工作做完，进入正题。这一步的内容也是整个Spark集群能否稳定运行的关键。

3.1 下载与解压

下载地址就在Spark官网，选择对应Hadoop版本的包，直接wget下来。比如3.5.1版本：

cd /opt wget https://archive.apache.org/dist/spark/spark-3.5.1/spark-3.5.1-bin-hadoop3.3.tgz tar -zxvf spark-3.5.1-bin-hadoop3.3.tgz mv spark-3.5.1-bin-hadoop3.3 spark-3.5.1

解压后目录结构里，bin目录存放spark-submit、spark-shell等客户端脚本，sbin目录存放Master、Worker、History Server启停脚本，conf目录是配置大本营，examples目录里有一些官方样例，后面验证集群就会用到example jar。

这里有个实际经验：不要把Spark解压到HDFS的挂载目录里，也不要放在每台机器的临时目录中，因为Spark的运行时临时文件会写入它的安装目录，目录被系统清掉之后，集群会出现各种未知故障。

3.2 spark-env.sh：一次讲清每个参数

进入conf目录，复制模板：

cd /opt/spark-3.5.1/conf cp spark-env.sh.template spark-env.sh

然后编辑spark-env.sh。这是Spark环境配置的核心，里面每一项参数都值得逐一看清楚，因为它直接控制Master和Worker的进程行为。

export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64 export HADOOP_HOME=/opt/hadoop-3.3.4 export HADOOP_CONF_DIR=$HADOOP_HOME/etc/hadoop export SPARK_MASTER_HOST=node01 export SPARK_MASTER_PORT=7077 export SPARK_WORKER_CORES=4 export SPARK_WORKER_MEMORY=8g export SPARK_EXECUTOR_MEMORY=4g export SPARK_DIST_CLASSPATH=$(hadoop classpath) export PYSPARK_PYTHON=/usr/bin/python3 export PYSPARK_DRIVER_PYTHON=/usr/bin/python3

逐个解释一下这几个参数的作用。

JAVA_HOME不用多说，Spark的Daemon和Executor都靠它找Java运行环境。

HADOOP_HOME和HADOOP_CONF_DIR的意义在于让Spark能够读取HDFS和YARN的配置。Spark读取的是core-site.xml、hdfs-site.xml、yarn-site.xml这些文件，如果这两个变量不设置，你会发现Spark Shell里直接访问hdfs://路径会报错。

SPARK_MASTER_HOST指定Master绑定到哪台机器。这里是node01，对应hosts配置里的主节点。SPARK_MASTER_PORT是Master服务的监听端口，客户端（Driver）会通过这个端口连接Master提交任务。

注意这里有个很容易踩的坑：很多教程会把SPARK_MASTER_PORT写成18080，实际上18080是History Server的默认端口，Master默认是7077。如果写错，会导致提交任务的时候连不上Master，或者连上了却识别不了端口。

SPARK_WORKER_CORES和SPARK_WORKER_MEMORY这两个参数控制每个Worker能为Spark贡献多少CPU和内存。默认情况下，Spark会使用机器的全部逻辑核，所有可用内存减掉1GB后都作为Worker内存。对个人集群那点资源来说，这个默认值非常不友好。我建议先给一个保守值，比如一台4核16GB的机器，设置WORKER_CORES=4，WORKER_MEMORY=8g，剩下的内存留给操作系统、HDFS、YARN以及偶发的大内存Java进程。如果直接把16g全分配给Spark，系统很容易因为内存不足触发OOM，表现就是Worker启动后反复被系统杀掉，日志里却看不到明显报错。

SPARK_EXECUTOR_MEMORY是应用运行时每个Executor请求的内存默认值。注意它和SPARK_WORKER_MEMORY是不同层级。Spark有一个Executor Allocator，它会根据Worker内存大小和这个默认请求值决定一台机器上能跑多少个Executor。如果Worker_MEMORY设置成8g，Executor请求4g，那同一台机器最多启动2个Executor。如果Executor请求8g，那只有1个Executor。具体场景下还要看core数量限制，这里有个常规经验：不要在一个Worker里堆太多超大Executor，小集群用多个小Executor往往更灵活。

3.3 spark-defaults.conf：应用行为的关键配置

spark-env.sh解决的是“进程怎么跑”，spark-defaults.conf解决的是“提交任务的默认行为”。我把几个高频项贴出来：

spark.master spark://node01:7077 spark.eventLog.enabled true spark.eventLog.dir hdfs://node01:9000/spark-logs spark.history.fs.logDirectory hdfs://node01:9000/spark-logs spark.serializer org.apache.spark.serializer.KryoSerializer spark.executor.memory 4g spark.driver.memory 2g spark.dynamicAllocation.enabled false

spark.master这一行很关键。它决定你提交任务时默认连哪个集群。如果你用Standalone模式，就写成spark://node01:7077；如果你后面改用YARN模式，这里就改成yarn。不写也没事，但运行前必须在Spark Shell或者Spark Submit时通过--master参数指定，否则默认走local模式，只在本地跑，根本不会用你的集群。

spark.eventLog.enabled和spark.eventLog.dir是给History Server用的。Spark会把每次任务执行的事件日志写到指定目录，History Server再读这些日志生成Web UI才能看到历史任务。如果这个目录不存在，作业虽然能正常执行，但事件日志写不进去，History Server打开是一片空白。

serializer默认是JavaSerializer，兼容性没问题，就是慢。个人集群如果想省内存和序列化时间，可以改成KryoSerializer，配上spark.kryo.registrationRequired设为false，省去注册类的麻烦。

spark.executor.memory和spark.driver.memory分别控制Executor和Driver进程的默认堆内存。个人机器上，Driver一般2g够用，Executor根据前面Worker内存往下拆分就行。

3.4 workers文件与环境变量

在conf目录下把worker文件模板复制一份：

cp workers.template workers

在这个文件里把集群内所有Worker节点的主机名列出来，一个一行：

node01 node02 node03

Master节点自己也可以当Worker，这是个人集群很常见的玩法，等于一台机器既当Master又提供计算资源。如果你有专门的Master节点不想让它分担计算任务，那就不把它的主机名写进workers文件。

最后把Spark的bin目录加入PATH：

echo 'export SPARK_HOME=/opt/spark-3.5.1' >> ~/.bashrc echo 'export PATH=$PATH:$SPARK_HOME/bin:$SPARK_HOME/sbin' >> ~/.bashrc source ~/.bashrc

这里写的SPARK_HOME路径要和前面解压目录完全一致。不配置PATH也可以，无非是每次输完整路径。

4. 部署模式怎么选——Standalone还是YARN

Spark支持很多部署模式，但个人集群真正能用的就两种：Standalone和YARN。这两个模式的选择会直接影响后续任务提交方式和资源管理行为。

4.1 两种模式的核心差异

Standalone模式是Spark自带的资源调度系统，它不依赖外部的YARN或者Kubernetes，架构上就是Master节点和Worker节点。Master负责接收Driver提交过来的任务，把任务拆解后分发给Worker，Worker再启动Executor去执行。对只有两三台机器的个人集群来说，Standalone最简单直接，问题也少。

YARN模式则是把Spark当做一个运行在Hadoop YARN框架下的分布式应用。资源调度完全交给YARN的ResourceManager、NodeManager来做。Spark只是作为YARN上的一个Application，通过ApplicationMaster向NodeManager申请容器运行Executor。

这两种模式的运行机制有什么差别？拿我自己跑的一个数据清洗任务举例。任务大约需要处理20GB的日志，用Standalone模式，资源申请和分配都在Spark内部完成，调度速度快，但一旦YARN上有其他任务在跑，两者互不感知，会抢占资源。用YARN模式，Spark提交后交给YARN统一排队和调度，能跟集群里的MapReduce任务共享资源，但对小集群来说，YARN的调度过程本身会增加一些额外的请求开销，任务启动速度会稍微慢一点。

4.2 个人集群的场景建议

如果你用的是我前面系列搭建的Hadoop集群，里面已经有YARN组件了，那我建议分两步走。

第一步，先用Standalone模式把Spark跑熟。这个模式依赖少、配置简单，出问题的时候排查起来也快，适合验证Spark本身的功能和调试作业。

第二步，等Spark作业稳定了，再切换到YARN模式跑。原因是你的集群里多半还有HDFS的MapReduce任务，YARN能统一资源管理，避免不同组件之间抢夺内存和CPU。YARN模式下，你只需要在spark-defaults.conf里把spark.master改成yarn：

spark.master yarn

同时确保YARN_CONF_DIR或HADOOP_CONF_DIR指向了包含yarn-site.xml的真实目录，否则Spark不知道ResourceManager在哪里。

切换到YARN模式后还有一个坑：默认情况下YARN对每个容器的内存限制十分严格，Spark Executor的容器超过限制会被直接杀掉。你需要在yarn-site.xml中调整NodeManager的资源参数：

yarn.nodemanager.resource.memory-mb yarn.nodemanager.resource.cpu-vcores yarn.scheduler.maximum-allocation-mb

个人小集群一般把memory-mb设置成机器物理内存的60%-70%，maximum-allocation-mb设置成和memory-mb相近的值，避免Executor请求的内存超过YARN允许的上限。改完YARN配置后要记得重启YARN相关进程，重启前先执行配置检查命令确认参数没有语法或类型错误，不然整个集群可能起不来。

5. 启动集群与验证安装

配置全部就位后，终于到了激动人心的启动环节。这个环节不光要看到进程列表，还要真正跑一个计算任务压压惊。

5.1 启动顺序与进程检查

启动顺序其实不强求。你可以先启动Master，再启动Worker；也可以一条命令同时启动：

cd /opt/spark-3.5.1 sbin/start-master.sh sbin/start-workers.sh

用start-master.sh单独启动Master，然后用start-workers.sh扫描workers文件，在列出的每台机器上启动Worker进程。

有人喜欢用sbin/start-all.sh一键搞定，这个脚本在旧版本里很常用，但新版本里官方不推荐使用，因为它会把你本机所有已经配置好的组件一起启动，容易跟HDFS的start-dfs.sh混淆。我更倾向于分开启动，这样第一台机器的Master日志有问题时，不会影响到后面的Worker启动。

启动后立刻用jps检查进程：

jps

正常情况能看到一个Master进程和若干个Worker进程。Master进程名就是Master，Worker进程名是Worker，很好认。

如果jps里没有这些进程，别慌，先去logs目录看日志：

tail -f /opt/spark-3.5.1/logs/spark-org-apache-spark-deploy-master-*.out

日志文件命名格式是spark-用户名-角色-主机名.out，不同机器名字不一样，认准Master和Worker关键字就行。

5.2 跑通Spark Shell和第一个任务

确认进程在跑了，接下来用Spark Shell做一次交互式冒烟测试：

bin/spark-shell --master spark://node01:7077

启动后看到scala>提示符就说明连接成功。输入几行最简单的RDD操作验证一下：

sc.parallelize(1 to 10).sum

如果返回一个数字，说明Driver能和Master正常通信，Executor也成功启动了。

接下来用官方自带的示例程序算圆周率。这是Spark社区非常经典的第一个任务，它用蒙特卡洛方法估算Pi值，涉及集群调度、任务分发和Executor计算的全链路验证，非常合适：

bin/spark-submit \ --class org.apache.spark.examples.SparkPi \ --master spark://node01:7077 \ examples/jars/spark-examples_2.12-3.5.1.jar 10

运行结束后，日志里会输出类似“Pi is roughly 3.1411771”这样的结果，看到它，整个Spark集群的安装就算正式通过验证了。

跑任务的时候可以在Web UI上看执行过程。Master的默认Web端口是8080，打开http://node01:8080，能看到集群当前有多少Worker、多少Executor、每个任务的状态。这个页面是排查集群资源分配问题的一线阵地，比看日志直观得多。

5.3 配置与验证History Server

Spark Shell里确实跑通了一个任务，但任务结束后，Web UI上的作业信息就没了。要想任务跑完后还能在Web UI上回顾，就得靠History Server。

启动History Server：

sbin/start-historyserver.sh

然后打开http://node01:18080，页面上应该能列出所有历史作业。

History Server依赖前面spark-defaults.conf里的spark.eventLog.dir配置。如果你在配置里填写的是HDFS路径，要先在HDFS上创建这个目录并赋予写入权限：

hdfs dfs -mkdir -p /spark-logs

如果忘了创建目录，任务看起来能正常运行，但History Server页面会空空如也，或者提示找不到日志文件。这个坑我踩过一次，印象极其深刻，那次我以为是Web UI的Bug，排查了半天才发现是HDFS目录未创建。

6. 常见问题与排查实操记录

Spark安装和运行阶段，我遇到过不少让人头疼的问题。下面把比较有代表性的几个列出来，按现象、原因、排查步骤、解决方案的方式整理成速查表，方便对照排查。

这里面有两条值得单独说。

第一条是Python worker报错。我有一次在某台Worker节点上发现Python路径是/usr/local/bin/python3，但Master所在机器的Python是/usr/bin/python3，结果Spark在Driver端序列化数据给Python worker时，Python worker起不来，任务卡死在报错里。解决方案就一行，在spark-env.sh里统一写死PYSPARK_PYTHON，并且确保每台机器都安装了同样的Python版本。

第二条是YARN模式下Executor被杀的场景。你的集群如果同时跑HDFS和YARN，YARN默认的内存限制上限可能比Executor默认请求内存小很多。这时即使Spark提交成功，Executor运行没几分钟就会被NodeManager强制杀掉，表现就是任务先跑后挂，日志里只有executor lost这种模糊信息。排查时先打开YARN ResourceManager的UI页面，看容器被kill的原因，再到NodeManager日志里搜索kill关键字，基本能定位到是内存超限。在yarn-site.xml里调大资源上限即可解决。

除此之外，我在排查过程的最后一步永远是去看日志，直接看Spark的日志文件，而不是只盯着控制台。控制台显示的往往是钝化的报错信息，真正的堆栈和第一次异常都在日志文件里。比如Executor反复启动失败，控制台只会告诉你“Executor lost”，但日志文件会具体到构造函数抛了什么异常、是哪段代码的问题。

7. 资源有限时的一些调优经验

个人集群的资源就那么多，如何在有限的内存、CPU下把Spark用得舒服，这里有不少技巧。

7.1 内存怎么分才不爆

我见过不少新手装完Spark，发现作业一跑机器就卡死。原因在于给Executor的内存设置太大，几个Executor同时申请内存，机器直接爆掉。

一个很实用的经验分配是：假设一台机器物理内存是16GB，操作系统和YARN的守护进程预留大约4-5GB，HDFS的DataNode大约1-2GB，剩下的内存才是Spark能用的。然后在这个可用内存范围内给Executor设置一个合理值。比如可用内存10GB，一个Executor设4GB，同时限制串行任务数，一台机器最多启动两个Executor。

这样做的原因是，Executor是JVM进程，除了堆内存，它还占用一部分堆外内存（元空间、网络缓冲区、序列化缓冲区等）。如果堆内存设到8GB，实际进程占用的物理内存可能超过11GB，多个Executor同时跑，机器内存就爆了。

实际改参数时，建议先用小数据量测试，观察各个Executor的内存使用曲线，再逐步上调。网上那些“一个Executor内存等于Worker总内存除以核数”的说法只适合理想情况，真实环境里要留出安全余量。

7.2 序列化、并行度与动态分配

序列化器我从第一天就改成了Kryo。在小数据集上感觉不明显，但数据量稍微大点，Kryo能比Java序列化减少不少内存占用和序列化耗时。在spark-defaults.conf里改一行即可：

spark.serializer org.apache.spark.serializer.KryoSerializer

如果你的Driver需要传输自定义类，可以开启类注册，但个人集群图省事的话，吧spark.kryo.registrationRequired设为false就行，Kryo会自动处理大部分类型。

并行度方面，Spark SQL默认的shuffle分区数是200。这个数是给大集群准备的，个人小集群跑两三百MB的数据，设置成200个shuffle分区意味着每个分区处理不到一两MB，大量的分区调度和网络传输开销会拖慢任务。我在小集群上通常把spark.sql.shuffle.partitions调整到20-50之间，任务明显轻快很多。

动态资源分配这个功能，默认是关的。网上很多教程推荐开启，说可以弹性伸缩Executor，但个人小集群一般不值得开。因为Executor的数量本身就少，反复启停Executor的过程反而增加任务提交时的延迟，而且Executor如果被回收，缓存在内存中的RDD数据也会失效，可能导致后续阶段重算。我的建议是保持关闭，让Executor在作业执行期间持续运行，充分利用那点可怜的内存。

日志级别也别忽略。Spark默认的日志是INFO，跑一次作业会刷出好几屏信息，既干扰视线又影响性能。把log4j的默认级别改成WARN，关掉那些琐碎的INFO输出，排查问题时如果需要细节再临时调回INFO。

cp conf/log4j2.properties.template conf/log4j2.properties # 修改 rootLogger.level 为 WARN

还有个我自己常用的性能观察方法：在Web UI里看Executor的Shuffle读写和GC时间。如果GC时间占了运行总时间的很大比例，说明堆内存或对象处理方式有问题，建议检查是否存在大量对象序列化或小对象创建。如果Shuffle读写量很大，则要优化JOIN或聚合操作的顺序，尽量在宽依赖之前做好数据过滤。

最后再分享一个小经验。Spark安装好之后，不要急着把生产数据都往集群里灌。先用几十MB的测试数据把整个链路跑通，包括HDFS读写、Standalone/YARN切换、History Server日志归档，全部验证稳定了，再逐步放大数据量。这样出了任何问题都能在小范围里定位，而不会在一堆复杂数据里追根溯源追到怀疑人生。我前几套集群翻车的案例，绝大多数都是因为还没验证完就急着上真实数据，结果一个小配置问题被放大了好几十倍。先把基础打牢，后面的事就顺了。