4. 切片计算引擎选型：Flink vs Spark Streaming、内存数据库选型（Redis/Tair）、存储选型（HBase/ClickHouse）
实时风控人群切片的核心挑战在于：在毫秒级延迟内完成海量事件的关联计算、规则匹配与结果存储。选型不当会导致计算延迟高、数据不一致或运维成本失控。本章从计算引擎、内存数据库、持久化存储三个维度进行对比，给出选型建议。
4.1 计算引擎选型：Flink vs Spark Streaming
实时计算引擎是切片引擎的“大脑”，负责接收事件流、维护状态、执行规则。当前主流方案为 Apache Flink 和 Spark Streaming（含 Structured Streaming）。
选型核心原则： 风控场景对“精确一次语义”和“低延迟”有硬性要求，Flink 的原生事件驱动架构更适合；若团队 Spark 技术栈成熟且延迟容忍度在秒级，可考虑 Spark Structured Streaming。
4.1.1 核心对比
| 对比维度 | Apache Flink | Spark Streaming (Structured) |
|---|---|---|
| 处理模型 | 原生事件驱动，逐条处理 | 微批次（Micro-batch），默认批次间隔 100ms~1s |
| 延迟 | 毫秒级（< 10ms） | 秒级（取决于批次间隔） |
| 状态管理 | 内置 Keyed State、ValueState、MapState，支持 RocksDB 状态后端 | 依赖外部存储（Redis/HBase）或 DataFrame 无状态计算 |
| 精确一次语义 | 原生支持（Checkpoint + 两阶段提交） | 通过 WAL 和幂等输出实现 |
| 事件时间处理 | 原生支持，Watermark 机制成熟 | 支持，但 Watermark 精度受批次间隔影响 |
| 运维复杂度 | 中等，需管理 JobManager/TaskManager | 较低，与 Spark 生态统一 |
| 适用场景 | 高频交易、实时反欺诈、毫秒级切片 | 准实时风控、离线+实时混合场景 |
4.1.2 选型决策树
- 延迟要求 < 100ms？ → 选 Flink。
- 需要复杂事件处理（CEP）或自定义状态算子？ → 选 Flink。
- 团队 Spark 技术栈成熟，且延迟容忍度 > 1s？ → 选 Spark Structured Streaming。
- 需要与离线批处理共用同一套代码？ → 优先考虑 Spark。
实战建议： 在金融级风控场景中，90% 以上的团队最终选择 Flink。如果初期资源有限，可以先使用 Spark Streaming 快速验证切片逻辑，后续再迁移至 Flink。
4.2 内存数据库选型：Redis vs Tair
内存数据库在切片引擎中承担“特征缓存”和“实时计数器”的角色。每次事件到来，需要快速读取用户画像、设备指纹、历史行为计数等数据。Redis 和 Tair 是两大主流选择。
4.2.1 核心对比
| 对比维度 | Redis | Tair（阿里云） |
|---|---|---|
| 数据结构 | String、Hash、List、Set、Sorted Set、HyperLogLog、BloomFilter | String、Hash、List、Set、Sorted Set、Counter、BloomFilter |
| 持久化 | RDB / AOF，可配置 | 默认持久化（基于RDB + Binlog） |
| 集群模式 | Redis Cluster（去中心化） | Proxy + Data Server（中心化） |
| 延迟 | 亚毫秒级（p99 < 1ms） | 亚毫秒级（p99 < 1ms） |
| 扩展性 | 水平扩展，但 rehash 有性能抖动 | 水平扩展，支持在线扩缩容 |
| 运维 | 自建或云托管（Redis Labs / 云厂商） | 阿里云托管，运维成本低 |
| 成本 | 开源免费，云托管按规格付费 | 商业授权，按容量+QPS 付费 |
4.2.2 选型建议
- 自建或混合云场景： 优先选择 Redis，生态成熟、社区活跃、客户端丰富。
- 阿里云原生场景： 如果业务已深度绑定阿里云，Tair 的持久化、自动扩缩容、冷热数据分层能力更省心。
- 特殊需求： 需要强一致性或分布式锁时，Redis 需配合 Redlock 或 etcd；Tair 提供内置分布式锁。
避坑提示： 不要将 Redis 当作唯一数据源。风控场景中，Redis 宕机可能导致切片数据丢失。务必配置持久化（AOF + RDB）和主从/集群高可用。Tair 默认持久化，但需注意 QPS 上限和成本。
4.3 持久化存储选型：HBase vs ClickHouse
持久化存储用于保存切片结果、历史特征、回溯分析数据。选型需权衡写入吞吐、查询延迟、存储成本和扩展性。
4.3.1 核心对比
| 对比维度 | HBase | ClickHouse |
|---|---|---|
| 存储模型 | 宽表存储，列族，Key-Value 风格 | 列式存储，面向分析 |
| 写入性能 | 高吞吐（百万行/秒），适合随机写入 | 高吞吐（批量写入），适合批量导入 |
| 查询性能 | 点查快（毫秒级），范围查询一般 | 聚合查询极快（毫秒级），点查较慢 |
| 数据一致性 | 强一致性（基于 HDFS + WAL） | 最终一致性（异步复制） |
| 扩展性 | 水平扩展，RegionServer 自动分裂 | 水平扩展，分片 + 副本 |
| 运维复杂度 | 高（依赖 HDFS、ZooKeeper） | 中等（依赖 ZooKeeper） |
| 典型场景 | 实时特征存储、用户画像、事件明细 | 离线分析、报表、回溯切片、监控 |
4.3.2 选型建议
- 实时特征存储： 选 HBase。需要毫秒级点查用户最新特征、设备指纹、历史行为。
- 回溯分析与报表： 选 ClickHouse。需要秒级聚合查询，如“过去1小时某规则命中次数”。
- 混合架构： 同时使用 HBase 存储实时特征，ClickHouse 存储离线分析数据，通过 Flink 双写或异步同步。
实战案例： 某支付风控团队使用 Flink + Redis + HBase 架构：Flink 实时计算切片，Redis 缓存用户画像，HBase 存储事件明细。每天凌晨通过 Flink 将 HBase 数据批量写入 ClickHouse，供分析师进行切片复盘。
4.3.3 存储选型决策矩阵
| 需求 | 推荐存储 | 理由 |
|---|---|---|
| 毫秒级点查（用户特征） | HBase | RowKey 设计灵活，点查延迟 < 10ms |
| 秒级聚合查询（规则统计） | ClickHouse | 列式存储 + 向量化执行，聚合极快 |
| 高吞吐写入（事件流） | HBase | LSM-Tree 结构，写入无锁 |
| 低成本存储（历史归档） | HBase + HDFS | 利用 HDFS 冷存储，压缩率高 |
| 实时 + 离线混合查询 | HBase + ClickHouse | 各取所长，通过 ETL 桥接 |
4.4 整体选型总结
实时风控人群切片的技术栈选型没有银弹，需要根据业务场景、团队能力和运维成本综合决策。以下是一份推荐组合：
| 层级 | 推荐方案 | 备选方案 |
|---|---|---|
| 计算引擎 | Apache Flink | Spark Structured Streaming |
| 内存数据库 | Redis（自建/云托管） | Tair（阿里云） |
| 持久化存储 | HBase（实时特征） + ClickHouse（分析） | 仅 HBase 或 仅 ClickHouse |
最终建议： 从“最小可行架构”开始：Flink + Redis + HBase。当分析需求增长时，再引入 ClickHouse 作为分析层。避免一开始就追求大而全的架构，导致运维负担过重。