NilmiKaushallya/Fintech-Fraud-Detection-Pipeline
GitHub: NilmiKaushallya/Fintech-Fraud-Detection-Pipeline
基于 Kafka-Spark-Airflow 的 Lambda 架构实时欺诈检测管道,针对数字钱包交易实现规则驱动的异常检测与批处理对账。
Stars: 0 | Forks: 0
# 金融科技实时欺诈检测管道
## 1. 介绍与场景概述
在快速发展的金融科技领域,实时欺诈检测是维护消费者信任和金融稳定的关键要求。本项目实现了一个端到端的数据管道,旨在检测欺诈交易——特别是高价值异常和“不可能的旅行”场景——在它们发生时进行检测,同时为财务审计提供强大的基于批处理的账目核对功能。
## 2. 技术栈选型理由
| 组件 | 技术 | 选型理由 |
|---|---|---|
| 数据摄取 | Apache Kafka | Kafka 作为高吞吐量的分布式骨干。在金融科技环境中,如果下游消费者发生故障,系统绝不能丢失任何交易记录。Kafka 提供了必要的持久性和解耦能力,允许生产者以高速发送数据,而不会使处理引擎过载。 |
| 流处理 | Apache Spark | 因其 Stateful Processing(有状态处理)能力而入选。与简单的过滤器不同,Spark 可以在多个微批次之间记住用户状态,以检测“不可能的旅行”模式,这使其非常适合处理复杂的欺诈逻辑。 |
| 编排调度 | Apache Airflow | 当 Spark 负责“速度层”时,Airflow 则管理“批处理层”。金融系统需要定期生成“事实来源”报告。Airflow 负责编排将验证后的数据移动到长期存储的过程,并每 6 小时生成一次对账报告,确保账目平衡并提供人类可读的洞察。 |
| 存储 / 数据接收 | Parquet 文件 | 这是一种列式存储格式,可为报告层提供极高的压缩率和高速的分析性能。由于我们的报告主要聚合 Amount(金额)列,Parquet 允许系统在读取过程中跳过不相关的元数据,从而显著降低 I/O 开销。 |
## 3. 系统架构(Lambda Architecture)
该系统采用了 **Lambda Architecture**,结合了用于即时检测的 **Speed Layer(速度层)** 和用于全面审计与报告的 **Batch Layer(批处理层)**。
```
Source → Kafka → Spark Streaming → Parquet Storage → Airflow Reporting
```
## 
## 4. 事件时间与处理时间处理
在金融系统中,由于网络延迟的存在,**Processing Time(处理时间,即服务器接收数据的时间)** 可能会产生误导。本项目优先考虑 **Event Time(事件时间,即交易实际发生的时间)**。
### 水位线
实现了 **10 分钟水位线** 来处理乱序数据。
### 逻辑
Spark 会将用户的位置状态保持 10 分钟。如果交易由于网络连接不良而延迟,它仍然可以根据 **“不可能的旅行”** 规则被准确处理。
### 数学阈值
```
Threshold = max(eventTime) - 10 minutes
```
## 5. 分析报告:按商户类别分类的欺诈情况
管道会自动对欺诈企图进行分类,以识别高风险领域。
### 原始数据输出
### 分类分析
| 商户类别 | 欺诈次数 | 风险特征 |
|---|---|---|
| Travel(旅行) | 5 | 高(身份盗窃 / 不可能的旅行) |
| Luxury(奢侈品) | 1 | 中(高价值异常) |
| Food(餐饮) | 3 | 低(撞库 / 小额测试) |
| Electronics(电子产品) | 1 | 中(高转售价值) |
### 关键洞察
最高的欺诈频率发生在 **Travel(旅行)** 领域。这与检测算法相符,因为欺诈者通常将旅行预订作为难以撤消的高价值变现目标。
## 6. 伦理、隐私与数据治理
### 隐私影响
检测欺诈需要追踪用户位置和消费习惯。这构成了 **用户画像**,带来了监控风险。一旦泄露,用户的物理行踪和财务状况将暴露无遗。
### 数据治理策略
#### 匿名化
用户 ID 应当被散列处理(例如,加盐的 SHA-256),以便引擎在检测模式时无需了解用户的真实身份。
#### 数据最小化
仅存储城市级别的位置数据,而不是精确的 GPS 坐标。
#### 保留策略
为了符合 GDPR 的规定,交易日志会被转移到“数据仓库”中,并实施 7 年的清除策略,以满足财务审计的合规性要求。
## 7. 项目最终对账
以下报告确认了 **Speed Layer(速度层)** 和 **Batch Layer(批处理层)** 已保持同步。
### 验证公式
```
Total Ingress == Validated Amount + Fraud Amount
```
### 当前运行状态
✅ 已成功平衡
# 🚀 如何运行
## 1. 初始化技术栈
```
docker-compose up -d
```
## 2. 启动流处理
```
docker exec -it spark /opt/spark/bin/spark-submit --packages org.apache.spark:spark-sql-kafka-0-10_2.12:3.5.1 /opt/spark-apps/fraud_detection.py
```
## 3. 生成交易数据
```
python producer/transaction_producer.py
```
## 4. 运行 Airflow 编排调度
通过以下地址访问 Airflow:
```
http://localhost:8080
```
然后触发:
```
reconciliation_dag
```
## 8. 结论
所实施的 Lambda Architecture 成功弥合了实时响应与历史准确性之间的差距。通过利用 Kafka、Spark 和 Airflow,该系统为金融科技安全提供了一个极具弹性的框架,确保欺诈行为不仅能在毫秒内被捕获,还能被记录归档,从而保障长期的财务完整性。
标签:Airflow, Apache Airflow, Apache Kafka, Apache Spark, FinTech, Gradle集成, Kafka, Lambda架构, Parquet, SonarQube插件, Spark, Spark Streaming, 不可能旅行, 云计算, 交易监控, 分布式系统, 列式存储, 响应大小分析, 大数据, 实时数据处理, 实时欺诈检测, 对账系统, 异地登录, 异常检测, 微批处理, 批处理, 数字钱包, 数据工程, 数据流水线, 数据清洗, 数据湖, 数据编排, 流式处理, 消息队列, 状态处理, 目录扫描, 离线计算, 规则引擎, 请求拦截, 软件成分分析, 逆向工具, 金融审计, 金融科技, 风控系统, 高价值交易, 高吞吐, 高并发