图计算(图数据库)肇始于学术界对图论的研究,从最早的200多年前的欧拉的七桥问题演化出早期图论,再到后来的地图上色问题、20世纪60年代的随机图理论研究、多种最短路径算法,以及过去20年间随着大数据框架和理论发展而形成的各种社交图谱(图数据集)研究。但是,图计算(Graph Computing)与图数据库(Graph Database)之间的差异有很多,这是刚接触“图”的人不容易厘清的。尽管在很多情况下,图计算可以和图数据库混用、通用,但它们之间存在着很多的不同。
图计算可以简单的等同于图处理框架(Graph Processing Frameworks)、图计算引擎(Graph Computing Engines),它的主要工作是对已有的数据进行计算和分析。图计算的框架多数都出自学术界,这个和图论与计算机学科的交叉发生自上个世纪60年代并一直在不断演化有关。
图计算框架在过去20年中的主要发展趋势是在OLAP(Online Analytical Processing)场景中进行数据批处理(bulk analysis)。
OLAP:OnLine Analytical Processing即在线分析处理,通常OLAP因经常面向全量数据,计算量巨大而导致时延较长,因此很多人把OLAP等同于高延时批处理+静态数据处理。尽管,这么理解并不准确。在批处理时延中,T+1时延指的就是OLAP系统需要连夜运行到第二天才能结束。而T+0通常指的是当天(小时级时延)可以分析、运算完毕。
图数据库的出现要晚得多,最早可以称之为图数据库的,也要到了上个世纪90年代,而真正原生的图数据库在2011年后才出现。
图数据库的框架主要功能可以分为3大部分:存储、计算与面向应用的服务(例如数据分析、决策方案提供、预测等等)。值得一提的是,传统类型的数据库通常并没有独立的计算引擎,这部分工作都是在存储引擎侧完成的,几乎所有讲关系型数据库包括分布式数据库的书中,存储都占尽风头,通常不会为计算单列一章,由此可见一斑。就计算部分,包含图计算,但图数据库可以处理OLAP与OLTP类操作,也就是说可以兼顾OLAP与OLTP(两者的结合也衍生出了新型的HTAP类型的图数据库,在之前的文章中,笔者曾详细介绍过它的原理)。如果非常粗略的说,从功能角度上看,图数据库是图计算的超集。
OLTP:Online Transactional Processing即在线事物(交易)处理。OLTP相对于OLAP系统有两点不同:1. 低时延,OLTP系统通常是实时性的,例如典型的交易处理系统要求低时延、高并发;2. 数据一致性,交易处理系统尤其会强调对于系统的数据一致性要求,特别是当系统有高并发的读写,例如增删查改操作时的系统中的数据一致性要求。
HTAP:Hybrid Transactional & Analytical Processing指的是在一套系统内可以同时支持OLAP+OLTP,既同时支持这两类业务场景。通常是在一套分布式集群内不同的实例来支撑不同的OLAP或OLTP的需求。
但是,图计算与图数据库有个重要的差异点:图计算通常只关注和处理静态的数据,而图数据库则必须能处理动态的数据。换言之,在能保证数据动态变化的同时,保证数据的一致性,并能完成业务需求。这两者的区别基本上也是OLAP和OLTP类型操作的区别之所在。
静态与动态数据的这个区别有它们各自的历史成因,多数图计算框架都源自学术界或大厂的研究机构,其关注的要点和场景与工业界的图数据库有很大的不同。前者在创建之初很多都是面向静态的磁盘文件,通过预处理、加载入磁盘或内存后处理;后者,特别是在金融、通信、物联网等场景中,数据是不断流动的、频繁更新的,静态的计算框架不可能满足各类业务场景的诉求。这也催化了图数据库的不断迭代,从OLAP为主的场景开始,直至发展到可以实现OLTP类型的实时、动态数据处理。
另一方面,图计算框架所解决的问题和面对的数据集因为历史原因,通常都是一些路网数据、社交网络数据。尤其是后者,社交网络中的关系类型非常简单(例如:关注),任何两个用户间只存在一条边,这种图也称之为simple graph(单边图),而在金融交易网络中,两个账户之间的转账关系可以形成非常多的边(每一条边代表一笔交易),这种图我们称之为multi-graph(多边图)。显然,用单边图来表达多边图会造成信息缺失,或者需要通过增加大量点、边来实现同样的效果(但是这样会造成图上处理效率的低下)。
图:要更自然的表达真实的世界,显然是需要多边图的。否则就需要制造大量的实体和没有太多意义的关联边来构图。单边图的构图会有数倍于多边图构图所消耗的顶点与边,并且效率低下。
再者,图计算框架中一般只关注图本身的拓扑结构,并不需要理会图上点、边的复杂的属性问题。而这对于图数据库而言则是必须关注的。
图计算与图数据库的另外几个差异点还包含:
1.图计算框架中能提供的算法一般而言都比较简单,换言之,在图中的处理深度都比较浅层,例如PageRank网页排序、LPA标签传播、联通分量、三角形计数等算法,图计算框架可能会面向海量的数据,并且在高度分布式的集群框架之上运行,但是每个算法的复杂度并不高。图数据库所面对的查询复杂度、算法丰富度远超图计算框架。例如5层以上的深度路径查询、K邻查询、复杂的随机游走算法、大图上面的鲁汶社区识别、图嵌入算法、复杂业务逻辑的实现与支持等等。
2.图计算框架的运行接口通常是API调用,而图数据库则需要提供更丰富的编程接口,例如API、各种语言的SDKs,可视化的图数据库管理及操作界面,以及最为重要的图查询语言。熟悉关系型数据库的读者一定不会对SQL陌生,而图数据库对应的查询语言是GQL(Graph Query Language),通过GQL可以实现复杂的查询、计算、算法调用和业务逻辑。
3.图数据库通常与图谱可视化高度融合,而图计算框架则没有这种工业界(业务人员与数据库管理人员)才会有的诉求。换句话说,图计算框架很多就是个简单、粗糙的模型或者是个可执行文件,它所能提供的接口要比图数据库要单薄的多,因为它根本不用考虑极其复杂、全面的用户需求、体验。
希望以上介绍,能够让大家更深入地了解图计算、图数据库这项通过增强智能方式实现的更贴近人类智能的第三代人工智能技术。
·END·
【文章Ultipa版权所有,未经Ultipa授权不得转载,已授权使用的,应在授权范围内使用,并注明“来源:Ultipa”。违反上述声明者,Ultipa追究其相关法律责任。】