很多第一次接触Spark的人打开终端敲下spark-shell还没来得及输入任何代码先看到满屏的WARN日志其中一行特别显眼using sparks default log4j profile: org/apache/spark/log4j-defaults.properties然后就开始恐慌以为环境坏了、依赖冲突了、哪里配置不对了。其实这行信息只是一个通知不是错误更不是环境问题。真正的问题在于绝大多数Spark初学者连Spark到底在解决什么问题、Driver和Executor在干什么、RDD和DataFrame有什么区别都没搞明白就被各种似懂非懂的概念和日志包围了。这堂课标题里的3-4通常是大数据课程里Spark入门的那一节课我想换个讲法不按官方文档的顺序念概念而是从一个真实的、贴合实际开发的视角把Spark基础拆成几个必须想明白的问题来聊——它是什么、为什么快、跑起来之后各个角色在忙什么、第一次作业怎么做、以及初学者最容易踩的坑。这篇内容适合刚学完Hadoop、准备进入Spark阶段的读者也适合已经跑过一些Spark Demo但总觉得哪里没通的开发者。1. 为什么是Spark它在Hadoop生态里到底解决了什么很多人学Spark之前先学了MapReduce然后会产生一个理所当然的疑问Hadoop的MapReduce已经能处理海量数据了为什么还要Spark这个问题的答案直接决定你后面能不能真正理解Spark的设计。1.1 MapReduce的痛点每一步都在落盘MapReduce的核心计算模型是Map之后接Reduce。听起来没问题但实际执行的时候有一个非常要命的特性每个Stage的中间结果都会写入磁盘或者HDFS下一个Stage再从磁盘读。举个例子一个最简单的日志分析任务如果分成两步——先按IP统计访问量再按天汇总——MapReduce会把这个任务拆成两轮每一轮结束都要把结果写到HDFS上下一轮再读回来。磁盘IO在大数据场景下是最贵的操作之一这么搞性能很难上去。更别说复杂的任务如果拆成五六轮中间结果的读写次数是成倍增加的。还有一个问题MapReduce的编程模型太底层了。你要实现一个稍微复杂点的逻辑就得自己设计Key、Value的序列化结构自己写Partitioner自己考虑怎么在一次Shuffle里完成需求。这不是在写业务逻辑这是在写框架的插件。1.2 RDD的核心设计把中间结果留在内存Spark的核心抽象叫RDDResilient Distributed Dataset弹性分布式数据集。它最重要的一件事就是把中间结果尽可能留在内存里。RDD本身不是一个实际存储数据的集合它更像是一个数据的描述记录了我这份数据是从哪里加载的比如从HDFS、本地文件、Kafka、我要对这份数据做什么操作。当执行一个action操作比如count()、saveAsTextFile()时Spark才会根据这套描述真正去计算。这个设计带来的好处非常直接如果后续计算需要复用中间结果直接内存里拿不用再来回读磁盘。对于迭代式算法比如机器学习里的梯度下降每轮迭代都要用上一轮的结果Spark的