目录导读
- 数据库与数据仓库与数据湖泊的介绍
- 图数据库与图数据仓库的区别
- 图库发展与现状
- HOLAP（ROLAP+MOLAP）图数仓的优点
- HOLAP数仓数据摄入方式
- HOLAP数仓数据存储方式
- 总结
最近，第一款面向大规模实时数据分析的HOLAP知识图谱数据仓库AbutionGraph发布了，同时也可以当作一款面向多种数据格式共同存储的数据湖系统（即湖仓一体架构），支持如图谱、时序数据、空间数据、文本、机器学习特征等，它们都是从图数仓中拆分出来基于HDFS的数据存储与管理子系统，在后续文章中会做介绍。以下篇幅内容均出自AbutionGraph的设计架构拆分。
既然是图谱数据仓库，那咱们先来了解一下：
数据库（Data Base）与数据仓库（Data Warehouse）与数据湖泊（Data Lake）的介绍
<数据库>一般指联机操作数据系统（Online Transaction Processing）OLTP定义：面向事务操作、数据增删改查，存储既定的历史数据。
<数据仓库>一般指联机分析处理系统（Online Analytical Processing）OLAP定义：面向分析、管理、决策、一般只进行读写操作的有组织的数据集合，可按时间区分数据。
<数据湖泊>一般指可以存储海量任意类型且有能管理这些数据能力的数据系统，我们熟知的HDFS就是一个很好的数据湖底座。
如定义所述，三者最主要的区别是用途不同，即面向的业务场景不同。一些经典热门的数据库的特性比较如下：
| 特征\产品 |
数据库（OLTP） |
数据仓库（OLAP） |
| 离线 |
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则是ROLAP和MOLAP的混合形式。
| 种类\介绍 |
介绍 |
产品 |
优点 |
缺点 |
| 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异常，这种指标计算的场景则非常适合MOLAP，即pre-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）
合作 | 联系方式
试用 | 您有任何业务场景想要用到知识图谱都可以与我们联系 免费给您提供先进的且和以往不同的解决方案
技术交流群：
