三两句 知识图谱系统

一个知识图谱应用主要存在如下分层：

业务层， 模型层， 物理层。

业务层，对应各类应用，比如展示类，查询类，推理类应用。

模型层， 就是业务数据图化抽象，可以使用多种方式建模， 学术界常用的rdf， 关系型数据库，

bigtable 三元组等。核心是要能够完整的表示本体的含义， 充当整个应用的模型schema。

物理层，关于本体和实体 的数据如何存储，在上一篇中讲到了使用 neo4j，hugetable，janusgraph 作为物理层的的实现。

比如在目前的一个实现过程中，使用了mysql 数据库作为中间的模型层， neo4j和hugegraph 作为物理层。在物理层中 使用了 elasticsearch辅助作为实体时序数据的存储。

随着业务的发展遇到了一些问题：

业务层，变化太快， 业界普遍缺少可用的，灵活性高的 编辑图谱的工具。

业务可理解为基于模型层的一个 view， 对与view的crud操作，需要额外建立一个 包含多个实体和关系的复杂表。

用户的操作，通过 一个migration的过程 写入到 模型层。

模型层实现目前使用的是 ER关系建模，每个实体为一张表， 关系为一张表。

在某个实际业务View中，实体有7，8 个，关系有6-7个，模型层需要管理的表非常多，维护比较复杂。

设想在新增加业务的场景下，需要 的工作包括;

1. 建立一个view 表，使用migration 过程，把view表中的 n个实体和m 个关系写入到 模型层。

2. 模型层之外，需要针对每个实体和关系做etl 把数据同步到 物理层的graphdb 和 elasticsearch辅助作为实体时序数据的存储。

存在的问题：

1. 针对每个业务场景，几乎都是case by case， 重复的劳动和 业务响应速度忙。

2. case by case下需要维护非常多的实体关系表，写多个migration 和etl job

3. batch式的工作，使得实时性要求达不到。

proposed 解决方案：

1、 中间模型换成通用的类似rdf 的模式，避免不同的业务建立不同的表，所以的业务数据统一对待，都是点 和边。

2、中间模型层 提供管理配置功能，方便不同的业务场景定义不同的view，以及后续的权限控制。

3、 提供灵活的基于图式的UI编辑工具，作为 业务对数据的crud 接口，避免使用 view 表操作。

4、 UI工具上的操作，记录日志写入到kafka，后台使用flink等流式计算工具实时更新物理层数据，入graphdb，es， 缓存,实现流程自动化。

从目前市场来看，支持 图数据到现有业务的转化的图数据UI工具， 子图版本控制，局部权限控制 等是非常缺乏的。

相对关系型数据库，周边配套还差很远。