技术概览

AbutionGraph是北京图特摩斯科技自研的时序动态知识图数据仓库与分析系统。

AbutionDB是底层数据的承载，存储包括：动静结合的图谱数据、时间序列数据、KV表格数据、地理空间数据、事件数据、文本数据。

AbutionGRS是以图谱为核心构建的下一代数据认知中台，是数据的开发层，提供所有大数据以及AI技术的逻辑封装、一键业务功能调用、指标数据查询、数据及资源资产管理等支持。

AbutionGraph与外部数据库系统关系图

为图谱智能中台AbutionGRS提供快速数据流转的能力-AbutionJet是一个分布式计算平台，中台的“灵魂”，专为高性能流处理和快速批处理而构建。AbutionJet架构基于并行，流核心引擎，是高性能和低延迟驱动的，该引擎使数据密集型应用程序能够以接近实时的速度运行。一些功能概览：

• 将数据从Kafka实时提取到AbutionDB中，将数据从AbutionDB查询发送到Kafka中；
• 建立一个ETL Pipeline，该Pipeline可以将数据从原始数据库导入AbutionGraph，反之亦然；
• 作为分布式缓存系统（功能同Redis），以低延迟丰富流数据、热数据缓存；
• 作为分布式计算平台，复杂任务更易于扩展，进行基于事件的处理，数据来源和去向自定；
• 为AbutionGraph提供“事务”支持，如交易付款时间约定，约定成功后对图指标属性更新；
• 分布式图数据查询与摄入，集群任何一台服务器都可以作为图实例的Source和Sink，一键调用分布式计算功能对查询与导入数据进行二次分析；

• 针对内部部署和云部署的动态节点发现，轻松扩展服务；
• 。。。

背景

1. 数据库不具备分布式计算能力。我们知道对于一个知识图谱数据库或是关系数据库，执行完查询语句后返回数据都在Client端，如果进行深入的二次分析都是基于Client端的本机内存，对于大量且复杂的任务服务器压力是非常巨大的，使用过JanusGraph的开发者可能都遇到过查询量太大Client服务器直接挂了的情况，以至于我们倾向于使用Spark等分布式计算引擎做大规模的历史数据分析。
2. 图库与其它数据库难以实现知识整合。知识图谱系统还是一套比较新的技术方案，企业既往的业务数据都在Hbase、Redis、MongoDB等传统大数据库中，场景迁移到图谱不能一蹴而就，考虑到用户痛点，传统数据库与图谱数据库的结合应用就显得非常重要。

AbutionJet 与Spark/Flink对比

Spark/Flink都是通用的大数据计算引擎，它们都是AbutionGraph技术生态中的一员，计算平台与存储平台数据互通无壁垒，使用Spark可以分析AbutionGraph中大量历史数据并将结果回流到AbutionGraph中，使用Flink可以大规模实时采集与处理事件数据同时入库AbutionDB中，两者皆可完美的与AbutionDB结合。

但是，有些用户会觉得维护Spark或是Flink有些“大”，略显笨重，于是我们开发了AbutionJet，将分布式计算的思想贯穿于AbutionGraph之中（存储分布式+计算分布式），AbutionGraph即包含AbutionJet，它提供一条Pipeline数据处理逻辑，Transformation类似于Spark/Flink中的语法，包括map，filter，groupBy，join等。它可以将AbutionGraph查询出的实体与关系数据做为Source，经过Transformation后Sink到其它数据库系统中，反向亦然。同时可将java.util.stream代码逻辑扩展为分布式。

边缘计算+动态知识图谱～=“数字孪生”

AbutionJet的意义在于，让计算服务像查询数据一样简单，提供一个轻量级、随时准备就绪的大数据计算引擎。我们直到移动数据是昂贵的，而移动计算相较容易得多，AbutionJet是一个贯穿AbutionGraph的计算服务集群，当把它孤立为若干个计算服务集群时，共用的还是底层的AbutionGraph图数据库，我们可以把每个计算服务集群放在就近的数据生产端优先消费区域数据，再把响应过的数据落地到AbutionGraph作更大范围的汇总，以此实现计算移动到数据端的“边缘计算”架构。

“数字孪生”是智慧城市的终极形态，即把真实世界搬进数字信息网络，这个“数字网络”记录着真实社会万物互联的各种事件，每个实体与实体间的关系都是具有多维度的指标属性，即一个有生命力的“用户画像”。AbutionGraph就是把这种动态的多维度指标状态保存于图谱中，并且实时的依据历史数据动态的更新这些“用户画像”指标，我们称之为实时图数据仓库，它是知识图谱与实时数仓的融合，面向物联网级应用，让数字化场景更智慧更接近于“数字孪生”。