4. 数据采集层设计：埋点规范、日志采集、消息队列（Kafka）接入、实时数据流
贷后风险秒级拦截的根基在于数据采集层。该层负责将分散在 API 网关、业务服务、风控引擎中的原始事件，以统一、可靠、低延迟的方式汇聚到实时数据管道中。本章围绕埋点规范、日志采集、Kafka 接入与实时数据流四个核心环节展开设计。
4.1 埋点规范：统一事件模型
所有贷后风险事件必须遵循统一的埋点协议，确保下游消费方无需适配多套格式。我们采用 Flat-Event 2.0 规范，每个事件包含以下三层结构：
| 层级 | 字段组 | 示例字段 | 说明 |
|---|---|---|---|
| L1 元数据 | 事件标识 | event_id, event_type, source, timestamp |
全局唯一、不可变 |
| L2 上下文 | 请求/响应快照 | api_path, http_method, status_code, latency_ms |
API 网关自动注入 |
| L3 业务载荷 | 风控特征 | user_id, loan_id, overdue_days, risk_score |
业务系统按需填充 |
埋点避坑：禁止在业务载荷中嵌套 JSON 对象；所有字段必须拍平为 string/number/boolean 基本类型，否则 Kafka Schema Registry 无法做兼容性校验。
4.2 日志采集：Agent 与 Sidecar 双模架构
针对容器化与虚拟机混合部署场景，我们采用 Filebeat + Sidecar 双模采集方案：
- 容器环境：每个 Pod 注入日志采集 Sidecar（基于 Fluent Bit），直接从 stdout/stderr 流式读取，延迟 < 200ms。
- 虚拟机环境：部署 Filebeat DaemonSet，监听固定日志路径（如
/var/log/risk-engine/*.log），使用多行匹配规则合并 Java 异常栈。 - 统一输出：所有采集端均将日志写入 Kafka Topic
raw-risk-log，禁止直接写 Elasticsearch 或文件。
# Filebeat 配置示例：多行匹配 Java 异常栈
filebeat.inputs:
- type: log
paths:
- /var/log/risk-engine/*.log
multiline:
pattern: '^\d{4}-\d{2}-\d{2}'
negate: true
match: after
output.kafka:
hosts: ["kafka-1:9092", "kafka-2:9092"]
topic: "raw-risk-log"
partition.round_robin:
reachable_only: true4.3 消息队列（Kafka）接入设计
Kafka 作为实时数据流的骨干，必须围绕高吞吐、有序性、可回溯三个目标进行主题规划与参数调优。
4.3.1 主题（Topic）规划
| Topic 名称 | 分区数 | 副本数 | 保留时间 | 数据来源 |
|---|---|---|---|---|
raw-risk-log |
12 | 3 | 7 天 | 日志采集 Agent |
risk-event |
24 | 3 | 3 天 | API 网关 / 业务服务 |
risk-decision |
8 | 3 | 30 天 | 风控引擎输出 |
risk-alert |
4 | 2 | 90 天 | 规则引擎告警 |
关键参数：分区数 = max(消费者线程数 × 2, 预期峰值 TPS / 10MBps)。
risk-event 使用 key 为 user_id 保证同一用户的事件顺序；raw-risk-log 使用轮询分区，不保证全局有序。
4.3.2 生产者与消费者配置
// 生产者配置（Java 示例）
Properties props = new Properties();
props.put("bootstrap.servers", "kafka-1:9092,kafka-2:9092");
props.put("acks", "all"); // 最强持久性
props.put("retries", 3);
props.put("enable.idempotence", true); // 幂等写入
props.put("compression.type", "snappy"); // 减少网络带宽
props.put("linger.ms", 5); // 微批聚合
// 消费者配置
props.put("group.id", "risk-interceptor-group");
props.put("enable.auto.commit", false); // 手动提交偏移量
props.put("max.poll.records", 500); // 单次拉取上限
props.put("session.timeout.ms", 30000);4.4 实时数据流：从 Kafka 到秒级拦截
数据采集的最终目标是构建一条端到端延迟 < 1 秒的实时流。下图展示了从埋点到风控引擎的完整数据流拓扑：
延迟预算分配：埋点发送 50ms + 采集传输 100ms + Kafka 排队 200ms + 消费计算 300ms + 拦截执行 150ms = 总延迟约 800ms，满足秒级拦截要求。
4.5 数据质量保障：校验与降级
采集层必须内置数据质量监控，防止脏数据污染下游风控模型：
- Schema 校验：生产者侧使用 Avro + Schema Registry，写入前校验字段类型与必填项。
- 延迟监控：每个 Topic 的 consumer lag 超过 30 秒触发告警，自动扩容消费者线程。
- 降级策略：当 Kafka 集群不可用时，采集 Agent 回退到本地文件缓存（最多保留 10 分钟数据），集群恢复后自动回放。
# 延迟监控告警规则（Prometheus + Alertmanager）
- alert: KafkaConsumerLagHigh
expr: kafka_consumer_lag{group="risk-interceptor-group"} > 30000
for: 1m
annotations:
summary: "风险拦截消费者组延迟超过 30 秒"
runbook_url: "https://wiki.risk.internal/kafka-lag-handling"通过上述埋点规范、双模采集、Kafka 主题规划与实时流拓扑，数据采集层为贷后风险秒级拦截提供了稳定、低延迟、可回溯的数据底座。下一环节将基于此实时流，构建特征计算与规则引擎。