Spark on My Learning Notes

【二】Spark 下载与入门：环境配置、PySpark 交互与独立应用

Wed, 14 Oct 2026 17:25:56 +0800

过程参考：Spark官网的Quick Start - Spark 4.2.0 Documentation

1、下载

选择所需要的包类型 http://spark.apache.org/ ，得到spark-3.5.9-bin-hadoop3.tgz包并解压

1.1 前置环境

1、已安装并配置 Python

如果没有安装 Python，需要先安装 Python 3.8～3.11并添加到环境变量中

1

python --version

输出

1
2


C:\Users\v-liuyuhang\source\spark3.5.9>python --version
Python 3.12.10

用户变量中新增环境变量设置

Driver 使用 Python 3.12：PYSPARK_DRIVER_PYTHON
Worker 使用 Python 3.12：PYSPARK_PYTHON

图中两个变量均指向 Python 3.12 的解释器路径，仅记录本次配置；版本选择仍需以所用 Spark 版本的兼容要求为准。

在系统环境变量中新增Spark安装路径 C:\Users\v-liuyuhang\source\spark3.5.9\bin

2、已安装 Java并设置 `JAVA_HOME`

64 位 JDK 8，可以运行 Apache Spark 3.5.9，满足最低要求

1

java -version

输出

1
2
3
4


C:\Users\v-liuyuhang\source\spark3.5.9>java -version
java version "1.8.0_503"
Java(TM) SE Runtime Environment (build 1.8.0_503-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.503-b01, mixed mode)

检查 JAVA_HOME（如果你使用了 JRE 而不是 JDK，Spark 运行时可能出问题，最好确认目录中存在%JAVA_HOME%\bin\java.exe和%JAVA_HOME%\bin\javac.exe）

1

set JAVA_HOME

输出

1
2


C:\Users\v-liuyuhang>set JAVA_HOME
JAVA_HOME=C:\Program Files\Java\jdk1.8.0_503\

3、Windows系统适配(Linux不需要)

过程完全参考Arjun650/Hadoop-3.3.4-Windows-Installation-Guide 就可以，但是如果出现下载很慢的情况可以安装一个aria2工具，再用aria2多线程下载hadoop压缩包）

1
2
3


winget install aria2.aria2

aria2c -x 16 -s 16 -k 1M https://repo.huaweicloud.com/apache/hadoop/common/hadoop-3.3.4/hadoop-3.3.4.tar.gz

下载的输出可以参考，这样操作之后几分钟就可以下载完成

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


C:\Users\v-liuyuhang\Downloads>aria2c -x 16 -s 16 -k 1M https://repo.huaweicloud.com/apache/hadoop/common/hadoop-3.3.4/hadoop-3.3.4.tar.gz

10/19 16:39:46 [NOTICE] Downloading 1 item(s)
[#e1da51 0B/0B CN:1 DL:0B]
10/19 16:39:54 [NOTICE] Allocating disk space. Use --file-allocation=none to disable it. See --file-allocation option in man page for more details.
 *** Download Progress Summary as of Mon Oct 19 16:40:46 2026 ***
======================================================================================================================
[#e1da51 81MiB/663MiB(12%) CN:16 DL:3.2MiB ETA:2m56s]
FILE: C:/Users/v-liuyuhang/Downloads/hadoop-3.3.4.tar.gz
----------------------------------------------------------------------------------------------------------------------

 *** Download Progress Summary as of Mon Oct 19 16:41:47 2026 ***
======================================================================================================================
[#e1da51 300MiB/663MiB(45%) CN:16 DL:3.6MiB ETA:1m40s]
FILE: C:/Users/v-liuyuhang/Downloads/hadoop-3.3.4.tar.gz
----------------------------------------------------------------------------------------------------------------------

 *** Download Progress Summary as of Mon Oct 19 16:42:47 2026 ***
======================================================================================================================
[#e1da51 520MiB/663MiB(78%) CN:16 DL:3.4MiB ETA:41s]
FILE: C:/Users/v-liuyuhang/Downloads/hadoop-3.3.4.tar.gz
----------------------------------------------------------------------------------------------------------------------

[#e1da51 662MiB/663MiB(99%) CN:1 DL:28KiB ETA:13s]
10/19 16:43:37 [NOTICE] Download complete: C:/Users/v-liuyuhang/Downloads/hadoop-3.3.4.tar.gz

Download Results:
gid |stat|avg speed |path/URI
======+====+===========+=======================================================
e1da51|OK | 2.9MiB/s|C:/Users/v-liuyuhang/Downloads/hadoop-3.3.4.tar.gz

Status Legend:
(OK):download completed.

C:\Users\v-liuyuhang\Downloads>

将下载的 C:/Users/v-liuyuhang/Downloads/hadoop-3.3.4.tar.gz解压缩可以得到1.28G，后面跟着链接教程走就行。

ps. 如果JAVA_HOME 路径里有的空格，如JAVA_HOME=C:\Program Files\Java\jdk1.8.0_503\，需要在所有使用此路径时替换成C:\PROGRA~1\Java\jdk1.8.0_503。因为 hdfs.cmd、hadoop-config.cmd 这类批处理脚本在拼接 %JAVA_HOME%\bin\java 时没有加引号。

2、Spark中的Python shell

2.1 启动shell

进入一开始解压的目录 C:\Users\v-liuyuhang\source\spark3.5.9\ 打开cmd，执行

1

bin\pyspark

可以看到

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


C:\Users\v-liuyuhang\source\spark3.5.9>bin\pyspark
Python 3.12.10 (tags/v3.12.10:0cc8128, Apr 8 2025, 12:21:36) [MSC v.1943 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
26/10/14 17:25:56 WARN Shell: Did not find winutils.exe: java.io.FileNotFoundException: java.io.FileNotFoundException: HADOOP_HOME and hadoop.home.dir are unset. -see https://wiki.apache.org/hadoop/WindowsProblems
Setting default log level to "WARN".
To adjust logging level use sc.setLogLevel(newLevel). For SparkR, use setLogLevel(newLevel).
26/10/14 17:25:56 WARN NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable
Welcome to
 ____ __
 / __/__ ___ _____/ /__
 _\ \/ _ \/ _ `/ __/ '_/
 /__ / .__/\_,_/_/ /_/\_\ version 3.5.9
 /_/

Using Python version 3.12.10 (tags/v3.12.10:0cc8128, Apr 8 2025 12:21:36)
Spark context Web UI available at http://host.docker.internal:4040
Spark context available as 'sc' (master = local[*], app id = local-1791969960653).
SparkSession available as 'spark'.
>>>

在 Spark 中，我们通过对分布式数据集的操作来表达我们的计算意图，这些计算会自动地在集群上并行进行。这样的数据集被称为弹性分布式数据集（resilient distributed dataset），简称 RDD。RDD 是 Spark 对分布式数据和计算的基本抽象。

2.2 使用python shell 即时统计

先来使用 shell 从本地文本文件创建一个RDD 来作一些简单的即时统计。

>>> lines = sc.textFile("README.md") # 创建一个名为lines的RDD,读取README.md文档
>>> lines.count() # 统计RDD中的元素个数
125
>>> lines.first() # 输出这个RDD中的第一个元素，也就是README.md的第一行
'# Apache Spark' 
>>>

要退出任一 shell，按 Ctrl-D

2.3 spark UI

日志的输出中可以由这个地址访问 Spark 用户界面，查看关于任务和集群的各种信息。

点击日志中的 Web UI 地址，再进入 Stages 页面，可以查看已执行的 Stage。

图中展示了前面 count() 和 first() 两次操作产生的 Stage；仅凭 Stage 列表不能判断是否发生了宽依赖切分，具体依赖关系需要查看对应 Job 的 DAG。

3、Spark核心概念简介

从上层来看，每个 Spark 应用都由一个驱动器程序（driver program）来发起集群上的各种并行操作。驱动器程序包含应用的 main 函数，并且定义了集群上的分布式数据集，还对这些分布式数据集应用了相关操作。在前面的例子里，实际的驱动器程序就是 Spark shell 本身。

驱动器程序通过一个 SparkContext 对象来访问 Spark。这个对象代表对计算集群的一个连接。shell 启动时已经自动创建了一个 SparkContext 对象，是一个叫作 sc （SparkContext的缩写）的变量。我们可以通过例 2-3 中的方法尝试输出 sc 来查看它的类型。

1
2


>>> sc
<SparkContext master=local[*] appName=PySparkShell>

Spark 会自动将函数（比如line.contains("Python")）发到各个执行器节点（executor）上。这样就可以在单一的驱动器程序中编程，并且让代码自动运行在多个节点上。

%%{init: {'themeVariables': {'fontSize': '22px', 'titleFontSize': '24px', 'nodeTextColor': '#1a1a1a'}, 'flowchart': {'nodeSpacing': 50, 'rankSpacing': 60}}}%%
flowchart LR

 subgraph Driver["Driver Program"]
 SC["SparkContext"]
 end

 subgraph Worker1["Worker Node 1"]
 E1["Executor"]
 T1["Task"]
 T2["Task"]
 end

 subgraph Worker2["Worker Node 2"]
 E2["Executor"]
 T3["Task"]
 T4["Task"]
 end

 SC --> E1
 SC --> E2

 E1 --> T1
 E1 --> T2
 E2 --> T3
 E2 --> T4

 Worker1 <--> Worker2

4、独立应用

除了上面shell那样的交互式运行之外，Spark 也可以在 Java、Scala 或 Python 的独立程序中被连接使用。

对比项	Spark shell	独立 Spark 程序
使用方式	在交互式窗口中逐条输入代码	编写完整程序，再启动运行
常见形式	`spark-shell`、`pyspark`	Scala / Java / Python 应用
初始化	shell 通常预先创建好 `sc`（SparkContext）、`spark`（SparkSession）	程序负责创建或获取上下文、会话
常见用途	探索数据、验证逻辑、调试	批处理任务、生产数据管道

shell和独立程序的主要区别在于你需要自行初始化SparkContext，它们不是两套执行引擎，而是同一套 Spark 执行能力的两种使用方式。

例如，同样执行 filter → groupBy → count，无论代码来自 shell 还是独立程序，后续都要经过执行计划、Stage 划分、Task 调度和 Executor 执行。

4.1 Spark和Hive

Spark shell和独立 Spark 程序这种划分方式，很容易联想到Hive的Hive CLI和程序化客户端，也是交互式运行和程序化运行，这里简单区分一下

划分维度	Spark 示例	Hive 示例
交互式使用	Spark shell、PySpark shell	Hive CLI、Beeline
程序化使用	Scala / Java / Python Spark 应用	Java JDBC 程序等
客户端连接服务端	Spark Connect 等另行讨论	Beeline / JDBC → HiveServer2

但针对程序化使用来说，不能简单理解成：~~Spark 独立程序和 Hive JDBC 程序一样，都是连接远端查询服务器、发送查询~~。二者的区别在于是否包含了负责组织计算的 Driver。

Hive JDBC 程序通常是“查询请求的发起者”，不包含计算

1
2
3
4


1. 建立与 HiveServer2 的连接。
2. 将 SQL 文本提交给 HiveServer2（HiveServer2 及其执行链路负责“理解查询并组织计算）
3. 等待执行引擎的查询执行。
4. 读取返回的结果。

Java 程序本身不负责把 SQL 编译成分布式执行计划，也不负责把计算拆成任务并调度到集群。

具体计算可能交给 Tez、MapReduce 等执行引擎，取决于 Hive 的版本和配置。

MRAppMaster 向 YARN 申请 Container，在获得的 Container 中启动 Map/Reduce Task 的执行进程。详情参考【十一】HiveSQL底层执行过程：SQL 编译、任务生成与 YARN 调度流程

传统 Spark 独立应用则包含“计算执行的组织者”，也就是 Driver

4.2 统计单词数

现在写 Spark 业务， Scala、PySpark、SQL 三者更常见。大致这样理解：

场景	常见选择
学习 Spark 原理（Spark 底层框架、性能敏感组件、强类型 Dataset、函数式转换）	优先 Scala
Spark SQL、日常ETL、数据分析	SQL、PySpark
公司已有 Java 服务体系	Java
快速开发、算法与数据科学、Notebook 交互分析	PySpark

Scala/Java 两者调用的最终都是 Spark 的执行引擎，

Scala 的 lambda、集合操作、模式匹配与 Spark API 更自然

Java 更容易和传统 Java 工程、Spring 生态及现有公共库集成

前置检查

检查 Java，确保 JAVA_HOME 正确指向 JDK。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


C:\Users\v-liuyuhang>java -version
java version "1.8.0_503"
Java(TM) SE Runtime Environment (build 1.8.0_503-b01)
Java HotSpot(TM) 64-Bit Server VM (build 25.503-b01, mixed mode)

C:\Users\v-liuyuhang>javac -version
javac 1.8.0_503

C:\Users\v-liuyuhang>echo %JAVA_HOME%
C:\Program Files\Java\jdk1.8.0_503\

检查 Spark 和 Scala 版本

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


C:\Users\v-liuyuhang>spark-submit --version
Welcome to
 ____ __
 / __/__ ___ _____/ /__
 _\ \/ _ \/ _ `/ __/ '_/
 /___/ .__/\_,_/_/ /_/\_\  version 3.5.9
 /_/

Using Scala version 2.12.18, Java HotSpot(TM) 64-Bit Server VM, 1.8.0_503
Branch HEAD
Compiled by user holden on 2026-07-12T18:40:50Z
Revision 7c14a3c28b141cc97a330c4d0f5d2a6da7267f85
Url https://github.com/apache/spark
Type --help for more information.

在这一堆里输出里可以找到：Spark version 3.5.9、Scala version 2.12.18、Java version 1.8.0_503

检查 sbt，没有安装的话，以管理员身份打开cmd执行 choco install sbt

1
2
3


C:\Users\v-liuyuhang>sbt --version
sbt version in this project: 1.9.9
sbt script version: 1.9.9

sbt 是 Scala 项目常用的构建工具，作用类似：

Java 的 Maven 或 Gradle
.NET 的 dotnet CLI
Python 的部分依赖管理和打包工具

创建项目目录

如果是windows系统则中执行

1
2
3
4
5
6
7
8


mkdir spark-line-count\project
mkdir spark-line-count\data
mkdir spark-line-count\src\main\scala\com\example

type nul > spark-line-count\build.sbt
type nul > spark-line-count\project\build.properties
type nul > spark-line-count\data\input.txt
type nul > spark-line-count\src\main\scala\com\example\LineCountApp.scala

如果是linux系统则执行

1
2
3
4
5


mkdir -p spark-line-count/project
mkdir -p spark-line-count/data
mkdir -p spark-line-count/src/main/scala/com/example

cd spark-line-count

完成后在 spark-line-count\data\input.txt 加几行文字作为测试的输入

build.sbt

build.sbt 就是 Spark 项目的「配置文件 + 依赖清单」。编译、打包时 sbt 启动会读取它，生成一个键值对 Map 来描述整个项目。决定：

配置项	作用
`name`	项目名称
`version`	项目版本号
`scalaVersion`	使用哪个 Scala 版本
`libraryDependencies`	项目依赖哪些 jar（Spark、测试库等）
`assembly` 相关	控制打包行为（合并 / 排除冲突）

类比理解：

Java 的 pom.xml
Python 的 requirements.txt + setup.py

针对我当前的版本

1
2
3
4


Spark 3.5.9
Scala 2.12.18
Java 1.8.0_503
sbt launcher 1.9.9

填入build.sbt得到

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


ThisBuild / organization := "com.example"
ThisBuild / scalaVersion := "2.12.18"
ThisBuild / version := "1.0.0"

lazy val root = (project in file("."))
 .settings(
 name := "spark-line-count",

 // ========== 依赖 ==========
 libraryDependencies ++= Seq(
 "org.apache.spark" %% "spark-core" % "3.5.9" % "provided",
 "org.apache.spark" %% "spark-sql" % "3.5.9" % "provided"
 ),
 )

% "provided" （适合最后使用spark-submit运行程序）表示：

编译项目时需要 Spark 依赖
打包 JAR 时不把完整 Spark 包塞进应用 JAR
运行时由本机 Spark 或集群提供 Spark 依赖

创建目录的时候已经创建了sbt 版本配置文件 spark-line-count\project\build.properties，现在将其版本填入

1

sbt.version=1.9.9

编写 Scala Spark 程序

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40


package com.example

import org.apache.spark.sql.SparkSession

object LineCountApp {

 def main(args: Array[String]): Unit = {

 // 如果调用程序时传入了文件路径，就使用第一个参数；
 // 否则默认读取项目下的 data/input.txt。
 val inputPath =
 if (args.nonEmpty) args(0)
 else "data/input.txt"

 // 创建 SparkSession 对象
 val spark = SparkSession
 .builder()
 .appName("Scala Spark Line Count") //设置 Spark 应用名称
 .master("local[*]")// 设置本地运行模式为local，使用所有可用的 CPU 核心
 .getOrCreate()

 try {
 // 读取输入文件的所有行，返回Dataset[String]
 val lines = spark.read.textFile(inputPath)
 // 触发 Spark Job：计算输入文件的总行数
 val totalLineCount = lines.count()

 // 触发 Spark Job：计算非空行的总行数
 val nonEmptyLineCount = lines
 .filter(line => line.trim.nonEmpty)// 去掉行首和行尾空白。
 .count()

 println(s"Input file: $inputPath")
 println(s"Total line count: $totalLineCount")
 println(s"Non-empty line count: $nonEmptyLineCount")
 } finally {
 spark.stop()
 }
 }
}

sbt 编译+打包

先清理旧产物，再重新把 Scala 源代码编译成 JVM 可以执行的字节码(JAR)，但不会运行程序。

1

sbt clean package

编译时会发生什么？

读取构建配置
sbt 根据 build.properties 选择 sbt 版本，再读取 build.sbt 中的 Scala 版本、依赖等配置。
准备编译器和依赖
首次编译时，可能需要下载 Scala 编译器和声明的依赖；已缓存的通常会复用。
检查并编译源码
例如检查 LineCountApp.scala 中的语法、类型，以及引用的类是否存在。
生成 .class 文件
编译成功后，通常输出到：target\scala-<Scala二进制版本>\classes\

编译成功会输出Compilation completed如下

1
2


[info] Compilation completed in 21.912s.
[success] Total time: 87 s (01:27), completed 2026-10-16 16:44:51

同时会生成文件

1

target\scala-2.12\spark-line-count_2.12-1.0.0.jar

后缀的2.12-1.0.0.jar 分别表示scala-2.12、Scala 二进制版本1.0.0（来自ThisBuild / version := "1.0.0"）

spark-submit 运行

启动已经打包好的 Spark 应用（通常流程如下，所以必须先编译）

1

Scala 源码 → sbt 打包成 JAR → spark-submit 启动 → Spark 读取数据、执行计算

运行

1
2
3
4
5


spark-submit `
 --class com.example.LineCountApp `
 --master "local[*]" `
 target\scala-2.12\spark-line-count_2.12-1.0.0.jar `
 data\input.txt

参数含义：

参数	作用
`--class com.example.LineCountApp`	指定包含 `main` 方法的入口
`--master "local[*]"`	在本机运行，使用所有可用 CPU 核心
JAR 路径	要运行的应用包
JAR 后面的参数	传给应用的 `main(args)`，这里是输入文件路径

Spark 的选项放在 JAR 前面，应用自己的参数放在 JAR 后面。

执行成功的话会看到有输出如下

1
2
3


Input file: data/input.txt
Total line count: 6
Non-empty line count: 5

过程总结

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


sbt package
 ↓
生成应用 JAR
 ↓
spark-submit 启动 Driver
 ↓
Driver 执行 main()
 ↓
创建 SparkSession / SparkContext
 ↓
textFile() 构建读取计划
 ↓
count() 触发 Spark Job
 ↓
Task 读取文件分区并计数
 ↓
Driver 汇总并输出行数
 ↓
spark.stop() 释放资源，程序退出

【一】Spark 是什么：组件、应用场景与发展简史

Tue, 13 Oct 2026 18:33:19 +0800

事先声明：内容大部分整理自书籍《Spark快速大数据分析 (图灵程序设计丛书) 》，部分总结和人话是原创，顺便提一嘴，书写的超级好理解，推荐大家读原文展开自己的思考！

1、Spark的组成部分

定义

Spark 是一个用来实现快速而通用的集群计算的平台。可以说它是一个大一统的软件栈，为各种不同应用场景专门设计了多个紧密集成的高级组件，如下：

在速度方面，Spark 扩展了广泛使用的 MapReduce 计算模型，而且高效地支持更多计算模式，包括批处理、迭代算法、交互式查询、流处理。

1.1 Spark Core

park Core 实现了 Spark 的基本功能，包含任务调度、内存管理、错误恢复、与存储系统交互等模块。

Spark Core 中还包含了对弹性分布式数据集（resilient distributed dataset，简称 RDD）的 API 定义

RDD 表示分布在多个计算节点上可以并行操作的元素集合，是 Spark 主要的编程抽象。
Spark Core 提供了创建和操作这些集合的多个 API。

1.2 Spark SQL

Spark SQL 是 Spark 用来操作结构化数据的程序包。

通过 Spark SQL，我们可以使用 SQL 或者 Hive SQL（HQL）来查询数据。Spark SQL 支持多种数据源，比如 Hive 表、Parquet 以及 JSON 等。
除了为Spark 提供了一个 SQL 接口，Spark SQL 还支持开发者将 SQL 和传统的RDD 编程的数据操作方式相结合，不论是使用 Python、Java 还是 Scala，开发者都可以在单个的应用中同时使用 SQL 和复杂的数据分析。

通过与Spark 所提供的丰富的计算环境进行如此紧密的结合，Spark SQL 得以从其他开源数据仓库工具中脱颖而出。

Spark SQL 是在 Spark 1.0 中被引入的。

在 Spark SQL 之前，加州大学伯克利分校曾经尝试修改 Apache Hive 以使其运行在 Spark 上，当时的项目叫作 Shark。现在，由于 Spark SQL 与 Spark 引擎和 API 的结合更紧密，Shark 已经被 Spark SQL 所取代

1.3 Spark Streaming

Spark Streaming 是 Spark 提供的对实时数据进行流式计算的组件。

比如生产环境中的网页服务器日志，或是网络服务中用户提交的状态更新组成的消息队列，都是数据流。
Spark Streaming 提供了用来操作数据流的 API，并且与 Spark Core 中的 RDD API 高度对应。这样一来，程序员编写应用时的学习门槛就得以降低，不论是操作内存或硬盘中的数据，还是操作实时数据流，程序员都更能应对自如。

从底层设计来看，Spark Streaming 支持与Spark Core 同级别的容错性、吞吐量以及可伸缩性。

1.4 MLlib

Spark 中还包含一个提供常见的机器学习（ML）功能的程序库，叫作MLlib。

MLlib 提供了很多种机器学习算法，包括分类、回归、聚类、协同过滤等，还提供了模型评估、数据导入等额外的支持功能。
MLlib 还提供了一些更底层的机器学习原语，包括一个通用的梯度下降优化算法。所有这些方法都被设计为可以在集群上轻松伸缩的架构。

1.5 GraphX

GraphX 是用来操作图（比如社交网络的朋友关系图）的程序库，可以进行并行的图计算。

与 Spark Streaming 和 Spark SQL 类似，GraphX 也扩展了Spark 的 RDD API，能用来创建一个顶点和边都包含任意属性的有向图。
GraphX 还支持针对图的各种操作（比如进行图分割的 subgraph 和操作所有顶点的 mapVertices），以及一些常用图算法（比如 PageRank 和三角计数）。

1.6 集群管理器

就底层而言，Spark 设计为可以高效地在一个计算节点到数千个计算节点之间伸缩计算。

为了实现这样的要求，同时获得最大灵活性，Spark 支持在各种集群管理器（cluster manager）上运行，包括 Hadoop YARN、Apache Mesos，以及 Spark 自带的一个简易调度器，叫作独立调度器。

如果要在没有预装任何集群管理器的机器上安装 Spark，那么 Spark 自带的独立调度器可以让你轻松入门；
而如果已经有了一个装有 Hadoop YARN 或 Mesos 的集群，通过 Spark 对这些集群管理器的支持，你的应用也同样能运行在这些集群上。

2、Spark 的用途

我概括一下，可以分成两类：

预处理机器学习/深度学习的数据集，执行计算任务 ——> AI 研发岗算法工程师
优化后端代码以及数据库的大量数据的计算 ——> 大数据开发工程师/数据仓库工程师

2.1 数据科学任务

数据科学是过去几年里出现的新学科，关注的是数据分析领域。

数据科学家（data scientist）就是主要负责分析数据并建模的人，他们具备 SQL、统计、预测建模（机器学习）等方面的经验，以及一定的使用 Python、Matlab 或 R 语言进行编程的能力。例如，在数据科学家完成初始的调研之后，我们可能最终会得到一个生产环境中的推荐系统，可以整合在网页应用中，为用户提供产品推荐。

数据科学家在使用 Python 或 Pandas 等传统数据分析工具时所能处理的数据集/训练模型始终受限于单机（GPU只存在一台电脑上），而有了 Spark，再加上购买的云计算资源就能处理更大数据规模的问题。

1

上面是搬运了英文书籍的原文，按我们中国话来说这个岗位对应的人，在大学读计算机视觉/自然语言的研究生毕业找到的AI研发岗工作啦

2.2 数据处理应用

开发者一般有基本的软件工程概念，比如封装、接口设计以及面向对象的编程思想，他们通常有计算机专业的背景，并且能使用工程技术来设计和搭建软件系统，以实现业务用例。

Spark 已经为工程师提供了足够的接口来快速实现常见的任务，以及对应用进行监视、审查和性能调优。其 API 模块化的特性（基于传递分布式的对象集）使得利用程序库进行开发以及本地测试大大简化。

1

上面是搬运了英文书籍的原文，简单来说就是数据量太大啦，即使充分利用 关系型数据库全部性能 + 代码的多线程计算 还是很慢的任务（因为就算是把代码部署到网页服务器上，实际可利用的也是单机的CPU计算资源），此时就要考虑将传统数据库升级为数据仓库，同时将数据的处理逻辑从代码迁移到数仓任务中，利用分布式计算框架即Spark（通常可以利用>=3台计算机资源）来加速计算过程

3、Spark 简史

Spark 是于 2009 年作为一个研究项目在加州大学伯克利分校 RAD 实验室（AMPLab 的前身）诞生。

实验室中的一些研究人员曾经用过 Hadoop MapReduce。他们发现MapReduce 在迭代计算和交互计算的任务上表现得效率低下。因此，Spark从一开始就是为交互式查询和迭代算法设计的，同时还支持内存式存储和高效的容错机制。

2011 年，AMPLab 开始基于 Spark 开发更高层的组件，比如 Shark（Spark上的 Hive）1 和 Spark Streaming。（Shark 已经被 Spark SQL 所取代）

Spark 最早在 2010 年 3 月开源，并且在 2013 年 6 月交给了 Apache 基金会，现在已经成了 Apache 开源基金会的顶级项目。

阶段	年份	版本	一句话	解决了什么
① 起步	2009–2012	闭源	用内存 + DAG 替代 MapReduce 的反复落盘	迭代计算（如机器学习）太慢
② 统一	2014	1.0	一套引擎跑批、流、SQL、ML、图	以前要学好几个框架
③ 声明式	2015–2016	1.x→2.0	RDD → DataFrame/SQL，优化器接管	用户手写代码，引擎没法优化
④ 榨干 CPU	2015–2018	2.x	Tungsten + 代码生成	JVM 对象、GC 成了新瓶颈
⑤ 自适应	2020	3.0	AQE、动态分区裁剪	静态计划猜不准真实数据
⑥ 服务化	2023–2025	3.4→4.0	Spark Connect、云原生、ANSI SQL	从"本地库"变成"远程数据服务"

4、Spark

分布式计算有个绕不开的现实问题：一个算子算完的结果，下游算子怎么拿到？

两个算子可能跑在不同的机器上，上游某个 task 的输出，下游某个 task 要作为输入来读。解决办法是找个地方"寄存"一下，再网络传输。看一下在Hadoop MapReduce和Spark中都是怎么实现的

4、详解 Spark 的出现契机

实验室中的一些研究人员曾经用过 Hadoop MapReduce。他们发现MapReduce 在迭代计算和交互计算的任务上表现得效率低下。因此，Spark从一开始就是为交互式查询和迭代算法设计的，同时还支持内存式存储和高效的容错机制。

这里我想展开说一下，众所周知新技术的出现一般是因为现有的技术无法解决或纯因为人懒，Spark的出现正是如此，因为随着时代发展数据量的增大，MapReduce处理数据的效率变低，达到人们的忍耐上限啦，所以必须重新设计一个计算模型来解决喽！

先用一个简单的例子看看一样的数据处理逻辑交给MapReduce和Spark会发生什么？

已知一段数据的处理执行逻辑如下

flowchart LR
 1.读取数据 --> 2.初步过滤--> 3.字段转换--> 4.按Key聚合--> 5.再过滤--> 6.写出结果

4.1、Hadoop MapReduce

Hadoop MapReduce采用的就是最朴素的做法：每一步的上游算完，都把结果写进 HDFS，下游再从 HDFS 读出来，同时执行模型相对固定，阶段之间必须将中间结果落盘

flowchart LR
 A1[1.读取 HDFS]-->B1[2.Map计算]-->C1["3.写中间结果到磁盘(HDFS)"]-->D1[4.Reduce通过网络拉取中间结果]-->E1[5.Reduce计算]-->F1["6.写结果到磁盘(HDFS)"]
 classDef default font-size:18px;

复杂逻辑通常要拆成多个 MapReduce Job（每个 Job 之间通常以文件系统作为边界）

---
config:
 theme: default
 layout: elk
 elk:
 spacing: 
 nodeSubgraph: 5 # 节点与子图间距
---
flowchart LR
 subgraph Job1
 direction LR
 A1[1.读取 HDFS]-->B1[2.Map计算]-->C1["3.写中间结果到磁盘(HDFS)"]-->D1[4.Reduce通过网络拉取中间结果]-->E1[5.Reduce计算]-->F1["6.写结果到磁盘(HDFS)"]
 end
 subgraph Job2
 direction LR
 A2[1.读取 HDFS]-->B2[2.Map计算]-->C2["3.写中间结果到磁盘(HDFS)"]-->D2[4.Reduce通过网络拉取中间结果]-->E2[5.Reduce计算]-->F2["6.写结果到磁盘(HDFS)"]
 end
 subgraph Job3
 direction LR
 A3[1.读取 HDFS]-->B3[2.Map计算]-->C3["3.写中间结果到磁盘(HDFS)"]-->D3[4.Reduce通过网络拉取中间结果]-->E3[5.Reduce计算]-->F3["6.写结果到磁盘(HDFS)"]
 end

 Task --> Job1
 Task --> Job2
 Task --> Job3

 classDef default font-size:18px;

落盘(存入HDFS)看着无害，其实开销巨大：

磁盘 I/O：数据从内存刷到磁盘
序列化：对象要变成字节流才能写
HDFS 多副本：写一份数据默认要复制 3 份到不同机器

一次落盘就是一次"内存 → 磁盘 → 网络 → 磁盘 → 内存"的往返。如果你的 pipeline 有 10 个算子，每一步都落盘，那就是 10 次这样的往返。这是 MapReduce 慢的根本原因之一。

4.2、Spark

Spark 通过窄依赖整合 Pipeline，再按 Shuffle 边界切分为 Stage，最终组合成全局 DAG。 ——Spark 的优化逻辑分三层递进：先整合，再切分，最后编排。

窄依赖：Pipeline 得以成立的前提

Spark 为什么能"不落盘"？——关键在窄依赖（Narrow Dependency）。

依赖说的是：下游的每一个分区，只由上游的少数几个分区计算而来。

窄依赖（如 map、filter、select）：下游一个分区只依赖上游一个分区。既然数据没重分布，上下游算子可以安排给同一台机器、同一个 task 串行执行——中间结果不用存，直接拿对象在内存里传下去，这就是流水线（pipeline）

map → filter → map 全在一个 task 里一气呵成，中间不落盘

宽依赖（如 groupByKey、join）：下游一个分区依赖上游很多分区，必须Shuffle——数据要按 key 重新分发到不同机器。这一步不可避免要落盘 + 网络传输。

所以准确说法是：

窄依赖之间不落盘，可以流水线；遇到宽依赖（Shuffle）才必须落盘。

Pipeline / Stage / DAG 来优化执行过程

概念	是什么	关注的问题
算子	`map`、`filter`、`reduceByKey` 等数据处理操作	数据怎么变换？
DAG	数据集及其依赖构成的有向无环图	整体计算依赖是什么？
Stage	由 Shuffle 依赖划分出的调度阶段	哪些计算可以在一个阶段完成？
Pipeline	同一个 Task 内串联执行的操作链	一份数据如何连续经过多个操作？
Task	一个 Stage 中针对一个分区的执行任务	谁来计算这一份数据？
Executor	工作节点上运行的 Spark 进程，提供执行线程、缓存等	Task 实际在哪里运行？

它们不是一条简单的上下级链条，而是“计算逻辑”和“执行调度”两个视角：

计算逻辑：算子组成 DAG；Shuffle 边界把 DAG 切成 Stage；Stage 内可流水线执行的操作组成 Pipeline。
执行调度：Stage 按分区生成 Task；Task 被分配给 Executor 执行。

用一个 RDD 按 Key 聚合的例子，把逻辑依赖、Shuffle 边界和 Task 在 Executor 上的执行过程串起来

1、形成逻辑DAG

Spark 记录用户写下的一系列转换关系，形成逻辑上的 DAG，不立即计算：

flowchart LR
 1.读取 --> 2.filter--> 3.map--> A["4.groupByKey / reduceByKey"]--> 5.filter--> 6.write

这张图里的 6 个方块，其实是 6 个 RDD 对象 + 它们之间的关系（依赖关系），串成图就是DAG。 filter、map、groupByKey 这些都是 transformation（变换），它们的执行结果是一个新的 RDD 引用。

1
2
3
4
5


rdd0 = sc.textFile("...") // RDD 0：读取
rdd1 = rdd0.filter(...) // RDD 1：filter 变换
rdd2 = rdd1.map(...) // RDD 2：map 变换
rdd3 = rdd2.groupByKey(...) // RDD 3：shuffle 变换
rdd4 = rdd3.filter(...) // RDD 4：filter 变换

2、切分DAG得到 stages

collect() 触发 Job，DAG 按宽依赖（Shuffle 边界）切分得到 stages

Driver 上的 DAGScheduler 沿 RDD 依赖分析计算：

[ Stage 0: map → filter → map ] ← 全是窄依赖，这一条就是一个pipeline可以串联执行
 ↓ Shuffle（落盘 + 网络）
[ Stage 1: groupByKey → map ] ← 把相同 Key 的数据重新组织到同一个分区，形成 Shuffle 依赖

注意：reduceByKey 不是全部只在下游 Stage 执行。 它的实现跨越边界：

上游Stage 0：分区内预聚合、Shuffle Write。
下游Stage 1：Shuffle Read、合并聚合。

3、Pipeline 化 + Task 化后执行Stages的计算

切分之后，执行引擎再对每个 Stage 做两件事：

Pipeline 化：把 Stage 内的窄依赖算子合成一条管道，消除中间物化；
Task 化：把这条管道切成 N 个并行 Task，分发到集群中的 Executor 上运行。

SQL / DataFrame
 │
 ▼
Catalyst 逻辑计划 ──(优化)──▶ 物理计划
 │
 ▼
按 Shuffle 边界切分为 Stage
 │
 ▼
每个 Stage 内部 Pipeline 化（窄依赖算子合成一条管道）
 │
 ▼
每条 Pipeline 切成 N 个 Task，分发到集群
 │
 ▼
同一台机器上的多个 Task 共享 Executor 的 JVM / 内存池

从上一步划分的 [ Stage 0: map → filter → map ] 可知分区内将执行预聚合、Shuffle Write。假设集群有 3 个输入分区，那么实际执行的 Pipeline（map → filter → map）的Task就有3 个。

这个3个Task在通过Excutor获取计算资源后会按照上一步设定的pipeline并行处理各自分区的数据。

例如 Task 0 在 Executor 1 上处理输入分区 0：

读取一条订单。
filter 判断是否有效。
有效订单通过 map 转成 (userId, amount)。
在本分区内合并相同用户的金额。
按目标分区写出 Shuffle 数据。

由于Stage 0聚合数据后由于宽依赖必须将相同Key的数据合并到一起，所以下一步就是 Shuffle（落盘 + 网络）

假设3个输入分区中都有用户 "A" 的订单：

输入分区 0：("A", 10)、("A", 20)
输入分区 1：("A", 5)
输入分区 2：("A", 15)

上游预聚合后，分别得到 "A" 的金额 30、5、15。

Partitioner 保证这些 "A" 的输出属于同一个目标分区。负责这个目标分区的下游 Task 会读取三个上游 Task 的相关输出。

这里就看出 Shuffle 不是一个集中处理数据的单独进程，而是上游写出、下游拉取的分布式数据交换过程。

Stage 0 结束后才会执行 [ Stage 1: groupByKey → map ] Shuffle Read、合并聚合。假设集群有2 个输出分区，那么实际执行的 Pipeline（groupByKey → map）的Task就有2 个。

负责 "A" 所在分区的 Task：

读取对应的 Shuffle 数据。
合并金额，得到 ("A", 50)。
执行后面的 map，生成 "A,50"。
将结果返回 Driver。

Executor 提供资源，不决定计算边界，它可以：

同时执行多个 Task，具体取决于可用核数及 Task 资源需求。
先执行 Stage 0 的 Task，再执行 Stage 1 的 Task。
执行不同 Stage、不同 Job 的任务。

所以，Stage 是计算的划分，Executor 是运行计算的资源，两者不是一一对应关系

4、步骤总结图

把前面的所有步骤看明白后，就很好理解下面的完整执行图啦！

%%{init: {'themeVariables': {'fontSize': '20px', 'titleFontSize': '22px', 'nodeTextColor': '#1a1a1a'}, 'flowchart': {'nodeSpacing': 50, 'rankSpacing': 60}}}%%

flowchart TB

 %% ============ Driver：触发与规划 ============
 subgraph DRIVER["Driver：Action 触发 Job，DAGScheduler 按 Shuffle 依赖划分 Stage"]
 ACTION["collect()：触发执行"]
 PLAN["RDD 依赖 DAG
输入 → filter → map → reduceByKey → map"]
 ACTION --> PLAN
 end

 %% ============ Job：两个 Stage ============
 subgraph JOB["Job：本例包含两个 Stage"]
 direction TB

 subgraph S0["Stage 0：ShuffleMapStage｜3 个输入分区 → 3 个 Task"]
 direction LR
 T00["Task 0：输入分区 0
读取 → filter → map
→ 分区内预聚合 → Shuffle Write"]
 T01["Task 1：输入分区 1
读取 → filter → map
→ 分区内预聚合 → Shuffle Write"]
 T02["Task 2：输入分区 2
读取 → filter → map
→ 分区内预聚合 → Shuffle Write"]
 end

 SH["Shuffle 边界：按 userId 重新分区
每个上游 Task 的输出按目标分区分桶
下游 Task 拉取属于自己的桶"]

 subgraph S1["Stage 1：ResultStage｜2 个结果分区 → 2 个 Task"]
 direction LR
 T10["Task 0：结果分区 0
Shuffle Read → 合并聚合
→ map → 返回结果"]
 T11["Task 1：结果分区 1
Shuffle Read → 合并聚合
→ map → 返回结果"]
 end

 T00 --> SH
 T01 --> SH
 T02 --> SH
 SH --> T10
 SH --> T11
 end

 PLAN --> S0

 %% ============ 运行资源 ============
 subgraph RUNTIME["运行资源：Executor 执行 Task，不固定属于某个 Stage"]
 direction LR
 E1["Executor 1
线程池执行 Task
管理缓存等"]
 E2["Executor 2
线程池执行 Task
管理缓存等"]
 end

 T00 -.->|"示例分配"| E1
 T01 -.->|"示例分配"| E2
 T02 -.->|"示例分配"| E1
 T10 -.->|"示例分配"| E2
 T11 -.->|"示例分配"| E1

 %% ============ 结果回收 ============
 RESULT["Driver 收到 collect 的结果"]
 T10 --> RESULT
 T11 --> RESULT

 %% ============ 样式：分区着色 ============
 classDef driver fill:#EDE7F6,stroke:#7E57C2,stroke-width:2px,color:#311B92;
 classDef stage0 fill:#E0F2F1,stroke:#00897B,stroke-width:2px,color:#004D40;
 classDef stage1 fill:#FFF3E0,stroke:#F57C00,stroke-width:2px,color:#E65100;
 classDef shuffle fill:#FFEBEE,stroke:#E53935,stroke-width:3px,color:#B71C1C;
 classDef executor fill:#ECEFF1,stroke:#607D8B,stroke-width:2px,color:#263238;
 classDef result fill:#E3F2FD,stroke:#1565C0,stroke-width:3px,color:#0D47A1;

 class DRIVER,ACTION,PLAN driver;
 class S0,T00,T01,T02 stage0;
 class S1,T10,T11 stage1;
 class SH shuffle;
 class RUNTIME,E1,E2 executor;
 class RESULT result;

总结： Spark 的优势通常来自多方面：

DAG 执行模型，不局限于固定的 Map → Reduce 两阶段。
窄依赖可以流水线执行，不必在每个算子之间落盘。
数据可以 Cache/Persist，适合多次复用。
Lazy Evaluation，可以先记录转换关系，遇到 Action 再执行。
DataFrame/SQL 还能通过优化器优化执行计划。