第三章：知识图谱基础理论
好，咱们进入正题。这一章我打算聊聊知识图谱的底层逻辑。说白了，就是搞清楚图到底是个什么东西，以及我们怎么用计算机去描述它、存它、查它。
我个人习惯是，学任何技术之前，先搞懂它的“根”。图论就是知识图谱的根。你想想看，没有图论，哪来的节点和边？没有RDF和属性图模型，我们怎么把现实世界的股票、公司、高管这些乱七八糟的关系塞进数据库？
3.1 图论基础：别怕，就几个概念
图论听起来高大上，其实核心就三样东西：节点、边、属性。
- 节点（Vertex/Node）：代表一个实体。比如“贵州茅台”这只股票，或者“张三”这个基金经理。
- 边（Edge/Relationship）：代表实体之间的关系。比如“贵州茅台”属于“白酒板块”，或者“张三”管理“贵州茅台”。
- 属性（Property）：描述节点或边的特征。比如贵州茅台的“市值”是2万亿，张三的“从业年限”是15年。
我在项目中遇到过不少新人，一上来就纠结“有向图”和“无向图”。其实在投研场景里，绝大多数关系都是有方向的。比如“A公司投资了B公司”，这个方向很重要，不能反过来。你想想看，如果搞反了，那你的股权穿透分析就全错了。
核心要点：图论在投研里，就是用来解决“多跳查询”和“路径分析”的。比如查“张坤管理的基金重仓了哪些新能源公司”，这就是一个典型的图遍历问题。
3.2 RDF与属性图模型：两种不同的“方言”
搞清楚了图论，接下来就是怎么用代码或标准去描述它。目前主流就两套：RDF和属性图。
3.2.1 RDF（资源描述框架）
RDF是W3C的标准，很学术。它的基本单元是三元组：（主体，谓词，客体）。比如：（贵州茅台， 属于， 白酒板块）。
RDF的优点是标准化，适合做数据交换和语义推理。但缺点也很明显——太啰嗦。每个节点和边都得用URI（统一资源标识符）来标识，写起来很累。我个人不太喜欢在投研这种偏工程化的场景里用纯RDF，除非是做大规模的知识融合。
我的经验：如果你需要做复杂的本体推理，比如“如果A是B的子公司，B是C的子公司，那么A也是C的子公司”，那RDF+OWL（Web本体语言）是首选。但如果你只是做查询和可视化，属性图会更顺手。
3.2.2 属性图模型（Property Graph Model）
属性图是Neo4j、JanusGraph这些图数据库用的模型。它比RDF更灵活，允许节点和边直接挂载属性（键值对）。比如一个“股票”节点，可以直接有代码：600519、市值：20000亿这些属性，不用再拆成三元组。
举个例子，用属性图描述“张三管理贵州茅台”这条关系，可以写成：
节点1: (张三:基金经理 {姓名: "张三", 从业年限: 15})
节点2: (贵州茅台:股票 {代码: "600519", 市值: 20000})
边: (张三)-[:管理 {任职起始: "2018-01-01", 任职状态: "在职"}]->(贵州茅台)看到了吗？边也可以带属性。这在投研里太重要了。比如“任职起始”这个属性，能帮你分析基金经理的任职周期和业绩的关系。
避坑指南：我曾经在一个项目里，把“任职起始”写成了节点的属性，结果查询“某时间段内任职的基金经理”时，性能差得一塌糊涂。后来改成边的属性，查询效率直接提升了10倍。记住：属性该挂在哪就挂在哪，别乱放。
3.3 Neo4j vs JanusGraph：选型对比
好，模型讲完了，该聊聊具体工具了。目前最主流的就是Neo4j和JanusGraph。我两个都用过，说说我的感受。
| 对比维度 | Neo4j | JanusGraph |
|---|---|---|
| 底层存储 | 自研的Native存储（针对图优化） | 依赖外部存储（HBase、Cassandra、BerkeleyDB） |
| 查询语言 | Cypher（声明式，易学） | Gremlin（函数式，灵活但陡峭） |
| 事务支持 | ACID，强一致性 | 最终一致性（取决于后端存储） |
| 扩展性 | 单机为主，企业版支持集群（贵） | 天生分布式，水平扩展能力强 |
| 社区与生态 | 非常活跃，文档齐全 | 相对小众，但Apache项目，稳定 |
| 典型场景 | 中小规模（亿级节点以内），实时查询 | 超大规模（百亿级），需要分布式计算 |
嗯，这里要注意。选型不是非黑即白。我个人的建议是：
- 如果你团队小，业务刚起步，数据量在千万级以内：无脑选Neo4j。Cypher语言太友好了，写起来像说话一样。比如查“张三管理的所有基金”：
MATCH (p:Person {name:'张三'})-[:管理]->(f:Fund) RETURN f。是不是很直观？ - 如果你要处理百亿级数据，或者需要跟Hadoop/Spark生态集成：那就得考虑JanusGraph了。虽然Gremlin学习曲线陡，但它的表达能力更强，而且能跑在分布式集群上。
核心要点：选型的关键不是看谁更“先进”，而是看谁更“匹配”。我在一个量化私募项目里，一开始用了JanusGraph，结果团队里没人会Gremlin，开发效率极低。后来换回Neo4j，两周就上线了。所以，技术服务于业务，别为了炫技而选型。
3.4 本章知识体系图
为了让你更直观地理解这三块内容的关系，我画了一张图。它展示了从图论基础，到数据模型，再到具体数据库的演进路径。
这张图把本章的三个核心模块串起来了。你可以把它当作一个思维导图，每次用图数据库时，都回想一下：我是在用图论思维分析问题，还是在用属性图模型建模，或者是在选型对比？
一个小技巧：我习惯在项目开始前，先用纸笔画一下图论模型。比如画几个圈（节点），连几条线（边），标上属性。这一步做完，后面用Cypher或Gremlin写查询就顺了。别一上来就写代码，先想清楚图结构。
好了，这一章就聊到这儿。图论、RDF与属性图、Neo4j与JanusGraph，这三块是知识图谱的基石。搞懂了它们，后面讲具体应用时，你就能理解为什么有些查询快，有些查询慢，以及为什么选这个库不选那个库。
公众号:蓝海数据掘金营，微信deep3321