基于Spark的大规模数据集成处理实战教程-171主机测评

基于Spark的大规模数据集成处理实战教程

关键词：Spark、数据集成、分布式计算、RDD、DataFrame、数据清洗、实战教程

摘要：本文以“如何用Spark处理大规模数据集成”为核心，从Spark的核心概念讲起，结合生活案例通俗解释技术原理，通过代码实战演示数据集成全流程（数据读取→清洗→转换→输出），并总结企业级最佳实践。无论你是大数据新手还是有经验的工程师，都能通过本文掌握Spark数据集成的核心技能。

背景介绍

目的和范围

在数字化时代，企业数据像“爆炸的烟花”——来源多（日志、数据库、IoT设备）、格式杂（CSV/JSON/关系表）、规模大（TB级甚至PB级）。传统工具（如Python脚本、Excel）处理这类数据时，要么慢如蜗牛，要么直接“罢工”。本文聚焦用Spark解决大规模数据集成问题，覆盖：

Spark核心组件的工作原理
数据集成的典型场景（多源数据合并、清洗、转换）
从环境搭建到代码落地的全流程实战

预期读者

想入门大数据处理的开发者（有Python/Java基础即可）
需解决企业数据集成痛点的工程师（如电商用户行为数据整合、日志分析）
对分布式计算感兴趣的技术爱好者

文档结构概述

本文采用“概念→原理→实战”的递进结构：

用“快递工厂”故事类比Spark核心概念

拆解Spark分布式计算的底层逻辑

手把手演示从数据读取到输出的完整代码

总结企业级调优技巧和未来趋势

术语表（用“快递”类比理解）

术语类比解释（快递工厂）

RDD	快递包裹的“批次”（比如“双11第3批包裹”，每个批次包含多个分区，分区是具体的“包裹堆”）
DataFrame	带“电子面单”的快递批次（每单有明确的“收件人”“地址”等字段，类似表格的列名和类型）
Driver	快递调度中心（负责规划“包裹从哪来、到哪去”，协调各个快递站点工作）
Executor	快递站点的“搬运工”（实际干活的人，负责处理每个包裹批次的具体任务，如分拣、打包）
Shuffle	跨站点的“包裹中转”（比如北京的包裹需要发到上海，需先集中到中转仓重新分配，可能导致大量网络传输）
Lineage	包裹的“物流追踪单”（记录包裹从揽收到派送的所有步骤，丢件时可快速回溯恢复）

核心概念与联系

故事引入：用“快递工厂”理解Spark

假设你是“宇宙快递”的CEO，每天要处理10亿个包裹（相当于企业的TB级数据）。传统模式是用1辆小货车（单台电脑）送包裹，显然会堵车、超时。于是你建了一个“分布式快递网络”：

总调度中心（Driver）：规划路线（执行用户写的Spark程序），告诉各个站点（Worker节点）要做什么。
快递站点（Worker）：每个站点有多个搬运工（Executor），负责实际搬包裹（处理数据）。
包裹批次（RDD）：把10亿个包裹分成1000个批次（分区），每个批次由一个搬运工处理，并行完成。
电子面单（DataFrame）：每个包裹有电子面单（结构化数据），记录收件人、地址等信息，方便快速分拣（类似SQL查询）。

这就是Spark的核心——用分布式计算网络，把海量数据拆分成小块并行处理，就像用1000辆小货车同时送包裹，效率飙升！

核心概念解释（像给小学生讲故事）

核心概念一：RDD（弹性分布式数据集）

RDD是Spark的“数据基石”，可以理解为分布式存储的“数据批次”。比如你有1000本《西游记》要分发给全校学生，直接搬1000本很麻烦。于是你把书分成10堆（分区），每堆100本，让10个同学各搬一堆（并行处理）。如果某堆书被淋湿了（数据丢失），你可以根据“搬运记录”（Lineage）重新搬一次（容错）。关键特性：

分布式：数据存在多台机器上
不可变：一旦生成，不能修改（修改会生成新RDD）
弹性：自动容错、自动调整分区

核心概念二：DataFrame（数据框）

DataFrame是“带结构的RDD”，就像带表头的Excel表格。比如你有一堆快递面单（RDD），但面单是乱的（有的写“地址”，有的写“收件地址”）。DataFrame给这些面单加了统一的表头（列名+类型），比如姓名:字符串、地址:字符串、重量:数值，这样你可以像查Excel一样快速筛选（“找北京的包裹”）、统计（“总重量”）。关键优势：

结构化：通过列名和类型约束数据，避免混乱
优化执行：Spark会自动优化DataFrame的执行计划（类似SQL的查询优化）

核心概念三：Spark集群架构（Master/Worker/Driver/Executor）

Spark集群就像一个“工厂”，由四类角色协作：

Master（厂长）：管理整个工厂，分配任务给各个车间（Worker）。
Worker（车间）：工厂里的各个车间，每个车间有多个工人（Executor）。
Driver（调度员）：用户程序运行的地方，负责把任务拆解成多个子任务（Task），并监控执行。
Executor（工人）：实际干活的人，负责执行Task（处理数据），并把结果返回给Driver。

核心概念之间的关系（用“快递”类比）

RDD与DataFrame：RDD是“没有面单的包裹堆”，DataFrame是“有电子面单的包裹堆”。DataFrame基于RDD，但多了结构信息，处理更高效。
Driver与Executor：Driver是“调度员”，Executor是“搬运工”。调度员（Driver）告诉搬运工（Executor）“把第3堆包裹送到上海”，搬运工实际搬包裹（处理RDD分区）。
集群架构与数据处理：Master管理车间（Worker），Worker提供搬运工（Executor），搬运工处理包裹批次（RDD分区），最终由调度员（Driver）汇总结果。

核心概念原理和架构的文本示意图

用户程序（Driver） → 提交任务给Master
Master → 分配Worker节点启动Executor
Executor → 从存储（HDFS/S3）读取RDD分区 → 处理数据（清洗/转换） → 输出结果
DataFrame → 基于RDD，附加列名和类型信息 → 优化执行计划（比RDD更高效）

Mermaid 流程图（Spark数据集成流程）

#mermaid-svg-R9KAqD1NHOxuIZwL{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-R9KAqD1NHOxuIZwL .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-R9KAqD1NHOxuIZwL .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-R9KAqD1NHOxuIZwL .error-icon{fill:#552222;}#mermaid-svg-R9KAqD1NHOxuIZwL .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-R9KAqD1NHOxuIZwL .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-R9KAqD1NHOxuIZwL .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-R9KAqD1NHOxuIZwL .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-R9KAqD1NHOxuIZwL .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-R9KAqD1NHOxuIZwL .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-R9KAqD1NHOxuIZwL .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-R9KAqD1NHOxuIZwL .marker{fill:#333333;stroke:#333333;}#mermaid-svg-R9KAqD1NHOxuIZwL .marker.cross{stroke:#333333;}#mermaid-svg-R9KAqD1NHOxuIZwL svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-R9KAqD1NHOxuIZwL p{margin:0;}#mermaid-svg-R9KAqD1NHOxuIZwL .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-R9KAqD1NHOxuIZwL .cluster-label text{fill:#333;}#mermaid-svg-R9KAqD1NHOxuIZwL .cluster-label span{color:#333;}#mermaid-svg-R9KAqD1NHOxuIZwL .cluster-label span p{background-color:transparent;}#mermaid-svg-R9KAqD1NHOxuIZwL .label text,#mermaid-svg-R9KAqD1NHOxuIZwL span{fill:#333;color:#333;}#mermaid-svg-R9KAqD1NHOxuIZwL .node rect,#mermaid-svg-R9KAqD1NHOxuIZwL .node circle,#mermaid-svg-R9KAqD1NHOxuIZwL .node ellipse,#mermaid-svg-R9KAqD1NHOxuIZwL .node polygon,#mermaid-svg-R9KAqD1NHOxuIZwL .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-R9KAqD1NHOxuIZwL .rough-node .label text,#mermaid-svg-R9KAqD1NHOxuIZwL .node .label text,#mermaid-svg-R9KAqD1NHOxuIZwL .image-shape .label,#mermaid-svg-R9KAqD1NHOxuIZwL .icon-shape .label{text-anchor:middle;}#mermaid-svg-R9KAqD1NHOxuIZwL .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-R9KAqD1NHOxuIZwL .rough-node .label,#mermaid-svg-R9KAqD1NHOxuIZwL .node .label,#mermaid-svg-R9KAqD1NHOxuIZwL .image-shape .label,#mermaid-svg-R9KAqD1NHOxuIZwL .icon-shape .label{text-align:center;}#mermaid-svg-R9KAqD1NHOxuIZwL .node.clickable{cursor:pointer;}#mermaid-svg-R9KAqD1NHOxuIZwL .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-R9KAqD1NHOxuIZwL .arrowheadPath{fill:#333333;}#mermaid-svg-R9KAqD1NHOxuIZwL .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-R9KAqD1NHOxuIZwL .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-R9KAqD1NHOxuIZwL .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-R9KAqD1NHOxuIZwL .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-R9KAqD1NHOxuIZwL .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-R9KAqD1NHOxuIZwL .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-R9KAqD1NHOxuIZwL .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-R9KAqD1NHOxuIZwL .cluster text{fill:#333;}#mermaid-svg-R9KAqD1NHOxuIZwL .cluster span{color:#333;}#mermaid-svg-R9KAqD1NHOxuIZwL div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-R9KAqD1NHOxuIZwL .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-R9KAqD1NHOxuIZwL rect.text{fill:none;stroke-width:0;}#mermaid-svg-R9KAqD1NHOxuIZwL .icon-shape,#mermaid-svg-R9KAqD1NHOxuIZwL .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-R9KAqD1NHOxuIZwL .icon-shape p,#mermaid-svg-R9KAqD1NHOxuIZwL .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-R9KAqD1NHOxuIZwL .icon-shape rect,#mermaid-svg-R9KAqD1NHOxuIZwL .image-shape rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-R9KAqD1NHOxuIZwL .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-R9KAqD1NHOxuIZwL .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-R9KAqD1NHOxuIZwL :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

数据输入

创建RDD/DataFrame

数据清洗（去重/填充空值）

数据转换（关联/聚合）

数据输出（写入Hive/数据库）

任务完成（Driver汇总结果）

核心算法原理 & 具体操作步骤

Spark的分布式计算核心：DAG调度与Stage划分

Spark处理任务时，会把用户代码转化为DAG（有向无环图），然后拆分成多个Stage（阶段），每个Stage包含多个Task（任务），Task由Executor并行执行。

举个例子：你要计算“所有订单中，每个用户的总消费金额”，步骤如下：

读取订单数据（Input Stage）：从HDFS读取数据，生成RDD。

清洗数据（Clean Stage）：过滤无效订单（如金额为0）。

分组聚合（Shuffle Stage）：按用户ID分组，计算总金额（需Shuffle，即跨节点传输数据）。

输出结果（Output Stage）：将结果写入数据库。

用Python代码演示核心操作（以数据清洗为例）

假设我们有一个CSV文件user_behavior.csv，包含用户行为数据（用户ID、行为类型、时间戳），需要清洗空值并统计每种行为的次数。

步骤1：初始化Spark会话

from pyspark.sql import SparkSession

# 创建Spark会话（本地模式，用于测试；生产环境需配置集群）
spark = SparkSession.builder \\
.appName("DataIntegrationDemo") \\
.master("local[*]") # 本地模式，使用所有CPU核心
.getOrCreate()

步骤2：读取数据（创建DataFrame）

# 读取CSV文件（自动推断列名和类型）
df = spark.read.csv(
path="user_behavior.csv",
header=True, # 第一行是表头
inferSchema=True # 自动推断列类型（如整数、字符串）
)

# 查看前5行数据
df.show(5)

输出示例：

+——-+———+———-+
|user_id|behavior |timestamp |
+——-+———+———-+
|1001 |click |1620000000|
|1002 |purchase |1620000001|
|1003 |null |1620000002| # 无效行为（空值）
|1001 |add_cart |1620000003|
+——-+———+———-+

步骤3：数据清洗（过滤空值、去重）

# 过滤behavior列为空的行（isNull判断）
clean_df = df.filter(df.behavior.isNotNull())

# 去重（按user_id和timestamp去重，避免重复记录）
distinct_df = clean_df.dropDuplicates(["user_id", "timestamp"])

# 查看清洗后的数据
distinct_df.show(5)

输出示例（空值行和重复行被删除）：

+——-+———+———-+
|user_id|behavior |timestamp |
+——-+———+———-+
|1001 |click |1620000000|
|1002 |purchase |1620000001|
|1001 |add_cart |1620000003|
+——-+———+———-+

步骤4：数据转换（统计行为次数）

# 按behavior列分组，统计次数
behavior_counts = distinct_df.groupBy("behavior").count()

# 按次数降序排序
sorted_counts = behavior_counts.orderBy("count", ascending=False)

# 显示结果
sorted_counts.show()

输出示例：

+———+—–+
|behavior |count|
+———+—–+
|click |15000|
|purchase |3000 |
|add_cart |2000 |
+———+—–+

步骤5：输出结果（写入数据库）

# 写入MySQL数据库（需配置JDBC连接）
sorted_counts.write \\
.format("jdbc") \\
.option("url", "jdbc:mysql://localhost:3306/analytics") \\
.option("dbtable", "behavior_stats") \\
.option("user", "root") \\
.option("password", "123456") \\
.mode("overwrite") # 覆盖模式（若表存在则替换）
.save()

数学模型和公式 & 详细讲解 & 举例说明

数据分区与并行度：如何拆分数据？

Spark将RDD拆分为多个分区（Partition），每个分区由一个Executor处理。分区数决定了并行度（分区越多，并行处理能力越强，但分区过多会增加调度开销）。

分区数公式：

分区数

max

⁡

(

文件总大小

块大小

最小分区数

)

\\text{分区数} = \\max\\left( \\frac{\\text{文件总大小}}{\\text{块大小}}, \\text{最小分区数} \\right)

$分区数 = max (\frac{文件总大小}{块大小}, 最小分区数)$

例如，HDFS默认块大小是128MB，一个10GB的文件会被拆分为

1024

128

10 \\times 1024 / 128 = 80

$10 \times 1024/128 = 80$ 个分区。

容错机制：Lineage（血统）如何恢复数据？

RDD通过Lineage记录数据的“生成路径”（即从原始数据到当前RDD的所有转换操作）。当某个分区丢失时，Spark可以根据Lineage重新计算该分区，而无需存储所有中间结果（节省内存）。

举例：假设RDD3由RDD2经过map操作生成，RDD2由RDD1经过filter操作生成。如果RDD3的一个分区丢失，Spark会重新执行RDD1→RDD2→RDD3的转换，恢复丢失的分区。

Shuffle的代价：为什么要尽量避免？

Shuffle是分布式计算中“跨节点传输数据”的过程（如groupBy、join操作）。Shuffle需要：

每个Executor将数据按分区规则（如哈希）写入本地磁盘

其他Executor从所有节点拉取属于自己的分区数据

合并数据后继续处理

Shuffle的代价公式（简化版）：

Shuffle开销

网络传输量

磁盘IO量

内存占用

\\text{Shuffle开销} = \\text{网络传输量} + \\text{磁盘IO量} + \\text{内存占用}

$Shuffle 开销 = 网络传输量 + 磁盘 IO 量 + 内存占用$

例如，对100GB数据进行groupBy操作，假设每个节点处理10GB，Shuffle时需将每个节点的10GB数据按哈希分布到所有节点，总网络传输量可能达到

100

100GB \\times N

$100 GB \times N$ （N为节点数），非常耗时！

项目实战：代码实际案例和详细解释说明

开发环境搭建（以本地模式为例）

安装Java（Spark依赖Java 8+）：官网下载JDK并配置JAVA_HOME环境变量。

安装Spark：从Spark官网下载预编译版本（如spark-3.3.2-bin-hadoop3），解压到/opt/spark。

安装Python依赖：

pip install pyspark pandas # pandas用于本地数据验证

验证安装：运行pyspark命令，看到Spark版本信息即成功。

源代码详细实现（电商用户行为数据集成）

假设我们要集成用户基本信息（user_info.csv）和用户行为日志（user_behavior.csv），计算“每个用户的总点击次数”。

步骤1：读取两个数据源

# 读取用户信息（user_id, name, age）
user_df = spark.read.csv("user_info.csv", header=True, inferSchema=True)

# 读取用户行为（user_id, behavior, timestamp）
behavior_df = spark.read.csv("user_behavior.csv", header=True, inferSchema=True)

步骤2：清洗行为数据（过滤非点击行为、空值）

# 只保留behavior='click'的记录
click_df = behavior_df.filter(behavior_df.behavior == "click")

# 过滤user_id为空的行
valid_click_df = click_df.filter(click_df.user_id.isNotNull())

步骤3：关联用户信息与行为数据（join操作）

# 按user_id关联两个DataFrame（类似SQL的JOIN）
joined_df = user_df.join(
valid_click_df,
on="user_id", # 关联键
how="inner" # 内连接（只保留两边都有数据的用户）
)

步骤4：统计每个用户的点击次数

from pyspark.sql.functions import count

# 按user_id分组，统计点击次数
user_click_count = joined_df.groupBy("user_id", "name", "age") \\
.agg(count("*").alias("click_count")) \\
.orderBy("click_count", ascending=False)

步骤5：输出结果到Excel（测试用）或Hive（生产用）

# 写入本地CSV（测试用）
user_click_count.write.csv("user_click_count_result", header=True, mode="overwrite")

# 写入Hive表（生产环境需配置Hive元数据）
user_click_count.write.mode("overwrite").saveAsTable("user_click_count")

代码解读与分析

join操作：需要Shuffle（跨节点传输数据），需确保关联键（user_id）分布均匀，避免数据倾斜（某节点处理过多数据）。
agg(count(“*”))：count("*")统计所有行（包括空值），count("behavior")统计非空值，根据业务需求选择。
orderBy：全局排序需要将所有数据拉到Driver节点，大数据量时慎用（可用sortWithinPartitions局部排序）。

实际应用场景

场景1：电商用户画像构建

集成用户基本信息（注册时间、性别）、行为数据（点击/购买记录）、交易数据（订单金额、退货率），通过Spark清洗、关联、聚合，生成用户标签（如“高价值用户”“沉睡用户”），用于精准营销。

场景2：日志数据分析

企业服务器每天产生TB级日志（访问日志、错误日志），用Spark读取日志文件（文本/JSON），提取关键字段（IP、访问路径、错误码），统计TOP10错误、热门页面，帮助优化系统性能。

场景3：IoT设备数据集成

工厂里的传感器每秒钟生成百万条数据（温度、湿度、设备状态），用Spark Streaming（Spark的实时处理组件）实时读取Kafka消息，清洗异常值（如温度>100℃），并聚合每分钟的平均温度，写入时序数据库（如InfluxDB），用于设备监控。

工具和资源推荐

必装工具

Spark官方文档：https://spark.apache.org/docs/latest/（最权威的学习资料）
Databricks：基于Spark的云平台（提供托管服务，适合企业级部署）
PyCharm/VS Code：推荐使用IDE编写Spark代码（支持代码补全、调试）

优化工具

Spark UI：任务运行时访问http://driver:4040，查看DAG图、Stage耗时、Shuffle量（定位性能瓶颈）。
Glowroot：分布式性能监控工具（监控Executor的CPU/内存使用情况）。

学习资源

书籍：《Spark: The Definitive Guide》（Spark官方团队合著，深入原理）
课程：Coursera《Big Data with Spark》（实战项目丰富）

未来发展趋势与挑战

趋势1：与AI深度融合

Spark MLlib（机器学习库）支持分布式训练，未来会更紧密集成TensorFlow/PyTorch，实现“数据集成→特征工程→模型训练”全流程一体化。

趋势2：实时化与批流统一

传统Spark处理分为批处理（Batch）和流处理（Streaming），未来会向批流统一发展（如Spark 3.0+的DataStreamWriter），用同一套API处理实时和离线数据。

挑战1：数据倾斜优化

当某一分区数据量远大于其他分区时（如双11某用户产生百万条行为记录），会导致该节点超时。需通过加盐分区（给关联键加随机数）、预处理过滤等方法解决。

挑战2：资源高效管理

Spark任务需要合理分配CPU/内存（如Executor的cores和memory参数），资源不足会导致任务慢，资源过剩会浪费。未来可能通过AI自动调优（如Google的AutoML for Spark）。

总结：学到了什么？

核心概念回顾

RDD：分布式数据批次，Spark的底层抽象。
DataFrame：带结构的RDD，适合结构化数据处理。
集群架构：Driver（调度）、Executor（执行）、Master（管理）协作完成任务。

概念关系回顾

RDD是“基础砖块”，DataFrame是“带标签的砖块”，两者共同支撑数据处理。
集群架构是“施工队”，Driver规划任务，Executor搬砖（处理RDD分区），Master管理施工队。

思考题：动动小脑筋

如果你要处理1PB的日志数据（非常大！），如何设置Spark的分区数？太大或太小会有什么问题？

数据集成时，经常遇到“同一用户在不同表中ID不同”（如用户表用user_id，行为表用uuid），如何用Spark解决这种“ID映射”问题？

假设你需要实时统计“过去1小时的用户点击数”，应该用Spark的哪个组件（Batch/Streaming）？为什么？

附录：常见问题与解答

Q：Spark任务运行很慢，如何定位问题？ A：通过Spark UI查看：

Stage耗时：哪个Stage最慢？可能是Shuffle或计算复杂。
Shuffle量：Shuffle读/写数据量是否过大？尝试减少Shuffle（如用广播变量替代大表JOIN）。
Executor状态：是否有Executor频繁GC（内存不足）？调大spark.executor.memory。

Q：DataFrame和RDD选哪个？ A：优先用DataFrame：

结构化数据处理更高效（Spark优化器自动优化执行计划）。
代码更简洁（类似SQL，易维护）。
仅当需要处理非结构化数据（如二进制文件）或自定义复杂算子时，才用RDD。

Q：如何避免数据倾斜？ A：

预处理：过滤掉异常大的key（如某用户行为记录过多，可能是机器人）。
加盐分组：给key加随机数（如user_id_1、user_id_2），先局部聚合，再全局聚合。
使用广播变量：小表JOIN时，将小表广播到所有Executor，避免Shuffle。

扩展阅读 & 参考资料

《Spark权威指南》（Bill Chambers等著）
Spark官方文档：https://spark.apache.org/docs/latest/
Databricks博客：https://www.databricks.com/blog（最新Spark技术动态）