1. 课程导论：Flink CEP 在风控领域的价值、异常交易场景概述、告警阈值优化的必要性
1.1 为什么风控系统需要 Flink CEP？
在金融交易、电商支付、账户登录等场景中，欺诈行为往往不是孤立的单点事件，而是由一系列时序相关、因果关联的操作组合而成。例如：短时间内多次尝试不同密码、先小额试探再大额转账、同一设备在多地频繁登录。传统的规则引擎（如 Drools）或离线批处理分析，难以在毫秒级延迟内识别这种跨事件的复杂模式。
Flink CEP（Complex Event Processing） 作为 Apache Flink 的原生复杂事件处理库，能够对无界数据流进行基于时间窗口的模式匹配。它允许风控工程师用声明式 API 定义“事件序列模板”，并在事件到达时实时检测匹配，从而在欺诈行为完成前触发阻断或告警。
核心价值对比： 传统规则引擎 vs. Flink CEP
| 对比维度 | 传统规则引擎（Drools） | Flink CEP |
|---|---|---|
| 事件时序支持 | 弱（需额外编码） | 强（原生支持 next/followedBy/within） |
| 状态管理 | 有限（内存规则栈） | 强（Flink 分布式状态 + Checkpoint） |
| 吞吐与延迟 | 单机瓶颈，延迟 10~100ms | 分布式并行，延迟 < 10ms |
| 时间语义 | 仅处理时间 | 事件时间 + 水位线 + 乱序处理 |
| 动态更新规则 | 需重启引擎 | 支持动态模式（结合广播流） |
1.2 典型异常交易场景概述
风控领域常见的异常交易模式具有明显的时序特征。以下列举三类高频场景，它们也是本课程后续案例的核心素材：
- 撞库攻击： 同一 IP 或设备在短时间内（如 5 秒内）连续尝试 3 次以上不同账号登录，且均失败。
- 小额试探 + 大额盗刷： 同一用户先发起 1~2 笔小额交易（< 10 元）验证卡片可用，随后在 1 分钟内发起大额交易（> 5000 元）。
- 异地登录 + 敏感操作： 用户登录地理位置与历史常用地偏差 > 500 公里，且在登录后 30 秒内执行修改密码或转账操作。
模式定义示例（Flink CEP API）： 以下代码片段展示了“小额试探 + 大额盗刷”的模式定义，使用
followedBy 和 within 约束时序关系。
Pattern<TransactionEvent, ?> fraudPattern = Pattern
.<TransactionEvent>begin("small")
.where(event -> event.getAmount() < 10.0)
.followedBy("large")
.where(event -> event.getAmount() > 5000.0)
.within(Time.minutes(1));1.3 告警阈值优化的必要性
在风控系统中，告警阈值直接决定了检出率与误报率之间的平衡。阈值设置过严，会导致大量正常交易被误拦截，影响用户体验和业务转化率；阈值设置过松，则无法有效捕获欺诈行为，造成资金损失。
传统的阈值配置通常依赖人工经验或静态统计，存在以下痛点：
- 静态阈值无法适应业务波动： 大促期间交易量激增，静态阈值容易触发大量误报。
- 缺乏多维特征联动： 仅依赖单一指标（如金额、频率）设置阈值，忽略设备、IP、行为序列等上下文。
- 调优周期长： 每次调整需要重新上线规则，缺乏自动化反馈闭环。
常见误区： 不要试图用一个“万能阈值”覆盖所有交易类型。不同渠道（PC / 移动端 / API）、不同用户等级（新用户 / VIP）、不同时段（白天 / 凌晨）的分布特征差异巨大，必须采用分群 + 动态阈值策略。
1.4 本课程的核心目标
本课程将围绕一个完整的风控巡检案例，带你掌握以下能力：
| 模块 | 核心内容 | 产出物 |
|---|---|---|
| Flink CEP 模式设计 | 基于真实交易日志定义异常序列模式 | 可复用的 CEP 规则模板 |
| 告警阈值优化 | 使用滑动窗口分位数 + 机器学习回归动态调参 | 阈值自动校准 Pipeline |
| 巡检与可视化 | 构建实时巡检 Dashboard，监控规则命中率与误报趋势 | Flink + Kafka + Elasticsearch 集成方案 |
| 生产化部署 | 状态后端选择、Checkpoint 策略、动态规则更新 | 高可用生产配置清单 |
通过本课程的学习，你将能够独立搭建一套低延迟、高准确率、可自优化的实时风控巡检系统，从容应对业务增长带来的欺诈挑战。