4. Spark 核心回顾：RDD、DataFrame、Dataset 概念、Spark SQL 与 Catalyst 优化器、Spark 作业执行流程
在深入《Spark 回放反欺诈图谱数据血缘》之前，必须夯实 Spark 核心基础。本章将系统回顾 Spark 的三大抽象（RDD、DataFrame、Dataset）、Spark SQL 的 Catalyst 优化器以及作业执行流程，为后续构建反欺诈图谱血缘链路打下坚实的技术根基。
4.1 三大核心抽象：RDD、DataFrame、Dataset
Spark 提供了三种主要的数据抽象，它们在类型安全、性能优化和易用性上各有侧重。理解其差异是选择正确 API 的关键。
| 特性 | RDD (Resilient Distributed Dataset) | DataFrame | Dataset |
|---|---|---|---|
| 引入版本 | Spark 1.0 | Spark 1.3 | Spark 1.6 |
| 数据表示 | Java/Scala 对象，无 Schema | Row 对象，带有 Schema（列名+类型） | 强类型 JVM 对象，带有 Schema |
| 类型安全 | 编译时类型安全 | 运行时类型安全 | 编译时类型安全 |
| 序列化方式 | Java/Kryo 序列化（较重） | Off-Heap 二进制存储（Tungsten 优化） | Off-Heap 二进制存储（Tungsten 优化） |
| GC 开销 | 高（大量 Java 对象） | 低（堆外内存管理） | 低（堆外内存管理） |
| Catalyst 优化 | 不支持 | 完全支持（逻辑/物理优化） | 完全支持（逻辑/物理优化） |
| 适用场景 | 底层数据操作、自定义分区、非结构化数据 | 数据探索、ETL、SQL 分析、反欺诈特征工程 | 需要类型安全且高性能的复杂 ETL 管线 |
反欺诈选型建议： 在反欺诈图谱血缘场景中，DataFrame 是首选。它既能享受 Catalyst 的极致优化，又能通过 SQL 或 DSL 快速表达复杂的关联规则和聚合逻辑。仅在需要自定义序列化或操作非结构化日志时，才考虑 RDD。
4.2 Spark SQL 与 Catalyst 优化器
Spark SQL 是 Spark 处理结构化数据的核心模块，其性能关键依赖于 Catalyst 优化器。Catalyst 是一个基于规则和代价的查询优化框架，它将用户提交的 SQL 或 DataFrame 操作转化为高效的物理执行计划。
4.2.1 Catalyst 优化流程
Catalyst 的优化过程分为四个主要阶段：
- 分析（Analysis）： 解析 SQL 或 DataFrame 的未解析逻辑计划，通过 Catalog 解析表名、列名和数据类型，生成解析后的逻辑计划。
- 逻辑优化（Logical Optimization）： 应用一系列基于规则的优化，如谓词下推（Predicate Pushdown）、列剪枝（Column Pruning）、常量折叠（Constant Folding）等，生成优化的逻辑计划。
- 物理计划（Physical Planning）： 将逻辑计划转换为一个或多个物理计划（如选择不同的 Join 策略：BroadcastHashJoin、SortMergeJoin），并根据代价模型（Cost Model）选择最优的物理计划。
- 代码生成（Code Generation）： 使用 Whole-Stage Code Generation（全阶段代码生成）将选中的物理计划编译为高效的 Java 字节码，减少虚函数调用和内存分配。
反欺诈血缘优化点： 在构建反欺诈图谱时，经常需要关联多个交易表、设备指纹表和黑名单表。Catalyst 的 谓词下推 和 列剪枝 能显著减少 Shuffle 数据量，避免读取无关的“设备型号”或“IP 段”列，从而加速血缘回溯查询。
4.3 Spark 作业执行流程
一个 Spark 作业从提交到执行，经历了从高层逻辑到分布式物理执行的完整过程。理解这一流程有助于诊断反欺诈血缘计算中的性能瓶颈。
4.3.1 核心执行阶段
| 阶段 | 组件 | 关键动作 | 反欺诈血缘场景示例 |
|---|---|---|---|
| 1. 作业提交 | SparkSubmit / Driver | 解析用户代码，构建 DAG（有向无环图） | 提交“计算 24h 内关联交易图谱”的作业 |
| 2. DAG 调度 | DAGScheduler | 将 DAG 切分为 Stage（宽依赖为界） | Join 操作产生 Shuffle，切分为 ShuffleMapStage 和 ResultStage |
| 3. 任务调度 | TaskScheduler | 将 Stage 内的 Task 分发到 Executor | 每个图谱分区的 Task 被分配到不同节点 |
| 4. 任务执行 | Executor | 执行 Task，进行数据读取、计算、Shuffle 写 | Executor 读取 HDFS 上的交易日志，构建本地子图 |
| 5. 结果返回 | Driver | 收集或存储最终结果 | 将构建好的图谱血缘关系写入图数据库（如 Neo4j） |
4.3.2 宽依赖与窄依赖
Stage 的划分依据是 宽依赖（Wide Dependency） 与 窄依赖（Narrow Dependency）：
- 窄依赖： 父 RDD 的每个分区最多被子 RDD 的一个分区使用（如
map、filter）。
→ 无需 Shuffle，可流水线执行。 - 宽依赖： 父 RDD 的每个分区可能被子 RDD 的多个分区使用（如
groupByKey、join）。
→ 需要 Shuffle，是 Stage 划分的边界。
反欺诈性能陷阱： 在构建大规模图谱血缘时，频繁的
groupByKey 或 join 会产生大量宽依赖。建议优先使用 reduceByKey 或 map-side combine 来减少 Shuffle 数据量。对于反欺诈中的“设备关联图谱”，尽量在 Join 前对设备 ID 进行预聚合，降低 Shuffle 规模。
4.4 小结：反欺诈图谱血缘中的 Spark 核心应用
回顾本章核心要点：
- RDD 提供底层灵活性，但性能受限于 Java 序列化；DataFrame 是反欺诈特征工程和血缘分析的主力 API。
- Catalyst 优化器 通过谓词下推、列剪枝和代码生成，将复杂的图谱关联查询编译为高效物理计划。
- 作业执行流程 中，宽依赖（Shuffle）是性能瓶颈的主要来源，在反欺诈场景中应通过预聚合和 Broadcast Join 等手段优化。