2. 实时化技术选型总览：流计算引擎、消息队列与 OLAP 引擎的选型对比
贷后预警策略从 T+1 批处理转向实时化，核心在于构建一条端到端的低延迟数据管道。技术选型需覆盖三个关键层次：消息队列（数据缓冲与解耦）、流计算引擎（实时加工与规则匹配）、OLAP 引擎（实时特征存储与多维分析）。本章从工程实践角度，对主流组件进行横向对比。
2.1 流计算引擎：Flink vs Spark Streaming
流计算引擎是实时预警的“大脑”，负责将原始事件流与预警规则进行匹配。当前业界主流为 Apache Flink 和 Spark Streaming（含 Structured Streaming）。
选型核心结论： 贷后预警场景对事件时间语义、精确一次语义（Exactly-Once）和状态管理要求极高，Flink 是更优选择。Spark Streaming 更适合与现有 Spark 批处理生态深度绑定的团队。
| 对比维度 | Apache Flink | Spark Streaming (Structured Streaming) |
|---|---|---|
| 计算模型 | 原生流计算（逐条处理），也支持批模式 | 微批处理（Micro-Batch），本质是批处理 |
| 延迟 | 亚秒级（毫秒级延迟） | 秒级（默认 100ms-1s 微批间隔） |
| 事件时间语义 | 原生支持，内置 Watermark 机制处理乱序 | Structured Streaming 支持，但 Watermark 实现较晚 |
| 状态管理 | 强大的 Keyed State 和 Operator State，支持 RocksDB 大状态 | 基于 Checkpoint 的状态存储，大状态性能不如 Flink |
| 精确一次语义 | 端到端 Exactly-Once（需 Source/Sink 支持） | Structured Streaming 支持，但端到端保证更复杂 |
| SQL 支持 | Flink SQL 成熟，支持动态表与 CDC | Spark SQL 生态丰富，但流表 Join 场景不如 Flink 灵活 |
| 运维复杂度 | 中等，需管理 JobManager/TaskManager | 较低，复用 Spark 集群 |
贷后场景提示： 预警规则常涉及“30 分钟内同一客户触发 3 次以上”这类时间窗口聚合。Flink 的滑动窗口与事件时间语义能天然处理客户行为乱序到达问题，避免因网络延迟导致误报。
2.2 消息队列：Kafka vs Pulsar
消息队列是实时管道的“缓冲池”，负责削峰填谷、异步解耦。在贷后预警场景中，消息队列需要支撑高吞吐写入（来自业务系统的事件流）和低延迟消费（被流计算引擎拉取）。
| 对比维度 | Apache Kafka | Apache Pulsar |
|---|---|---|
| 存储模型 | 分区日志（Partition Log），存储与计算耦合 | 存储与计算分离（BookKeeper + Broker） |
| 吞吐量 | 极高（百万条/秒），依赖顺序读写 | 高，支持分层存储（Tiered Storage） |
| 延迟 | 毫秒级（P99 通常 < 10ms） | 毫秒级，但跨地域复制延迟更低 |
| 消息保留 | 基于时间/大小删除，不支持 TTL 自动清理 | 支持 TTL、保留策略、自动死信队列 |
| 消费模型 | 基于 Consumer Group 的拉模式 | 支持独占、共享、灾备等多种订阅模式 |
| 运维复杂度 | 中等，需管理 ZooKeeper/KRaft | 较高，组件多（Broker + BookKeeper + ZooKeeper） |
选型避坑： 如果团队已有 Kafka 运维经验且预警流量稳定，优先选 Kafka。如果业务需要跨机房容灾、多租户隔离或消息 TTL 灵活管理，Pulsar 的存算分离架构更具优势。贷后场景中，Kafka 仍是当前最主流的选择，与 Flink 的集成最为成熟。
2.3 OLAP 引擎：ClickHouse vs Apache Doris
OLAP 引擎在实时预警中承担两个角色：实时特征存储（存储客户画像、额度、历史行为等维度数据，供流计算引擎 Join）和预警结果明细查询（支持风控人员实时排查）。
| 对比维度 | ClickHouse | Apache Doris |
|---|---|---|
| 架构 | MPP 架构，列式存储 | MPP 架构，兼容 MySQL 协议 |
| 写入性能 | 极高（批量写入 > 100MB/s），适合 Append 场景 | 高，支持实时 Upsert 和部分列更新 |
| 查询性能 | 极快（单表聚合、宽表扫描），Join 较弱 | 快，Join 性能优于 ClickHouse，支持物化视图 |
| 实时更新 | Mutation 操作代价高，不适合高频更新 | 原生支持高频 Upsert（Unique Key 模型） |
| SQL 兼容性 | 类 SQL，部分语法不标准 | 高度兼容 MySQL，学习成本低 |
| 生态集成 | 与 Flink 通过 JDBC/ClickHouse Connector 集成 | 与 Flink 通过 Doris Connector（支持 Stream Load） |
贷后场景选型建议：
- 实时特征存储（Lookup Join）： 如果特征数据需要高频更新（如实时额度、状态变更），优先选 Doris（Unique Key 模型支持 Upsert）。如果特征数据以 Append 为主（如历史行为序列），ClickHouse 性能更优。
- 预警明细查询： 两者均可，但 Doris 的 MySQL 兼容性对风控运营人员更友好。
2.4 选型决策矩阵
综合贷后预警场景的典型需求（低延迟、高吞吐、状态管理、实时更新），给出以下决策矩阵：
| 技术组件 | 推荐选型 | 备选方案 | 核心考量 |
|---|---|---|---|
| 流计算引擎 | Apache Flink | Spark Structured Streaming | 事件时间、状态管理、Exactly-Once |
| 消息队列 | Apache Kafka | Apache Pulsar | 吞吐量、运维成熟度、Flink 集成 |
| OLAP 引擎（特征存储） | Apache Doris | ClickHouse | 高频 Upsert、MySQL 兼容 |
| OLAP 引擎（明细查询） | ClickHouse | Apache Doris | 宽表扫描性能、聚合查询速度 |
工程落地建议： 在初期 MVP 阶段，建议采用 Kafka + Flink + Doris 的组合。Kafka 作为事件总线，Flink 负责规则引擎，Doris 同时承担实时特征存储和预警结果查询，减少技术栈复杂度。后续根据性能瓶颈再引入 ClickHouse 作为独立的查询加速层。