1、课程导论：实时图计算为什么是交易监控的银弹？核心概念与行业痛点

大家好，我是老张。在量化交易这个行当摸爬滚打了十几年，今天咱们来聊聊一个让我又爱又恨的话题——实时图计算在交易监控中的应用。

先问大家一个问题：你手头的交易监控系统，是不是经常出现这种情况？

• 某个账户突然大量撤单，你半小时后才看到告警
• 关联账户组同时交易同一只股票，风控系统毫无反应
• 资金链异常流转，查了半天才发现是几个账户在循环对倒

嗯，这些我都经历过。而且说实话，传统的关系型数据库和流处理框架，在面对这种「关系型」异常时，基本就是抓瞎。

1.1 交易监控的「关系」困境

交易监控的本质是什么？说白了，就是发现异常行为。但异常行为往往不是孤立的，而是藏在实体之间的关联里。

举个例子。我2018年帮一家券商做反洗钱系统时，遇到一个经典案例：

账户A -> 转账 -> 账户B -> 转账 -> 账户C -> 买入股票X
账户D -> 转账 -> 账户E -> 转账 -> 账户F -> 卖出股票X

传统做法是：先查A到B的转账，再查B到C的转账，最后查C买X。每一步都要写SQL JOIN，查完黄花菜都凉了。而且，如果中间多跳了几层，SQL写得你想哭。

为什么会这样？因为交易数据天然就是一张图：

• 账户是节点
• 转账、交易、委托是边
• 异常模式就是图中的特定子结构

你想想看，如果我们能实时地在这张图上做遍历、做匹配、做聚合，是不是所有问题都迎刃而解了？

1.2 实时图计算：银弹还是噱头？

我个人习惯把实时图计算定义为：在数据流上持续维护一张动态图，并实时执行图算法或图查询。

它和传统图计算的区别在哪？我画了张图，大家一看就明白：

看到区别了吧？传统做法是「先存后算」，实时图计算是「边来边算」。这个差异在交易监控场景下，就是生与死的区别。

1.3 核心概念：节点、边、属性、时序

搞实时图计算，有几个概念必须刻在脑子里：

概念	交易监控中的例子	为什么重要
节点	账户、IP地址、设备指纹、股票代码	异常行为的「主体」和「客体」
边	转账、委托、登录、关联持仓	行为之间的「关系」载体
属性	账户余额、交易金额、时间戳、IP地理位置	用于过滤和聚合的「特征」
时序	事件发生的时间窗口、顺序关系	很多异常模式依赖「先后顺序」

我记得刚开始做这个方向时，犯过一个低级错误：只关注节点和边，忽略了时序。结果呢？一个典型的「老鼠仓」模式——先买入后跟单——因为时间顺序搞反了，漏掉了30%的告警。嗯，从那以后，我再也不敢轻视时序了。

1.4 行业痛点：为什么传统方案搞不定？

咱们来盘点一下，传统交易监控方案到底「痛」在哪：

1. 关系查询性能差：多表JOIN在数据量上来后，基本就是灾难。我见过一个系统，查3层关联要跑5分钟。
2. 无法处理动态关系：账户之间的关联是实时变化的。传统方案只能做快照分析，抓不住「正在发生」的异常。
3. 模式匹配能力弱：比如「短时间内多个账户通过中间账户循环转账」，这种环形模式用SQL写出来，代码量感人。
4. 扩展性瓶颈：交易数据量是爆炸式增长的。传统图数据库在单机上跑还行，一上分布式就各种坑。

1.5 实时图计算的「银弹」价值

那实时图计算到底能解决什么问题？我列几个真实场景：

• 团伙识别：实时发现多个账户共享同一IP、同一设备，或者资金流向形成闭环
• 循环交易检测：A卖B买，B卖C买，C卖A买——这种对倒行为在图上就是一个小环
• 关联账户风控：一个账户触发风控，实时冻结其所有关联账户
• 资金链路追踪：从某个可疑账户出发，实时追踪资金流向的所有下游

1.6 技术选型：该选什么图计算引擎？

目前主流的实时图计算方案，我按场景给大家分个类：

方案	适用场景	我的评价
Neo4j + 流处理	中小规模，关系查询为主	入门简单，但实时性一般
JanusGraph + Kafka	大规模，需要分布式	扩展性好，运维成本高
自研内存图引擎	超低延迟，定制化需求	性能最强，但开发周期长
Flink Gelly	流批一体，算法丰富	适合做图算法，不适合做图查询

我个人习惯是：先用自研原型验证可行性，再根据规模选型。别一上来就上分布式，很多场景单机内存图就能搞定。

好了，这一章咱们把实时图计算的核心概念和行业痛点讲清楚了。下一章，我会带大家手撸一个简单的实时图计算引擎，看看它到底是怎么工作的。

---

公众号:蓝海资料掘金营，微信deep3321