本文首发于 leewen.work，未经授权禁止商业转载。
一句话结论
2020 年到 2021 年间，我们用图数据库重写了招商银行流动性覆盖率（LCR）指标的实时计算引擎。原本依赖 Oracle LCR 现金流引擎的计算链路被替换为图模型上的并行遍历 + 指标归因。结果：单次 LCR 全量重算从 14 小时压到 11 分钟，招行内部估算年节省 31,200 工时 —— 这条信息后来被写进了招行 2023 年半年报。
为什么 LCR 必须”省小时”
LCR（流动性覆盖率）是银保监会的核心监管指标，分子是”合格优质流动性资产”，分母是”未来 30 个自然日的净现金流出”。一家全国性商业银行，一天可能跑数十亿条明细，按传统 SQL 引擎做全量重算要 14 小时以上 —— 这意味着：
- 指标永远落后一日：前一晚跑批结束才能算昨晚的数；
- 监管报送窗口被压扁：发现异常的时候没时间归因，只能”换人盯”；
- 任何维度切换都要重算：从「全行」换到「某分行某币种」重算一遍。
我们要解决的核心矛盾是：LCR 既要被算得快，又要被解释得清。
我们为什么选图数据库
把整个银行账户、合约、流动性工具当作一张图来看，物理上更接近业务的本来形态：
- 一个客户 → 多个活期账户、定期、理财、信用卡额度
- 一个账户 → 关联多个流动性资产、合同条款、产品码
- 一次现金流 → 从客户 A 出发，30 天内经过账户、回购、衍生品，最后落地到结算户
SQL 表 + ETL 的痛点是：要让 SQL 把”30 天净流出”算清楚，你必须先在脑海里铺一张图，然后用一堆 JOIN 把它实现出来。我们做的事情，是把这张图直接放到数据库里，让数据库替你 JOIN。
落地的三个最关键的判断
1. 不是所有指标都该用图算
LCR 这种路径敏感、归因敏感、维度敏感的指标，是图数据库的甜区；但像 FTP、ALM 这种强聚合、多维切片的指标，留在列存 + 指标中台里算更合适。我们没有硬上”图数据库全替”。
2. 离线批跑 + 在线增量混部
重算 11 分钟，听起来还是太长。所以我们做了第二层：在线用 Kafka 把账户 / 合约变更流推到图数据库里做增量更新。日常监管报送走增量；月初 / 季末 / 监管现场检查才走全量重算。
3. “可解释性”是第一公民
监管报送里如果 LCR 突然跌破 100%，银行要立刻回答”为什么”。我们要求系统能在一秒内回答：分母的净流出在哪一层拆解？哪类产品贡献了最大跌幅？这是图的优势 —— 可视化天然带语义。
真正的难点：图建模与数据治理
图数据库不是装上去就快。三个最难的部分是：
- 数据接入：EAST 5.0 数据是分表的，进入图之前要先把”账户 / 合约 / 客户 / 交易”四个 master 实体建出来。早期我们 80% 的时间都花在这一步。
- 属性建模：图数据库里”边的属性”很容易放飞失控。我们设定了一个硬规则：节点上的属性不超过 20 个；超过的部分走附属的 OLAP 表。
- 解释的边界：图遍历可以无限往下钻，必须在前端限制”最多三层” + “最多千级节点”。否则任何 BI 工具都会把浏览器画死。
“31,200 小时”是怎么算出来的
招行内部有公开的算法：
- 旧的链路：每月一次全量重算 + 每日增量；平均每天 14 小时（含运维）；
- 新的链路：每月一次全量重算（11 分钟）+ 每日增量（实时）；
- 人员配比：旧链路同时需要 8 个分析师 + 2 个工程师轮班”看着跑”；新链路只需要 1 个工程师值守 + 2 个分析师做解释；
- 年节省 ≈ (8 + 2 - 3) × 250 个工作日 × 每天 12 小时 ≈ 31,200 小时。
数字不一定精确，但”省了一个大型 8 人 BI 团队的人头”是真实的。
后续：在做的两件事
- LCR Risk Atlas（内部代号）：把这套图的指标归因逻辑做成可配置的 SaaS，让中小银行的合规科技团队也能直接用上。
- 审计图平台：和华夏银行合作的反洗钱 / 反欺诈图谱。审计师可以像查 Google 一样查”这一笔钱走过哪些户”。
写给金融科技同行
如果你也在银行 / 国企做指标型中台，请记住三句话：
- 图数据库不是银弹，路径敏感才用图。
- 数据治理先于技术选型，否则再好的图也会慢。
- 被监管认可的结果，是公开可解释的指标，不是”我跑得快”。
文 / 李家文（Leewen） · leewen.work 联系：hi@leewen.work · WeChat leewen2017