2. 反欺诈图谱基础：图数据库选型与图谱数据模型设计
在反欺诈实时评分场景中，图数据库的选型直接决定了图谱查询的延迟上限。本章从工程实践出发，对比主流图数据库在反欺诈场景下的核心差异，并给出适用于延迟敏感型业务的数据模型设计方法。
2.1 图数据库选型：Neo4j vs JanusGraph
反欺诈图谱评分接口的核心操作是多跳邻居遍历与子图匹配。当前工业界最成熟的两条技术路线是 Neo4j（原生图存储）与 JanusGraph（分布式图引擎）。下表从延迟敏感维度进行对比：
| 对比维度 | Neo4j（社区版） | JanusGraph + HBase/Cassandra |
|---|---|---|
| 存储引擎 | 原生图存储（.db 文件） | 宽表存储（后端依赖 HBase/Cassandra） |
| 遍历性能（1~3 跳） | 亚毫秒级（指针直连） | 毫秒级（需多次 RPC 回后端存储） |
| 水平扩展 | 仅支持读扩展（集群版需企业授权） | 原生支持（Region 分片 + 动态扩缩） |
| 事务支持 | ACID（单机强一致） | 最终一致性（取决于后端存储） |
| 反欺诈典型部署 | 单机/主从（数据量 < 100 亿边） | 多 Region 集群（数据量 > 500 亿边） |
| 接口延迟 P99 | 5~15 ms（单跳） | 20~80 ms（含网络开销） |
选型结论： 对于反欺诈图谱评分接口，若单机数据量可控（节点 < 10 亿，边 < 50 亿），优先选择 Neo4j 以获得最低延迟；若数据量超大规模且需要弹性扩缩，选择 JanusGraph 并配合本地缓存层降低 P99 延迟。
2.2 图谱数据模型设计原则
反欺诈图谱的模型设计必须围绕查询模式而非存储范式展开。以下三条原则直接决定评分接口的遍历效率：
- 实体扁平化：将设备、手机号、身份证、银行卡等核心实体作为节点，避免多层子类继承。
- 关系显式化：将“登录”“转账”“注册”“同设备”等行为直接建模为带时间戳的有向边。
- 属性下推：将高频过滤字段（如风险等级、设备指纹、IP 段）设为节点属性，利用索引快速剪枝。
避坑提示： 不要将“设备指纹”建模为节点属性再通过额外索引查询，而应直接作为节点标签（Label）或节点主键的一部分，减少一次索引跳转。
2.3 反欺诈图谱核心数据模型（SVG）
下图展示反欺诈实时评分中最常用的 5 类实体与 4 类关系的星型/网状混合模型：
2.4 关系类型与时间衰减设计
反欺诈评分中，关系的时间属性直接影响权重计算。建议将关系分为三类，并分别设计存储策略：
| 关系类型 | 示例 | 时间衰减策略 | 索引方式 |
|---|---|---|---|
| 强关联（永久） | 身份证→银行卡 | 不衰减 | 关系类型 + 节点 ID 复合索引 |
| 行为关联（短期） | 设备→IP（登录） | 按小时衰减（半衰期 24h） | 关系类型 + 时间戳范围索引 |
| 弱关联（临时） | 设备→设备（同 WiFi） | 按分钟衰减（半衰期 30min） | 关系类型 + 时间戳 + 属性过滤 |
延迟陷阱： 不要在遍历过程中对每条关系做实时时间衰减计算。正确做法是在写入时预先计算衰减系数并存储为关系属性，查询时直接读取属性值参与评分，避免计算开销。
2.5 图谱数据模型与评分接口的映射关系
下图展示从“收到评分请求”到“图谱遍历完成”的完整数据流，突出模型设计对延迟的影响：
2.6 模型设计检查清单
在进入下一阶段编码前，请对照以下清单验证你的图谱数据模型：
- 节点标签：是否将设备、手机号、身份证、银行卡、IP 设为独立标签？
- 关系方向：是否所有关系都明确了方向（如设备→手机号，而非无向）？
- 时间戳属性：每条行为关系是否都携带了
last_seen或timestamp属性？ - 索引覆盖：是否为入口节点（设备 ID）建立了唯一索引？
- 属性剪枝：是否将风险等级、设备类型等高频过滤字段设为节点属性并建索引？
- 关系权重：是否在写入时预计算了时间衰减权重并存储为关系属性？
最佳实践： 在 Neo4j 中，使用
CREATE CONSTRAINT FOR (d:Device) REQUIRE d.device_id IS UNIQUE 保证入口节点 O(1) 查找；在 JanusGraph 中，使用混合索引（Composite + Mixed）覆盖设备 ID 与时间戳范围查询。