按关键词阅读：
?
本文插图
转载本文需注明出处：微信公众号EAWorld ， 违者必究 。
前言：
随着社交、电商、金融、物联网等行业的快速发展 ， 现实组成了一张庞大的关系网 ， 传统数据库很难处理关系运算 ， 大数据行业需要处理的数据之间的关系随着数据量呈几何指数增长 ， 亟需一种支持海量复杂数据关系运算的数据库 ， 图数据库应运而生 。 本文将探讨图数据库在数据资产可视化中的应用 。
目录：
1.图数据库介绍
2.关系型数据库和图数据库的区别
3.探索图数据库在数据资产可视化中的应用
1.图数据库介绍
本文插图
这张图是一个社交网络场景 ， 每个用户可以发短信、发邮件 ， 分享信息 。 这些都是最基本的增删改查 ， 也是大多数研发人员对数据库做的常见操作 。 而在研发人员的日常工作中除了要把用户的基本信息录入数据库外 ， 还需找到与该用户相关联的信息 ， 方便去对单个的用户进行下一步的分析 ， 比如说：我们发现张三的账户里有很多关于推理小说和音乐方面的内容 ， 那么我们可以据此推测出他可能是一名学生 ， 从而推送他可能感兴趣的内容 。
但是在数据分析过程中 ， 会出现各种各样的场景 ， 比如说在一个典型的社交网络中 ， 常常会存在“谁认识谁 ， 谁上过什么学校 ， 谁常住什么地方 ， 谁喜欢什么餐馆”等查询 ， 这种查询在数据分析过程中是很常见的 ， 但是这种操作会因为数据库的选择不同而对性能产生巨大的差异 。
传统数据库解决思路
本文插图
传统解决上述问题最简单的方法就是建立一个关系模型 ， 我们可以把每个员工的信息录入表中 ， 存在诸如 MySQL 之类的关系数据库 ， 图片展示的是最基本的关系模型图 。
基于上述的关系模型 ， 依据需求 ， 就不可避免的涉及到很多库表的join操作 ， 实现的查询语句可能也会很长 ， 并且这种代码可读性很差 ， 而且会有严重的性能问题 。 关于传统关系数据库的性能问题我们后续分析 。
图数据库解决思路
本文插图
在传统数据库虽然运用 JOIN 操作把不同的表链接了起来 ， 从而隐式地表达了数据之间的关系 ， 但是当我们要通过 A 管理 B ， B 管理 A 的方式查询结果时 ， 表结构并不能直接告诉我们结果 。 如果我们想在做查询前就知道对应的查询结果 ， 我们必须先定义节点和关系 。 使用图结构建模 ， 节点和关系先定义是图数据库和别的数据库的核心区别 。
打个比方 ， 我们可以把经理、员工表示成不同的节点 ， 并用一条边来代表他们之前存在的管理关系 ， 或者把用户和商品看作节点 ， 用购买关系建模等等 。 而当我们需要新的节点和关系时 ， 只需进行几次更新就好 ， 而不用去改变表的结构或者去迁移数据 。 根据节点和关联关系 ， 传统数据库建模可以转换为图片所示建模：
在通过图数据库原生图查询语言（Cypher）进行建模和查询后 ， 近百行的sql代码变成3,4行的代码可以明显的看出图数据库在数据表达上的优势：
MATCH (boss)-[:MANAGES*0..3]->(sub), (sub)-[:MANAGES*1..3]->(userid) WHERE boss.name = “zhangsan” RETURN sub.name AS list, count(userid) AS Total什么是图
【|探索图数据库在数据资产可视化中的应用】图的定义：A database that uses graph structures for semantic queries with nodes, edges and properties to represent and store data – independent of the way the data is stored internally. It’s really the model and the implemented algorithms that matter. 分页标题
图数据库是基于图模型的数据库 。 相比较于关系型数据库 ， 图数据库是真正注重“关系”的数据库 。 图数据库的主要职能是管理图数据 ， 因此需要支持高效的对顶点/边的查询与更新；为了方便用户的使用 ， 通常还需要增加对事务（transaction）的支持 ， 从而保证并发操作下的正常运作 。
图广泛存在于现实世界中 ， 从社交网络到金融关系 ， 都会涉及大量的高度关联数据 。 这些数据构成了庞大的图 ， 图数据库就是呈现和查询这些关联的方式 。 这种联系形成了一种互相关联的数据 ， 联系才是数据的本质所在 。 传统的关系型数据库并不能很好地表现数据的联系 ， 而一些NoSQL（Not Only SQL ， 非关系型数据库）数据库又不能表现数据之间的联系 。 同样属于NoSQL范畴的图数据库是以图的结构形式来存储数据的 ， 它所存储的就是联系的数据 ， 是关联数据本身 。
然而关联数据中的联系本来就很复杂 ， 若要在关系型数据库中使用结构化形式来表现这种联系 ， 则一般不能直接表示 ， 处理起来既繁琐又费事 ， 并且随着数据的不断增长 ， 其访问性能将日趋下降 。 无数的开发人员和数据库管理人员都或多或少地使用过关系型数据库 ， 在其应用的规模化进展过程中 ， 对于数据库的性能优化往往捉襟见肘、陷入窘境 。 图数据库没有模式结构的定义 ， 也不需要这些定义 ， 它使用非结构化的方式来存储关联数据 ， 所以能够直接表现数据的关联特性 。
图数据库的发展趋势
本文插图
在众多不同的数据模型里 ， 关系数据模型自20世纪80年代就处于统治地位 ， 而且出现了不少巨头 ， 如Oracle、MySQL ， 它们也被称为：关系数据库管理系统（RDBMS） 。 然而 ， 随着关系数据库使用范围的不断扩大 ， 也暴露出一些它始终无法解决问题 ， 其中最主要的是数据建模中的一些缺陷和问题 ， 以及在大数据量和多服务器之上进行水平伸缩的限制 。 同时 ， 互联网发展也产生了一些新的趋势变化：用户、系统和传感器产生的数据量呈指数增长 ， 数据量不断增加 ， 大数据的存储和处理；新时代互联网形势下的问题急迫性 ， 这一问题因互联网+、社交网络 ， 智能推荐等的大规模兴起和繁荣而变得越加紧迫 。 而在应对这些趋势时 ， 关系数据库产生了更多的不适应性 ， 从而导致大量解决这些问题中某些特定方面的不同技术出现 ， 它们可以与现有RDBMS相互配合或代替它们 。 过去的几年间 ， 出现了大量新型数据库 ， 它们被统称为NoSQL数据库 。 其中图数据库从最近十年的表现来看已经成为关注度最高 ， 也是发展趋势最明显的数据库类型 。
NoSQL数据库分为四种类型 ， 分别是：
- 键值(key/value)数据库
- 列存储数据库
- 文档型数据库
- 图数据库
图数据库是分析数据间关联的最佳技术
图数据库对于可以在不同场景下发挥作用 ， 从企业应用角度 ， 业务用户使用角度 ， 数据开发者应用角度都发挥着作用 。
分页标题本文插图
图数据库对于可以在不同场景下发挥作用 ， 从企业应用角度 ， 业务用户使用角度 ， 数据开发者应用角度都发挥着作用 。
图数据库产品
本文插图
依据db-engines.com网站对Graph DBMS的排名来看 ， 目前主流的图数据库有：Neo4j ， Janusgraph ， Dgraph ， ArangoDB ， OrientDB ， TigerGraph等 。 下面我们来介绍一下目前图数据库的分类都有哪些 。
图数据库分类
- 原生数据库：
- 直接在关系型数据库之上构建的图数据库：
- 使用外置nosql存储的数据库：
- 在图计算上基于batch进行优化的新一代图数据库：
Neo4j
Neo4j图数据库 ， 它是一个高性能的NOSQL图形数据库 ， 它将结构化数据存储在网络上而不是表中 。 它是一个嵌入式的、基于磁盘的、具备完全的事务特性的Java持久化引擎 ， 但是它将结构化数据存储在网络(从数学角度叫做图)上而不是表中 。
优势：
可集群 ， 使用读/写负载平衡器将请求直接到一个集群
支持事物、锁、页面缓存
遍历下：建立索引通常成本O(log(n)) ， 但Neo4J的遍历一个关系的复杂度趋向于O(1)
支持ACID事务 ， 它确保实时显示数据的合法性和准确性 。
Cypher语法友好
劣势：
Neo4j没法存储巨大的一张关系图， 因为他不支持分片
因为index-free adjacency ， 遍历快但是计算随机两个节点最短路径性能不佳
索引：
index-free adjacency ， 擅长遍历图 ， 以及计算不存在大量关系的节点的图
ArangoDB
ArangoDB图数据库 ， 它是一个原生多模型数据库 ， 兼有key/value键/值对、graph图和document文档数据模型 ， 提供了涵盖三种数据模型的统一的数据库查询语言 ， 并允许在单个查询中混合使用三种模型 。 基于其本地集成多模型特性 ， 您可以搭建高性能程序 ， 并且这三种数据模型均支持水平扩展 。
优势：
存储空间占用下：采用了元数据模式存储数据；可通过内存提速 ， CPU占用率低
支持主从集群
Multi-collection transactions
扩展性好：JavaScript
用JavaScript和ArangoDB构建应用 ， Foxx微服务运行在DB内部 ， 可快速访问数据 。
AQL功能很强大 ， 配置编程远方便于、灵活于Neo4J、OrientDB
Neo4J的Cypher也比较强大 ， 清晰 ， 但是不利于调整 ， 灵活性不够
OrientDB ， 类SQL ， 查询繁琐 ， 调整不便利 ， 内置SQL函数接口也不方便
劣势：
插入性能稍低
索引：
自动索引_key属性 ， _from和_to属性；保证V和E的查找速度
OrientDB
OrientDB是指兼具文档数据库的灵活性和图形数据库管理链接能力的可深层次扩展的文档-图形数据库管理系统 。
优势：
安装简单 ， 功能丰富
OrientDB是兼具文档数据库的灵活性和图形数据库管理链接能力的可深层次扩展的文档-图形数据库管理系统(NoSQL数据库) 分页标题
可选无模式、全模式或混合模式下 。 支持许多高级特性 ， 诸如ACID事务、快速索引 ， 原生和SQL查询功能
可以JSON格式导入、导出文档
若不执行昂贵的JOIN操作的话 ， 如同关系数据库可在几毫秒内可检索数以百计的链接文档图
劣势：
坑很多
性能和可扩展性不好
索引：
侧重文档数据库 ， 主要还是SB树索引导致 ， 空间浪费比较大；插入节点与另外两个数据库（neo4j和ArangoDB）相差无几 ， 但是在插入关系中另外两个数据库都做了优化 ， OrientDB无优化 ， 就挂了；在图论计算力上性能优异 ， 但是在遍历中还是优化不够 ， 被甩开 。
JanusGraph
开源 JanusGraph是一个可扩展的图数据库 ， 可以把包含数千亿个顶点和边的图存储在多机集群上 。 它支持事务 ， 支持数千用户实时、并发访问存储在其中的图 。
优势：
分布式部署 ， 因此 ， 支持集群
可以存储大图 ， 比如包含数千亿Vertices和edges的图
支持数千用户实时、并发访问 。
集群节点可以线性扩展 ， 以支持更大的图和更多的并发访问用户 。
数据分布式存储 ， 并且每一份数据都有多个副本 ， 因此 ， 有更好的计算性能和容错性 。
支持在多个数据中心做高可用 ， 支持热备份 。
通过集成大数据平台 ， 比如Apache Spark、Apache Giraph、Apache Hadoop等 ， 支持全局图数据分析、报表、ETL
集成ElasticSearch、Apache Solr、Apache Lucene等系统后 ， 可以支持全文搜索
在计算层上可使用Spark做计算 ， 这点优于Neo4j和OrientDB
即可OLAP也可OLTP ， 可以执行批处理和实时处理
开源 ， 基于Apache 2 Licence
支持各种后端存储系统 ， 目前标准支持以下四种 ， 当然也可以增加第三方的存储系统：
- Apache Cassandra?
- Apache HBase?
- Google Cloud Bigtable
- Oracle BerkeleyDB
新图形数据库
可视化工具缺乏（可继承第三方工具Cytoscape、Gephi等）
2.关系型数据库和图数据库的区别
与传统关系型数据库相比 ， 图数据库的优势
优秀的查询性能
相对于关系型数据库 ， 图数据库产品在设计上避免大量的join操作 ， 提供快速的查询 。 图数据库则天然把关联数据连接在一起 ， 无需耗时耗内存的Join操作 ， 可以保持常数级时间复杂度 。
灵活的数据建模和查询语言 ， Schema-less
多数图数据库没有预设的schema ， 借助底层的存储机制 ， 能够更加灵活的变更结构
灵活的图查询语言 ， 轻松实现复杂关系网络的分析
灵活的数据模型可以适应不断变化的业务需求
易于理解 ， 更加敏捷
相对于关系型数据库的二维表格 ， 图的组织形式更接近于现实世界 ， 易于理解
可以很自然的表达现实世界中的实体及其关联关系（对应图的顶点及边）
关系型数据库在遍历关系网络并抽取信息的能力非常弱 ， 图数据库则为此而生
基于图算法提供强大分析能力
PageRank/社区发现算法等
图数据库的功能是传统关系型数据库的一个拓展 ， 相比较关系型数据库仅支持表结构 ， 图数据支持的图结构更为灵活 。 图数据库在基于图的数据增加、删除、查询、修改等方面做了不同于其他数据库的设计 。 在图数据的操作抽象上 ， 采用基于顶点的视角 ， 比如顶点通过其所有处、边访问其邻接顶点 ， 这一类的操作也是图数据库系统设计的核心 。
图数据库与关系型数据库优劣比对
优势
a) 用户可以面向对象的思考 ， 用户使用的每个查询都有显式语义；
b) 用户可以实时更新和查询图数据库；
c) 图数据库可以灵活应对海量的关系变化 ， 如增加删除关系、实体等； 分页标题
d) 图数据库有利于实时的大数据挖掘结果可视化 。
劣势
a) 不适合记录大量基于事件的数据（例如日志条目）；
b) 二进制数据存储 。
c) 并发性能要求高的项目 。
d) 目前相关图查询语言比较多 ， 尚未有很好统一 。
e) 图数据库相关的一些书籍文档偏少 ， 相关生态还在不断完善 。
图数据库在处理关联关系上具有完全的优势 ， 但是在一些场景下 ， 图数据库并不能完全代替关系型数据库 。
图数据库在处理关联数据时三个技术优势
本文插图
1、性能方面：
随着数据量的增多和关联深度的增加 ， 传统关系型数据库受制于检索时需要多个表之间连接操作 ， 数据写入时也需考虑外键约束 ， 从而导致较大的额外开销 ， 产生严重的性能问题 。 而图模型固有的数据索引结构 ， 使得它的数据查询与分析速度更快 。 在关联关系的处理上 ， 用关系型数据库处理不可避免要用到表的JOIN操作 ， 对性能的影响较大；而图数据库则是类指针直接跳转访问 ， 更高效的操作关联数据 ， 比关系型数据库有2到4个数量级的性能提升 。
2、灵活度方面：
图数据库有非常灵活的数据模型 ， 使用者可以根据业务变化随时调整数据模型 ， 比如任意添加或删除顶点、边 ， 扩充或者缩小图模型这些都可以轻松实现 ， 这种频繁的 Schema 更改在关系型数据库上不能到很好的支持 。 现实中 ， 项目的进程往往是不断演进的 。 数据的内容甚至数据格式也会不断发生变化 。 在关系型数据库中 ， 这意味着表结构的变化 ， 或者多个新表的建立 ， 对源数据的改动非常大 。 而在图数据库里 ， 仅需添加新的顶点、边、属性 ， 设置为对应的类型即可 。 从本质上说 ， 一个表代表一个类型的数据 ， 一个顶点代表一个特定的数据 ， 意味着关系数据库更关注数据的类型 ， 而图数据库更关注数据的个体 ， 识别其关联关系 。
3、敏捷度方面：
图数据库的图模型非常直观 ， 支持测试驱动开发模式 ， 每次构建时可进行功能测试和性能测试 ， 符合当今最流行的敏捷开发需求 ， 对于提高生产和交付效率也有一定帮助 。 使用图（或者网）的方式来表达现实世界的关系更加直接、自然 ， 在万物互联的物联网时代尤为突出 。 如果采用关系型数据 ， 先将人物建表 ， 再将关系建表 ， 最后将数据进行映射 ， 需要高度的抽象思维 。 在图数据上进行分析查询时 ， 也可以直观地通过点边连接的拓扑 ， 交互式找到想要的数据 ， 不需要具备任何的专业知识 。
传统关系数据库的性能问题
本文插图
性能问题的本质在于数据分析面临的数据量 ， 假如只查询几十个节点或者更少的内容 ， 这种操作是完全不需要考虑数据库性能优化的 ， 但当节点数据从几百个变成几百万个甚至几千万个后 ， 数据库性能就成为了整个产品设计的过程中最需考虑的因素之一 。
在数据量这么大的场景中 ， 使用传统 SQL 会产生很大的性能问题 ， 原因主要有两个：
1、大量 JOIN 操作带来的开销：
之前的查询语句使用了大量的 JOIN 操作来找到需要的结果 。 而大量的 JOIN 操作在数据量很大时会有巨大的性能损失 ， 因为数据本身是被存放在指定的地方 ， 查询本身只需要用到部分数据 ， 但是 JOIN 操作本身会遍历整个数据库 ， 这样就会导致查询效率低到让人无法接受 。
2、反向查询带来的开销：
查询单个经理的下属不需要多少开销 ， 但是如果我们要去反向查询一个员工的老板 ， 使用表结构 ， 开销就会变得非常大 。 表结构设计得不合理 ， 会对后续的分析、推荐系统产生性能上的影响 。 比如 ， 当关系从_老板 -> 员工 变成 _用户 -> 产品 ， 如果不支持反向查询 ， 推荐系统的实时性就会大打折扣 ， 进而带来经济损失 。分页标题
图数据库和关系型数据库性能比较
本文插图
如图所见 ， 传统关系型数据库可以非常好地处理深度为2和3的查询 。 join操作在关系型数据库世界中很常见 ， 大多数数据库都是如此设计 ， 在某些特定列上使用索引相关也能帮助最大化join操作的性能 。 然而 ， 当深度达到4和5时 ， 您会看到性能显著下降：一个涉及4个join的查询需要10秒以上才能完成 ， 而在深度为5时更花了太长时间 ， 超过一分半钟 ， 虽然计数结果没有改变 。 这恰恰说明了在对图结构数据建模时关系型数据库的局限性：深度图遍历需要多个join操作 ， 关系数据库通常并不擅长这种处理 。
但是图数据库 ， 可以看见 ， 除了最简单的查询 ， 图数据库在其他查询的性能表现上都是明显更好的那一个 。 只有在寻找朋友的朋友时（深度为2） ， 关系型数据库性能可与图数据库遍历的性能相媲美 。 在深度为3时的遍历比关系型数据库快4倍 。 在深度为4 ， 结果则要好五个数量级 。 深度为5时 ， 图数据库结果的速度甚至要比关系型数据库要快1000万倍 。 关系型数据库查询性能下降如此之快正是由于 ， join操作需要对全部数据进行笛卡尔积运算 ， 其中大部分的数据我们并不需要 。
3.探索图数据库在数据资产可视化中的应用
当前这种任务扩展方式仅仅只是给开发人员提供了便利 ， 但是用户仍然很难扩展自己的任务 ， 因此后续会考虑将任务扩展的能力做成平台功能的一部分提供给用户使用 。
本文插图
我们以Apache Atlas为例 ， 探索图数据库在数据资产可视化方面的应用 。
Apache Atlas是Hadoop的数据治理和元数据框架 。 是一组可扩展和可扩展的核心基础治理服务 ， 使企业能够有效 ， 高效地满足Hadoop中的合规性要求 ， 并允许与整个企业数据生态系统集成 。
Apache Atlas为组织提供了开放的元数据管理和治理功能 ， 以建立其数据资产的目录 ， 对这些资产进行分类和治理 ， 并为数据科学家 ， 分析师和数据治理团队提供围绕这些数据资产的协作功能 。
此图为Atlas的架构图 ， 主要包含的组件如图所示 ， 我们主要关注于在Core组件中使用JanusGraph图数据库来存储元数据对象 。 Atlas采用了分布式图数据库JanusGraph作为数据存储 ， 目的在于用有向图灵活的存储、查询数据血缘关系 。 默认情况下元数据存储配置为 HBase， 索引存储配置为 Solr 。 也可以通过构建相应的配置文件使用BerkeleyDB存储元数据存储 和使用ElasticSearch存储 Index 。 元数据存储用于存储元数据对象本身 ， 索引存储用于存储元数据属性的索引 ， 其允许高效搜索 。
Atlas定义了一套atlas-graphdb-api ， 允许采用不同的图数据库引擎来实现api ， 便于切换底层存储 。 所以Atlas读写数据的过程可以看作就是将图数据库对象映射成Java类的过程 ， 基本流程如下：
本文插图
在Atlas中查询某一个元数据对象时往往需要遍历图数据库中的多个顶点与边 ， 相比关系型数据库直接查询一行数据要复杂的多 ， 当然使用图数据库作为底层存储也存在它的优势 ， 比如可以支持复杂的数据类型和更好的支持血缘数据的读写 。
JanusGraph与应用的集成 ， 有如下两种方式：
- 第一种：可以把JanusGraph嵌入到应用程序中去 ， JanusGraph和应用程序处在同一个JVM中 。 应用程序中的客户代码（相对JanusGraph来说是客户）直接调用Gremlin去查询JanusGraph中存储的图 ， 这种情况下外部存储系统可以是本地的 ， 也可以处在远程 。 分页标题
- 第二种：应用程序和Janus Graph处在两个不同JVM中 ， 应用通过给JanusGraph提交Gremlin查询给GremlinServer ， 来使用JanusGraph ， 因为JanusGraph原生是支持Gremlin Server的 。 （Gremlin Server是Apache Tinkerpop中的一个组件） 。
本文插图
基于以JanusGraph图数据库为例 ， 结合Atlas获取hadoop生态系统的元数据思路 ， 未来数据资产可视化扩展对大数据的采集能力 ， 以kafka作为消息系统 ， 解耦生产者和消费者 ， 图数据库作为数据处理核心 ， 以Hbase、solr ， es ， zookeper等技术作为辅助手段 。 为数据存储 ， 关系建立 ， 数据血缘建立 ， 数据快速查询提供便利 。
写在最后
基于对图数据库知识的探索 ， 图数据库在未来数据资产可视化中的应用将会是促进数据价值提升 ， 提高企业数据资产配置效率的有效手段 ， 企业可以通过图数据库建立企业数据资产全景图 ， 快速搜索定位 ， 形成有效的数据交汇 ， 以个性化展现企业的数据资产 ， 方便使用者获取关键信息 ， 更好的了解数据资产的各个方面 。
以上是我分享的内容以及一些不成熟的思考 ， 希望跟大家一起探讨 。
本文插图
关于作者：隔壁老王 ， 普元产品经理 ， 曾参与多个数据治理项目的设计与研发工作 ， 并负责项目的咨询与实施工作 。 开源技术爱好者 ， 专注于企业数据服务 ， 数据治理的落地与实践 。
关于EAWorld：微服务 ， DevOps ， 数据治理 ， 移动架构原创技术分享 。
来源：(精彩趣投稿)
【】网址：/a/2020/0709/1594282739.html
标题：|探索图数据库在数据资产可视化中的应用
