一、项目全景与需求分析：金融图计算是什么？
大家好，我是这个项目的技术负责人。今天咱们聊聊金融图计算这个项目的第一章——全景与需求分析。
说实话，我第一次接触图计算的时候，脑子里也是一堆问号。图？不就是社交网络里那些好友关系吗？跟金融有啥关系？
后来真正做项目了才发现，金融领域里到处都是「关系」。你想想看，一个转账行为，背后涉及账户、交易、设备、IP、时间……这些实体之间天然就是一张网。用传统的关系型数据库去查「张三转给李四，李四又转给王五，王五跟张三有没有共同设备？」——这种多层关联查询，SQL 写出来能绕地球三圈，性能还惨不忍睹。
图计算，说白了就是专门处理这种「关系密集型」问题的技术。它把实体当成节点，把关系当成边，查询起来就像在脑子里画线一样自然。
项目背景：为什么非要用图？
这个项目来自一家中型支付公司。他们每天处理上千万笔交易，风控团队最头疼的问题就是「团伙欺诈」。
什么叫团伙欺诈？举个例子：
- 一个设备登录了 50 个不同的账户
- 这些账户又都向同一个新注册账户转账
- 那个新账户的钱，几分钟内就分散到了几十个不同的银行卡
这种模式，用传统规则引擎很难抓到。因为每个单点看起来都「正常」——一个设备登录多个账户？可能是家庭共用。一个账户收很多钱？可能是电商收款。但把这些关系连起来看，异常就非常明显了。
核心痛点：传统风控系统只能做「单点检测」，无法做「关系挖掘」。团伙欺诈的识别率不到 30%。
我记得第一次跟业务方开会，风控总监直接说：「你们别跟我讲技术，我就问一个问题——能不能在 200 毫秒内，查出一个账户背后关联的所有可疑实体？」
嗯，这就是我们做这个项目的初衷。
核心业务需求：到底要解决什么问题？
经过几轮需求梳理，我们提炼出三个核心场景：
- 实时团伙检测：交易发生时，实时判断当前账户是否与已知黑名单账户存在「二度关联」或「三度关联」。
- 资金链路追踪：给定一个可疑账户，快速画出它的资金流入流出路径，找到最终的资金汇聚点。
- 设备指纹关联：通过设备、IP、手机号等维度，发现不同账户之间的隐藏关联。
这三个场景，每个都对查询性能有硬性要求。业务方给的 SLA 是：单次查询延迟不超过 500 毫秒，数据更新延迟不超过 1 秒。
我的经验：需求阶段一定要把「性能指标」写死。我见过太多项目，技术选型时没考虑性能，上线后被业务方追着骂。你想想看，一个风控查询如果超过 1 秒，用户都完成转账了，查出来还有什么意义？
技术选型：Neo4j 还是 JanusGraph？
这是项目初期争论最激烈的问题。我直接说结论吧——我们最终选了 JanusGraph。
为什么？我列个对比表你就明白了：
| 维度 | Neo4j | JanusGraph |
|---|---|---|
| 存储引擎 | 自研本地存储 | HBase / Cassandra / Bigtable |
| 查询语言 | Cypher | Gremlin |
| 水平扩展 | 有限（依赖企业版） | 原生支持 |
| 事务支持 | ACID | 最终一致性 |
| 社区活跃度 | 高 | 中等 |
| 学习曲线 | 低 | 高 |
看到这里你可能会问：「Neo4j 学习成本低、社区活跃，为什么不选它？」
原因很简单——数据量。我们预估半年后节点数会超过 10 亿，边数超过 50 亿。Neo4j 的社区版单机最多支持几十亿节点，企业版虽然能集群，但授权费用高得离谱。而且，Neo4j 的集群方案本质上还是「主从架构」，写扩展性有限。
JanusGraph 就不一样了。它底层依赖 HBase 或 Cassandra，这些分布式存储天生就是为海量数据设计的。加节点就能线性扩展，成本可控。
避坑指南：我曾经在一个项目里选了 Neo4j，结果半年后数据量翻了三倍，单机扛不住了。迁移到 JanusGraph 的过程简直是噩梦——数据导出、Schema 重建、查询重写……所以这次我坚持一开始就选对。
当然，JanusGraph 也有缺点。Gremlin 查询语言比 Cypher 难学，调试起来也麻烦。但我觉得，技术选型不能只看「好不好学」，要看「能不能撑住业务」。
项目里程碑规划
整个项目我们分了四个阶段，每个阶段 3 个月：
- 第一阶段（第 1-3 月）：基础设施搭建
- 部署 JanusGraph + HBase 集群
- 完成数据模型设计（账户、交易、设备等节点和边的 Schema）
- 实现基础数据导入管道
- 第二阶段（第 4-6 月）：核心查询开发
- 实现「二度关联查询」和「资金链路追踪」
- 性能优化，目标达到 500ms 以内
- 编写 Gremlin 查询模板
- 第三阶段（第 7-9 月）：实时接入与联调
- 对接消息队列（Kafka），实现实时数据写入
- 与现有风控系统集成
- 压力测试与稳定性调优
- 第四阶段（第 10-12 月）：灰度上线与迭代
- 先接入 10% 的流量，观察效果
- 根据反馈调整查询逻辑
- 全量上线
关键节点：第二阶段结束时，我们做了一个内部演示。用真实数据跑了一个「二度关联查询」，从输入账户到返回结果，耗时 320 毫秒。业务方当场就拍板了——继续干！
说实话，这个里程碑规划看起来挺顺的，但实际执行中踩了不少坑。比如第一阶段，我们以为 HBase 部署很简单，结果 RowKey 设计不合理，导致数据倾斜严重。后来花了整整两周重新设计分区策略。
嗯，这些坑后面我会详细讲。今天先把全景图给你画清楚。
知识体系总览
下面这张图，是我做项目时自己画的。它把整个知识体系串起来了，你一看就明白：
这张图从下往上看，就是项目的实施路径。从上往下看，就是需求到落地的映射关系。我个人习惯把这种图贴在工位旁边，每次开会讨论时直接指着图说——「我们现在卡在第三层，数据模型还没定好。」
好了，第一章的内容就到这里。项目全景和需求分析讲清楚了，后面我们会一步步深入每个环节。