金融图谱批流链路从入门到实战 - 第2节
2.1 批处理与流处理的区别
在金融图谱场景中，数据源天然分为“静态存量”与“动态增量”两类。批处理与流处理正是针对这两种数据形态设计的计算范式。理解两者的本质差异，是掌握批流一体架构的前提。
| 对比维度 | 批处理 (Batch Processing) | 流处理 (Stream Processing) |
|---|---|---|
| 数据范围 | 有界数据集（全量历史） | 无界数据流（持续到达） |
| 触发方式 | 定时调度（如 T+1 凌晨） | 事件驱动（记录到达即处理） |
| 延迟要求 | 分钟级 ~ 小时级 | 毫秒级 ~ 秒级 |
| 计算语义 | 全量扫描、精确一次 | 增量计算、至少一次 / 精确一次 |
| 典型场景 | 日终报表、风控模型训练 | 实时反欺诈、行情推送 |
| 存储模式 | HDFS / 数仓分区表 | Kafka / Pulsar 消息队列 |
金融图谱视角： 批处理负责构建“实体-关系”的基线快照（如全量企业股权结构），流处理负责实时更新边与属性的变更（如新增担保关系、风险等级变动）。两者缺一不可。
2.2 批流一体的技术演进
批流一体并非一蹴而就，其技术路线经历了三个主要阶段：
- 分离期（2010–2015）： 批处理用 MapReduce / Hive，流处理用 Storm / Spark Streaming（微批）。两套代码、两套运维，数据口径难以对齐。
- 融合期（2016–2020）： Flink 提出“批是流的特例”，统一 Runtime；Spark Structured Streaming 改进连续处理模式。同一引擎可切换批/流语义。
- 原生一体期（2021–至今）： 流式数仓（Kafka + Flink + Iceberg）、流式湖仓（Paimon / Hudi）实现存储与计算的双重统一，金融图谱开始采用“实时打宽 + 离线回溯”混合链路。
演进本质： 从“用两个引擎做两件事”变为“用一个引擎做所有事，按需选择延迟与准确性”。
2.3 Lambda 架构与 Kappa 架构对比
批流一体在系统架构层面最经典的两种模式是 Lambda 与 Kappa。下图展示了两种架构的核心组件与数据流向。
2.3.1 Lambda 架构
Lambda 架构由 Nathan Marz 提出，核心思想是“用两条路径分别保证低延迟与高准确性”：
- 批路径（Batch Layer）： 存储全量原始数据，定期（如每小时）重新计算完整结果，保证数据绝对准确。
- 流路径（Speed Layer）： 实时处理增量数据，提供秒级延迟的近似结果，弥补批路径的滞后。
- 合并服务层（Serving Layer）： 合并批结果与流结果，对外提供统一查询视图。
金融图谱中的痛点： 两套代码逻辑必须保持一致，但实际项目中常出现“批流不一致”问题——例如批处理用 Hive SQL 计算股权穿透，流处理用 Flink DataStream 实现，口径差异导致图谱查询结果在日切时出现跳变。
2.3.2 Kappa 架构
Kappa 架构由 Jay Kreps 提出，核心思想是“只用一套流处理引擎，通过日志重放实现历史计算”：
- 统一日志层： 所有数据以不可变日志形式存储在 Kafka 中，支持按偏移量或时间戳回溯。
- 单一流处理： 使用 Flink / Kafka Streams 同时处理实时数据与重放的历史数据。
- 无合并层： 不需要批路径，架构更简洁，但要求流引擎具备“状态快照”与“精确一次”语义。
适用条件： Kappa 架构要求数据源可重放（Kafka 保留足够长的日志），且计算逻辑支持幂等写入。在金融图谱中，适用于“实时关系更新 + 短周期回溯”的场景（如日内担保链变更）。
2.3.3 架构选型对比
| 评估维度 | Lambda 架构 | Kappa 架构 |
|---|---|---|
| 代码复杂度 | 高（两套代码 + 合并逻辑） | 中（一套代码，需处理回溯） |
| 数据准确性 | 高（批路径保证最终一致） | 高（需流引擎支持精确一次） |
| 运维成本 | 高（维护两套集群与调度） | 中（依赖 Kafka 日志保留策略） |
| 金融图谱适配 | 适合日终全量重建图谱 | 适合实时增量 + 短周期回溯 |
| 典型工具链 | Hive + Spark + Flink + HBase | Kafka + Flink + 状态后端 (RocksDB) |
实战建议： 金融图谱项目初期建议采用 Lambda 架构保证数据准确性，待流引擎稳定性验证通过后，逐步向 Kappa 架构演进，最终实现“批流一体”的单一技术栈。