第1章：系统架构设计——Lambda与Kappa的抉择
大家好，我是你们的老朋友。今天咱们聊聊实时风控系统的架构设计。
说实话，我见过太多团队一上来就选技术栈，结果做到一半发现架构撑不住。嗯，这章咱们就把架构选型这件事掰开揉碎了讲清楚。
1.1 Lambda架构 vs Kappa架构
先问个问题：你的风控系统需要处理历史数据吗？
大部分场景都需要。比如你要计算用户过去30天的交易频次，或者做离线模型训练。这时候，Lambda架构和Kappa架构就成了两个主要选项。
Lambda架构：批处理层 + 流处理层 + 服务层。批处理负责全量历史数据，流处理负责实时增量数据，服务层合并结果。
Kappa架构：只用流处理层，通过重放消息队列中的历史数据来实现全量计算。
我个人习惯用Lambda架构做风控。为什么？因为风控场景对数据一致性要求极高。你想想看，如果因为数据延迟导致误判，用户投诉是小，资金损失是大。
但Lambda架构有个痛点——维护两套代码。批处理和流处理的逻辑必须保持一致，否则结果对不上。我在项目中遇到过这种情况：批处理跑出来的用户风险分是85，流处理实时算出来却是92，排查了半天发现是窗口函数实现方式不同。
我的建议：如果团队人力充足，选Lambda。如果团队小、追求快速迭代，Kappa更合适。但记住，Kappa对消息队列的存储能力要求很高。
Kappa架构的优势在于简单。所有数据都走流处理，没有批处理层。但代价是——你需要一个能存下所有历史数据的消息队列。Kafka默认的保留期是7天，你要改成30天甚至更久，磁盘开销不小。
我曾经在一个项目中尝试用Kappa架构做实时风控，结果发现历史数据重放需要3小时。嗯，这个延迟对风控来说有点长。后来还是改回了Lambda。
1.2 实时计算引擎选型：Flink vs Spark Streaming
选计算引擎，说白了就是选Flink还是Spark Streaming。我两个都用过，说说我的感受。
| 对比维度 | Flink | Spark Streaming |
|---|---|---|
| 实时性 | 真正的逐条处理，毫秒级延迟 | 微批次处理，秒级延迟 |
| 状态管理 | 原生支持，功能强大 | 需要借助外部存储 |
| 事件时间 | 原生支持，watermark机制完善 | 支持但配置复杂 |
| SQL支持 | Table API + SQL | Structured Streaming |
| 社区活跃度 | 高，阿里贡献大量代码 | 更高，生态更成熟 |
我个人习惯用Flink做实时风控。原因很简单——风控需要真正的实时。你想想看，用户正在下单，你等5秒才算出风险分，黄花菜都凉了。
Flink的事件时间处理能力是它的杀手锏。风控场景中，数据可能乱序到达。比如用户先点支付，后点下单（网络延迟导致）。Flink的watermark机制能正确处理这种乱序。
避坑指南：我曾经在Spark Streaming上踩过坑。微批次默认是2秒一个批次，但风控场景要求毫秒级响应。虽然可以把批次间隔调到100ms，但这样吞吐量会大幅下降。Flink就没有这个问题。
不过Spark Streaming也有它的优势。如果你的团队已经熟悉Spark生态，比如用Spark做离线ETL，那选Spark Streaming可以复用技术栈。而且Spark Streaming的容错机制更成熟，checkpoint恢复速度更快。
嗯，这里有个小技巧：如果数据量不大（每秒几千条），两个引擎差别不大。但如果数据量达到每秒百万级，Flink的背压机制会让你省心很多。
1.3 消息队列选型：Kafka vs Pulsar
消息队列是实时风控的「血管」。数据从业务系统流过来，经过消息队列，再到计算引擎。选错了，整个系统都会卡脖子。
| 对比维度 | Kafka | Pulsar |
|---|---|---|
| 架构 | 分区 + 副本 | 计算存储分离 |
| 存储 | 本地磁盘 | BookKeeper（可分离） |
| 延迟 | 毫秒级 | 毫秒级 |
| 消息重放 | 按offset重放 | 按时间/位置重放 |
| 运维复杂度 | 中等 | 较高 |
Kafka是业界标准，我用它做了五六年。它的优势是稳定、生态好、社区资源多。但Kafka有个问题——扩容麻烦。你要增加分区数，得重新分配数据，这个过程很痛苦。
Pulsar的架构更先进。计算和存储分离，扩容只需要加broker节点，数据自动均衡。我在一个项目中用过Pulsar，扩容确实方便，但运维成本高了不少。
我的建议：如果团队运维能力强，选Pulsar。如果追求稳定和生态，选Kafka。我个人习惯用Kafka，因为踩过的坑少，文档也全。
曾经有个项目，我们用Kafka做风控消息队列，每天处理10亿条消息。Kafka扛住了，但磁盘IO成了瓶颈。后来我们做了消息压缩和分区优化，才把性能提上来。
Pulsar的优势在于消息保留时间长。Kafka默认7天，Pulsar可以轻松做到30天甚至更久。这对Kappa架构来说是个福音。
1.4 数据存储选型：ClickHouse vs Druid
实时风控计算完的结果，得有个地方存。既要支持实时写入，又要支持快速查询。ClickHouse和Druid是两大热门。
| 对比维度 | ClickHouse | Druid |
|---|---|---|
| 写入性能 | 极高，百万行/秒 | 高，十万行/秒 |
| 查询性能 | 极快，列式存储 | 快，预聚合 |
| 实时性 | 秒级可见 | 秒级可见 |
| SQL支持 | 完整SQL | 类SQL |
| 运维复杂度 | 中等 | 较高 |
ClickHouse是我目前的主力存储。它的写入速度惊人，我测试过单机每秒能写80万行。查询也快，特别是聚合查询，秒出结果。
Druid的优势在于预聚合。它会把数据按时间粒度预计算好，查询时直接拿结果。这对风控场景的「用户风险分趋势图」这类查询特别友好。
我的经验：如果主要做明细查询和实时写入，选ClickHouse。如果主要做聚合查询和时间序列分析，选Druid。我个人的风控系统里，ClickHouse存原始事件，Druid存聚合指标。
曾经有个项目，我们用Druid做风控指标存储。查询确实快，但数据摄入配置很复杂。后来换成了ClickHouse，配置简单多了，而且SQL支持更完整。
嗯，这里要注意：ClickHouse的更新操作比较弱。它适合写一次读多次的场景。如果你的风控指标需要频繁更新（比如用户风险分实时变化），那ClickHouse可能不是最佳选择。
1.5 架构选型总结
说了这么多，最后给个总结性的建议：
- 架构：团队大选Lambda，团队小选Kappa
- 计算引擎：追求实时性选Flink，追求生态选Spark Streaming
- 消息队列：求稳选Kafka，求灵活选Pulsar
- 数据存储：明细查询选ClickHouse，聚合查询选Druid
没有银弹，只有最适合你场景的方案。我见过用Flink + Kafka + ClickHouse的组合做风控，也见过用Spark Streaming + Pulsar + Druid的组合。关键是要理解每个组件的优缺点，然后根据你的业务场景做取舍。
好了，这章就到这里。下一章咱们聊聊实时风控指标的具体设计，包括窗口计算、去重、累加这些核心逻辑。
公众号:蓝海资料掘金营，微信deep3321