好多新手第一次接触Spark都会有个困惑Spark不是说是“Hadoop的替代品”吗怎么讲课的时候又说Spark跑在Hadoop的HDFS上这个认知如果不掰扯清楚后面所有入门操作都会带着偏见去做很容易踩坑。我先给一个直观结论Spark和Hadoop不是同一个层面的东西。Hadoop是一个生态里面包含分布式文件系统HDFS、资源调度器YARN、计算框架MapReduce。Spark在计算框架这个位置上对标的是MapReduce而不是整个Hadoop生态。所以你会看到Spark任务经常从HDFS上读数据、跑到YARN上这完全不矛盾反而是主流用法。那Spark为什么能替代MapReduce成为事实上的标准计算引擎一句话MapReduce把中间结果一次一次往磁盘写而Spark可以把它留在内存里。但这里有个特别容易误导人的地方“内存计算”不是说所有数据都堆在内存里跑而是指中间结果尽可能不落盘。MapReduce的Map阶段输出的中间结果要写磁盘Shuffle的时候还要再来一次落盘和网络传输每一步都是几十上百MB的序列化和磁盘IO。Spark做了一次重大简化把计算过程抽象成一个有向无环图也就是常说的DAG把一个任务所有算子的执行计划画成一幅图能流水线执行的算子直接在内存里连续算完只有在需要重新分区也就是Shuffle的时候才不得不落一次盘。光是这一个改变实际业务场景里Spark和MapReduce放在一起横向对比通常就能快上几倍到几十倍。再说RDD这是Spark最核心的数据抽象。它的名字是“弹性分布式数据集”拆开来看分布式数据被切分成多个分区Partition分布在集群不同节点上数据集你可以把它理解成一组分布式对象的集合像Scala里集合那样操作弹性内存不够了可以从磁盘恢复、自动重算不会因为某个节点挂了就整个任务完蛋RDD里最有价值的设计是Lineage血缘机制。这个机制有点像一个“数据族谱”每个RDD记录着自己是从哪个父RDD通过哪个算子算出来的。一旦某个分区的数据丢失或者负责计算的Executor挂掉Spark不需要从源数据全部重读只需要根据血缘关系从上一个能用的父RDD开始重算丢失的那部分。这种“偷懒式容错”比MapReduce把整条链重跑一遍效率高太多了。所以入门Spark的第一件事别急着装环境先把“Spark 内存优先 DAG调度 RDD血缘容错”这个三角形记在心里后面学任何组件都会顺很多。1.1 Spark的完整生态不只是批处理很多教程会告诉你Spark是“统一大数据引擎”然后硬塞给你一长串名词Spark SQL、Spark Streaming、MLlib、GraphX。你第一次看到可能会头大但说白了就四件事Spark SQL用SQL或DataFrame处理结构化数据Spark Streaming做准实时流计算MLlib分布式机器学习算法库GraphX图计算刚入门不用每个都摸一遍。我的建议是先吃透Spark SQL再有余力看StreamingMLlib和GraphX知道有这么个东西就行。实际工作里开发一个离线数仓任务90%的时间都在写Spark SQL和DataFrameRDD那种底层的写法反而用得少。这个点我后面专门有一节讲。1.2 一次Spark任务是怎么被执行的理解了抽象概念还需要在脑子里建立一个简单的执行模型。一次提交上去的Spark作业大概会经历这么几步客户端通过spark-submit提交任务启动Driver进程Driver根据代码构建DAG调度图然后在宽依赖处把图切分成多个Stage每个Stage会生成一批Task分发给集群里的Executor去执行Executor从HDFS或本地文件系统读数据完成计算后把结果写回存储系统这一步里最重要的是“Driver”这个概念。它是整个作业的“大脑”负责任务切分、调度和汇总。新手调试时经常会发现日志里有大量Driver的报错或者看到某个节点上Driver挂掉了导致整个应用失败就是因为没理解Driver和Executor是主从关系Driver没了整个Application就完蛋。2. 搭建集群前先想明白部署模式Local、Standalone还是YARN说到安装和集群搭建网上教程一抓一大把大多数都直接甩命令跟着敲完能启动但换个环境就抓瞎。我觉得入门阶段最重要的是先搞清楚“部署模式”这个选择题因为选错了模式后面所有问题排查方向都会跑偏。Spark支持四种部署方式部署模式定位适用场景Local本机单进程模拟开发调试、入门学习StandaloneSpark自带的独立集群学习、中小集群、不想引YARNYARN跑在Hadoop资源调度器上生产环境最主流Kubernetes容器化方式运行云原生环境新手入门推荐先玩Local因为Spark目录里自带一个local模式什么都不用配在IDE里写个main函数指定local[*]就能跑。这里有个小陷阱local[*]里的星号表示使用本机全部可用CPU核数如果你的开发机是8核16线程那它会用16个并发来跑有时候会让你误以为自己代码写得很好其实是机器猛。真调试的时候建议先指定local[2]这种较小的并发便于看日志和定位问题。2.1 Standalone集群搭建一个最少可行的实例如果要从单机跨到集群我建议先搭一个Standalone模式。不是因为它生产可用而是因为它最简单能帮你把Master、Worker这两个角色理解透。假设你有三台Linux服务器一台叫node01另外两台叫node02、node03。规划如下node01Master Workernode02Workernode03Worker标准的安装流程大致是这样三台机器统一配置JDK8或JDK11配置好SSH免密登录下载Spark安装包选带Hadoop版本的比如spark-3.5.x-bin-hadoop3解压到/opt/spark修改conf/spark-env.sh设置JAVA_HOME修改conf/workers文件把node02、node03这两行写进去在node01上执行sbin/start-all.sh启动访问node01:8080能看到Web UI里列出了三台Worker的信息就算搭建成功有几个常见的坑我在搭建的时候都踩过写在这里目录权限Spark在Worker节点上要写临时文件和日志如果用root用户启动后面换成普通用户跑任务经常各种Permission denied。最好从第一步就让所有节点用同一个非root用户操作。hostname问题集群里机器之间的通信默认用主机名识别/etc/hosts里必须把三台机器的IP和主机名写全。我有一次漏配了一行结果Spark任务卡在连接Executor的阶段日志翻半天才看到是DNS解析不到。版本匹配本地开发用的Scala版本和Spark编译的Scala版本最好一致比如Spark 3.5内置Scala 2.12/2.13要去看bin包的说明否则SDK依赖冲突能折腾一下午。2.2 部署模式选择的实际建议看到这里你可能会问搞了半天这才是Standalone生产环境不是都用YARN吗没错所以我把YARN单独放了一节。但在那之前先给一个选型上的总体建议个人学习、跑DemoLocal就够不要为了显得专业硬搭三台云主机公司内部有Hadoop平台直接用YARN模式资源和权限统一管理不要自己另起炉灶如果是云原生架构Kubernetes模式是未来但对入门者来说前提是你先懂K8s否则排查问题会叠加两层复杂度还有一个重要心态部署模式的选择是为了让业务跑得更稳不是为了炫技。我就见过有人把Spark部署在Docker容器里容器一重启所有节点全部丢失还坚持用结果每次跑任务前先花一小时恢复环境。这种“先进”不要也罢。3. Spark on YARN的CPU只用1个核根因在Executor核心数配置这个问题的完整表述经常在搜索引擎和面试题里出现“在某些Spark作业中Executor在YARN上运行时每个Container只分配一个vCore这是为什么”好多人的第一反应是“YARN资源分配有问题”其实绝大多数情况YARN背不了这个锅。真正的根因是Spark作业自身申请资源的参数没有配明白。先理解YARN和Spark的关系。Spark任务要跑在YARN上YARN的资源分配单位是ContainerContainer里有CPU和内存配额。Spark在启动时会向YARN申请一批Container来当Executor申请多少个、每个多大完全由Spark的提交参数决定YARN只是按需求分配而已。3.1 从1个vCore到多核参数链条拆解看几个关键参数参数默认值含义spark.executor.cores1每个Executor占用几个CPU核心spark.executor.instances2运行多少个Executorspark.task.cpus1每个任务占用几个核心spark.default.parallelism无默认分区数如果你只是执行一个默认配置的Spark作业每个Executor的cores就是1。这时候每个Executor同一时刻只能并行跑一个Task哪怕你一个Job里有1000个分区并发度也只是Executor的数量乘以1。并发度低CPU利用率当然起不来看起来就像“CPU只能用1个”。那怎么解决可以从两个层面调整Spark作业层面在提交命令或spark-defaults.conf里显式设置spark.executor.cores比如设成4或者6。这时候每个Executor会向YARN申请对应的vCore数量。YARN调度器层面YARN的容量调度器Capacity Scheduler里有两个全局参数决定了单个Container能申请的最大资源yarn.scheduler.maximum-allocation-vcores单个Container最多能申请多少vCore默认是32yarn.scheduler.maximum-allocation-mb单个Container最多能申请多少内存如果集群管理员把最大vCore限制调得很小比如4那你即使设了spark.executor.cores8YARN也会把申请压到4而且不会报错。很多“为什么我配了没效果”的情况都出在这里查的时候要两头一起看。再说一个额外细节spark.cores.max这个参数用来限制整个Spark Application最多能使用的总核数。在YARN模式下如果你只设置了每个Executor的cores但忘了设置spark.executor.instances那Spark会根据spark.cores.max来推算Executor数量比如总核数12、每个Executor 4核那就启动3个Executor。如果你开了动态分配spark.dynamicAllocation.enabledExecutor数量会被框架动态伸缩手动指定的spark.executor.instances就变成了初始值这种情况另当别论。这里有一个调优经验不要把spark.executor.cores设得过高。集群上还有别的任务在跑一个Executor如果占8个甚至更多核心GC停顿和调度延迟都会被放大而且Executor异常后分批重启的成本也高。我在生产中一般习惯单选5或6配合spark.executor.instances控制总规模既能保证并发度又不至于拖垮整个集群。3.2 一个真实的排查链路最后分享一次我遇到过的现场。有一回同事提交任务日志里看到每个Executor都是1个vCore他第一个动作就去翻YARN的capacity-scheduler.xml把maximum-allocation-vcores从8改成32然后重新提交结果还是1。我帮他查了两步先看Spark UI的Executors页面发现Executor数量是5个每个内核栏显示1。这说明Spark这边确实没有申请多核。再翻提交命令发现他压根没传--executor-cores也没有在spark-defaults.conf里配置spark.executor.cores。把参数补上、重新提交之后同样是5个Executor每个4核任务运行时长从42分钟降到了11分钟。CPU从“只能用1个”变成“能用4个”差的不是一点半点但根因既不神秘也不复杂就是配置缺失。排查这类问题的通用顺序我总结一下先看Spark UI的Executors页确认申请了多少Executor、每个几核再确认提交参数有没有带--executor-cores和--executor-memory如果带了但没生效再去看YARN调度器的单Container上限最后确认机器本身的CPU核数、物理资源是否充足4. Spark内存模型Executor里的内存到底分给谁了Spark内存这块是入门阶段公认最难啃、也最容易被面试官问倒的地方。我先给你一个画面你在YARN上申请了一个2GB内存的Executor Container但Spark进程真正能用的不是全部2GB它要先预留一部分给JVM运行剩下的才切成几块干不同的活。从Spark 1.6之后引入的是统一内存模型Unified Memory Management。Executor的JVM堆内存大致分成三块内存区域默认占比用途Reserved Memory300MBSpark内部对象、元数据等固定预留User Memory1 - spark.memory.fraction用户自定义数据结构、RDD存储用户代码里的对象Spark Memoryspark.memory.fraction默认0.6Execution计算和Storage缓存共用如果你用默认配置给一个1GB的Heap那么Reserved Memory300MB剩余可用1024 - 300 724MBSpark Memory724 × 0.6 ≈ 434MBUser Memory724 × 0.4 ≈ 290MB从这就能看出来真正给Spark计算和缓存用的其实只有堆内存的六成左右并没有很多人想的那么多。4.1 Execution和Storage内存的动态抢占机制Spark Memory内部又分成Execution和Storage两半默认spark.memory.storageFraction0.5也就是各占一半。但它的精妙之处在于这两块内存可以互相借用不是死板地各管各Storage主要用来放缓存的数据比如persist()、cache()的那些RDD、DataFrameExecution主要用来放Shuffle过程中的临时数据、Join和聚合的操作缓冲区当Execution内存不够用时它可以从Storage那边借反过来当Storage需要缓存数据但空间不足时也可以驱逐EvictExecution占用的内存——除非那块Execution内存正在被Shuffle数据锁定这时候缓存数据会写落到磁盘。这个动态抢占机制是很多人忽略的重点也是“Spark到底怎么决定什么时候溢写磁盘”的核心判断逻辑。搞懂它你才能解释为什么某些任务明明设置了很大的spark.executor.memory却仍然频繁Spill到磁盘作业跑得巨慢。4.2 常见的内存相关配置和OOM问题入门阶段最常遇到的内存错误无外乎两种。第一种是堆内OOM报错通常是OutOfMemoryError: Java heap space。这种最常见的原因是spark.executor.memory给小了或者某个算子的结果集特别大。初级解决办法是加内存但加内存前最好先确认数据是否均衡是不是某个分区数据特别大也就是数据倾斜如果是加内存只是增加了容忍度治标不治本。第二种是堆外内存超限报错通常是类似Container killed by YARN for exceeding memory limits。注意这个不是JVM堆OOM而是YARN检测到整个进程的物理内存占用超过了申请时指定的spark.executor.memory加spark.executor.memoryOverhead的总和。很多新手一看到这个报错就在Spark里调大内存其实更应该关注spark.executor.memoryOverhead它默认是executor内存的10%或384MB中取较大值。如果你的任务做大量序列化或第三方库申请了原生内存这个overhead不够用就会被YARN直接杀容器。再补充一个知识点DataFrame和Dataset的内存管理默认走的是Tungsten它用了基于内存的二进制格式来存储数据会把对象布局优化成紧凑的列式格式大幅减少JVM对象头和GC压力。这也是为什么Spark官方一直建议能用DataFrame就别写RDD操作底层省下来的内存是实实在在的。5. Spark SQL实战用一套API搞定数据分析前面说了那么多概念现在说点能直接上手的。Spark SQL是Spark生态里使用频率最高的组件也是入门阶段最快能出成果的方向。它最大的价值在于让你用写SQL的方式操作分布式数据不暴露复杂的RDD转换逻辑。举一个很常见的例子假设有一份电商订单明细字段包括order_id, user_id, amount, category, create_time除了数据量大之外这个Schema和MySQL里的表几乎没区别。用Spark SQL处理它代码大概长这样val spark SparkSession.builder() .appName(OrderAnalysis) .master(local[*]) .getOrCreate() val df spark.read.option(header, true).csv(/data/orders.csv) df.createOrReplaceTempView(orders) val result spark.sql( SELECT category, count(*) AS order_count, round(sum(amount), 2) AS total_amount, round(avg(amount), 2) AS avg_amount FROM orders WHERE create_time 2024-01-01 GROUP BY category ORDER BY total_amount DESC ) result.show()这段代码里工作流就四步创建SparkSession、读数据成DataFrame、临时注册成表、写SQL。SparkSession是Spark 2.0之后的统一入口一个程序里只应该创建一次不要每个方法里都new一个这不是Java Bean。5.1 DataFrame vs RDD到底该用谁很多刚入门的人会纠结既然RDD是核心为什么大家都让我用DataFrame因为DataFrame在RDD之上加了一层Schema信息让Spark知道每一列的类型。这个信息的价值在于优化引擎Catalyst可以对SQL做逻辑优化Tungsten可以做物理优化最终生成的执行计划比RDD硬算高效得多。用一个不恰当的比喻RDD像是在仓库里一个个散装的麻袋你得自己拆、自己看标签DataFrame像是装好的周转箱标签写着里面是什么仓库系统可以自动规划怎么摆放最省空间。所以Spark官方和社区都默认DataFrame/Dataset优先只有在做非常底层的、Schema不固定的处理时才考虑RDD。5.2 数据分析案例的完整闭环上面那段代码只完成了“查询”一个完整的数据分析任务往往还包括结果落库和资源释放。比如把分析结果写到MySQLval props new java.util.Properties() props.setProperty(user, your_user) props.setProperty(password, your_password) result.write .mode(overwrite) .jdbc(jdbc:mysql://192.168.1.10:3306/analysis_db, order_summary, props)这里需要注意mode的语义append是追加overwrite是覆盖还有ignore和error。我在生产环境里因为误用overwrite把历史结果表覆盖掉过一次从那以后我习惯在写库前先确认一下表数据的保留策略尤其是跑批任务时overwrite和append选错一次影响的是下游所有人的报表。Spark SQL还有一个高频使用场景是直接查Hive表。只要把Spark和Hive的元数据连起来你就可以让Spark读Hive里的表执行分析这在大数据平台里基本是标配。配置上主要是把hive-site.xml放进Spark的conf目录然后SparkSession开启enableHiveSupport()下面的写查询和查普通表完全没有区别。初学者如果直接跟着教程配Hive最容易翻车的地方是Hive和Spark用的是不同版本的derby元数据库会赶上一堆“元数据锁”之类的诡异错误建议要么直接用MySQL做Hive的元数据库要么把spark.sql.catalogImplementation明确指到hive。6. 顺带聊聊DGX SparkNVIDIA为什么要做“Spark专用机”本来这个话题可以放彩蛋但既然大家对“NVIDIA Spark”、“dgx spark部署”这些词搜得这么频繁我就在这里多写几句。DGX Spark是NVIDIA推出的桌面级AI计算设备定位很有意思它不是传统的Spark集群服务器而是面向AI和数据工程的开发工作站。如果你关注得早会发现它的外形和一台迷你主机差不多内置的却是Grace Blackwell架构的芯片主打“在桌面上跑超算级任务”。当初NVIDIA官方演示里专门放大了Spark的能力因为是NVIDIA优化过的Spark版本配合cuDF等GPU加速库类似ETL和数据处理这部分可以把CPU集群的很多耗时压下去。6.1 GPU加速的Spark和普通的Spark差在哪传统的Spark跑在CPU集群上数据以RDD或DataFrame的形态在JVM堆内流转。而NVIDIA的GPU加速Spark本质上是把Spark SQL和DataFrame里的算子翻译成GPU指令在显存里做并行计算。数据从磁盘读进来之后会被转换成GPU端的列式格式然后由cuDF这类库执行过滤、Join、聚合等操作。这些操作在CPU上是多核并发到了GPU上就是成千上万个CUDA核心同时干活密集型的ETL任务差距一下就拉开了。和“DGX Spark部署”相关的部分有一件事必须先说清楚NVIDIA的Spark发行版和社区版Spark不是完全一致的东西部署时通常需要匹配特定版本的CUDA驱动、Java版本以及RAPIDS插件。如果你想在自己现有的Spark集群上尝试GPU加速没必要买整台DGX Spark可以先装RAPIDS Accelerator插件让它跑在一个小的测试集群上看看效果。但要注意不是所有Spark算子都能被GPU加速一些非常复杂或者自定义的UDF最终还是会回退到CPU执行。真到了这一步一个任务里频繁发生算子来回切换性能反而可能下降。所以搜“NVIDIA Spark图标”的朋友多半是在确认某个集群里是不是真的用了GPU加速Spark。判断方法很简单看Executor日志里有没有NVIDIA驱动和CUDA上下文相关的初始化信息或者看Spark UI里的任务名称有没有RAPIDS相关的算符。6.2 谁真的需要DGX Spark我的选型建议我的个人看法是DGX Spark这一类产品解决的是一个真实存在但未必适合所有人的痛点适合做AI和数据工程开发的个人或小团队想低门槛地在本地跑GPU加速的数据预处理又不想为云GPU付高昂小时费。不适合大部分刚学Spark的新手。因为学习Spark只需要一台普通电脑local模式绰绰有余如果一开始就扎进GPU优化的生态里会被底层依赖、驱动兼容这些细节耗掉大量精力。我的建议是先弄明白CPU模式下Spark的执行模型、资源调度、内存划分再去碰GPU加速顺序不能反。GPU能让你更快地算完但不能帮你看懂Spark为什么慢。7. 高频Spark面试题自查被问烂了但你未必答得明白写到最后这一节正好把热词里“spark面试题”这个需求一起解决掉。我按自己面试别人的经验挑了几道最有区分度的题每道题附一个简明的答题思路供入门阶段自查。7.1 reduceByKey和groupByKey有什么区别两者都能做分组聚合但性能差异巨大。reduceByKey会先在每个分区内部做一次聚合再对分区之间的结果做聚合Map端完成了预聚合Shuffle的数据量就小很多。groupByKey则把所有key-value原样Shuffle到下游再聚合数据量大得多。实际场景中90%的reduce聚合用reduceByKey或aggregateByKey就能解决没必要先groupByKey再reduce。答这点时如果能补一句“groupByKey适合需要保留整个value列表的场景”会显得更完整。7.2 宽依赖和窄依赖Stage是怎么划分的窄依赖是父RDD每个分区只被子RDD的一个分区使用比如map、filter宽依赖是父RDD分区需要被多个子分区使用典型的就是groupByKey、join这类Shuffle操作。Spark在宽依赖处把整个DAG切分成多个Stage因为宽依赖意味着数据要跨分区、跨节点传输它是一个天然的执行边界。面试时如果能说出“窄依赖的Stage内部可以pipeline执行大量减少IO”就是一个加分项。7.3 repartition和coalesce到底应该用哪个repartition可以增加或减少分区但代价是必定发生Shuffle。coalesce只能减少分区而且默认不Shuffle它是在本地把多个分区合并所以效率高。有一个容易被忽略的细节coalesce减少分区之后数据分布未必均匀如果你只是想让输出文件数量变少它非常合适但如果后续还需要重新调整并行度可能还得用repartition。回答时点出“coalesce在减少分区时通常用窄依赖但如果要处理的数据量极大也可能退化成宽依赖”能体现对源码的理解。7.4 数据倾斜有什么处理手段这个问题面试基本必问。基础答案是先定位倾斜的key然后考虑加盐随机前缀打散key、调整并行度、用广播变量、改用Skewed Join。但面试官要听的不只是这些名词而是你能不能说出“加盐”之后的完整链路对小表加随机前缀可以和大表匹配但如果两张表都很大加盐后要先对倾斜key单独处理再和普通key的关联结果union起来。能说出来这个细节基本证明不是背的。7.5 RDD缓存级别怎么选缓存级别有MEMORY_ONLY、MEMORY_AND_DISK、DISK_ONLY等。选择依据是“这块数据后续会被复用几次”以及“你的内存是否够用”。生产中我一般选MEMORY_AND_DISK_SER因为存储内存不足时可以写磁盘避免OOM序列化后又省内存代价是读取时反序列化需要CPU但对于一个跑批任务来说完全划算。面试时要会说“缓存只是辅助手段如果一个RDD只被使用一次缓存它纯粹浪费资源”。这几道题如果答得上来说明你对Spark的“数据流动方式”已经有了比较扎实的理解。面试中如果被继续深挖大多会落到源码层面的调度机制或者实际项目里遇到过的故障那已经是另一个量级的经验积累问题了。最后说点入门学习的心得不要囤几十个教程视频也不要急着把各种组件都安装一遍。把三台机器搭好、把Spark SQL跑通、把YARN的Executor规划和内存模型真正弄明白然后再带着生产环境里遇到的故障去翻源码这比任何“XX天精通Spark”的路径都靠谱。我用这套思路带过好几个转行数据分析的新人基本三个月内都能独立跑数仓任务。你也按这个节奏走Spark入门这件事其实没有那么玄乎。