4. 数据采集策略：实时流式采集与离线批量采集的选型

在异常交易检测系统中，数据采集策略直接决定了模型训练的时效性与覆盖度。实时流式采集适用于毫秒级拦截欺诈交易，而离线批量采集则适合历史特征回溯与模型重训练。本章将系统对比两种模式的选型依据，并介绍 Kafka、Flume 等主流采集工具的核心架构。

4.1 实时流式采集 vs 离线批量采集

两种采集模式在延迟、吞吐、容错与适用场景上存在本质差异。下表从关键维度进行对比：

4.2 实时流式采集架构与工具

实时流式采集的核心是构建一个高吞吐、低延迟、可持久化的消息管道。下图展示了典型的实时采集三层架构：

4.2.1 Apache Kafka

Kafka 是实时流式采集的事实标准，在异常交易场景中承担消息缓冲与解耦的核心角色。其关键特性包括：

• 分区与并行消费： 每个 Topic 可拆分为多个 Partition，支持水平扩展，单集群吞吐可达百万条/秒。
• 持久化与回溯： 消息写入磁盘，可配置保留策略（如 7 天），支持消费者从任意 offset 重新消费，便于模型回测。
• 精确一次语义： 结合事务 API 与幂等生产者，保障交易数据不重不丢。

4.2.2 Apache Flume

Flume 是专为日志采集设计的分布式系统，适合从大量服务器收集日志文件并导入 Kafka 或 HDFS。其核心组件包括：

4.3 离线批量采集架构与工具

离线批量采集主要用于构建训练集的历史数据抽取。典型流程包括定时调度、增量抽取与数据落盘。下图展示了离线采集的 ETL 流程：

4.3.1 增量抽取策略

为降低离线采集对业务库的压力，推荐使用以下增量策略：

• 时间戳增量： 基于交易时间字段（如 trans_time）抽取 T-1 数据，适用于大部分交易表。
• Binlog 变更捕获： 通过 Canal / Debezium 订阅 MySQL Binlog，准实时同步至 HDFS，兼顾实时与批量。
• 分区裁剪： 在 Hive 表中按日期分区，查询时只扫描目标分区，大幅提升 ETL 效率。

4.4 混合采集策略：Lambda 架构

在大型风控系统中，单一采集模式无法满足所有需求。Lambda 架构将实时流与离线批处理结合，兼顾低延迟与高精度：

4.5 工具选型决策树

根据实际业务需求，可参考以下决策路径选择采集工具：

1. 是否需要毫秒级延迟？
   • 是 → 使用 Kafka + Flink 实时流
   • 否 → 进入下一步
2. 数据源是否为日志文件？
   • 是 → 使用 Flume 采集至 Kafka 或 HDFS
   • 否 → 使用 Sqoop / DataX 从数据库批量抽取
3. 是否需要历史数据回溯？
   • 是 → 配置 Kafka 消息保留期 > 7 天，或全量导入 Hive
   • 否 → 仅保留近期数据，降低存储成本