共计 7005 个字符，预计需要花费 18 分钟才能阅读完成。
简介：无论是学术界还是产业界，都对图数据库有比拟高的预期。Gartner 公布的《2021 年十大数据和剖析技术趋势》中提到：“到 2025 年图技术在数据和剖析翻新中的占比将从 2021 年的 10% 回升到 80%。”利用需要推动着技术的倒退，在 GDB V3 的引擎设计过程中，通过重建并改良数据存储架构、优化数据流转过程、自研计算引擎、重写执行引擎，以及资源池化、无锁化编程等一系列性能优化办法，从而逐渐迫近物理硬件的极限性能。提供超过传统图数据库百倍的查问能力，为图技术的利用，解锁了更多的可能性。
一、业务价值，为什么咱们要用图数据库？
随着互联网时代的疾速倒退，企业的数据出现爆发式的增长，数据之间的关联也越来越简单，图数据库应运而生。最重要的是如何使用技术形式帮忙业务施展辅助的决策作用，从而使用到新冠疫情、社交举荐、信用卡交易反欺诈等场景中。
技术创新与产业利用，遵循着双螺旋回升的发展趋势，促使图技术达到了爆发式增长的边缘。从技术角度登程，图数据库的使用是针对解决数据的高度关联带来的重大的随机拜访问题；从业务角度登程，图的价值在交融数据、技术、于突破生态位屏蔽产生高维认知。
在理解图数据库时，咱们不得不提到“常识图谱”这个概念。计算机在智能倒退门路上，遵循着从数据 - 信息 - 常识 - 智慧的演进过程，常识图谱是其中认知智能倒退的根底，而图数据库是承载常识图谱的最佳底座，帮忙咱们实现智能决策。
二、利用场景，图数据库可能解决什么问题？
图数据库目前曾经利用在金融、社交、互联网等畛域，这个局部我会更多分享阿里巴巴的图数据库的利用场景，心愿与各位更多探讨如何利用图帮忙客户解决问题。
社交关系
以社交关系为例，图技术在好友查问中仅须要几毫秒的工夫，它将好友定义成节点，将好友与好友之间的关系定义成边，图数据库这样以“点、边”的查问形式，速度远远快于关系型数据库。
不仅是好友查问，在“初始用户举荐、好友精密举荐、点赞查问、关联话题举荐”等场景中都能使用图来建模。
智能营销
图神经网络等图技术曾经是阿里巴巴智能营销中必不可少的组件。接下来我将分享两个在智能营销中的图技术利用。
第一个是 One-ID，它的外围思路是借助联通子图等图算法，将不同数据源的多个实体理论代表的是同一个实在实体进行合并，从而辨认到不同行为门路的 ID 隶属于同一个用户。
第二个是智能营销。它的实质是是协同过滤算法思维为外围，通过计算独特街坊数进行类似节点举荐。
欺诈检测
同时图技术还使用在金融畛域中，实现信用卡欺诈检测。
保险欺诈检测
与此同时，图技术也在保险反欺诈中施展了作用。在某头部保险公司的案例中，使用图技术的测算，使得关联查问性能是原有保险反欺诈计划的 10-100 倍（客户理论测试反馈）。
游戏拉新、促活、防散失
因为游戏业务成长周期的特殊性，经营促活效率至关重要。一旦呈现用户散失，之后用户沉闷简直不可逆。通过应用图数据库 GDB 的主动机器学习组件，能够更加精确的预测付费、7 日内留存玩家，帮忙经营人员更精确的投放点卡、道具等权利。
三、产品介绍，揭开阿里云图数据库 GDB 性能的机密
图数据库 GDB 为企业提供从“常识存储”到“推理剖析”，一站式智能决策计划
为了帮忙企业更好地解决业务问题进行智能决策，阿里云 GDB 从“常识存储”到“推理剖析”，为企业提供了一站式智能决策计划。
在常识图谱技术在解决智能决策的问题过程中，蕴含着四个重要的环节：常识构建、常识存储、推理剖析、可视化展现。
在常识存储的环节中，咱们须要将提取进去的信息进行无效存储与治理，以及应用时可能疾速筛选及查问。最为简单环节是推理剖析，如何在互相关联的信息中抽取并推理剖析出高度有价值的信息，最初要在数据分析推理后如何进行可视化展现。这其中常识存储产品化水平最高，推理剖析价值后劲最大。
图数据库 GDB 的劣势个性
GDB 引擎领有以下四个独特的劣势：
● 极致性能，相较于传统图数据库晋升近百倍。通过自研算子体系、计算引擎、执行引擎，逐渐迫近物理硬件的极限性能，提供超过传统图数据库百倍的查问性能，只为解锁更多可能性。
● 兼容并包，集多种图查询语言于一身。高度兼容 Neo4j、JanusGraph 等图数据库引擎，反对 OpenCypher、Gremlin 查询语言，升高迁徙老本和研发门槛。
● 疾速弹性、高可用、易运维，尽享云原生技术普惠。基于云原生架构的图数据库引擎，可疾速扩缩容，应答突增业务负载；反对高可用实例、节点故障主动切换，保障业务连续性；提供备份复原、主动降级、监控告警、故障切换等丰盛的运维性能，免去繁琐的运维懊恼。
● 低构建老本、灵便计费，满足不同老本需要。产品构建、运维老本，仅为国外图数据库友商的 40%；反对按量付费、包年包月多种计费模式，无论翻新摸索，亦或生产利用都能自在把握。
国内惟一进入 Forrest Wave 评测报告的图数据库产品
Forrest Wave 在 2020 年底颁布了一次评测报告，在寰球中遴选了十余款图数据库产品进行评审，其中阿里云 GDB 是国内惟一进入评测报告中的图数据库产品，同时在高可用于劫难复原评测我的项目中获得了最高的问题。
GDB V3 高性能的机密
不同于关系型数据库的设计指标，图数据库诞生是为了解决高度关联数据带来的随机拜访问题，这就注定了在这一畛域上没有太多的现成办法可供间接参考。咱们以影响查问申请性能的三大因素“硬件间性能墙”、“数据管理开销”、“硬件效力利用”登程，在 GDB V3 的引擎设计过程中，通过重建并改良数据存储架构、优化数据流转过程、自研计算引擎、重写执行引擎，以及资源池化、无锁化编程等一系列性能优化办法，从而逐渐迫近物理硬件的极限性能。提供超过传统图数据库百倍的查问能力，为图技术的利用，解锁了更多的可能性。
1. 影响用户查问申请时延的因素
硬件间性能墙：数据处理会波及到 CPU、CACHE、MEMOERY、SSD、NETWORD 等部件，各部件的解决提早差别微小；
数据管理开销：CPU 利用率中 90% 左右的工夫都在破费在优化内存和硬盘之间性能墙、数据一致性、持久性等方面；
硬件效力利用：传统的执行调用逻辑相比面向硬件个性实现逻辑可能会有比拟大的性能差别
2. 图数据库架构分类
从目前业界风行的图数据库产品来看，支流的架构次要分为两类：计算、存储拆散的分布式架构和以主 - 备架构为代表的高可用架构。
前者的典型代表包含 Tiger、Janus、Nebula 等。这种架构下零碎个别包含计算节点、存储节点和元数据管理节点。劣势是通过 Share Nothing 的形式能够实现存储规模和计算能力弹性扩大，十分实用面向海量数据万亿大图场景。毛病是计算和存储个别跨节点部署，查问时会带来较大的跨网络数据交互开销，另外可能有数据热点问题。
后者的典型代表包含阿里云 GDB、Neptune、Neo4j 等。这种架构下零碎个别只有主节点和备节点。主节点提供读、写服务，备份通过提供 stand-by 模式提供主异样时服务切换。劣势是架构轻量, 用户应用体验好，比拟适宜中小规模的用户。毛病是存在存储规模和计算能力的瓶颈，另外如果存储模型 和 计算逻辑不统一的化，会存在数据转换，开销会比拟大。对阿里云 GDB 而言，因为采纳 Cloud Native 的架构，存储和计算本质上也能够独立扩缩容，存储规模个别能够达到数百亿规模，计算既能够垂直升配，也能够程度扩容到最多 15 个只读节点。
GDB V3 引擎基于主 - 备架构做了深度优化，次要体现在两点：
- 计算、存储紧耦合，最大化执行效率
- 设计图原生存储层，省掉数据转换开销
- 关键技术
● 自研算子体系
数据库的根底包含: 数据模型以及基于数据模型之上的各类数据操纵算子。
关系数据库的逻辑模型是 E - R 模型，该模型次要包含：Entity、Releation、Property。用户将业务场景建模为逻辑模型后，再转换为关系表并存储再关系数据库中，而后利用基于关系代数衍生而出的操纵算子例如：扫描、投影、过滤等对其数据进行业务洞察。
图数据库的模型包含属性图和 RDF 图，以属性图为例其蕴含要害信息为：Vertex、Edge、Property。实质上和 E - R 模型是统一的。但不同于关系模型将逻辑模型转换为一张张物理表，属性形象为列，用表的外键来形容表之间的关系，属性图间接将逻辑模型利用邻接矩阵 (表) 等技术进行图原生存储。存储模型的简洁使的操纵算子非常灵活和丰盛。
以 Gremlin 图查询语言为例，操纵算子有 map(flatmap)、filter、sideEffect、branch 四大类共有 110 多个。思考到 Tinkerpop 通用执行框架效率低下，GDBV3 自研算子体系能够进行高效优化并大幅晋升申请执行效率。
● 自研计算引擎
定义算子执行体系后，须要通过计算引擎先将 Gremlin 申请翻译为物理算子树，GDBV3 中这由三个模块形成：
● 解析引擎：相比 Tinkerpop 原生引擎性能晋升 1000 倍，同时极大晋升用户体验，加强数据库安全能力
● 翻译引擎: Gremlin 每个算子都有对应的算子或者表达式，翻译过程中实时优化，多轮优化
● 优化引擎：相比基于策略的优化存在依赖性、低效性等问题，基于 Cascade 子树匹配模型自上向下多层匹配优化，反对谓词下推、子查问打平、算子 Schema 交融等
● 自研执行引擎
GDB V3 的执行引擎次要包含三个方面：
● 存算一体的架构：传统基于开源组件构建的非原生图数据库系统个别都是存算拆散架构，无奈防止跨网络数据交互等问题。V3 采纳存算一体解决方案，将这个执行算子树下推到图原生存储层，最大化的缩小了算子和数据之间的间隔，晋升了数据处理的效率。同时图原生存储自身就是针对图算子设计的存储构造，也会让算子的每个操作执行时延降到最低。
● 数据驱动：传统的基于 Volcano 执行引擎调度过程相似下图两头左侧，算子自上向下调用，每次每个算子只获取解决一条数据，大量 Cache Miss、数据转换、函数调用开销、内存节约等问题导致数据执行效率低下。V3 采纳数据驱动的策略，每个算子会对一批数据进行集中处理，并生成新的一批数据。父子算子间通过 Producer-Consumer 模型共享同一批后果汇合，极大缩小数据跨算子传输。
● 动静执行技术：图原生存储基于 Tree 构造准确保留了各个属性的相干统计信息，零碎并不需要额定的统计模块进行代价估算。动态优化后间接将整个物理算子树下推到图原生存储层，利用算子进行执行时实时优化。
4. 面向性能设计
● 资源池化：为解决零碎运行时频繁 new(delete)开销，自研内存管理系统并构建数组、树等根底数据结构，同时将零碎中要害数据结构资源池化
● 无锁化编程：基于快照的 MVCC 技术防止读申请进行锁期待；通过多级缓存池解决高并发下线程资源分配竞争；应用线程局部变量，解决数据可见性与多线程资源争抢的矛盾；基于 CAS 原子操作解决高并发下多线程资源同步、日志记录等并发抵触
● 应用 < 指针, 援用计数 > 思路解决简单数据结构跨算子数据传输中编解码性能问题
● 自研 Binary 数据编解码算法解决简单后果集 Encoding(Decoding)开销
5. 性能测试数据
以 Twitter 数据集作为测试数据，
● 2 跳查问中，相比 Neo4j 性能晋升 95 倍；
● 3 跳查问中，相比 Neo4j 性能晋升 87 倍；
● 6 跳查问中，GDB V3 单线程耗费 266s，其余测试产品均已超时，均匀几十纳秒扫描一条数据；
GDB V3 原生内存图存储引擎
1. 原生图和非原生图
从存储形式来讲，目前市面上的图数据库，能够分为原生图和非原生图两大类。
非原生图应用现有的关系型数据库或者 NoSQL 数据库存储图数据，在查问时把图查问语句映射到底层零碎的查询语言或者算子上。典型的例子是应用 HBase/Cassandra 作为存储后端的 JanusGraph 和 HugeGraph。还有一些以插件模式内嵌到传统关系数据库里，实现图查问性能的零碎，也能够归为这一类，比方 Apache Age，Oracle PGX 等。非原生图的劣势是能够充分利用现有零碎中比拟成熟的基础设施，缩小开发工作量。然而毛病也很显著：首先，非原生图数据库架构在其余零碎之上，软件栈往往更加简单，调用档次更深，可能还须要进行跨过程通信，带来额定的开销；其次，因为底层存储引擎并不是专门针对图数据的设计的，并不能很好的反对图查问的 I / O 拜访模式。总而言之，非原生图数据库通常很难施展硬件的最佳性能。
原生图数据库针对这些问题进行了从新设计，从数据结构和数据布局上进行了优化，数据拜访的效率大大晋升。除此之外，原生图数据库还能够从存储引擎的层面为图计算提供定制化的算子反对，从而将计算工作下推到存储层，缩小不必要数据交互，进一步晋升性能。也正是因为这些劣势，GDB 始终保持采纳原生图存储。其余应用原生图存储的产品还包含 neo4j、Nebula Graph、TigerGraph 等。
2. GDB V3 内存图存储引擎
图查问是 I / O 比拟密集的操作，计算高度依赖数据，因而数据的拜访效率对于查问性能十分重要。不仅如此，对于多跳图遍历这一类常见的查问模式，还存在数据局部性差的问题。在图遍历中，每向外一跳，须要拜访的数据量都会成倍增加，并且这些数据通常是随机散布的，拜访效率低并且对缓存不敌对。所以图数据库的查问性能通常会随着跳数的减少急剧下降。
GDB V3 针对这些问题，设计了新的原生内存图存储引擎，以内存为存储介质来承载图数据，解决随机 I / O 性能差的问题，同时从数据结构、遍历算法、动静更新和垃圾回收等几个方面进行了优化。
3. 优化的外围数据结构
GDB V3 的外围数据结构是改良的压缩邻接矩阵。咱们从如下三个方面进行了改良：
● 以行位单位进行存储和更新。邻接矩阵中的一行，就是一个顶点关联的所有边。在理论数据中，大部分点的度数都比拟小。比方 twitter 数据集，80% 以上的顶点，出度和入度在 30 以内。把他们作为一个单元在内存中间断存储，能够保障高效的读取，也比拟容易更新，更加适宜动态图的存储。
● 以树状构造存储超级顶点。对于度数很大的超级顶点，用间断内存空间存储的办法并不实用。因而咱们把它进一步拆分成树结构，以解决超级顶点的更新问题。
● 对雷同类型（标签）的边进行聚合。在理论业务场景中，一次图查问往往只会选取特定类型的边进行遍历，把雷同类型的边寄存在一起，能够无效的进步这种拜访模式下的性能体现。
4. 用矩阵计算的思维解决图遍历问题
基于 GDB V3 所应用的邻接矩阵构造，咱们在实现图查问的过程中，应用矩阵计算的思维。图的多跳遍历问题，能够转换成邻接矩阵的乘法问题：将邻接矩阵跟本身屡次相乘，能够失去顶点之间的多跳邻接关系。GDB V3 在图查问的实现中，借鉴了矩阵乘法中的优化办法，以达到更高的性能。
5. 动态图的实时更新
GDB V3 的内存存储引擎反对细粒度的快照，并以此为根底实现了乐观的 MVCC 事
务。更新操作不会间接批改现有数据，而是创立一个新版本的快照。
读事务都基于某一个版本的快照来进行，保障了数据的一致性和事务之间的互相隔离，彻底杜绝 dirty-read、non-repeatable 等异常现象的呈现。读事务也不会被写事务阻塞，能够做到无锁并发，达到很高的读性能。
写事务在执行阶段先把更新数据记录到本身的事务缓存里，仅对本人可见，事务之间互不烦扰，在事务提交阶段，才会解决并发抵触。在低抵触率的状况下，这种形式能够充分利用处理器多个外围的并行能力。
6. 高效垃圾回收
在 GDB 的 MVCC 机制下，随着数据的不断更新，会产生多个版本的快照，而不再须要的快照须要及时回收以开释空间。如前文所述，大部分数据都是在多个快照之间共享的，所以在删除快照时，须要晓得每个数据单元的生命周期[start, end)，其中 start 是以后版本的创立工夫，end 则是它从逻辑上被删除的工夫。在删除快照 Si 时，如果一个数据单元同时满足 start > i – 1（①）且 end <= i + 1（②）（即该单元在前一个版本和后一个版本均不可见），它就能够被平安删除。
在大数据量的状况下，全量扫描一一去查看快照中的所有数据单元是很耗时的。因而，GDB 为每个快照引入了一个生效列表来减速这个过程。快照 Si 的生效列表，记录的是在 Si 中从可见变为不可见的所有数据单元，也即生命周期 end = i 的数据单元。通过生效列表，能够疾速拿到满足上述条件②的数据，只须要再查看是否满足条件①，就能够疾速找出能够删除的数据。
为了晋升内存调配和开释的效率，GDB 在外部保护了轻量级资源池，垃圾回收中收集到的内存不会马上开释，而是放入资源池期待复用，以缩小跟操作系统和内存管理器之间的交互，晋升效率。
Graph + AI，从数据升维到法则总结
图数据库要解决的问题是将大规模，多元异构的数据无效连接起来之后产生高维决策。
不同于关系型数据库，图数据库背地目前没有领导进行决策的思维与规定，也是导致图数据库技术至今没有被大规模利用的外围起因。图的意义在于信息升维，因而咱们将图技术与主动机器学习联合，应用机器学习算法，探寻数据法则并找到最佳剖析门路，实现数据升维到法则总结。
从数据科学家到业务专家 – 升高应用门槛
通过 GDB 主动学习机器的工作，能够实现在不写任何代码的状况下，去帮忙开发选取业务模型、实现模型调优，从而造成相应的超级模型。以此帮忙客户进行辅助判断，升高模型研发周期。
原文链接
本文为阿里云原创内容，未经容许不得转载。
