Closed cynbarby closed 4 years ago
11 月 2 号 - 11 月 3 号,以“大爱无疆,开源无界”为主题的 2019 中国开源年会(COSCon'19)正式启动,大会以开源治理、国际接轨、社区发展和开源项目为切入点同全球开源爱好者们共同交流开源。
作为图数据库技术的代表,Nebula Graph 总监——吴敏在本次大会上将会讲述了大规模分布式图数据库设计思考和实践。在信息爆发式增长和内容平台遍地开花的信息时代,图数据库在当中扮演了什么样的角色?同传统数据库相比,图数据库又有什么优势?图数据库开发需要哪些新技术?就此,开源社特访吴敏来分享下图数据库主题内容,从图数据 Nebula 的研发开始,就传统数据库面临的挑战,开源模式的优势,Nebula 的社区开展和产品规划等问题进行深入解析。
VEsoft 总监,博士毕业于浙江大学。 曾就职于阿里云、蚂蚁金服,从事分布式图数据库以及云存储相关工作。
随着抖音、小红书等社交内容平台的爆红诞生了一种基于社交关系网路的推荐需求,而以垂直领域作为切入点的知识图谱过去两年的“爆火”,传统数据库在处理社交推荐、风控、知识图谱方面的性能缺陷,图数据库的研发应运而生。
本演讲开篇将陈述图数据库行业现状,让你对图数据库存储的数据及对场景有所了解,再从开源的分布式图数据库 Nebula Graph 切入深度讲解大规模分布式图数据库应该如何设计存储、计算及架构,最后讲述开源对图数据库开发的影响。
内容大纲
对图数据库有兴趣,或是有推荐、风控、知识图谱等业务场景需求的人。
Nebula 是星云的意思,很大嘛,也是漫威宇宙里面漂亮的星云小姐姐。对了,Nebula的发音是:[ˈnɛbjələ]
OceanBase、TiDB 这类 NewSQL 最近发展势头很强劲,他们的出现更多的是对传统单机的关系型数据库在可用性的补充。 Nebula 聚焦在图数据库这一领域,也是近年来在数据库各分支中增长最为快速的领域。图数据库使用图(或者网)的方式很直接、自然的表达现实世界的关系: 用节点来表示实体,边来表示关联关系,everything is connected。能高效的提供图检索,提供专业的分析算法、工具,比如 ShortestPath、PageRank、标签传播等等。
典型的应用场景有社交网络,金融风控,推荐引擎,知识图谱等。
社交网络,比如,推荐一条最短路径让我结识迪纳热巴,还可以加上筛选条件,路径中的每个人都是单身女性。
金融风控场景,比如,去查一个信用卡反套现的网络。很典型的一个场景,A 转账到 B,B 转账到 C,C 又转回给 A 即是一个典型的闭环。对于这样的闭环,这类查询在图数据库大规模应用之前,大部分都是采用离线计算的方式去查找,但是离线场景很难去控制当前发生的这笔交易。一个信用卡交易或者在线贷款,整个作业流程很长,而在反套现这块的审核时间又限制在毫秒级,这就是图数据库非常大的一个应用场景。
在推荐算法中,为某个人推荐他的好友。现在的方案是去找好友的好友,判断好友的好友有没有可能成为某人的新好友,这当中涉及好友关系的亲密度,抵达好友的好友的最短路径等。业务方可能会用 MySQL 等传统数据库或是 HBase 来存各类好友关系,然后通过多个串行的 Key-Value 来做查询,但这在线上场景是很难满足性能要求的。
知识图谱这些年非常火,知识图谱结合自然语言的形式在金融,医疗,互联网等众多领域被广泛使用,常见的有语音助手、聊天机器人、智能问答等应用场景。而图数据库存储的数据结构完全适配知识图谱数据,图谱中的实体对应图数据库的点,实体与实体的关系对应图数据库的边,拿 Nebula 为例,Nebula Graph Schema 采用属性图,点边上的属性对应图谱实体和关系中的属性,边的方向表示了关系的方向,边上的标记表示了关系的类型。
存储计算分离 对于 Nebula Graph 来讲,有这么几个技术特点:第一个就是采用了存储计算分离的架构,主要好处就是为了上云或者说弹性,方便单独扩容。业务水位总是很难预测的,一段时间存储不够了,有些时候计算不够了。在云上或者使用容器技术,计算存储分离的架构运维起来会比较方便,成本也更好控制。大家使用 HBase 那么久,这方面的感触肯定很多。
查询语言 nGQL Nebula Graph 的第二个技术特点是它的查询语言,我们称为 nGQL,比较接近 SQL。唯一大一点的语法差异就是 不用嵌套 (embedding)。大家都知道嵌套的 SQL,读起来是非常痛苦的,要从里向外读。
支持多种后端存储 第三个特点就是 Nebula Graph 支持多种后端存储,除了原生的引擎外,也支持 HBase。 因为很多用户,对 HBase 已经相当熟悉了,并不希望多一套存储架构。从架构上来说,Nebula Graph 是完全对等的分布式系统。
计算下推 和 HBase 的 CoProcessor 一样,Nebula Graph 支持数据计算下推。数据过滤,包括一些简单的聚合运算,能够在存储层就做掉,这样对于性能来讲能提升会非常大。
多租户 多租户,Nebula Graph是通过多 Space 来实现的。Space 是物理隔离。
索引 除了图查询外,还有很常见的一种场景是全局的属性查询。这个和 MySQL 一样,要提升性能的主要办法是为属性建立索引 ,这个也是 Nebula Graph 原生支持的功能。
图算法 最后的技术特点就是关于图算法方面。 这里的算法和全图计算不太一样,更多是一个子图的计算,比如最短路径。大家知道数据库通常有 OLTP 和 OLAP 两种差异很大的场景,当然现在有很多 HTAP 方面的努力。那对于图数据库来说也是类似,我们在设计 Nebula Graph 的时候,做了一些权衡。我们认为全图的计算,比如 Page Rank,LPA,它的技术挑战和 OLTP 的挑战和对应的设计相差很大。我们希望 Nebula Graph 能够在 OLTP 这块提供最好的表现。
存储计算分离是个很热的话题。我们将存储模块和 Query Engine 层分开主要有以下考虑。
我们使用 Raft 协议,Raft 一致性协议使得 share-nothing 的 kv 有一致性保障。为什么选择 Raft?相对于 Paxoes,Raft 更加有利于工程化实现。Nebula 存储层 Raft 使用 Multi-Raft 的模型,多个 replica 上的同一个 partition 组成一个 Raft 组,同一个集群内存在互相独立 Raft 组,在一致性保障的同时,提高了系统的并发能力。
我们有 CSV、HDFS 数据导入工具。用户可以将数仓中的数据、CSV 文件的数据导入到 Nebula。我们也提供 C++,Java,Golang,Python 的客户端供用户写入数据。由于图这块目前并没有统一的国际标准,这对行业的发展并不是好事,用户的学习成本很高。目前有个 ISO / IEC 组织在准备图语言的国际标准,我们也在积极兼容标准。
存储层 share-nothing 的架构,理论上支持无限加机器。
目前实现较为简单,基于双向搜索,返回点边组合的路径。未来规划是计划在执行计划与优化器都完成后,完善对路径的支持,包括实现 match,支持双向 bfs、双向 dijkstra、allpair(全路径),kshortest 等。当然我们欢迎社区的同学们都参与完善 Nebula 的路径算法。
对于刚开始使用图数据库的用户,我们提供了详细的文档;
对于已经在使用其他图数据库,想要试试 Nebula 的用户,我们提供了数据导入等工具,有疑问或者任何问题,欢迎在 GitHub 上给我们提 issue,我们的工程师会在第一时间为您解答。
如果没 Linux,现在互联网的格局也不会是今天这样。我们想要建立图数据库的社区,做出更好的图数据库产品,也希望更多对 Nebula,对图数据库感兴趣的同学成为社区的贡献者,一起努力,共同建立一个互助互利的社区。
很多人都想为开源做一份力,但会被开源项目的门槛“劝退”,尤其是 Nebula 是一个即使耕耘在数据库领域多年的数据库专家,如果对图数据库的不够了解的话,都会感叹“高大上”的一个项目。但技术是为业务服务的,所以 Nebula 力求自己的文档让你即使你对图数据库一无所知,通过 Nebula 的文档也能够了解到图数据库及其应用场景。
开源项目最重要的是生态的搭建,Nebula Graph 刚开源半年在社区搭建这块只能说略有心得,仅供大家参考 :) 开源社区运营主要从下面几个方面展开
最后,打个小广告:欢迎大家来参与到 Nebula 的建设中,为开源贡献一份力 :)
多看看论文,看看开源分布式系统的设计以及源代码;多关注数据库的的会议,比如,SIGMOD, VLDB,关注学术界的最新成果;多关注业界相关公司的发展和动态,比如 OsceanBase,TiDB。
https://shimo.im/docs/jGhcT9TWcY9VkT68
11 月 2 号 - 11 月 3 号,以“大爱无疆,开源无界”为主题的 2019 中国开源年会(COSCon'19)正式启动,大会以开源治理、国际接轨、社区发展和开源项目为切入点同全球开源爱好者们共同交流开源。
作为图数据库技术的代表,Nebula Graph 总监——吴敏在本次大会上将会讲述了大规模分布式图数据库设计思考和实践。在信息爆发式增长和内容平台遍地开花的信息时代,图数据库在当中扮演了什么样的角色?同传统数据库相比,图数据库又有什么优势?图数据库开发需要哪些新技术?就此,开源社特访吴敏来分享下图数据库主题内容,从图数据 Nebula 的研发开始,就传统数据库面临的挑战,开源模式的优势,Nebula 的社区开展和产品规划等问题进行深入解析。
About Nebula 总监--吴敏
开源社:Hi,吴敏,先和大家介绍下自己。
VEsoft 总监,博士毕业于浙江大学。 曾就职于阿里云、蚂蚁金服,从事分布式图数据库以及云存储相关工作。
开源社:谈谈您在 COSCon'19 上的分享话题。
随着抖音、小红书等社交内容平台的爆红诞生了一种基于社交关系网路的推荐需求,而以垂直领域作为切入点的知识图谱过去两年的“爆火”,传统数据库在处理社交推荐、风控、知识图谱方面的性能缺陷,图数据库的研发应运而生。
本演讲开篇将陈述图数据库行业现状,让你对图数据库存储的数据及对场景有所了解,再从开源的分布式图数据库 Nebula Graph 切入深度讲解大规模分布式图数据库应该如何设计存储、计算及架构,最后讲述开源对图数据库开发的影响。
内容大纲
开源社:哪些人可以应该了解这个内容?
对图数据库有兴趣,或是有推荐、风控、知识图谱等业务场景需求的人。
Nebula 研发之旅
开源社:为什么给图数据库取名 Nebula ?
Nebula 是星云的意思,很大嘛,也是漫威宇宙里面漂亮的星云小姐姐。对了,Nebula的发音是:[ˈnɛbjələ]
开源社:现在数据库领域百花齐放,国产的 OceanBase 和 TiDB 都发展得不错,为什么还要研发 Nebula 这样的图数据库?
OceanBase、TiDB 这类 NewSQL 最近发展势头很强劲,他们的出现更多的是对传统单机的关系型数据库在可用性的补充。 Nebula 聚焦在图数据库这一领域,也是近年来在数据库各分支中增长最为快速的领域。图数据库使用图(或者网)的方式很直接、自然的表达现实世界的关系: 用节点来表示实体,边来表示关联关系,everything is connected。能高效的提供图检索,提供专业的分析算法、工具,比如 ShortestPath、PageRank、标签传播等等。
开源社:图数据库应用场景有哪些?
典型的应用场景有社交网络,金融风控,推荐引擎,知识图谱等。
社交网络,比如,推荐一条最短路径让我结识迪纳热巴,还可以加上筛选条件,路径中的每个人都是单身女性。
金融风控场景,比如,去查一个信用卡反套现的网络。很典型的一个场景,A 转账到 B,B 转账到 C,C 又转回给 A 即是一个典型的闭环。对于这样的闭环,这类查询在图数据库大规模应用之前,大部分都是采用离线计算的方式去查找,但是离线场景很难去控制当前发生的这笔交易。一个信用卡交易或者在线贷款,整个作业流程很长,而在反套现这块的审核时间又限制在毫秒级,这就是图数据库非常大的一个应用场景。
在推荐算法中,为某个人推荐他的好友。现在的方案是去找好友的好友,判断好友的好友有没有可能成为某人的新好友,这当中涉及好友关系的亲密度,抵达好友的好友的最短路径等。业务方可能会用 MySQL 等传统数据库或是 HBase 来存各类好友关系,然后通过多个串行的 Key-Value 来做查询,但这在线上场景是很难满足性能要求的。
知识图谱这些年非常火,知识图谱结合自然语言的形式在金融,医疗,互联网等众多领域被广泛使用,常见的有语音助手、聊天机器人、智能问答等应用场景。而图数据库存储的数据结构完全适配知识图谱数据,图谱中的实体对应图数据库的点,实体与实体的关系对应图数据库的边,拿 Nebula 为例,Nebula Graph Schema 采用属性图,点边上的属性对应图谱实体和关系中的属性,边的方向表示了关系的方向,边上的标记表示了关系的类型。
开源社:作为图数据库,有参考借鉴了哪些数据库吗?哪些方面是 Nebula 有特点的设计?
存储计算分离 对于 Nebula Graph 来讲,有这么几个技术特点:第一个就是采用了存储计算分离的架构,主要好处就是为了上云或者说弹性,方便单独扩容。业务水位总是很难预测的,一段时间存储不够了,有些时候计算不够了。在云上或者使用容器技术,计算存储分离的架构运维起来会比较方便,成本也更好控制。大家使用 HBase 那么久,这方面的感触肯定很多。
查询语言 nGQL Nebula Graph 的第二个技术特点是它的查询语言,我们称为 nGQL,比较接近 SQL。唯一大一点的语法差异就是 不用嵌套 (embedding)。大家都知道嵌套的 SQL,读起来是非常痛苦的,要从里向外读。
支持多种后端存储 第三个特点就是 Nebula Graph 支持多种后端存储,除了原生的引擎外,也支持 HBase。 因为很多用户,对 HBase 已经相当熟悉了,并不希望多一套存储架构。从架构上来说,Nebula Graph 是完全对等的分布式系统。
计算下推 和 HBase 的 CoProcessor 一样,Nebula Graph 支持数据计算下推。数据过滤,包括一些简单的聚合运算,能够在存储层就做掉,这样对于性能来讲能提升会非常大。
多租户 多租户,Nebula Graph是通过多 Space 来实现的。Space 是物理隔离。
索引 除了图查询外,还有很常见的一种场景是全局的属性查询。这个和 MySQL 一样,要提升性能的主要办法是为属性建立索引 ,这个也是 Nebula Graph 原生支持的功能。
图算法 最后的技术特点就是关于图算法方面。 这里的算法和全图计算不太一样,更多是一个子图的计算,比如最短路径。大家知道数据库通常有 OLTP 和 OLAP 两种差异很大的场景,当然现在有很多 HTAP 方面的努力。那对于图数据库来说也是类似,我们在设计 Nebula Graph 的时候,做了一些权衡。我们认为全图的计算,比如 Page Rank,LPA,它的技术挑战和 OLTP 的挑战和对应的设计相差很大。我们希望 Nebula Graph 能够在 OLTP 这块提供最好的表现。
开源社:为什么会考虑存储计算分离的架构呢?
存储计算分离是个很热的话题。我们将存储模块和 Query Engine 层分开主要有以下考虑。
开源社:作为一个分布式数据库,是如何保障数据一致性的?
我们使用 Raft 协议,Raft 一致性协议使得 share-nothing 的 kv 有一致性保障。为什么选择 Raft?相对于 Paxoes,Raft 更加有利于工程化实现。Nebula 存储层 Raft 使用 Multi-Raft 的模型,多个 replica 上的同一个 partition 组成一个 Raft 组,同一个集群内存在互相独立 Raft 组,在一致性保障的同时,提高了系统的并发能力。
开源社:在数据库的优化方面,Nebula 做了哪些?
开源社:现在市面上已有一些图数据库,Nebula 考虑兼容部分数据库让已有的用户无缝切到 Nebula 吗?
我们有 CSV、HDFS 数据导入工具。用户可以将数仓中的数据、CSV 文件的数据导入到 Nebula。我们也提供 C++,Java,Golang,Python 的客户端供用户写入数据。由于图这块目前并没有统一的国际标准,这对行业的发展并不是好事,用户的学习成本很高。目前有个 ISO / IEC 组织在准备图语言的国际标准,我们也在积极兼容标准。
开源社:水平伸缩能够支持多大的规模?
存储层 share-nothing 的架构,理论上支持无限加机器。
开源社:Nebula 最新的版本 RC1 支持最短路径和全路径算法,可以具体讲下这块的实现,及以后的研发规划吗?
目前实现较为简单,基于双向搜索,返回点边组合的路径。未来规划是计划在执行计划与优化器都完成后,完善对路径的支持,包括实现 match,支持双向 bfs、双向 dijkstra、allpair(全路径),kshortest 等。当然我们欢迎社区的同学们都参与完善 Nebula 的路径算法。
开源社:使用 Nebula 之前,用户应该做哪些准备工作?
对于刚开始使用图数据库的用户,我们提供了详细的文档;
对于已经在使用其他图数据库,想要试试 Nebula 的用户,我们提供了数据导入等工具,有疑问或者任何问题,欢迎在 GitHub 上给我们提 issue,我们的工程师会在第一时间为您解答。
Nebula 和开源
开源社:作为一个企业级产品,为什么 Nebula 一开始就选择了走开源路线?
如果没 Linux,现在互联网的格局也不会是今天这样。我们想要建立图数据库的社区,做出更好的图数据库产品,也希望更多对 Nebula,对图数据库感兴趣的同学成为社区的贡献者,一起努力,共同建立一个互助互利的社区。
开源社:在开源的过程中,有遇到什么困难吗?
很多人都想为开源做一份力,但会被开源项目的门槛“劝退”,尤其是 Nebula 是一个即使耕耘在数据库领域多年的数据库专家,如果对图数据库的不够了解的话,都会感叹“高大上”的一个项目。但技术是为业务服务的,所以 Nebula 力求自己的文档让你即使你对图数据库一无所知,通过 Nebula 的文档也能够了解到图数据库及其应用场景。
开源社:在开源社区搭建这块,有什么可以和开源社小伙伴们分享的吗?
开源项目最重要的是生态的搭建,Nebula Graph 刚开源半年在社区搭建这块只能说略有心得,仅供大家参考 :) 开源社区运营主要从下面几个方面展开
最后,打个小广告:欢迎大家来参与到 Nebula 的建设中,为开源贡献一份力 :)
程序员寄语
开源社: 作为资深数据库从业人员,怎样让自己的眼界更加开阔,怎么获取这个领域的最前沿信息?
多看看论文,看看开源分布式系统的设计以及源代码;多关注数据库的的会议,比如,SIGMOD, VLDB,关注学术界的最新成果;多关注业界相关公司的发展和动态,比如 OsceanBase,TiDB。