汉中站,怎么做原创短视频网站,正规的装饰行业网站建设公司,中文域名到期对网站的影响简介#xff1a;无论是学术界还是产业界#xff0c;都对图数据库有比较高的预期。Gartner发布的《2021年十大数据和分析技术趋势》中提到#xff1a;“到2025年图技术在数据和分析创新中的占比将从2021年的10%上升到80%。”应用需求推动着技术的发展#xff0c;在GDB V3的引…简介无论是学术界还是产业界都对图数据库有比较高的预期。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引擎基于主-备架构做了深度优化主要体现在两点
计算、存储紧耦合最大化执行效率设计图原生存储层省掉数据转换开销
3. 关键技术 ● 自研算子体系 数据库的基础包括: 数据模型以及基于数据模型之上的各类数据操纵算子。 关系数据库的逻辑模型是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 AgeOracle 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自动学习机器的任务可以实现在不写任何代码的情况下去帮助开发选取业务模型、实现模型调优从而形成相应的超级模型。以此帮助客户进行辅助判断降低模型研发周期。 原文链接
本文为阿里云原创内容未经允许不得转载。
