知识图谱的数据量，更新方式，使用场景的不同，决定其数据流如何设计。
我们的应用有着上亿级别的节点数，数据存在着离线批量更新以及用户实时手工修改两种方式，使用场景也有着图查询以及模糊的搜索查询。这样就决定着我们的数据流设计如下图：
分别介绍其中的功能模块：
（1）图数据库
我们采用图数据库来存储知识图谱的数据，图数据库天然地满足节点-->关系-->节点这种存储格式。目前业界多使用neo4j，titan等，我们使用了公司内部的分布式图数据库。感觉目前业界图数据库还没有一个有压倒性优势的系统，配置运维起来也比较麻烦。
（2）离线计算平台
我们每天会对图谱数据进行一次离线批量更新，在离线计算平台hadoop上完成，具体数据流如下：
2.1，新数据：数据源会有新实体进来，例如新增的歌曲，变化的电影播放次数等；
2.2，全量数据：把图数据库的最新全量数据同步回来，这部分数据里会包含用户的修改，会在后文中讲到；
2.3，增量数据：对新数据和全量数据进行diff，计算出增量数据，为了简洁起见，这里的增量数据仅仅考虑新增的节点，以及某些指定的节点属性，新增的边。
（3）Elasticsearch
由于对于图谱的查询存在一些分词模糊查询，原生的图数据库无法很好地满足查询需求，所以我们接入了Elasticsearch来承载这部分需求，每天会将图数据库数据同步到search。
（4）用户操作界面
用户有直接编辑知识图谱数据的需求，因此提供了操作界面，可以支持用户的编辑，包括新增节点，删除节点，修改边，修改节点属性等。对于这种用户操作会将其记录到mysql，实现操作记录可追溯，可重放，可撤销。
（5）定时清理程序
在长期的数据操作过程中，由于程序异常，数据异常等原因，不可避免地会出现一些无效数据，而图数据库的数据清理逻辑比较复杂，单独开启了一个定期清理程序。它会清理无效节点和无效边，保证图数据库的数据干净。
