先说个让人又爱又恨的事实Spark的环境配置可能是大数据入门里劝退率最高的一步。不是它本身多难而是网上教程版本混乱JDK、Scala、Hadoop、Python各自为政照着某个教程配好了换个版本立刻翻车。这篇文章我尽量把为什么这么配讲清楚而不是只甩给你一串命令。你照着走完不只是能跑起来以后自己排查问题也有底气。1. 环境配置的本质先搞清楚Spark到底依赖什么很多人一上来就搜Spark安装教程然后被各种术语绕晕。其实你只需要想明白一件事Spark本身是一个用Scala写的计算框架它不存储数据、不管理元数据它只是算。所以它运行的时候必须有个地方放数据HDFS、S3、本地文件都行必须有一套资源调度自己带的Standalone、YARN、Mesos都行还必须有个Java虚拟机来承载运行环境。换句话说装Spark本质上是装一套JVM 调度器 存储 计算引擎的组合拳。1.1 为什么Spark不是一个安装包那么简单你去官网下载Spark拿到的其实是一个压缩包里面是编译好的二进制文件。但这个压缩包假设你机器上已经有JDKSpark的所有进程Driver和Executor都是JVM进程。Python如果你想用PySparkPySpark本质是Python进程通过py4j桥接调用JVM里的Spark核心。Hadoop客户端Spark读写HDFS时需要Hadoop的jar包和配置。注意从Spark 3.x开始官方预编译版本默认附带的是Hadoop 3.x的客户端库但如果你要连一个具体的Hadoop集群还是得保证版本兼容。所以你在网上看到的各种一键安装脚本本质是把上面这一串依赖按特定版本组合好再帮你把PATH写进shell配置文件里。我自己也写过类似的脚本给团队用但说实话如果是学习目的建议手动配一遍。手动配过的人才真正理解哪里出了问题因为后面你总会遇到新环境、新版本脚本帮不了你一辈子。1.2 常见安装方式的优劣对比先看一张表我自己的经验总结安装方式优点缺点适合场景手动下载解压灵活、可控性最强依赖要自己一个个装学习、理解原理包管理器如Homebrew/apt命令简单、自动处理依赖依赖版本被锁定快速试玩、不想折腾Docker镜像环境隔离、一键启动数据持久化需要额外配置避免污染本机、快速复现云服务商托管如Databricks零运维、开箱即用收费、学习成本在平台生产级项目、企业团队我见过太多人卡在docker run之后不知道怎么把数据传进去或者映射端口搞错了。如果你是想把基础打牢老老实实走手动路径。等你会配了再用Docker不迟。2. 版本选型这一步走错后面全是坑版本选型绝对是整个环境配置里最值得花时间想清楚的事。因为Spark的版本兼容性问题往往不会在启动成功时暴露而是在你跑某个算子、连接某个数据源时突然炸出来。那种半夜排查到凌晨两点的经历我太熟了。2.1 JDK版本怎么选结论先行Spark 3.2及以上版本直接上JDK 8或者JDK 17都行Spark 3.5以后已经完全兼容JDK 17。但如果你是Spark 2.x的老项目老老实实用JDK 8。很多人会问为什么不直接用最新JDK 21——因为Spark官方编译时没有对JDK 21做全面验证某些JDK内部API的变更会导致反射调用出错。这一点在分布式集群上特别明显你的Driver用JDK 21没事但某个Worker节点上的JVM版本不一致瞬间报一堆NoSuchMethodError。实操建议装两个JDK版本平时用8需要新特性时切17。Linux下用alternatives命令切换Windows下手动改JAVA_HOME就行。我个人在Mac上用的是jenv挺好用。2.2 Scala版本与Spark版本的绑定关系这一步是网上教程最不常讲、但坑最多的点。Spark 3.x默认绑定Scala 2.12但部分发行版是Scala 2.13二者完全不兼容。你下载Spark时的文件名就能看出来spark-3.4.0-bin-hadoop3.tgz是Scala 2.12的默认版。如果你要自己编译插件、或者用特定功能的第三方库得确认你的jar包是哪个Scala版本编译的。SCALA版本不同哪怕源码一模一样编译出来的jar包字节码都是不兼容的。这方面容易被忽略的场景是你用Maven或SBT写Spark应用时pom.xml里的scala-library依赖版本必须和Spark带的Scala版本一致。否则本地编译通过丢到集群上跑直接ClassNotFound。2.3 Hadoop版本与Spark预编译版本的对应关系这里我单独拎出来说因为太多人栽在这里。Spark官方下载页有多个预编译版本Spark for Hadoop 3.3当前主流推荐Spark for Hadoop 2.7老集群用户才需要假如你本地没有装Hadoop只是用local模式测试选哪一个其实区别不大。但如果你要连接公司的HDFS集群不匹配就会在读写文件时报错报错信息里通常会带UnsupportedOperationException或者直接的FileSystem相关异常。2.4 推荐的一套稳定组合我按照学习不折腾、工作够用的标准给你一套我个人实测半年没出问题的组合组件推荐版本说明JDK8或178最稳17性能更好Python3.8~3.10不要用3.11以上的版本跑PySpark部分API兼容存在问题Spark3.4.x3.x的稳定版兼容性好Hadoop3.3.x选Spark预编译版时对应Hadoop3即可Scala2.12Spark自带写业务代码时注意版本对齐3. 手动安装实操从零开始跑通Local模式现在进入实际操作环节。我以Linux/macOS为主要环境Windows用户我会标注差异。这套流程我自己走了无数遍每台机器上重复一样的事情闭着眼睛都能写出来但你跟着做时会发现很多细节是教程没有的。3.1 JDK安装与环境变量配置安装JDK8以OpenJDK为例。Linux下用apt/yummacOS下用HomebrewWindows下下载安装包即可。这一步一般不复杂关键是环境变量# Linux/macOS编辑 ~/.bashrc 或 ~/.zshrc export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 # 把这个路径改成你自己的 export PATH$JAVA_HOME/bin:$PATH# 验证 java -version重点来了务必检查一下有没有别的软件比如系统自带的jre把java这个命令指向了别的路径。我碰到过很多次which java显示的是/usr/bin/java但这个其实是旧版本而JAVA_HOME指向新版本——最后跑Spark时用的JVM和你想的不是同一个。Windows下的环境变量去系统属性里设置记住JAVA_HOME不要带bin后缀PATH里加%JAVA_HOME%\bin。3.2 Spark本体下载与目录规划这一步我给你一个建议不要把所有东西都堆在/root或用户目录下规划一个大数据软件目录。# 我一般习惯放在 /opt/bigdata 下 mkdir -p /opt/bigdata cd /opt/bigdata # 下载Spark以3.4.0为例注意对应Hadoop版本 wget https://archive.apache.org/dist/spark/spark-3.4.0/spark-3.4.0-bin-hadoop3.tgz # 解压并重命名 tar -zxvf spark-3.4.0-bin-hadoop3.tgz mv spark-3.4.0-bin-hadoop3 spark-3.4.0为什么推荐用archive.apache.org而不是dlcdn.apache.org因为归档站点的版本是永久保留的dlcdn上只保留最新版本你以后想复现某个旧环境时归档站点是救命稻草。3.3 Spark环境变量配置export SPARK_HOME/opt/bigdata/spark-3.4.0 export PATH$SPARK_HOME/bin:$PATH # 如果你想在Jupyter里用PySpark还需要设置这个 export PYTHONPATH$SPARK_HOME/python:$SPARK_HOME/python/lib/py4j-0.10.9.5-src.zip:$PYTHONPATH注意上面的py4j-0.10.9.5-src.zip这个文件名在不同Spark版本里可能不同。你实际用的时候先ls $SPARK_HOME/python/lib/看一眼文件名再复制。有一个隐藏的功能是$SPARK_HOME/conf/spark-env.sh。这个文件默认不存在需要从模板拷出来。在里面你可以设置JAVA_HOME、PYSPARK_PYTHON等这些设置比shell环境变量优先级更高而且会随Spark的启动脚本自动加载不会污染全局环境。cd $SPARK_HOME/conf cp spark-env.sh.template spark-env.sh # 打开编辑添加 export JAVA_HOME/path/to/your/jdk export PYSPARK_PYTHON/usr/bin/python3这里有个小细节值得多说两句如果你只配了PYTHONPATH没有在spark-env.sh里指定PYSPARK_PYTHON那么pyspark脚本会去PATH里找python找到的可能是系统的python2如果你机器上还有老版本的话大概率报语法错误。我一再跟新人强调spark-env.sh才是Spark自己的环境门户shell里的环境变量只是帮忙传递。3.4 验证安装pyspark和spark-shell# 如果刚才的配置生效你应该能看到一个交互式SPARK命令行 pyspark进入pyspark后会有SparkSession的logo打印出来。那一瞬间很有成就感。但这只是开始——你需要真正跑一个任务来验证计算能力# 在pyspark交互式shell里输入 df spark.createDataFrame([(1, a), (2, b), (3, c)], [id, name]) df.show()如果这个能正常输出三行数据说明local模式已经跑通了。第一次启动可能会有些日志中间夹着WARN比如NativeCodeLoader: Unable to load native-hadoop library这个可以先忽略不影响功能后面针对HDFS时再处理。3.5 内存与Executor配置初探这里说个新手最容易懵的配置项。你用local模式跑任务时Spark默认只使用本机一半内存。如果你的机器只有8GB内存那Spark能用的就只有4GB跑稍微大一点的数据集就OOM。spark-env.sh里可以设置export SPARK_WORKER_MEMORY4g # 仅Standalone模式生效但local模式下真正控制堆内存的是spark.driver.memory和spark.executor.memory需要写在代码里或者spark-defaults.conf里。建议一开始就在conf/spark-defaults.conf.template拷贝出来的配置文件里写上spark.master local[*] spark.driver.memory 2g spark.executor.memory 2g spark.serializer org.apache.spark.serializer.KryoSerializerlocal[*]的意思是用所有CPU核心跑local任务*可以换成数字来限制。4. 进阶配置读取JSON与Noetbook环境整合环境能跑通只是第一步你真正做数据分析时至少会碰到两个躲不开的需求读取JSON文件、在Notebook里交互式分析。这两个需求如果不提前配好你会在项目中期突然卡壳。4.1 Spark读取JSON格式与配置的关键点Spark读JSON就是一行代码df spark.read.json(path/to/your/file.json)但现实往往没这么简单。我帮你梳理三个高频问题问题一日期格式不一致。Spark的JSON解析器会用默认格式推断如果你的日期字段是2024-01-01 10:30:00这种字符串Spark可能把它识别成string而不是timestamp。解决办法是在读的时候强制指定schemafrom pyspark.sql.types import StructType, StructField, StringType, TimestampType schema StructType([ StructField(id, StringType(), True), StructField(event_time, TimestampType(), True) ]) df spark.read.schema(schema).json(path/to/file.json)显式指定schema还有一个好处——避免Spark推断带来的额外扫描开销。数据量大时不指定schema会让Spark先完整扫一遍文件来推断类型时间成本能翻倍。问题二JSON里嵌套结构。读进来之后嵌套字段会变成StructType。如果你想要扁平化用select(字段.*)或者withColumn配合col(a.b)访问。这里有个from_json和to_json的用法常用于处理Kafka里的消息建议提前熟悉。问题三多行JSON文件。如果你的JSON文件是每行一个JSON对象JSON Lines格式那Spark默认就能读。但如果你拿到的是传统的多行美化JSON需要加一个选项df spark.read.option(multiline, true).json(path/to/multi_line.json)这个选项我第一次没注意花了一整个下午查为什么解析出来的数据全是null最后发现是文件格式问题而不是代码问题。4.2 在Jupyter Notebook里用PySpark很多人的习惯是先在Notebook里做数据分析验证再打包成正式作业。这个流程很合理但前提是Notebook能正常用Spark。方式一使用findspark。在Python脚本里走一个初始化步骤import findspark findspark.init(/opt/bigdata/spark-3.4.0) import pyspark from pyspark.sql import SparkSession spark SparkSession.builder.appName(notebook).getOrCreate()用findspark的好处是不依赖你shell里配置的SPARK_HOME适合多版本切换的场景。我认识的一些数据工程师会在不同的Notebook里测试不同Spark版本这个方法很实用。方式二配置pyspark内核。创建一个IPython kernel spec启动时自动设置环境变量和SparkContext这种方式会让Notebook一打开就能直接使用spark变量。要配置的话执行python -m ipykernel install --user --name pyspark --display-name Python (PySpark)然后修改对应的kernel.json文件加入环境变量配置。这种方式一劳永逸适合每天都要用Spark的人。4.3 PyCharm与VSCode里的远程调试配置最近的搜索热词里出现了很多vscode配置python开发环境、pycharm配置python环境这类词。确实日常数据分析不只是在交互式环境里你还需要一个像样的IDE来写复杂逻辑。VSCode里配置PySpark主要解决两件事代码提示和远程解释器。如果你是在本机跑local模式直接在设置里指定Python解释器为你的Python3路径即可VSCode会自动识别PySpark。如果你是在远程服务器开发需要一个SSH Remote插件把远程的Python解释器和本地目录映射过来。这样你在本地写的代码可以直接调用服务器的Spark。这里有一个细节坑远程服务器上的Python路径和你本地的可能不同你需要在VSCode的settings.json里明确指定远程解释器的路径不然Python扩展会自动选一个默认的大概率不是你想用的Python。{ python.defaultInterpreterPath: /usr/bin/python3, python.terminal.activateEnvironment: false }还有activateEnvironment这个设置如果你远程服务器上配了condaVSCode终端会默认激活conda基础环境导致你实际用的Python和settings里指定的不一致。实测关掉它能少掉很多诡异的问题。5. 环境验证与性能初步优化环境配好了别急着开始写业务逻辑。建议按下面的顺序做一轮体检确认每个环节都是通顺的。这能帮你把环境问题和业务问题清楚分开后面排查时不会两头乱。5.1 用Spark自带的示例Job做端到端验证Spark自带了一个计算Pi的示例作业这个是我最推荐的体检工具。cd $SPARK_HOME ./bin/spark-submit \ --class org.apache.spark.examples.SparkPi \ --master local[*] \ examples/jars/spark-examples_2.12-3.4.0.jar 10参数说明最后一个10是并行度意思是要生成10个分片来计算Pi的近似值。正常跑完后你会在日志里看到一行Pi is roughly 3.142857142857142857这个结果因为是随机采样每次会稍微不同但大致应该在3.14左右浮动。如果这个能跑通说明JVM、Spark核心、资源分配全都正常。5.2 用一个小型分析任务测试完整流程我的习惯是跑一个读-算-写的闭环。比如从CSV读数据做groupBy写入JSONfrom pyspark.sql import SparkSession from pyspark.sql.functions import count, avg spark SparkSession.builder \ .appName(sanity_check) \ .getOrCreate() # 构造一个简易数据集 data [(A, 1), (A, 2), (B, 3), (B, 4)] df spark.createDataFrame(data, [key, value]) result df.groupBy(key).agg(count(value).alias(cnt), avg(value).alias(avg_val)) result.show() result.write.mode(overwrite).json(/tmp/test_spark_output)这个流程虽然简单但验证了三个核心环节DataFrame创建、算子执行、结果写入外部存储。5.3 初步内存配置的优化建议内存配置是Spark环境配置里最玄学的部分很多人喜欢背一个公式——Executor内存 堆内存 * (spark.memory.fraction) * (spark.memory.storageFraction)。背公式没问题但得理解背后的权衡。核心矛盾Spark内存分为Storage和Execution两部分。Storage用于缓存数据Execution用于shuffle、join、aggregate时的中间结果。Spark 3.x开始统一内存管理意味着两者可以互相借用。所以你会发现单纯调大spark.executor.memory并不一定带来性能提升——如果Execution阶段压力大Storage部分被借用后续读取缓存数据时可能反而要重新计算。我的经验当你资源有限时比如本地8G内存优先保证Driver有足够内存来承接Driver端的collect和广播变量Executor内存够跑任务不OOM就行。这种情况下设spark.driver.memory3g、spark.executor.memory3g剩下的留给操作系统。生产环境里更复杂的memory tuning留给后续系列文章单独讲这里只是提醒你环境配置阶段不需要过度调优能稳定运行就是胜利。6. Windows环境下的特殊问题现在用Windows做大数据开发的人其实越来越多。虽然官方对Windows的支持没有Linux好但配好之后体验确实不错。这里单独拎一节讲讲Windows下独有的坑。6.1 PATH格式与Shell差异Windows环境变量用分号分隔不是冒号路径反斜杠不是正斜杠。这个说多了都是泪JAVA_HOMEC:\Program Files\Java\jdk1.8.0_202 SPARK_HOMED:\bigdata\spark-3.4.0千万别把反斜杠写漏了尤其SPARK_HOME结尾不要带\不然你拼路径时会出现D:\bigdata\spark-3.4.0\bin\\这种双斜杠。另外PowerShell的设置变量语法和CMD的setx完全不一样。很多教程用的是CMD你在PowerShell里照抄就报错。PowerShell里应该[Environment]::SetEnvironmentVariable(SPARK_HOME, D:\bigdata\spark-3.4.0, User)这一步很多人不知道会在PowerShell里用$env:SPARK_HOME...但这个只是会话级别的重启终端就丢了。6.2 winutils.exe与Hadoop客户端Windows下跑Spark读取本地文件系统有个老大难问题。Spark的Hadoop客户端会试图通过NativeIO访问Windows文件系统但Hadoop本身没有Windows原生实现所以程序会报一个Failed to locate the winutils binary in the hadoop binary path的错误。解决办法下载一个对应版本的winutils.exe放到HADOOP_HOME/bin下顺便加一个HADOOP_HOME环境变量。这个winutils网上有很多repo专门收集你可以搜winutils加hadoop版本号放到你本地Hadoop目录里去。重要提示这个错误一般不影响local模式下的纯Spark操作但一旦涉及写入HDFS或者某些文件系统API调用就会爆炸。所以建议Windows用户还是配一下一劳永逸。6.3 Windows下pyspark的Python路径配置Windows经常装多个Python微软商店版、Anaconda版、官网定制版。这种情况下的一个坑是pyspark去找Python的时候不是直接用你PATH里那个而是可能命中Windows应用商店的stub路径。推荐做法是明确指定Python执行文件# 设置环境变量 PYSPARK_PYTHONC:\Users\yourname\anaconda3\python.exe PYSPARK_DRIVER_PYTHONC:\Users\yourname\anaconda3\python.exe如果你用的是Notebook做开发注意区分PYSPARK_DRIVER_PYTHON。如果设成了jupyterpyspark会直接启动Jupyter Notebook而不进入pyspark shell。这个很多人会忘记清掉旧设置造成各种困惑。7. 常见问题排查实录与速查表这部分是我最想写的因为这些坑我基本全踩过。每次帮助同事解决完问题我都会记一下诊断思路。这里整理最典型的几类按症状 → 原因 → 解法给你梳理一遍。7.1 启动即报错类症状可能原因排查与解决java.lang.NoClassDefFoundErrorJDK版本与Spark不兼容检查java -version确认JAVA_HOME指向正确Python in worker has different version than driver各节点/进程使用的Python不一致统一设置spark-env.sh里的PYSPARK_PYTHON确认所有节点Python版本一致Failed to locate the winutils binaryWindows下缺少Hadoop本地库下载对应版本的winutils并设置HADOOP_HOMEUnable to load native-hadoop libraryHadoop原生库缺失Linux常规问题可忽略如需消除设置-Djava.library.path指向libhadoop.so所在目录Exception: Java gateway process exitedPySpark的JVM在启动时崩溃或无法找到Javaexport JAVA_HOME检查内存是否足够查看logs下的异常Java gateway process exited这个错误值得展开讲。PySpark的原理是Python进程启动一个子JVM进程通过socket通信。所以当你看到这个报错时问题往往出在JVM启动失败而不是Python端。排查顺序是先手动跑java -version看JVM是否正常再看看Spark日志里JVM崩溃的异常栈。7.2 运行中报错类OutOfMemoryError最常见的原因是Executor堆内存不够或者spark.memory.fraction设置不当。如果你是在local模式下优先调spark.driver.memory。如果你在集群模式单独调spark.executor.memory可能不生效因为YARN或Standalone的资源配置会限制上限。Shuffle file not found这个报错在集群跑大任务时特别容易出现让人以为磁盘坏了或者网络断了。但很多时候是Executor被Kill后其他任务还在寻找它的shuffle输出。这种情况下先看是不是有节点OOM被驱逐而不是一上来就检查磁盘。SparkSession或SparkContext已经存在你在同一个Python进程里多次创建SparkSession时常见尤其在使用Notebook时。解决方法是先spark.stop()再重新创建或者用SparkSession.builder.config(spark.driver.allowMultipleContexts, true)允许存在多个SparkContext不推荐只是应急用。7.3 配置优化与陷阱不要随便改序列化器。Spark默认的JavaSerializer虽然性能一般但稳定可靠。KryoSerializer更高效但如果你有自定义类没有注册会报ClassNotFoundException或者序列化异常。我的建议是环境配置阶段不要改等业务代码稳定后再考虑切换。不建议在spark-defaults.conf里写死spark.master。如果写死了你的代码里设置master会失效。尤其是你有时候临时想用local模式测试代码里写了setMaster(local[*])根本不生效——因为defaults文件里配置的master优先级更高。我一般只在spark-submit命令行里指定master代码里统一通过环境变量或args传入。7.4 排错思路总结后面你跟Spark打交道的每一天都会踩新的坑。我分享三个通用的排错步骤算是压箱底的经验看日志别猜。Spark打到控制台的WARN大部分无害但ERROR后面一定跟着异常栈从最底部往上找Caused by。真正的原因往往在日志最末尾那几行。先确认环境再怀疑代码。项目里某段代码昨天还跑得好好的今天突然挂了大概率是某个节点环境变了。先检查内存、磁盘、JDK版本再回头看代码。善用Spark UI。启动后访问http://localhost:4040里面有Jobs、Stages、Storage、Executors标签页。哪个Stage失败了、Executor是不是OOM了在这里一目了然。这是我排查问题的第一落脚点。8. 从单机到集群环境配置的思路升级单机环境配好后下一步大概率是搭集群。虽然Spark集群搭建是另一个更大的话题但这里先说说思路上的区别帮你做个心理建设。8.1 单机与集群的本质差异单机local模式用local[*]所有进程都在一个JVM里。集群模式则是Driver进程在提交任务的机器上Executor分散在多台机器上彼此通过网络通信。这个差异带来三个新问题网络是瓶颈同一份数据本地跑和跨节点跑性能完全不一样。环境一致性很关键每台Worker节点上的Java、Python、Spark版本必须一致否则你会看到各种诡异的序列化错误。资源归谁来管YARN、Kubernetes还是Standalone选择不同调度器Spark的部署方式参数就不同。如果你是从单机直接跳到集群我建议先别急着上YARN。先用Standalone模式把Spark自己的调度跑熟再换YARN。因为Standalone的架构更清晰Master-Worker逻辑上更好理解排障时也不用同时面对YARN和Spark两层问题。8.2 环境同步的最佳实践集群环境同步是最烦人的运维工作。手动登录每台机器装JDK、配环境变量不仅效率低而且容易出错。几个可行方案配置管理工具Ansible或者SaltStack写一个playbook在每台机器上执行同样的事。这个方案我强烈推荐哪怕只有两三台机器也能帮你省下大量重复劳动。镜像文件如果你用虚拟机或云主机直接创建好一个配好环境的镜像批量部署时用镜像创建新实例。共享文件系统把Java、Spark这类软件安装到NFS或集群共享存储上每台机器通过软链接访问。这个适合机器多、追求极致一致性的场景。8.3 集群环境下的常见坑坑一hostname与IP映射不完整。Spark的Master和Worker通信基于主机名如果/etc/hosts里没配好各节点的主机名和IP映射你会在日志里看到Connection refused或者注册超时。坑二SSH免密登录没配好。使用sbin里的start-all.sh脚本时Master会通过SSH登录到各Worker启动进程如果免密没配脚本就卡在那里不死不活。坑三每个Worker的本地存储空间不一致。Spark会在spark.local.dir指定的位置写shuffle临时文件如果你在各节点配了不同的目录且某个目录空间不足就会出现部分Executor反复失败的诡异现象。这些坑都属于不遇到不知道遇到了查半天的类型。我按自己踩过的顺序排了优先级你搭集群前先检查第8.3节这几项能提前躲开至少一半的问题。集群搭建的完整流程我计划放到本系列的第三篇详细展开这里先把单机环境的底子打好。最后分享一个实际工作中的小技巧环境配置说到底就是一个版本匹配的游戏。我前前后后给十几台机器配过Spark刚开始也踩坑后来养成一个习惯每配好一个环境立刻在本地记一份环境清单精确到jar包的版本号、Python解释器的路径、关键配置项的最终值。这看起来像个笨办法但后面做项目、帮别人排查、升级版本时这份清单的价值比任何教程都大。另外我强烈建议你养成看官方文档的习惯。Spark的版本更新很快网上大部分教程都是过时的你要学会在官方的Migration Guide里找版本间差异。环境配置这种问题官方文档里几乎全有答案只是信息比较分散很多人懒得翻而已。你在安装过程中遇到的一切报错几乎都可以从官网的文档里找到对应说明前提是耐心搜索。误配的坑都是让自己长记性的。我这个系列会持续更新下一篇我准备写Spark数据分析的入门操作细节从RDD和DataFrame的区别开始讲到常见的ETL操作。配置环境只是第一步真正的好戏在后面。
