金融图谱API发布回放验证课程 - 第2节
2.1 金融图谱的核心概念：节点与边
金融知识图谱将现实世界中的金融实体与它们之间的关联抽象为图结构。理解节点（Node）与边（Edge）是构建图谱的第一步。
- 节点（Node）：代表实体或概念。在金融场景中，节点可以是“上市公司”、“基金经理”、“金融产品”、“监管机构”等。
- 边（Edge）：代表节点之间的关系。例如“投资”、“控股”、“任职”、“监管”等。
关键区别：节点存储属性（如公司名称、注册资本），边存储关系类型与权重（如持股比例、关联强度）。
2.2 实体与关系：金融领域的语义抽象
在金融图谱中，实体（Entity）是节点的具体实例，关系（Relationship）是边的语义标签。设计良好的实体与关系模型是图谱可用的前提。
常见金融实体类型
| 实体类型 | 示例 | 关键属性 |
|---|---|---|
| 机构 | 工商银行、中金公司 | 统一社会信用代码、注册资本 |
| 人员 | 张坤、刘格菘 | 身份证号（脱敏）、从业资格编号 |
| 金融产品 | 易方达蓝筹精选 | 产品代码、成立日期、净值 |
| 事件 | 股权质押、债券违约 | 发生时间、涉及金额、状态 |
核心关系类型
- 控股/参股：机构A → 控股 → 机构B（属性：持股比例）
- 任职：人员 → 任职 → 机构（属性：职务、任职起始日）
- 管理：机构 → 管理 → 金融产品（属性：管理费率）
- 交易：机构 → 买入/卖出 → 金融产品（属性：交易金额、时间）
设计建议：关系应尽量带有时间属性和权重属性，便于后续进行时序分析和影响力计算。
2.3 图数据库选型：Neo4j 与 JanusGraph 对比
图数据库是存储和查询金融图谱的核心引擎。目前主流选型集中在 Neo4j 和 JanusGraph 之间，两者在架构、扩展性和适用场景上有显著差异。
| 对比维度 | Neo4j | JanusGraph |
|---|---|---|
| 架构类型 | 原生图存储（Native Graph） | 分布式图数据库（基于后端存储） |
| 存储后端 | 自有存储引擎 | HBase / Cassandra / Bigtable |
| 查询语言 | Cypher（声明式，易学） | Gremlin（遍历式，灵活） |
| 事务支持 | ACID 强事务 | 最终一致性（取决于后端） |
| 水平扩展 | 有限（主从复制） | 原生支持（分布式集群） |
| 部署复杂度 | 低（单机即可运行） | 高（需依赖 Hadoop 生态） |
| 金融场景适用性 | 中小规模图谱、实时查询 | 超大规模图谱（百亿节点以上） |
选型建议：对于金融图谱 API 发布回放验证课程，初期推荐使用 Neo4j，因其部署简单、Cypher 查询直观，便于快速验证图谱模型。当数据量超过 10 亿节点且需要分布式写入时，再考虑迁移至 JanusGraph。
2.4 金融图谱基础模型示例（Neo4j Cypher）
以下代码展示如何在 Neo4j 中创建金融图谱的基础节点与关系：
// 创建机构节点
CREATE (icbc:Institution {name: '工商银行', code: 'ICBC', reg_capital: 3564.06})
// 创建人员节点
CREATE (person:Person {name: '张坤', cert_no: '****1234'})
// 创建金融产品节点
CREATE (fund:FinancialProduct {name: '易方达蓝筹精选', code: '005827', nav: 2.3456})
// 创建关系
CREATE (person)-[:MANAGES {since: '2018-09-01'}]->(fund)
CREATE (icbc)-[:HOLDS {ratio: 0.8}]->(fund)
注意：实际生产环境中，节点属性应包含唯一标识（如 UUID），并建立索引以加速查询。
2.5 本章小结
- 金融图谱由节点（实体）和边（关系）构成，节点存储属性，边存储关系语义与权重。
- 实体类型包括机构、人员、金融产品、事件等；关系类型包括控股、任职、管理、交易等。
- 图数据库选型需根据数据规模：Neo4j 适合中小规模（<10亿节点），JanusGraph 适合超大规模分布式场景。
- 本课程后续章节将基于 Neo4j 进行图谱 API 的设计与发布回放验证。