联合分享人：
• 杨哲超，阿里云数据库高级产品专家、图数据库产品负责人；
• 周健 阿里云数据库内核技术专家、V3引擎设计师；
• 黄赛 阿里云数据库算法技术专家、V3引擎设计师；
视频链接：https://developer.aliyun.com/topic/gdb202112
目录：
业务价值
应用场景
产品介绍
正文：
一、业务价值
随着互联网的飞速发展，企业数据呈爆发式增长，数据与数据间的关联更加复杂，图数据库应运而生。如何更好的利用该技术帮助业务决策和解决问题呢？不论是新冠疫情爆发整体的监控、侦测还是社交网络推荐，信用卡风控、交易、反欺诈等，都离不开图数据库的身影。
1. 从Big data到Big graphs，图使一切产生关联
“Gartner预测，到2025年图技术在数据和分析创新中的占比将从2021年的10%上升到80%。该技术将促进整个企业机构的快速决策。”
——《Gartner 2021年十大数据和分析趋势》
技术与产业应用遵循着双螺旋上升的趋势，促使图技术达到了爆发式增长的边缘。从技术角度出发，图技术的应用是针对解决数据的高度关联和严重随机访问的问题；从业务角度出发，图的价值更多的在于，融合数据、技术，打破生态位屏蔽，产生高维认知。
2. 认知智能使AI触及生产核心，知识图谱决定认知智能的起点
相关链接:https://en.wikipedia.org/wiki/DIKW_pyramid
在提及图数据库时，就会涉及图数据知识图谱。计算机在智能发展的路径中，遵循着从数据到信息、到知识、到智慧的演进过程。知识图谱是认知智能发展的基础，而图数据库是承载知识图谱的最佳底座，帮助实现更智能的数据决策。
二、应用场景
目前图数据库已在金融、社交、互联网等不同领域发挥着重要的作用。
1. 社交分析
图数据库在社交关系应用中是最早的，可以将用户定义成点，用户与用户之间的关系定义为边，就此形成了以点边为关系查询的一张图。基于此图，我们可以进行很多分析比如初始用户推荐、好友精细化推荐、点赞查询、话题查询等功能操作。如果使用传统的关系数据库图，类似这种高度关联的数据去查询、建模、推理，一般数据库基本是无法完成的任务。
2. 智能营销
One-ID核心思想借助联通子图等一系列算法，将不同数据源的多个实体所代表的真实实体进行合并，从而识别到不同路径的ID隶属于同一用户，进行后续的管理操作，比如做更清楚的画像，更精确的信息推荐。
智能营销是使用图的简单方法或复杂方法方法来实现。简单方法可以以协同过滤算法思想为核心,通过查找共同邻居数进行相似节点推荐，也可以通过图神经网络的类似算法，去构建节点的向量来计算进行相关推荐。
3. 信用卡欺诈检测
• 方案思想：
通过图技术汇集信用卡周边信息，包括持卡人社交关系、网络环境、设备环境，结合自动机器学习优化风控决策参数，提升业务效果和构建效率；
• 应用效果：
帮助某头部商业银行信用卡中心，自动构建890个特征。发现嫌欺诈商户12个，预测逾期用户186万人(*卡片2.2万张，识别欺诈团伙102个，模型召回命中率92.4% (客户模型为60%)；
4. 保险欺诈检测
图数据库在保险领域，应用至少分为三个部分：
• 基础图查询：可以通过一个节点来查找相关的联络人以及相关投保保单；
• 分析嫌疑保单：可以以疑似保单为切入点，找到保单和承保人之间的关联；
• 高危投保人团伙分析：可以通过已知的投保人和被保人信息，进行潜在高危风险分析。
应用效果
某头部保险公司，经测算其关联查询性能是原有保险反欺诈方案的10-100倍。
例如客户信息系统查询一个账号关联的信息（手机、座机、地址、证件、车辆），我们之前是先从主表查询 -> 再从关系表 查询到目标表id -> 通过目标表id查询到关联的信息，这样如果属性多的话要经过几十次甚至百次数据库交互，网络通信上就要浪费多次通信成本。
5. 反洗钱
a. 核心痛点
• 发现更多的洗钱模式，提升召回率（Recall）。每年全球洗钱交易金额占全球GDP总量的2%-5%（数据来源：PWC报告）；
• 减少错误预警，提升准确率（Precision）。全球反洗钱预警数据误报率约为95%。
b. 细分场景
• 洗钱行为分析；
• 核心资金路径分析；
• 关键转账枢纽节点计算；
6. 游戏拉新、促活、防流失场景应用
a. 中国游戏市场特征
• 游戏行业整体市场规模在3300亿元，增速放缓，用户规模快到天花板；
• 游戏成长期周期短，之后用户活跃几乎不可逆，前期运营促活效率至关重要；
• 受“游戏版号”影响，头部聚集趋势明显。
b. 预测付费玩家，优化运营策略
此模式可以极大地降低用户使用门槛，实现更好的业务效果。
三、产品介绍
1. 从“知识存储”到“推理分析”，一站式智能决策方案
其中知识存储产品化程度最高，推理分析价值潜力最大。
a. 知识存储：将取出来的信息进行有效的存储管理，以便可以及时的检索和查询；
b. 推理分析：大部分企业面临的主要问题是有关联数据之后，到底能推理出什么结论；
c. 可视化展示：GDB提示了面向开发者的可视化控制台，可用于整个图数据库的调试。
2. GDB V3是阿里云自研的高性能图数据库引擎
a. 极致性能，相较于传统图数据库提升近百倍
通过自研算子体系、计算引擎、执行引擎，逐步逼近物理硬件的极限性能，提供超越传统图数据库百倍的查询性能只为解锁更多可能性。
b. 兼容并包，集多种图查询语言于一身
高度兼容Neo4j、JanusGraph等图数据库引擎，支持OpenCypher、Gremlin查询语言，降低迁移成本和研发门槛。
c. 快速弹性、高可用、易运维，尽享云原生技术普惠
基于云原生架构的图数据库引擎，可快速扩缩容，应对突增业务负载；支持高可用实例、节点故障自动切换，保障业务连续性;提供备份恢复、自动升级、监控告警、故障切换等丰富的运维功能，免去繁琐的运维烦恼。
d. 低构建成本、灵活计费，满足不同成本需求
产品构建、运维成本，仅为国外图数据库友商的40%；支持按量付费、包年包月多种计费形式，无论创新探索，亦或生产应用都能*掌握。
3. 国内唯一进入Forrester Wave评测报告的图数据库产品
在高可用和灾难恢复评测项目中，阿里云图数据库取得了最高的成绩。
4. 影响查询性能的核心问题
a. 为什么CPU利用率低？
就数据库性能设计而言，用户在使用数据库的过程中经常疑惑：查询为何如此的慢？
CPU利用率低，用户查询在server端会经过cache，内存以及网络等等的部件，这些部件处理的性能和时延相差较大。例如：缓存的时延约10纳秒，内存的时延约百纳秒，SSD已经上升到微秒。在数据的流转过程中，CPU很大程度上处于等待状态
b. 为什么CPU利用率100%，响应依然慢？
即便CPU100%的利用起来也不是意味着100%的处理用户的有效数据。2008年一篇文章表示，在CPU处理中，7%是在真正处理用户的数据，其它90%多都是用在缓存管理和数据一致性的保证上。
c. 为什么只有一个CPU忙？
目前的数据库架构往往有缓存的多级架构，并且提供cpu架构相关的优化指令集。在设计过程中，将CPU的此特性发挥出来，可以有效的提高性能，从而降低用户访问的时延。
5. 图数据库的架构分类
目前业界流行的图数据库主要分为两类：计算存储分离的分布式架构和以主-备架构为代表的高可用架构。
a. 分布式：万亿超大图场景，数据跨网络交互开销大。
• 分布式架构的典型代表：NebulaGraph、TigerGraph、JanusGraph，此架构一般包括计算节点、存储节点、元数据管理节点；
• 优势在于存储和计算各自可以平滑地进行扩展，适用于万亿海量大图场景；
• 劣势是数据跨节点分布， 计算、存储跨节点部署导致整个请求在处理过程中涉及到计算和存储之间多次网络交互，增加了很多不必要的时延。
b. 主-备：千亿内大图场景，存储模型和计算模型数据转换开销。
• 主-备架构的典型代表neo4j、Neptune、阿里云GDB V2，此架构一般包括两个角色，主节点对外提供读写，备节点在主服务出现问题时，提供切写服务；
• 此架构优势在于架构简单，用户体验度极佳，适用于中小规模的用户；
• 劣势在于存储规模和计算能力存在瓶颈。除此之外，用户存储逻辑与运算不匹配时，有数据转化的开销存在。
c. 主-备性能改进：计算、存储均基于图模型，无数据转换，计算存储一体，效率高。
• 就GDB而言，也是主-备架构，但依托于阿里云的云原生架构，存储和计算也可以各自平滑的扩容，存储规模可以扩展数十TB，计算可以垂直扩展，也可以水平扩展。
GDB V3是对V2版的优化，一是对存储层进行重构，设计出了持久化存储层和图原生存储层，二是将整个计算下拉到图原生存储层，通过存算一体，提升了整体的执行效率。
6. 数据流转逻辑
• 自研语法解析Parser；
• 定义面向图结构的存储模型以及算子体系；
• 实现高效的优化技术, 动态执行算法；
上图以用户查询为例，详解GDB是如何处理用户的查询。接入服务，得到用户的请求后，进行封装放入任务队列，Parser服务拿到此请求，进行语法算法解析，翻译为中间算子，V3版本接着对逻辑算子树进行静态优化，形成物理算子树，最终将整个物理算子树下压到图原生存储层进行动态执行，并最终给用户返回结果。
7. 自研算子体系
数据库两个核心分别是：数据模型、操纵算子。
a. 关系数据库
以关系数据库为例，要使用关系数据库，先要对业务场景进行建模，即E-R模型。接着转化为关系模型，形成一张张物理表。将数据存储到关系数据库后，用户可以通过数据库提供的标准算子，进行数据的增删改查操作。
b. 图数据库
图数据库整体和关系数据库类似。从模型上来讲，可以分为属性图模型、RDF图模型。
以属性图模型为例，包括Vertex、Edge、Prop。
将关系模型的E-R图和图模型的属性图Prop对比来看，所包含的元素本质上是一致的。不同的是关系数据库将E-R模型中转换成了关系表，图数据库则直接将其存储为一张图。正因为物理映射的简洁性，使得图数据库厂商可以基于这种模型之上，构建出较为丰富且复杂的算子体系。
GDB V3既考虑到了关系数据库的算子，也考虑到了图数据库的算子，将两者进行叠加优化得到GDB V3算子体系。
c. GDB V3算子体系
GDB V3算子体系整体分为两大类：修改类算子、只读类算子。按照子算子的数量，分为扫描类，单子算子类、多子算子类。将部分简单算子抽象成功能函数（AggFunc、ArithmeticFunc、FilterFunc、ScalarFunc、SelectFunc、SideEffectFunc、SubQueryFunc）。
8. 自研计算引擎
有了算子体系，那么用户的请求是如何转换成算子树呢？
a. 解析引擎
• 纯手写, 性能相比Groovy原生编译器快1000倍；
• 强化数据库安全防护能力；
• 大幅提升用户易用性；
b. 翻译引擎
• Gremlin IR转为自研算子树；
• 信：每个Gremlin IR都有对应的中间描述；
• 达(雅)：内嵌多层优化卡点、边翻译边优化；通过预扫描、递归等手段精确schema类型，进行算子消融；
c. 优化引擎
• 基于Cascade的子tree匹配模型, 解决基于策略优化天然存在的依赖性、低效率、一次性等问题；
• 支持Filter、Limit等谓词下推；Repeat、子查询打平；列裁剪；排序、去重消除等优化；
9. 高性能执行引擎
形成物理算子树之后，需要高性能的执行引擎进行执行。
a. 存算一体
请求数据被翻译之后形成了优化后的算子树，将此算子树下压到云原生的图原生存储层，进行存算一体的运算输出结果，每行都包含各自的object。
b. 数据驱动
传统数据处理一般基于火山模型，上图左边是算子树，自上而下的调度，数据自下而上一行行处理，这种处理效率极其低下。GDB V3虽然也是自上而下去调，但却在处理时一次生成一批数据，并且父子算子间通过Producer和Consumer的形式共享同一份数据集，极大地提升了数据处理效率。
c. 动态执行技术
原生图存储层，针对图的各个结构进行了统计，在优化的过程中不再需要大范围统计，而是生成了对应动态算子。在算子执行中，根据执行层数据结构进行实时优化。通过动态执行算子和动态优化策略，也可提升数据处理效率。
10. 面向性能的优化
a. 资源池化
• 问题：频繁New / Delete是一个很重操作；
• 自研内存管理系统；
• 自研多种数据数组、Tree等多种数据结构；
• 系统关键数据结构资源池化；
b. 无锁化编程
• 基于MVCC技术解决多线程数据一致性问题；
• 实现多级缓存池，解决高并发下线程资源分配竞争；
• 使用线程局部变量，解决资源频繁分配释放以及数据可见性与多线程资源争抢的矛盾等问题；
• 基于CAS原子操作解决高并发下多线程资源同步、日志记录等并发锁冲突场景；
c. 其他
• 使用<指针, 引用计数> 思路解决复杂数据结构跨算子树据传输中编解码性能问题；
• 自研Binary数据编解码算法，解决复杂结果集encoding开销；
• 使用SIMD指令优化部分函数操作；
11. 测试环境
a. 软件版本
• Neo4J: 4.4.2版本，单实例；
• GDB v3: 1.0.1版本，单实例；
b. ECS规格
• CPU：80 Core；
• 内存：960GB；
• 实例规格：ecs.re4.20xlarge；
• 磁盘：10TB SSD云盘；
c. 测试数据集
• twitter数据集；
• 点规模：41999999；
• 边规模：1468365181；
• 平均度数： 73；
• 修改点：
点: 添加name属性，String类型；
边: 添加weight属性,范围：[0, 1]；
注：选twitter数据集其一是因为其是图数据库里边标准数据集之一，点边规格适用大部分业务场景；其二是因为来源于twitter网站，且社交领域是图数据库的重要领域，数据价值极高；其三，点边比例为1:73，意味着每个点对应73条边，连通性极好，系统中的点有成万甚至几十万条边。此图模型能够真实反映出图数据库应用场景的复杂性和业务的真实性。
d. 测试指标
• k-hop查询
方法：计算1, 2, 3, 6 度路径数；
目标：验证大规模图数据随机查询能力；
• 超级点属性累积求和
方法：计算随机点一度邻居属性累积求和；
目标：超级顶点数据实时聚合能力复杂查询能力索。
• 复杂场景洞察
方法：计算随机点按照一定条件循环向外探索累积求所有有效路径数；
目标：模拟用户真实场景验证Repeat子图探索。
12. K-HOP测试
测试语句：g.V(uid).repeat(out()).times(k).path().count()
a. 2跳性能对比
• 相比Neo4j性能提升95倍；
b. 3跳性能对比
• 由于Nebula部分顶点超时，只统计了度最小的k个顶点的均值；
• 相比Neo4j性能提升87倍；
c. 6跳性能对比
• GDBV3单线程耗费266s；
• 扫描数据40亿，平均几十ns一条数据；
13. 超级点一跳属性累积求和
典型场景：社交、电商、游戏、金融、教育、知识图谱等场景。
测试效果：相比较Neo4j也有9倍性能提升。
测试语句：g.V($uid).inE($rel).values('weight').sum()
14. 复杂场景 – 瞬时“分析”，离线任务在线化
a. 场景描述
从种子节点，沿着边不断往外扩展，找到所有符合终止条件的所有节点（路径）：
• 中间条件过滤：扩展过程中，对中途经过的边类型和属性进行范围判断；
• 循环终止条件判断：顶点的属性符合特定条件或者探索深度超过特定深度；
b. 性能数据
相比Neo4J提升25倍。
测试语句：
g.V(’vid’).repeat(outE(‘edge’).has(‘property’, gte(low).and(lte(high))).otherV()).emit().until(has(‘property‘, eq(value)).or().loops().is(gte(k-hops))).count()
15. 两种图模型：属性图和RDF
a. 属性图
• 由顶点、边、属性组成；
• 顶点和边有一个或多个标签；
• 属性为键值对，顶点和边可以有任意多个属性；
• 多用于事务型图数据库，在工业界被广泛使用。
上图属性图示例，描述了人和软件间的关系，人和软件为顶点，通过标签来区分类型，附带一些属性来描述特征；关系用边来表示，同样拥有标签和属性。
b. RDF
• 由<主语，谓词，宾语>三元组构成；
• 主语是实体，谓词表示关系类型，宾语是实体或者属性值；
• W3C标准；
• 多用于知识图谱，学术界应用较多。
上图是将属性图转换成RDF之后的样子，对比以上两图，属性图更加的简洁，更接近对现实的理解，较适用于描述业务逻辑。RDF较适用于描述知识体系，更多用于知识图谱类的研究项目。
16. 图数据的存储方式
按照图数据的存储方式，目前市面上的图数据库可以分为原生图存储和非原生图存储。
a. 非原生图存储
基于现有的关系型数据库或者NoSQL数据库，查询时需要把图查询映射到存储引擎的查询语言或算子上。
• 优点：可以充分利用现有成熟系统的基础设施；
• 缺点：软件栈更复杂，且往往伴有跨进程通信开销，限制了性能；底层存储引擎并非专为图数据的访问模式而设计；
• 典型产品：JanusGraph、HugeGraph；一些关系数据库的图扩展如Apache Age、Oracle PGX；
b. 原生图存储
专门针对图重新设计的存储引擎，更加契合图查询和图计算的访问模式。
• 优点：针对图访问模式优化的数据结构和布局，提升访问效率；支持自定义图算子，以便将计算任务下推到存储层，减少数据的交互；
• 缺点：开发工作量大；
• 典型产品：GDB、Neo4j、Nebula、TigerGraph等。
17. 原生图存储的实现方式
原生图存储的实现方式大致分为三类，邻接矩阵，邻接链表，键值对。
a. 邻接矩阵：用矩阵表示点和点之间的关系
• 通常是稀疏矩阵，需要使用CSR/CSC等方式进行压缩来提高空间效率，导致更新困难，通常用于静态图；
• 案例：RedisGraph；
b. 邻接链表：用链表串连点相关的边
• 相比邻接矩阵更加灵活，可以用于存储较为复杂的异构图，更新效率更高。邻接多重表、十字链表等可以认为是邻接链表的不同实现形式；
• 案例：neo4j；
c. 键值对：
• 将点、边编码为键值对，通过编码规则建立关联，依赖KV存储系统的范围扫描进行查询；
• 案例：NebulaGraph。
18. 图存储面临的难题
a. 数据密集：图数据的访问模式中，计算高度依赖数据，I/O和计算的比值较高；
b. 数据局部性差：在图遍历中，每向外一跳，随机访问的数据量都会成倍增加，导致性能随着跳数的增加急剧下降。
c. 分区负载均衡问题：图查询的工作负载跟图本身的结构特点是高度相关，在分布式存储中，静态的分区策略往往并不能很好的适应工作负载，容易造成负载不均衡。
19. 阿里云GDB V3原生内存图存储
GDB V3原生内存图存储，通过高效的存储结构来查询数据访问问题和动态图实时更新问题，核心数据结构是改进了邻接矩阵：
• 矩阵行存储为连续数组，行与行之间可以不连续；
• 度数较大的顶点，使用树状稀疏数组存储，减小更新粒度，提升插入和删除的效率；
• 每个顶点关联的边，按标签进行聚合。
20. 用矩阵计算的思想解决图遍历问题
邻接矩阵中i行j列的1，表示i和j之间有一条边，即邻接矩阵表示的是点与点的一度邻接关系。那是否可以通过邻接矩阵得到点和点之间的k度邻接关系呢？
以上图中第二行为例，将邻接矩阵与自身相乘，得到一个新矩阵，其第4行的第2、3列为1，对应原图的点4、点3、点2之间各有一条2度的路径。换言之，邻接矩阵的平方，表示点与点间的2度邻接关系。类似的我们可以得到邻接矩阵的k次方，就代表了k度邻接关系。
如果只想查找某些特定点的2度邻接如何做呢？只需要用一个行向量来表示要查找的点，与邻接矩阵相乘就可以。以上图中第三例为例，行向量中第1、4列为1，要查找点1、点4的2度邻接，再和邻接矩阵相乘两次即可得出结果。
21. 基于细粒度快照的MVCC
a. 读事务基于快照进行
• 保证了事务隔离性，杜绝dirty-read、non-repeatable read等异常；
• 读操作不会因为写事务而阻塞，因此能达到很高并发的读性能；
b. 乐观写事务
• 事务无锁并行执行，提交时处理冲突。在低冲突率的情况，可以最大限度的利用处理器的多个核心，达到较高的吞吐率；
• 使用组提交(Group Commit) ，将创建快照的代价均摊到多个事务上，提升写事务吞吐率；
• 事务提交前先将数据持久化写入到外存，确保不丢失。
22. 高效的垃圾回收
任何一个MVCC，都面临着垃圾回收的问题，不再需要的版本需要回收存储空间，GDB V3也不例外。垃圾回收的核心问题：如何快速找到不再被需要的数据？
GDB V3垃圾回收基于快照，如果该快照没有被任何引用，就可以被删除。但大部分数据都是在多个快照之间共享的，在删除时，需要知道每个快照的生命周期，才能判断是>否可以被删除。生命周期用区间[start, end)，start是当前版本创建时间，end是逻辑上被删除时间。删除快照i是，如果一个数据单元的生命周期满足：① start > i - 1 并且 ② end <= i + 1,就可以安全删除。
当数据量很大时，逐个检查极其耗时，GDB为每个快照引入失效列表来加速检查，减少耗时。失效列表中记录的是上一个快照还在使用中，而当前快照不再需要的代码。失效列表实际上是代表生命周期中的end，有了失效列表，只要在每个列表中记录start，就可以快速找出需要删除的数据。
GDB V3还在内部维护轻量级资源池，垃圾回收释放的内存优先进入资源池等待复用，这就减少了跟操作系统和内存管理器间的交互，提升了内存分配和释放的效率。
23. GDB内嵌常用图计算算法
GDB内嵌算法有路径类、社区分析类、中心度类、统计类、相似度类等，可以帮助我们业务场景更多的实现关于图上特征的选取和捏合。
24. Graph + AI，从数据升维到规律总结
机器学习、深度学习的意义在于对规律总结，而图的意义在于信息升维。图数据库要解决多元、大规模异构的数据，使其有效的连接起来，产生高维决策。
不同于传统关系型数据库，图数据库背后没有指导其决策的思想和规则，这就是为什么现在图数据库和技术没有被特大规模应用的核心原因。图的意义更多的是在于信息的升维。我们将图数据库技术与自动机器学习技术进行结合，通过使用自动学习机的方法，在数据之中去找寻规律并得到最佳分析路径，实现从信息升维，到过滤总结。
• 融合：借助自然语言处理、计算机视觉、传感器分析、大数据等技术，进行知识构建；
• 注智：融合决策智能科学、管理科学、社会网络理论，通过机器学习总结数据特征规律，强化学习优化图计算精度，提升知识图谱推理效果；
• 随动：借鉴集成学习的思想，融合多方推理计算的结果，产生最终决策。
25. 从数据科学家到业务专家 – 降低使用门槛
通过使用阿里云GDB图数据库组件，可以在不写代码或者写极少代码的情况下，通过GDB自动机器学习平台，帮助业务来构建算法模型，实现有效模型调优，形成更好的辅助业务决策效果，同时极大地降低业务人员模型构建的开发周期。
26. 基于知识图谱的智能搜索推荐，激活业务增长潜力
• 易用：低代码操作，减少复杂的数据迁移工作，5分钟构您的建搜索引擎；
• 准确：多路召回、机器学习精排、持续进化，搜索模型精确度超过通用产品30%～50%；
• 低成本：构建成本低于同类产品20%。
与此同时，将阿里巴巴内部的电商推荐算法结合业务经验策略，进行集成打包，形成了基于知识图谱的智能搜索推荐方案，帮助客户在几分钟之内构建自己的搜索引擎和推荐引擎，激活业务潜力。
阿里云GDB V3引擎产品已在公有云发布，目前处于邀测期，欢迎感兴趣的同学，通过阿里云GDB官网页面申请试用。