知识图谱数据库还有OLTP、OLAP(MOLAP、ROLAP、HOLAP)的区别? 首个实时图数仓架构分析...

目录导读数据库

  1. 数据库与数据仓库与数据湖泊的介绍
  2. 图数据库与图数据仓库的区别
  3. 图库发展与现状
  4. HOLAP(ROLAP+MOLAP)图数仓的优势
  5. HOLAP数仓数据摄入方式
  6. HOLAP数仓数据存储方式
  7. 总结

最近,第一款面向大规模实时数据分析的HOLAP知识图谱数据仓库AbutionGraph发布了,同时也能够看成一款面向多种数据格式共同存储的数据湖系统(即湖仓一体架构,支持如图谱、时序数据、空间数据、文本、机器学习特征等,它们都是从图数仓中拆分出来基于HDFS的数据存储与管理子系统,在后续文章中会作介绍。如下篇幅内容均出自AbutionGraph的设计架构拆分。数组

 

既然是图谱数据仓库,那我们先来了解一下:网络

数据库(Data Base)与数据仓库(Data Warehouse)与数据湖泊(Data Lake)的介绍

<数据库>通常指联机操做数据系统(Online Transaction Processing)OLTP定义:面向事务操做、数据增删改查,存储既定的历史数据。数据结构

<数据仓库>通常指联机分析处理系统(Online Analytical Processing)OLAP定义:面向分析、管理、决策、通常只进行读写操做的有组织的数据集合,可按时间区分数据。架构

<数据湖泊>通常指能够存储海量任意类型且有能管理这些数据能力的数据系统,咱们熟知的HDFS就是一个很好的数据湖底座。机器学习

 

如定义所述,三者最主要的区别是用途不一样,即面向的业务场景不一样。一些经典热门的数据库的特性比较以下:性能

特征\产品学习

数据库(OLTP)大数据

数据仓库(OLAP)ui

离线

MySQL、Oracle

Apache Hive/Presto

实时

Hbase、Tikv

Apache Druid/Kylin

用户

初级的

决策者/高级的

功能

基本查询

分析决策

架构

面向应用

面向主题

数据

当前的,二维的

历史的,多维的

存取

百千条

上百万条

场景

简单事务

复杂查询

用户数

上千个

上百万个

数据量

MB ~ GB

GB、TD、PB、EB

经过概念和表格对比以后,相信咱们已经了解了数据库和数据仓库的区别,接下来将会很好区分图数据库和图数据仓库。

 

图数据库(Graph DataBase)与图数据仓库(Graph Data Warehouse)的区别

<图谱-数据库>是数据库的延伸,也指OLTP操做数据系统:在面向事务操做、数据增删改查,存储既定的历史数据的同时,可高效地管理大量关联数据,挖掘数据之间的深层关系。至关于给数据库中的每一条数据加上了实体和关系的数据结构,构成一个存储全部历史数据的“数据图谱”。

<图谱-数据仓库>是数据仓库+图数据库的延伸,也指OLAP分析处理系统:在面向分析、管理、决策的有组织的数据集合,可按时间区分数据,实时依据历史数据得出总结的同时,可高效地管理超大规模关联数据,挖掘数据之间的深层关系。至关于给知识图谱加了多维立方体“动效”,每个实体/关系上的 每个时间维度上的 每个属性 都是“实时动态”在线更新的,决策者能够快速的得知事件的缘由和动向,进行下一步动做。

咱们从下表中看看都有那些不一样:

特征\产品

图数据库(OLTP)

图数据仓库(OLAP)

离线

Neo4J、JanusGraph

实时

TigerGraph

AbutionGraph(惟一)

用户

初级的

决策者/高级的

功能

基本查询

分析决策

架构

面向应用

面向主题

数据

当前的,二维的

历史的,多维的

存取

百千条

上百万条

场景

简单事务

复杂查询

用户数

上千个

上百万个

数据量

MB ~ GB

GB、TD、PB、EB

聚合响应

秒~次天

亚秒~秒

 

图库发展与现状

图数据库是目前市场的应用主流,由于知识图谱技术还处于新兴领域,图库产品屈指可数,都属于OLTP系统,部分功能也相对落后,如:Neo4J与JanusGraph,这两款离线的图库占据了国内90%以上的市场,实时入库性能较好的TigerGraph,因其高昂的售价,多为大企使用OLAP图数仓领域目前只有图特摩斯科技的AbutionGraph这一款产品,是一款HybridOLAP图库,在性能和各方面功能上,都作了不少颠覆性的图库技术。

鉴于知识图谱优秀的知识检索和推理能力,可普遍应用于智能问答、关系搜索、个性化推荐、欺诈检测、金融风控、军工情报、供应链管理、loT监控、企业画像、线上零售、医疗保健等场景。因图库产品的缺乏,图技术认知不够,性能等各方面技术落后于工业场景的需求,知识图谱数据库的落地案例还不多。为了大力发展知识图谱技术,国家科技部也把“时序动态知识图谱技术”归入到了2030年的重大人工智能技术发展目标中,“时序动态”实际上是咱们接下来章节中介绍的MOLAP架构,也是AbutionGraph中使用的架构之一,相信在将来实时图数据仓库会和实时数据仓库同样成为企业的硬核底座。

 

HybridOLAP(ROLAP+MOLAP)图数仓的优势

使用AbutionGraph做为OLAP服务的常见的应用场景包括:BI报表, 监控系统、用户行为分析、在线分析,特征分析, Ad-hoc, DataFlow, ETL等场景绝大多数OLAP场景须要查询最近一段时间的数据(过去一分钟,过去三天,过去一周,过去一个月等) 它使分析人员可以迅速、一致、交互地从各个方面观察信息,以达到深刻理解数据的目的。OLAP按存储的数据存储格式分为ROLAP、MOLAP和HOLAP,前二者都有明显的优缺点,面向的应用场景也有所不一样HOLAP则是ROLAPMOLAP的混合形式

 

种类\介绍

介绍

产品

优势

缺点

MOLAP

(Multi-dimensional)

 

 

以多维数组(Multi-dim Array)存储模型的OLAP。

 

特色数据预计算(pre-computaion),而后把预计算结果(cube)存在多维数组里。

Apache

Druid

 

Apache

Kylin

 

cube包含全部维度的聚合(aggregate)结果,因此查询速度很是快

 

相对关系型数据库计算结果数据的磁盘空间占用更小扩展性强,适用于维度数量多的模型

对于维度多的模型预计算慢,空间占用大。update cube的时间跟计算维度(group)相关,随着维度增长计算时间大幅增长,此外预计算还会形成数据库占用急剧膨胀。须要提早设计维度模型,查询分析的内容仅限于这些指定维度,增长维度须要从新计算。

ROLAP

Relational

 

基于关系模型存放数据,通常要求事实表(fact table)和维度表(dimensition table)按必定关系设计,它不须要预计算,使用标准SQL查询不一样维度数据。

ApacheHive

 

ClickHouse

 

SparkSQL

 

Impala

 

Greeplum

 

Presto

 

 

更适合处理non-aggregate数据,例如文本描述

 

基于row数据更容易作权限管理

由于是即时计算,查询响应时间通常比预计算的MOLAP长

HybridOLAP

 

 

MOLAP和ROLAP类型的混合运用

 

细节的数据以ROLAP的形式存放,更加方便灵活,而高度聚合的数据以MOLAP的形式展示

Thutmose

AbutionGraph

更适合于高效的分析处理。公司使用HOLAP的目的是根据不一样场景来利用不一样OLAP的特性。

 


AbutionGraph的存储形式便是采用了HOLAP这种混合模式。由于在图分析场景中,咱们都会去计算节点的出度入度等指标,一个节点关联的邻居节点数量是很是多的,采用OLTP或者ROLAP的存储形式每次都计算一遍,对于一个百亿数据量的图谱,查询响应时间和资源消耗都是没法估量的,很容易资源不足而致使OOM异常,这种指标计算的场景则很是适合MOLAPpre-aggregate事件,只存放汇集值(count,sum等)大于某个最小支持度阈值的立方体单元。而对于MOLAP得出的报表结果,咱们一般须要深刻查看其中的每一条历史数据,即non-aggregate事件,这种须要得知历史事件的查询则是ROLAP的应用场景。在大规模的事件图谱中,任其一都没法及时知足复杂的业务需求,时序动态图库AbutionGraph结合了MOLAP与ROLAP二者的优势,使本来咱们熟知的关系型“数据图谱”(OLTP)变成了多维度数据存储的“cube graph”(MOLAP)和可实时聚合的“动态图谱”(MOLAP)。

HOLAP数仓数据摄入方式

AbutionGraph与其它数仓相似,能够覆盖以下两种场景:

  • 实时:数据流能够经过kafka/MQ或者flink实时处理以后,经过JDBC方式批量导入到AButionGraph中
  • 离线:数据落地HDFS ODS层,离线经过Spark或MR的batch形式批量导入到AButionGraph中

 

HOLAP数仓数据存储方式

HOLAP的数据模型是一个多维(group)立方体(cube)的存储模型,图谱中每一个实体与每条关系都是一个cube,整个图谱就比如一个全视角的“宇宙星际”。

立方体(Cube):图谱中实体与关系下的360度多维度标签,是一个多维数组包含着groups。

维(Group):人们观察事物的视角,如时间、地理位置、年龄和性别等,是单一角度概念。

维的层次(Lever):表示维度概念基础上进一步的细分,如时间能够细分为年、季度、月三个层次。

维的成员(Member):表示维不可再细分的原子取值,即维中的属性集,如时间维2020年10月的成员能够有出度、入度、对手集等(MOLAP),再如张某的基础属性维成员能够有age、name、occupation等(ROLAP)。

度量(Measure):表示在这个维成员上的取值,Count、Max、Sum、Cardinality、Last、TimeSeries、TopN....。

 Ps:图片来源于网络

 

总结

传统的 OLAP 须要作各类 pipeline、ETL 导入数据,这样的架构会存储多份数据,冗余而且一致性很差保证,也引入过多的技术栈和复杂度,也不能知足实时分析,即便 mini-batch 的处理仍然须要最快数分钟。业界的趋势在于赋予 OLAP 高吞吐实时写,提供实时查询能力,例如上游数据源,通过流计算系统,老的架构基于 lambda,写历史数据到存储再清洗,实时数据入一些 NoSQL,使用方须要作各类数据源 merge 操做,流行的方式是流计算系统直接写 OLAP,这样避免了数据孤岛,保证了链路简单,图特摩斯科技的AbutionGDB正如阿里云团队提出的 HSAP (Hybrid Serving/Analytical Processing)这种理念。

OLAP 领域经历了从 RDBMS 创建起来的 SQL + OLAP,到 ETL + 专有 OLAP 的数仓,ROLAP,MOLAP,再到咱们当前领先探索的 Know-How + HOLAP 的知识图谱数仓阶段,将Know-How与OLAP两个前沿领域进行碰撞、融合,让OLAP/GraphDB突破传统,以更数智化的架构应对刁钻复杂的业务场景。

目前OLAP系统仍在不断演进,也正在被更多企业的高级场景所应用,从传统数仓到实时数仓架构的演进、数据中台的搭建..... 更多的大数据厂商、云厂商、人工智能厂商、数据治理厂商... 也在尝试进入这个领域,为知识图谱和数据仓库的解决方案带来更多的灵感与实际的好处。

 

 

出品 | 北京图特摩斯科技 (www.thutmose.cn)

合做 | 联系方式

试用 | 您有任何业务场景想要用到知识图谱均可以与咱们联系 免费给您提供先进的且和以往不一样的解决方案

技术交流群: