2. 传统Spark批处理架构回顾:Spark Core/RDD/DataFrame基础,批处理在额度定价中的典型应用(T+1离线计算)

在进入流式决策之前,必须深刻理解传统批处理架构的基石。Spark 批处理模式(T+1)至今仍是金融风控领域额度定价、额度管理、贷后监控等场景的主力计算引擎。本章从 Spark Core 核心抽象 RDD 出发,逐步过渡到 DataFrame 结构化 API,并剖析其在额度定价离线链路中的典型应用。

2.1 Spark Core 与 RDD:分布式计算的基石

RDD(Resilient Distributed Dataset)是 Spark 最核心的抽象,代表一个不可变、可分区、可并行计算的数据集合。RDD 的五大特性决定了其容错与调度能力:

特性 说明 在额度定价中的意义
分区列表 数据被切分为多个分区,分布在集群节点上 支持海量用户额度数据并行加载
计算函数 每个分区上执行相同的算子逻辑 统一计算额度使用率、逾期率等指标
依赖关系 记录 RDD 之间的血缘(Lineage) 任务失败时可基于血缘重算,保障定价链路稳定
分区器 控制数据如何分布(Hash/Range 分区) 按用户 ID 分区,避免额度汇总时数据倾斜
首选位置 数据本地性调度,减少网络传输 HDFS 上的历史额度快照就近计算
关键认知: RDD 的不可变性和血缘机制,使得金融风控场景下的数据回溯、审计重算成为可能。任何额度定价策略的调整,都可以通过重新执行 RDD 的 DAG 来复现历史结果。

2.2 DataFrame:结构化数据的高阶抽象

DataFrame 在 RDD 之上增加了 Schema 信息,将分布式数据集合组织为命名列。相比 RDD,DataFrame 通过 Catalyst 优化器自动生成高效执行计划,在额度定价的 ETL 和特征工程中性能提升 2-5 倍。

以下是一个典型的额度定价离线 ETL 代码片段,展示 DataFrame 的声明式风格:

// 读取 Hive 中的用户基础信息表和额度使用表
Dataset<Row> userDF = spark.read().table("risk.user_base");
Dataset<Row> quotaDF = spark.read().table("risk.quota_usage");

// 关联、聚合、计算额度使用率
Dataset<Row> resultDF = userDF.join(quotaDF, "user_id")
    .groupBy("user_id", "credit_level")
    .agg(
        sum("used_amount").as("total_used"),
        max("total_limit").as("current_limit")
    )
    .withColumn("usage_rate", col("total_used").divide(col("current_limit")))
    .filter(col("usage_rate").gt(0.8));  // 筛选高使用率用户

resultDF.write().mode(SaveMode.Overwrite).saveAsTable("risk.quota_risk_daily");
实践建议: 在额度定价的离线批处理中,优先使用 DataFrame API 而非 RDD。DataFrame 的 Catalyst 优化器会自动做谓词下推、列剪枝、广播 Join 等优化,显著减少 Shuffle 开销。

2.3 批处理在额度定价中的典型应用:T+1 离线计算链路

传统额度定价系统以 T+1 批处理为核心节奏,每日凌晨执行全量或增量计算,产出当日额度策略。下图展示了典型的离线批处理链路:

额度定价 T+1 离线批处理链路 Hive 历史快照 MySQL 业务库 Kafka 日志 Spark ETL:数据清洗、关联、特征衍生 特征工程:额度使用率、逾期天数、多头借贷数 模型评分 & 额度定价:输出每日额度策略

上述链路中,Spark 批处理承担了三个核心职责:

  1. 多源数据整合: 从 Hive、MySQL、Kafka 日志中拉取用户基本信息、额度使用流水、外部征信数据,通过 Join 和 Union 构建宽表。
  2. 特征工程计算: 基于时间窗口聚合用户行为,计算额度使用率、近 30 天逾期次数、多头借贷平台数等关键风险特征。
  3. 模型评分与定价: 加载预训练的评分模型(如 XGBoost、逻辑回归),对每个用户输出风险评分,并根据评分卡规则映射为最终额度与利率。

2.4 批处理架构的局限性

尽管 T+1 批处理在稳定性、可审计性方面表现优异,但在实时风控场景下存在明显短板:

维度 批处理(T+1) 流式处理(实时)
延迟 至少 1 天,通常凌晨 2-6 点产出 秒级到分钟级
数据新鲜度 基于昨日快照,无法感知当天行为 实时消费事件流,立即响应
额度调整时效 次日生效,无法拦截当日突增风险 实时触发额度冻结、降额、提额
计算模式 全量扫描 + 批量聚合 增量计算 + 状态管理
架构演进启示: 批处理架构在额度定价中不会消失,但单纯依赖 T+1 计算已无法满足“秒级拦截欺诈交易”、“实时调整多头借贷用户额度”等业务需求。下一章将引入 Spark Streaming 与 Structured Streaming,在批处理基础上构建流批一体的额度定价体系。

2.5 本章小结

  • RDD 是 Spark 的底层抽象,提供容错、分区、数据本地性等核心能力,适合需要精细控制计算逻辑的场景。
  • DataFrame 基于 Schema 和 Catalyst 优化器,在结构化数据处理中性能更优,是额度定价 ETL 的首选 API。
  • T+1 批处理链路覆盖数据采集、特征工程、模型评分全流程,是当前金融风控额度定价的主流实现方式。
  • 批处理在延迟和数据新鲜度上的局限,驱动着架构向流式决策演进。