2. Spark 基础回顾：Spark Core 核心概念与 Spark SQL/Streaming

在构建反欺诈实时评分管道之前，必须牢固掌握 Spark 的三大核心抽象：RDD（弹性分布式数据集）、DAG（有向无环图）调度引擎以及 Shuffle 机制。同时，Spark SQL 的结构化数据处理能力和 Spark Streaming 的微批处理模型是实时评分管道的两大技术支柱。本节将系统梳理这些基础概念，为后续管道设计打下坚实根基。

2.1 Spark Core 核心概念

2.1.1 RDD：弹性分布式数据集

RDD 是 Spark 中最基本的数据抽象，代表一个不可变、可分区、可并行计算的数据集合。RDD 的“弹性”体现在：当部分分区丢失时，可以通过血统（Lineage）信息重新计算恢复，无需额外备份。

特性 说明 反欺诈场景意义
不可变性 RDD 一旦创建就不能修改，只能通过转换生成新 RDD 保证数据在计算过程中不被意外篡改，审计友好
分区性 数据被切分成多个分区，分布在集群不同节点上 支持对海量交易事件并行处理，提升吞吐
血统 记录 RDD 的依赖关系，用于故障恢复 长时间运行的评分管道中，节点故障可快速恢复
惰性求值 转换操作（如 map、filter）只记录依赖，不立即计算 优化执行计划，减少不必要的中间结果落盘
实践提示：在反欺诈场景中，RDD 的不可变性意味着每笔交易事件一旦被封装成 RDD 记录，就不会被后续操作修改。这天然符合金融审计对数据完整性的要求。

2.1.2 DAG：有向无环图与作业调度

Spark 将用户的一系列 RDD 转换操作构建成一个 DAG（有向无环图）。DAG 描述了 RDD 之间的依赖关系，并作为 Spark 调度器生成物理执行计划的依据。DAG 被划分为多个 Stage，每个 Stage 包含一组可以流水线执行的窄依赖任务。

核心调度流程： RDD 转换构建 DAG → DAGScheduler 划分 Stage → TaskScheduler 分发 Task 到 Executor → 每个 Executor 并行执行 Task。
DAG 调度与 Stage 划分示意图 读取交易日志 filter(欺诈标记) map(提取特征) join(用户画像) Stage 0：窄依赖（流水线执行） Stage 1：宽依赖（需 Shuffle） Shuffle 边界 Executor 1 Executor 2 Executor 3 Executor 4 评分结果 RDD 说明：窄依赖（Stage 0）内多个转换可流水线执行，无需跨节点数据移动；宽依赖（Stage 1）因 join 操作需要 Shuffle， 成为 Stage 划分边界。DAGScheduler 据此将作业拆分为多个 Stage。

2.1.3 Shuffle：数据重分区与性能关键

Shuffle 是 Spark 中最昂贵的操作，发生在宽依赖（如 groupByKey、join、repartition）时。Shuffle 过程需要将数据在集群节点间重新分发，涉及磁盘 I/O、网络传输和序列化/反序列化。

反欺诈性能陷阱：在实时评分管道中，频繁的 Shuffle 会显著增加延迟。例如，对交易流进行 groupByKey 按用户聚合时，如果用户 ID 分布不均匀，会导致数据倾斜，部分 Executor 负载过高，拖慢整体评分速度。建议优先使用 reduceByKey 或 aggregateByKey 等预聚合算子，减少 Shuffle 数据量。

2.2 Spark SQL 与 DataFrame

Spark SQL 是 Spark 处理结构化数据的核心模块，其核心抽象是 DataFrame。DataFrame 是组织成命名列的分布式数据集合，在 RDD 之上提供了更高级的声明式 API，并内置了 Catalyst 优化器 和 Tungsten 执行引擎。

特性 RDD DataFrame 反欺诈场景推荐
数据表示 Java/Python 对象 Row 对象 + Schema DataFrame 自带 Schema，便于定义交易字段类型
API 风格 函数式（map/filter） 声明式（select/where/groupBy） SQL 风格更易编写复杂特征计算逻辑
性能优化 开发者手动优化 Catalyst 自动优化执行计划 自动谓词下推、列剪枝，减少 I/O
序列化 Java/Kryo 序列化 Tungsten 二进制格式（堆外内存） 减少 GC 压力，适合高吞吐评分
Catalyst 优化器关键优化： 谓词下推（Predicate Pushdown）——将 filter 条件下推到数据源，减少读取的数据量；列剪枝（Column Pruning）——只读取查询所需的列，避免全表扫描。在反欺诈场景中，这两项优化可大幅降低特征提取阶段的 I/O 开销。 
// 使用 DataFrame API 进行反欺诈特征提取
Dataset<Row> transactions = spark.read()
    .option("header", "true")
    .csv("hdfs://logs/transactions/");

// Catalyst 自动优化：只读取 account_id, amount, timestamp 三列
Dataset<Row> highRiskTxns = transactions
    .select("account_id", "amount", "timestamp", "merchant_id")
    .where("amount > 10000")
    .groupBy("account_id")
    .agg(
        count("transaction_id").as("txn_count_1h"),
        sum("amount").as("total_amount_1h")
    );

2.3 Spark Streaming 微批处理模型

Spark Streaming 将实时数据流切分成一系列微批次（Micro-batches），每个微批次被当作一个 RDD/DataFrame 处理。这种“批处理流”模型牺牲了亚秒级延迟，换来了高吞吐和 exactly-once 语义保障，非常适合金融反欺诈场景。

Spark Streaming 微批处理模型 交易事件流 批次 1 批次 2 批次 3 批次 4 批次 5 时间 Spark Streaming 引擎（微批处理） 评分结果输出（每批次一次） 说明：每个微批次（如 2 秒间隔）被封装为一个 DataFrame，经过特征提取、模型预测后输出评分结果。批次间隔决定了延迟上限。

微批处理 vs 原生流处理

对比维度 Spark Streaming（微批） Flink（原生流） 反欺诈场景选择依据
延迟 秒级（通常 1-10 秒） 毫秒级 反欺诈通常接受秒级延迟，微批足够
吞吐 极高（批处理优化） 高 微批在吞吐上更有优势，适合大流量
Exactly-once 原生支持（结合 WAL） 原生支持 两者均满足金融级一致性要求
与批处理统一 同一引擎，代码复用 需额外配置 Spark 可同时处理历史批数据和实时流
课程实践要点：本课程的反欺诈管道将使用 Spark Structured Streaming（基于 DataFrame API 的流处理），它继承了微批模型的高吞吐优势，同时提供了更简洁的 event-time 处理和 watermark 机制，非常适合处理乱序到达的交易事件。

2.4 本章小结

  • RDD 是 Spark 的底层抽象，提供不可变、分区、血统恢复等核心能力；DAG 调度引擎通过 Stage 划分优化作业执行；Shuffle 是性能关键，需谨慎设计。
  • Spark SQL / DataFrame 提供了声明式 API 和 Catalyst 优化器，在反欺诈特征提取中可自动进行谓词下推和列剪枝，显著提升 I/O 效率。
  • Spark Streaming 的微批处理模型以秒级延迟换取高吞吐和 exactly-once 语义，是构建实时评分管道的理想选择。
← 上一章 📖 返回目录 下一章 →