批流一体风控链路优化技巧课程 - 第1节

1.1 批处理与流处理：核心概念对比

在构建风控系统时，数据处理的时效性直接决定了风险拦截的有效性。批处理与流处理是两种截然不同的数据计算范式，理解其本质差异是掌握批流一体架构的基础。

1.2 架构演进：从 Lambda 到 Kappa

为了解决批与流分离带来的数据一致性与维护成本问题，业界经历了两次重要的架构演进。

1.2.1 Lambda 架构：批流分离的经典方案

Lambda 架构将数据通路分为批处理层（Batch Layer）、速度层（Speed Layer）和服务层（Serving Layer）。批处理层提供全量、准确的视图，但延迟高；速度层提供低延迟的近似视图，但精度有限。服务层负责合并两路结果。

• 优点： 兼顾了历史全量计算的准确性与实时计算的低延迟。
• 痛点： 需要维护两套代码逻辑（批处理 Job + 流处理 Job），数据口径容易产生偏差；运维复杂度高，数据回溯时需要同时修正批和流两套链路。

1.2.2 Kappa 架构：统一流处理的新范式

Kappa 架构的核心思想是：一切皆流。所有数据（包括历史数据）都通过统一的流处理引擎处理，通过重放消息队列中的历史数据来实现全量计算，从而舍弃了独立的批处理层。

• 优点： 单一技术栈，逻辑统一，运维简化；数据回溯只需重放日志，无需维护两套代码。
• 挑战： 对消息队列的吞吐量和保留时长要求较高；流处理引擎的状态管理能力成为瓶颈。

1.3 批流一体在风控中的核心价值

批流一体并非简单的技术选型，而是为了解决风控系统在实时性、准确性和运维效率之间的根本矛盾。其核心价值体现在以下三个维度：

1.3.1 消除数据口径偏差

在传统 Lambda 架构中，批处理与流处理使用不同的计算逻辑，导致同一指标（如“用户当日累计交易金额”）在实时大屏与离线报表中数值不一致。批流一体通过同一套 SQL/算子处理实时与历史数据，从根源上保证了数据口径的统一。

1.3.2 降低运维与开发成本

• 单一技术栈： 团队只需精通 Flink 或 Spark Streaming 等一套引擎，降低招聘与学习成本。
• 简化数据回溯： 当风控规则或模型迭代时，只需重置消费位点（Offset），重放消息队列中的历史数据即可完成重新计算，无需编写独立的批处理 Job。
• 资源复用： 实时链路与离线链路共享计算集群，提高资源利用率。

1.3.3 支持实时 + 离线融合的复杂风控场景

现代风控策略往往需要同时依赖实时特征（如当前设备指纹）与离线特征（如用户过去30天的行为画像）。批流一体架构允许在同一个作业中：

• 通过流处理计算秒级滑动窗口（如最近5分钟登录次数）。
• 通过维表 Join 或异步 I/O 关联 HBase/MySQL 中的离线画像数据。
• 通过状态后端（State Backend）维护用户会话状态，实现跨事件的复杂规则判断。