2. 批流一体架构基础：Lambda 架构与 Kappa 架构对比
在风控网关场景中，数据链路需要同时处理实时交易事件（毫秒级）与历史批量回溯（小时/天级）。批流一体架构的选择直接决定了系统的实时性、一致性、运维复杂度与成本。当前主流方案为 Lambda 架构 与 Kappa 架构，两者在数据处理范式上存在本质差异。
2.1 Lambda 架构：双路计算，合并输出
Lambda 架构将数据流拆分为 批处理层（Batch Layer）与 流处理层（Speed Layer），分别计算后通过 服务层（Serving Layer）合并结果。批处理层提供全量、准确的历史视图；流处理层补偿批处理的延迟，提供近实时视图。
核心特征： 批与流使用两套独立代码逻辑，结果在查询时合并。典型组件：批处理（Spark Batch / Hive） + 流处理（Flink / Storm） + 服务层（HBase / Cassandra）。
2.2 Kappa 架构：单流处理，日志回放
Kappa 架构舍弃独立的批处理层，所有数据（包括历史回溯）均通过 同一套流处理引擎 处理。当需要重新计算历史数据时，通过回放消息队列（如 Kafka）中的全量日志，以流的方式重新消费，实现“批”的效果。
关键前提： 消息队列必须支持数据持久化与回溯（如 Kafka 的日志保留策略），且流处理引擎具备 Exactly-Once 语义与状态快照能力。
2.3 风控场景下的选型分析
风控网关对数据链路的 实时性、一致性、回溯能力 和 运维成本 有明确要求。下表从 6 个关键维度对比两种架构：
| 对比维度 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 实时性 | 流处理层秒级，批处理层小时级 | 统一秒级（回溯时受数据量影响） |
| 数据一致性 | 批流结果可能不一致，需合并逻辑补偿 | 单流处理，天然一致（Exactly-Once） |
| 历史回溯能力 | 强（批处理层天然支持全量重算） | 依赖消息队列保留时长与存储容量 |
| 运维复杂度 | 高（两套代码、两套集群、合并逻辑） | 低（单一引擎、单一代码逻辑） |
| 资源成本 | 高（批流独立集群，资源冗余） | 中（单集群，回溯时需额外算力） |
| 适用风控场景 | 离线模型训练 + 实时规则引擎混合 | 实时特征计算 + 在线模型推理 |
2.4 风控网关选型建议
- 优先选择 Kappa 架构：当风控链路以实时特征计算、在线模型推理、毫秒级决策为主，且消息队列（Kafka）保留窗口可覆盖回溯需求（如 7~30 天）。Kappa 架构能显著降低运维成本与数据不一致风险。
- 保留 Lambda 架构：当风控系统需要同时支撑离线模型训练（全量历史数据）与实时决策，且离线与实时计算逻辑差异较大（如离线使用复杂 Join，实时使用简单聚合）。此时可考虑批流分离，但需投入额外资源维护合并逻辑。
- 混合演进方案：部分风控团队采用“Kappa 为主，Lambda 为辅”的过渡策略——实时链路走 Kappa，离线模型训练通过定时导出流处理状态快照实现，避免维护两套独立代码。
避坑提示： 不要为了“技术潮流”盲目选择 Kappa 架构。如果风控场景需要频繁进行大规模历史数据重跑（如 T+1 全量特征回溯），且消息队列无法承载全量日志，Lambda 架构的批处理层仍是更稳定的选择。选型前务必评估数据保留策略、回溯频率与集群资源上限。