d3构建知识图谱可视化_项目实战：如何构建知识图谱

实践了下怎么建一个简单的知识图谱，两个版本，一个从 0 开始(start from scratch)，一个在 CN-DBpedia 基础上补充，把 MySQL，PostgreSQL，Neo4j 数据库都尝试了下。自己跌跌撞撞摸索可能踩坑了都不知道，欢迎讨论。

1. CN-DBpedia 构建流程

知识库可以分为两种类型，一种是以 Freebase，Yago2 为代表的 Curated KBs，主要从维基百科和 WordNet 等知识库中抽取大量的实体及实体关系，像是一种结构化的维基百科。另一种是以 Stanford OpenIE，和我们学校 Never-Ending Language Learning (NELL) 为代表的 Extracted KBs，直接从上亿个非结构化网页中抽取实体关系三元组。

与 Freebase 相比，这样得到的知识更加多样性，但同时精确度要低于 Curated KBs，因为实体关系和实体更多的是自然语言的形式，如“奥巴马出生在火奴鲁鲁。” 可以被表示为(“Obama”, “was also born in”, “ Honolulu”)。

下面以 CN-DBpedia 为例看下知识图谱大致是怎么构建的。

上图分别是 CN-DBpedia 的构建流程和系统架构。知识图谱的构建是一个浩大的工程，从大方面来讲，分为知识获取、知识融合、知识验证、知识计算和应用几个部分，也就是上面架构图从下往上走的一个流程，简单来走一下这个流程。

2. 数据支持层

最底下是知识获取及存储，或者说是数据支持层，首先从不同来源、不同结构的数据中获取知识，CN-DBpedia 的知识来源主要是通过爬取各种百科知识这类半结构化数据。

至于数据存储，要考虑的是选什么样的数据库以及怎么设计 schema。选关系数据库还是 NoSQL 数据库？要不要用内存数据库？要不要用图数据库？这些都需要根据数据场景慎重选择。

CN-DBpedia 实际上是基于 mongo 数据库，参与开发的谢晨昊提到，一般只有在基于特定领域才可能会用到图数据库，就知识图谱而言，基于 json (bson) 的 mongo 就足够了。用到图查询的领域如征信，一般是需要要找两个公司之间的关联交易，会用到最短路径/社区计算等。

schema 的重要性不用多说，高质量、标准化的 schema 能有效降低领域数据之间对接的成本。我们希望达到的效果是，对于任何数据，进入知识图谱后后续流程都是相同的。换言之，对于不同格式、不同来源、不同内容的数据，在接入知识图谱时都会按照预定义的 schema 对数据进行转换和清洗，无缝使用已有元数据和资源。

3