4. 实时数据流架构：从数据采集到模型推理再到结果回传的端到端实时管道设计

本章聚焦于精算模型在实时数据流中的完整生命周期。一个成熟的实时管道并非简单的“数据进、结果出”，而是由采集层、缓冲层、计算层、推理层与回传层构成的闭环系统。Kafka 在其中扮演了核心消息总线的角色，确保各阶段解耦与数据不丢失。

4.1 端到端实时管道总体架构

下图展示了从业务数据产生到精算结果落地的五层架构。每一层都对应明确的组件与职责，层与层之间通过 Kafka Topic 进行异步通信。

4.2 核心组件与职责矩阵

下表列出了各层的关键组件、技术选型及在精算场景下的特殊要求。

4.3 数据采集与入 Kafka 的标准化流程

数据采集阶段需要将异构数据源统一为标准事件格式，避免下游解析混乱。推荐使用 Avro 或 Protobuf 作为序列化协议，并注册 Schema Registry。

1. 数据库 CDC 采集：Debezium 监听 MySQL/PostgreSQL 的 binlog，将行变更转换为 Kafka 消息。每条消息包含 before/after 镜像与操作类型。
2. 应用日志采集：Filebeat 或 Fluentd 采集 JSON 格式日志，通过 Kafka Connect 写入原始日志 Topic。
3. 客户端 SDK 上报：移动端或 Web 端通过 HTTP/2 或 gRPC 上报埋点事件，网关层直接写入 Kafka。
4. 标准化清洗：在流式计算层对原始事件进行字段补齐、类型转换、异常值过滤，输出为“标准化事件 Topic”。

4.4 流式计算与特征工程

流式计算层是精算管道的“加工车间”。原始事件在此被聚合、关联、转换为模型所需的特征向量。Flink 是当前最主流的选型，其事件时间窗口与状态后端机制非常适合精算场景。

典型的特征工程步骤包括：

• 滑动窗口聚合：计算过去 5 分钟、30 分钟、24 小时的累计值（如交易金额、频次）。
• 跨事件关联：将当前事件与用户画像、设备指纹等静态数据做 Join。
• 特征编码：将类别特征转换为 Embedding 或 One-Hot 向量；数值特征做 Z-score 标准化。
• 特征向量组装：按模型输入顺序拼接特征，输出为固定长度的 Float 数组。

// Flink SQL 示例：滑动窗口聚合特征
CREATE VIEW user_5min_agg AS
SELECT
  user_id,
  COUNT(*) AS event_count,
  SUM(amount) AS total_amount,
  TUMBLE_END(event_time, INTERVAL '5' MINUTE) AS window_end
FROM raw_events
GROUP BY
  user_id,
  TUMBLE(event_time, INTERVAL '5' MINUTE);

4.5 模型推理层的集成模式

推理层接收特征向量 Topic 的数据，调用精算模型返回风险评分。根据延迟与吞吐要求，有两种主流集成模式：

在精算复盘场景中，推荐使用异步 Topic 推理模式。该模式天然支持消息回溯与重试，便于后续的“命中复盘”环节重新计算或验证历史评分。

4.6 结果回传与闭环设计

推理结果需要回传至业务系统（如风控决策引擎、交易系统）并同时写入复盘存储。回传层必须处理以下关键问题：

• 幂等性：同一笔推理结果可能因重试被多次消费，下游业务系统需通过唯一 ID（如 event_id）去重。
• 死信队列：回传失败超过重试次数的消息，转入死信 Topic 供人工排查。
• 复盘存储：将原始事件、特征向量、推理结果、模型版本号一并写入 ClickHouse 或 Elasticsearch，支持快速检索与对比。

4.7 管道监控与可观测性

端到端管道需要覆盖以下监控维度，确保在复盘时能快速定位数据断层或延迟瓶颈：

推荐使用 Prometheus + Grafana 统一采集与展示上述指标，并在 Kafka 侧启用 JMX Exporter 获取 Broker 级别的性能数据。