1. 课程导论与背景：为什么需要从 Spark 批处理演进到流式决策？
1.1 额度定价链路的业务痛点
在金融风控领域，额度定价是信贷业务的核心环节。传统基于 Spark 批处理的额度计算架构，在面对日益复杂的业务场景时，暴露出以下关键痛点：
| 痛点维度 | 具体表现 | 业务影响 |
|---|---|---|
| 时效性滞后 | Spark 批处理通常以 T+1 或小时级周期运行，无法感知用户实时行为变化 | 用户额度与当前风险状态脱节，导致优质客户流失或风险敞口扩大 |
| 决策僵化 | 批处理模型依赖离线特征，无法融入实时事件（如多头借贷、设备指纹、交易行为） | 额度定价策略无法动态调整，错失拦截欺诈或提升转化的窗口期 |
| 数据口径不一致 | 离线数仓与在线服务数据源分离，特征计算逻辑存在偏差 | 同一用户在不同渠道的额度结果不一致，引发合规与客诉风险 |
| 运维成本高 | 批处理链路依赖 Hive/Spark SQL 调度，失败重跑耗时长，且与在线服务耦合 | 故障恢复慢，SLA 难以保障，影响业务连续性 |
案例提示： 某头部消费金融平台曾因 Spark 批处理延迟，导致用户在 10 分钟内发生 3 次多头借贷后仍获得高额度，最终造成 200 万元坏账。该事件直接推动了流式决策架构的立项。
1.2 技术挑战：从批处理到流式的演进障碍
从 Spark 批处理迁移到流式决策，并非简单的框架替换，而是整个技术栈的重构。主要挑战包括：
- 状态管理复杂性： 额度定价需要维护用户长期行为画像（如近 30 天借贷次数、历史还款记录），流式计算中状态存储与容错机制的设计难度远高于批处理。
- 事件时间 vs 处理时间： 批处理天然基于数据快照，而流式决策必须处理乱序事件、延迟数据、水位线（Watermark）对齐等问题，否则会导致额度计算偏差。
- 特征计算一致性： 离线特征（如 Spark 生成的聚合指标）与实时特征（如 Kafka 流中的事件）需要统一口径，避免“同人不同额”的尴尬。
- 资源弹性与成本： 流式作业需要 7×24 小时运行，资源利用率与批处理差异巨大，如何平衡延迟、吞吐与成本是架构设计的核心。
避坑指南： 很多团队在初期尝试直接复用 Spark Structured Streaming 的批处理逻辑，结果发现状态后端（RocksDB/HDFS）的读写性能成为瓶颈，且 Exactly-Once 语义在复杂业务场景下难以保证。建议在架构设计阶段就明确区分“状态存储”与“计算引擎”的职责。
1.3 流式决策架构总览
下图展示了从数据源到额度定价的流式决策核心链路，对比传统批处理架构，流式架构在实时性、状态管理和决策闭环上做了根本性改进：
1.4 为什么选择流式决策？—— 核心收益对比
| 对比维度 | Spark 批处理架构 | 流式决策架构 |
|---|---|---|
| 决策延迟 | 分钟级 ~ 小时级 | 毫秒级 ~ 秒级 |
| 状态更新 | 离线快照，T+1 更新 | 实时增量，事件触发 |
| 特征时效 | 依赖离线数仓，滞后明显 | 融合实时事件与离线画像 |
| 容错恢复 | 任务重跑，耗时较长 | 基于状态快照 + 日志回放 |
| 业务灵活性 | 策略变更需重新调度 | 动态规则热加载 |
| 资源成本 | 波峰波谷明显，资源浪费 | 持续运行，弹性伸缩 |
课程定位： 本课程将带你从零搭建一套完整的流式额度定价链路，涵盖 Flink 状态编程、实时特征工程、决策引擎集成、性能调优与生产化部署。无论你是大数据工程师、风控算法同学还是架构师，都能从中找到可落地的实践方案。