11 月 2 号 - 11 月 3 号，以“大爱无疆，开源无界”为主题的 2019 中国开源年会（COSCon’19）正式启动，大会以开源治理、国际接轨、社区发展和开源项目为切入点同全球开源爱好者们共同交流开源。
作为图数据库技术的代表，NebulaGraph 总监——吴敏在本次大会上将会讲述了大规模分布式图数据库设计思考和实践。在信息爆发式增长和内容平台遍地开花的信息时代，图数据库在当中扮演了什么样的角色？同传统数据库相比，图数据库又有什么优势？图数据库开发需要哪些新技术？就此，开源社特访吴敏来分享下图数据库主题内容，从图数据 Nebula 的研发开始，就传统数据库面临的挑战，开源模式的优势，Nebula 的社区开展和产品规划等问题进行深入解析。
About Nebula 总监–吴敏
开源社：Hi，吴敏，先和大家介绍下自己。
大家好，我是吴敏，Vesoft Inc. 总监，博士毕业于浙江大学。 曾就职于阿里云、蚂蚁金服，从事分布式图数据库以及云存储相关工作。
开源社：谈谈您在 COSCon’19 上的分享话题。
随着抖音、小红书等社交内容平台的爆红诞生了一种基于社交关系网路的推荐需求，而以垂直领域作为切入点的知识图谱过去两年的“爆火”，传统数据库在处理社交推荐、风控、知识图谱方面的性能缺陷，图数据库的研发应运而生。
本演讲开篇将陈述图数据库行业现状，让你对图数据库存储的数据及对场景有所了解，再从开源的分布式图数据库 NebulaGraph 切入深度讲解大规模分布式图数据库应该如何设计存储、计算及架构，最后讲述开源对图数据库开发的影响。
内容大纲
- 图数据库概述及应用
- NebulaGraph 设计介绍
- 技术细节
- 开源社区及服务
开源社：哪些人可以应该了解这个内容？
对图数据库有兴趣，或是有推荐、风控、知识图谱等业务场景需求的人。
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 为例，NebulaGraph Schema 采用属性图，点边上的属性对应图谱实体和关系中的属性，边的方向表示了关系的方向，边上的标记表示了关系的类型。
再说到最近国内非常火的区块链场景，由于区块链上的所有行为都是公开被记录的又是不可篡改的，因此所有的交易行为，不管是历史数据，还是大概每几分钟产生的新 block，都可以对 DAT 文件解析后导入到图数据库和 GNN 中做分析。例如我们都听说在一些数字货币场景下，洗钱、盗窃、团伙、操纵市场的各类事情很多，通过图的手段包括可以帮助我们挖掘里面的非法行为。
开源社：作为图数据库，有参考借鉴了哪些数据库吗？哪些方面是 Nebula 有特点的设计？
Nebula 是完全自主研发的数据库，它主要有以下的技术特点
存储计算分离
对于 NebulaGraph 来讲，有这么几个技术特点：第一个就是采用了存储计算分离的架构，主要好处就是为了上云或者说弹性，方便单独扩容。业务水位总是很难预测的，一段时间存储不够了，有些时候计算不够了。在云上或者使用容器技术，计算存储分离的架构运维起来会比较方便，成本也更好控制。大家使用 HBase 那么久，这方面的感触肯定很多。
查询语言 nGQL
NebulaGraph 的第二个技术特点是它的查询语言，我们称为 nGQL，比较接近 SQL。唯一大一点的语法差异就是 不用嵌套 （embedding）。大家都知道嵌套的 SQL，读起来是非常痛苦的，要从里向外读。另外，由于图这块目前并没有统一的国际标准，这对整个行业的发展并不是好事，用户的学习成本很高。目前有个 ISO / IEC 组织在准备图语言的国际标准，我们也在积极兼容标准。
支持多种后端存储
第三个特点就是 NebulaGraph 支持多种后端存储，除了原生的引擎外，也支持 HBase。
因为很多用户，对 HBase 已经相当熟悉了，并不希望多一套存储架构。从架构上来说，NebulaGraph 是完全对等的分布式系统。
计算下推
和 HBase 的 CoProcessor 一样，NebulaGraph 支持数据计算下推。数据过滤，包括一些简单的聚合运算，能够在存储层就做掉，这样对于性能来讲能提升会非常大。
多租户
多租户，NebulaGraph是通过多 Space 来实现的。Space 是物理隔离。
索引
除了图查询外，还有很常见的一种场景是全局的属性查询。这个和 MySQL 一样，要提升性能的主要办法是为属性建立索引 ，这个也是 NebulaGraph 原生支持的功能。
图算法
最后的技术特点就是关于图算法方面。
这里的算法和全图计算不太一样，更多是一个子图的计算，比如最短路径。大家知道数据库通常有 OLTP 和 OLAP 两种差异很大的场景，当然现在有很多 HTAP 方面的努力。那对于图数据库来说也是类似，我们在设计 NebulaGraph 的时候，做了一些权衡。我们认为全图的计算，比如 Page Rank，LPA，它的技术挑战和 OLTP 的挑战和对应的设计相差很大。所以 Nebula 的查询引擎主要针对 OLTP 类的场景。
那么，对于 OLAP 类的计算需求，我们的考虑是通过支持和 Spark 的相互访问，来支持 Spark 上图计算，比如 graphX。这块工作正在开发中，应该在最近一两个月会发布。
开源社：为什么会考虑存储计算分离的架构呢？
存储计算分离是个很热的话题。我们将存储模块和 Query Engine 层分开主要有以下考虑。
- 成本的原因。存储和计算对计算机资源要求不一样，存储依赖 I/O，计算对 CPU 和内存的要求更高，业务在不同的应用或者发展时期，需要不同的存储空间和计算能力配比，存储和计算的耦合会使得机器的选型会比较复杂，存储计算分离的架构，使得 storage 的 scale out/in 更容易。
- 存储层抽象出来可以给计算带来新的选择，比如对接 Pregel, Spark GraphX 这些计算引擎。通常来说，图计算对于存储的要求是吞吐量优先的，而在线查询是时延优先的。通过把存储层分离出来，不管是开发的时候（做 QoS ）还是运维的时候（单独集群部署），都会更容易一些。
- 在云计算场景下，能实现真正的弹性计算。
开源社：作为一个分布式数据库，是如何保障数据一致性的？
我们使用 Raft 协议，Raft 一致性协议使得 share-nothing 的 kv 有一致性保障。为什么选择 Raft？相对于 Paxos，Raft 更加有利于工程化实现。Nebula 存储层 Raft 使用 Multi-Raft 的模型，多个 replica 上的同一个 partition 组成一个 Raft 组，同一个集群内存在互相独立 Raft 组，在一致性保障的同时，提高了系统的并发能力。
开源社：在数据库的优化方面，Nebula 做了哪些？
Nebula 在数据优化方面主要做了以下工作：
- 异步和并发执行：由于 IO 和网络均为长时延操作，NebulaGraph 采用异步及并发操作。此外，为避免一些大query 的长尾影响，为每个 query 设置单独的资源池以保证服务质量 QoS。
- 计算下沉：为避免存储层将过多数据回传到计算层，占用宝贵带宽，条件过滤等算子会随查询条件一同下发到存储层节点。
- 数据库系统的优化与数据的物理存储方式以及数据的分布息息相关。而且随着业务的发展，数据分布是会发生变化的，一开始设计的索引和数据存储或者分区会慢慢变得不是最优的，这就需要系统能够做一些动态的调整。我们 storage 支持 scale out/in, load balance。系统的调整会带来 overhead，这是需要权衡考虑的问题。
开源社：现在市面上已有一些图数据库，Nebula 考虑兼容部分数据库让已有的用户无缝切到 Nebula 吗？
Nebula 有 CSV、HDFS 批量 数据导入工具。用户可以将数仓的数据导入到 Nebula。也提供 C++，Java，Golang，Python 的客户端。另外对于市面上已有的一些产品，现在也正在开发将它的数据格式直接解析为 Nebula 的数据格式，这样就可以非常方便的迁移，包括查询语言层面的兼容。
开源社：水平伸缩能够支持多大的规模？
存储层 share-nothing 的架构，理论上支持无限加机器。
开源社：Nebula 最新的版本 RC1 支持最短路径和全路径算法，可以具体讲下这块的实现，及以后的研发规划吗？
目前实现较为简单，基于双向搜索，返回点边组合的路径。未来规划是计划在执行计划与优化器都完成后，完善对路径的支持，包括实现 match，支持双向 bfs、双向 dijkstra、allpair(全路径)，kshortest 等。当然我们欢迎社区的同学们都参与完善 Nebula 的路径算法。
开源社：使用 Nebula 之前，用户应该做哪些准备工作？
对于刚开始使用图数据库的用户，我们提供了详细的文档；
对于已经在使用其他图数据库，想要试试 Nebula 的用户，我们提供了数据导入等工具，有疑问或者任何问题，欢迎在 GitHub 上给我们提 issue，我们的工程师会在第一时间为您解答
Nebula 和开源
开源社：作为一个企业级产品，为什么 Nebula 一开始就选择了走开源路线？
如果没 Linux，现在互联网的格局也不会是今天这样。我们想要建立图数据库的社区，做出更好的图数据库产品，也希望更多对 Nebula，对图数据库感兴趣的同学成为社区的贡献者，一起努力，共同建立一个互助互利的社区。
开源社：在开源的过程中，有遇到什么困难吗？
很多人都想为开源做一份力，但会被开源项目的门槛“劝退”，尤其是 Nebula 是一个即使耕耘在数据库领域多年的数据库专家，如果对图数据库的不够了解的话，都会感叹“高大上”的一个项目。但技术是为业务服务的，所以 Nebula 力求自己的文档让你即使你对图数据库一无所知，通过 Nebula 的文档也能够了解到图数据库及其应用场景。
开源社：在开源社区搭建这块，有什么可以和开源社小伙伴们分享的吗？
开源项目最重要的是生态的搭建，NebulaGraph 刚开源半年在社区搭建这块只能说略有心得，仅供大家参考 
开源社区运营主要从下面几个方面展开
- 简洁明了的文档：一个好的文档能让使用者快速同产品拉近距离，Nebula 的文档从“让非技术人做技术事”的出发，力求即使你是一个不懂技术的人也可以按照文档部署 Nebula，玩起来——用 Nebula 完成简单的 CRUD，如果开源社的小伙伴阅读过 Nebula 文档觉得哪里有更改意见，欢迎联系我们；
- 实时的反馈回复：用户的反馈，我们会第一时间进行回复，在 GitHub 的 issue 及用户交流群里进行回复；
- 同用户直接对话：在线上，Nebula 在各大技术平台同图数据库和 Nebula 爱好者们进行交流，包括 Nebula 架构设计、用户使用实操等系列文章；在线下，我们也开展了主题 Meetup 同各地爱好者交流图数据库技术及 Nebula 的开发心得；
- 社区用户体系：在 Nebula 的 GitHub 上，现阶段你可以看到 3 种用户，User、Contributor、Committer，User 通过向 Nebula 提 issue / pr 或者投稿等方式成为 Contributor，Contributor 再进阶成为 Committer。配合 Nebula 开展的各类社区活动，eg：捉虫活动，帮助社区用户完成角色“升级”；
最后，打个小广告：欢迎大家来参与到 Nebula 的建设中，为开源贡献一份力
程序员寄语
开源社： 作为资深数据库从业人员，怎样让自己的眼界更加开阔，怎么获取这个领域的最前沿信息？
多看看论文，看看开源分布式系统的设计以及源代码；多关注数据库的的会议，比如，SIGMOD, VLDB，关注学术界的最新成果；多关注业界相关公司的发展和动态，比如 OsceanBase，TiDB。
Nebula 有话说
以上为开源社对图数据库 Nebula 总监——吴敏的采访，欢迎你关注 Nebula GitHub：github.com/vesoft-inc/nebula 交流图数据库技术？加入 Nebula 交流群请先填写下你的 Nebula 名片，Nebula 小助手会拉你进群~~
这是一个从原来 https://nebula-graph.com.cn/posts/coscon-2019-nebula-graph-database/ 中分离出来的主题