2. 技术选型：Flink vs Spark Streaming、Kafka消息队列选型、HBase/Redis/MySQL存储选型对比
在批流一体风控链路中，技术选型直接决定了系统的实时性、准确性、扩展性与运维成本。本章从计算引擎、消息队列、存储层三个核心维度展开对比，给出风控场景下的推荐方案。
2.1 计算引擎：Flink vs Spark Streaming
Flink 与 Spark Streaming 是当前流计算领域的两大主流引擎。风控场景对毫秒级延迟、精确一次语义、状态管理有极高要求，选型差异直接影响规则命中率与资金损失。
| 对比维度 | Apache Flink | Spark Streaming |
|---|---|---|
| 架构模型 | 真正的逐事件流处理（DataStream） | 微批次（Micro-Batch），将流切分为小批次 |
| 延迟 | 毫秒级（< 10ms） | 秒级（通常 1~10s，取决于批次间隔） |
| 状态管理 | 原生 Keyed State、Operator State，支持 RocksDB 大状态 | 基于 DStream 的 transform 或 Structured Streaming 的 StateStore |
| 精确一次语义 | 端到端精确一次（两阶段提交 + 可重置偏移量） | Structured Streaming 支持，但微批次边界存在重复风险 |
| 事件时间处理 | 原生 Watermark + 乱序处理，成熟度高 | Structured Streaming 支持，但 watermark 机制较晚引入 |
| 批流一体 | 同一 API（DataStream/Table API）覆盖批与流 | Spark SQL（批）+ Structured Streaming（流），API 有差异 |
| 风控适用场景 | 实时规则计算、滑动窗口聚合、复杂事件处理（CEP） | 准实时特征加工、离线模型训练、T+1 报表 |
风控选型结论：核心风控链路（交易实时拦截、登录保护、反欺诈决策）优先选择 Flink，其毫秒级延迟与精确一次语义能最大限度降低资金损失。离线特征工程与历史回溯分析可继续使用 Spark，形成 Flink + Spark 混合架构。
2.2 消息队列选型：Kafka 核心参数与风控适配
消息队列是批流一体链路的“主动脉”。风控场景下，Kafka 是事实标准，但需针对高吞吐、低延迟、数据不丢失进行精细化配置。
2.2.1 为什么是 Kafka？
- 高吞吐：顺序读写磁盘 + 零拷贝，单机可达数十万 TPS。
- 持久化与回溯：消息落盘，支持按偏移量重新消费，便于风控回溯与 replay。
- 分区并行：Topic 多分区天然适配 Flink 并行度，实现线性扩展。
- 生态成熟：与 Flink、Spark、HBase、Redis 均有原生连接器。
2.2.2 风控场景关键配置
| 配置项 | 推荐值 | 说明 |
|---|---|---|
acks |
all（-1） | 所有 ISR 副本确认后才返回，保证不丢消息 |
min.insync.replicas |
2 | 至少 2 个副本同步，配合 acks=all 防止单点故障 |
replication.factor |
3 | 3 副本，容忍 1 个 Broker 宕机 |
retention.ms |
604800000（7 天） | 风控需保留足够长窗口用于回溯与特征计算 |
compression.type |
lz4 或 zstd | 降低网络带宽与存储，CPU 开销可控 |
max.message.bytes |
10485760（10MB） | 风控事件可能携带设备指纹、图片元数据等大字段 |
避坑提示：不要在生产环境使用 acks=1 或 acks=0，风控场景下消息丢失可能导致规则漏判，直接造成资金损失。同时，min.insync.replicas 必须小于等于 replication.factor，否则生产者会持续报错。
2.3 存储选型：HBase vs Redis vs MySQL
风控链路中，存储层承担特征存储、黑白名单、规则配置、历史行为等不同角色。单一存储无法满足所有需求，需按数据特征分层选型。
| 对比维度 | HBase | Redis | MySQL |
|---|---|---|---|
| 数据模型 | 宽表、稀疏列族、多版本 | Key-Value、Hash、List、Set、Sorted Set | 关系型表、ACID 事务、索引 |
| 读写性能 | 毫秒级随机读写，吞吐高 | 微秒级，纯内存操作 | 毫秒级，受磁盘 IO 与锁影响 |
| 数据容量 | PB 级，水平扩展 | GB ~ TB 级（受内存限制） | TB 级，分库分表后可扩展 |
| 持久化 | HDFS 持久化，自动容错 | RDB/AOF 持久化，但主从切换可能丢数据 | Binlog + Redo Log，强持久化 |
| 一致性 | 最终一致性（CP 系统） | 最终一致性（AP 系统） | 强一致性（ACID） |
| 风控典型用途 | 用户画像、设备指纹、历史行为序列 | 黑白名单、计数器、限流、实时特征缓存 | 规则配置、策略元数据、审核记录 |
2.3.1 分层存储架构
- 热数据层（Redis）：毫秒级访问，存储黑白名单、实时计数器、限流令牌、Session 缓存。TTL 策略自动淘汰过期数据。
- 温数据层（HBase）：存储用户 30~90 天行为序列、设备指纹、IP 画像。RowKey 按用户 ID + 时间戳设计，支持范围扫描。
- 冷数据层（MySQL + HDFS）：规则配置、策略版本、审核日志、离线特征宽表。MySQL 保证事务一致性，HDFS 用于历史归档。
2.4 选型总结矩阵
| 链路环节 | 首选技术 | 备选技术 | 核心考量 |
|---|---|---|---|
| 实时计算引擎 | Apache Flink | Spark Structured Streaming | 延迟、状态管理、精确一次语义 |
| 消息队列 | Apache Kafka | Pulsar（若需多租户与计算存储分离） | 吞吐、持久化、分区扩展 |
| 热数据存储 | Redis Cluster | Memcached（仅缓存场景） | 微秒级响应、TTL 淘汰 |
| 温数据存储 | HBase | Cassandra（写多读少场景） | 水平扩展、稀疏列族、范围扫描 |
| 冷数据存储 | MySQL + HDFS | TiDB（需强一致 + 水平扩展） | 事务、归档、离线分析 |
架构师建议：技术选型没有银弹。在批流一体风控链路中，Flink + Kafka + Redis + HBase + MySQL 是经过大规模生产验证的黄金组合。初期可简化存储层（Redis + MySQL），随着数据量增长逐步引入 HBase。始终以“数据分层、读写分离、冷热隔离”为设计原则。