你们好，我是吴敏。今天分享一个叫图数据库的技术产品。数据库
什么是图和图数据库
先来介绍一下什么是图和图数据库，所谓的图和日常认知的图片其实不是同一个概念，图（Graph）在计算机科学里面是一种数据结构，这种数据结构有三个比较主要的概念：点、边和属性。安全
通俗的说，图结构还有其余的叫法，好比：网络结构、拓扑结构，大体上都是描述的同一种数据结构。服务器
举个例子，上面这个图是典型的图结构（网络结构），人和公司，公司与公司都存在关联关系。这里面存在几个重要的概念，在网络结构中一家公司、一我的能够是一个点；还有另一个概念是边，描述的是点与点之间的关系，对应上图中母公司和子公司之间的一个控股关系，也能够是某一我的是另一个公司的董事长，这样的一个身份关系。点和边基本上组成一个网络结构。微信
图结构在工业界使用的时候还会加上一个概念就是**属性。**好比，中间的这我的（点）能够有他的身份证、性别、年龄属性，关系就是边上也能够有一些属性，好比说投资某家公司的投资金额、投资的比例、投资的时间等等，均可以构成这个投资关系的属性。网络
像基于上图这样的工商关系，微众银行、腾讯和咱们（Nebula Graph）也都是有各自合做的项目。数据结构
图数据库的案例 1：反欺诈
下面来介绍下图的应用。运维
通常来讲，图在安全场景里面的应用会比较多，上面这种图的中间部分是和 360金融合做的一个项目，主要用于识别诈骗团伙。函数
具体来讲，如今是互联网时代，不少 APP 支持申请贷款，不论是持牌或者持其余牌照的平台，均可以提供必定的贷款能力。与此同时，也存在团伙“做案”，固然抢银行的少，诈骗、骗贷的团伙多，而这些团伙是有特征的，能够经过必定的方式进行关联。微服务
在左边的这个例子里，有些的黑产团伙，他们控制的帐号会登陆一些设备（手机），这些设备和 Wi-Fi 有关联关系。经过这样的 帐号-设备-WiFi 关联关系能够识别出来这些团伙。这些团伙被识别出来后，若是团伙相关的人来贷款或者说是来申请授信时，在风控环节会先识别出来。工具
在中间这个例子里，红色的点是已知存在风险的帐号，最中间的那个区域就是一个风险的团伙，这些节点就是被识别出来的风险节点，它们基于 Wi-Fi 关系将其余点关联到了一块儿。
360 金融经过用图的方法大概识别了接近 100 万个有风险的团伙，因此这些团伙哪怕换一个马甲或者其余设备也能第一时间把他们识别出来，进行屏蔽。右边案例图是一些受害人，蓝色的点是诈骗团伙，诈骗团伙仍是有挺明显的特征存在的。
图数据库的案例 2：公司信用分
上面的例子主要是识别有风险的人，在这个例子里主要讲下 BOSS 直聘的公司风控。在上图中显示了 BOSS 直聘的一些公司，有些公司是很早入驻 BOSS 直聘平台，有些是新注册的。当中存在部分公司不必定可信，须要对这些公司做区分给必定信用分。好比说，公司信用等级好的对它的运营策略会放松点，信用等级差的公司对它的运营审核严格些。由于有不停的新的公司在注册，能够经过不一样的运营方式获得这些公司的不一样信息，上图这里用的是同这些公司有关联关系的关系公司。举个例子，我新注册一家公司的时候，这家公司仍是会和其它公司有一些互动和关联，例如：该公司的分公司，或是公司同失信被执行人之间有关联关系，经过一轮轮的迭代算出风险评级和信用评级，为新出来的公司提供一个启动初始信用分，这个方法相似于网页权重中使用的 Page Rank。天天晚上 BOSS 直聘会跑几百万社区的权重。
图数据库的案例 3：可信设备
这个例子比较直观。如今每一个人基本上都有手机，而后会有经常使用的手机设备，也可能你会临时换一个设备。这个经常使用设备下，鉴权的要求比较低。而用临时设备鉴权的要求较高，风控等级较高。还有一种状况就是家人临时使用彼此的设备，这种状况下的鉴权要求能够不须要那么高。由于只要换一个新设备就判断为高风险场景的话，其实对于用户的侵入和打扰很明显。
图数据库的案例 4：智能助理
这个是和美团合做的项目，自己实际上是有两方面，一方面是和知识图谱相关，一方面是和深度学习相关。目前来讲大多数公司的推荐系统都有基于深度学习的模型。那么会存在一个问题：这个推荐出来的内容可解释性差。简单来讲，用户不知道为何产生这样的列表。所以，美团结合图谱作了一些应用，把全部的菜、地点、人、人与人之间的关系还有这些东西组成大的网，当深度学习模型算出推荐列表以后，取用户和商家之间全部可能的关系，取出一条路径或者多条路径的，在多条路径之间作一些加权或者说计算一些路径规则分，呈现给用户看上去更可理解的理由。好比，这里挺有意思的理由，叫“在北京喜欢北京菜的山东老乡都说这家店很赞”，看到这个理由的时候，你会以为这个推荐略微合理。固然相似的方法也能够用于像问答机器人这样的 KBQA 的系统。
图数据库的案例 5：外部做弊与刷单
这是一个刷单的例子，其实不少公司会有运营经费，特别是对新用户会有运营经费，可是这会招来一些羊毛党。这些专业的羊毛党技术很好，他们来薅羊毛的速度比通常的消费者速度快不少，通常前期的大多数的运营经费不是给新用户用掉而是给羊毛党薅走了，羊毛党通常就是那些人，把他们识别出来以后，就能够下降运营经费被薅走的几率。
图数据库的案例 6：数据治理系统
这个例子是关于 IT 系统的。我相信如今大多数的公司都是有一个庞大的数仓，几万张甚至几百万张的表，表与表之间又有比较强的依赖关系。例如：一张表或者某几张表取当中几个字段，经过一个 job 清洗，生成下一张表。某一天 DBA 或者某个业务人员发现有一个数据不太对，想知道哪一个环节出错了，一层一层往上查，上百层的依赖，用图的方式关联就能够很快的查到哪一个地方更有可能出错。这也是咱们和微众银行合做的，他们如今正在使用的东西。
图数据库的案例 7 / 8：服务依赖分析 / 代码依赖分析
左边是和运维相关的，右边是和研发相关的事。由于如今基本都是微服务化了，整个微服务之间的调用关系实际上是很庞大的。特别是一个大型集团内的RPC 调用关系，运维本身都不必定搞得清楚全局是什么依赖状况。
这个是美团的例子，把全部的调用关系写到图谱里，大概是百万级别的调用关系。好比说运维想知道过去 7 天可用率低于 4 个 9 的链路有哪些，能够很是快速地识别出来，深度能够是 10 层也能够 100 层。
右边是一个辅助开发过程的小工具，对研发人员来讲挺方便的。对于一个大型的代码仓库，函数之间相互调用。好比说研发今天想改用一个接口，可是我不知道有多少人在调用这个接口，是怎么调用的。对于测试来讲，也不知道要测试哪些边界场景。那能够把这些关系都放到图谱里面去，这样大约是一个千万级别的调用关系，把整个调用关系全抽出来以后，那研发说我想看一眼这个接口被多少人调用了，调用方是怎么使用的；QA 要作测试的时候，可能有哪些边界场景受到影响也能够很快地知道。
为何使用图数据库
刚才说的其实就是一些图的应用，固然其实这些应用不用图这种数据结构来处理，也是能够的。好比在数仓用 Spark 或者写 SQL 来作也能够。可是为何更推荐用图数据库呢？有如下几个缘由。
一图胜千言
一个是图的表达能力更强。左边是用表的结构方式来处理人物关系和社区关系。右边当中人的是比较重要的节点，他在左边的表中对应的某一行，右边是用图的方式来看。经过不一样的着色能够很容易地看出来不一样的社区，而后不一样的社区之间经过某些特殊的节点来关联。这样远比用表的方式直观得多，特别是在右边图里面查找中心节点比起在左边的表中查找属性值大小要方便的多。
繁琐 vs 简洁
第二个是对于图的遍历这种操做来讲——至关于表操做中 join。若是用 SQL 来写，大约是左边这么长，也不是算很是复杂；可是用图的查询语言（右侧）来写的话，其实例子核心就是一句话，沿着一个点开始沿着这样一个路径取 Person 数据。因此对于图遍历操做，图专用的查询语言要更简洁。
更快！
使用图还有一个优点是更快，行业内的经典例子就是查询的数据深度越多的时候，图数据库的优点越加明显。对于 四、 5 层深度的查询，小时级别的时延和秒级别的时延，是两种不一样的业务形态。
最后一个缘由是关于流行趋势。在国际上，用于统计各类数据库类型流行状况的 DB-Engines 上，能够看到图数据库的趋势。上图这是这个月最新的数据，绿色是图这种数据库类型流行的趋势，最下面红色的线是关系型数据库的流行趋势。能够看到，图数据库在过去 8 年内保持了比较好的增速，增加了 11 倍。
为何选择 Nebula Graph
固然，在整个图数据库领域，产品并非只有 Nebula Graph 一个，也有不少的其余公司。今天早上也有其余同行在会场上，我想解释一下为何会推荐 Nebula Graph。
通常你们选型基于不一样的需求看的重点不同，我想可能会对可靠性、成本性能、功能各个方面进行权衡。
Nebula Graph 是一个开源的产品，源代码是开放在 GitHub 上的。虽然产品的研发时间不长，从 2018 年 10 月开始第一行代码，可是整个项目很活跃。
上图左下角是 Nebula Graph 中文论坛的状况，在国内有大量的使用者。而 Nebula Graph 自己是开源的项目，整个项目除了咱们公司人员以外也有不少国内外贡献者，不少人在使用 Nebula 以后会发现一些 bug 这样就会 file 个 issue，也有很多人会本身动手 fix 和贡献 feature，这样提高了整个研发迭代速度。
右边是全部 Nebula 的 GitHub 贡献者列表，这些是公开状况，你能够在 GitHub 上面看到。总的来讲，贡献者来源不少，并非背后只有一家公司在研发。
上图是在生产环境使用 Nebula Graph 的公司。
既然是 Nebula Graph 是开源代码的，那么全部人能够下载和评测。全部的用户均可以根据本身的业务场景作的评测，会更贴近本身的实际场景。而不像某些供应商本身提供的评测，用户难验证这样的评测里面隐藏了多少坑。
这张图第一个例子是去年和微信合做的项目，他们如今的生产环境单个集群是 50 台机器的规模，它的更新数据量大概是 4,000 亿这样的级别。第二个是美团的例子，美团所作的 Nebula 和其它竞争对手产品的评测。由于美团也是有一个很是高的可用需求，基本上都是要两地多机房。第三个是 BOSS 直聘的评测，从友商产品迁移到 Nebula 以后，从最初只能作 50 亿量级的边的产品，提高到作千亿点边的项目。下面这是贝壳作的评测，公开在今年的DTCC，也是和友商产品的的对比。右边是 360 金融作的评测，生产环境服务器数量减小到原先集群的 1/3，性能是原来的 20 倍以上。
虽然软件自己是开源的，可是开源软件是能够商业化的。这个在国内外也是一个比较广泛的事情。Nebula 的源代码是开放的，因此不论是社区版也好，企业版也好，在产品功能内核、可视化、生态方面基本上没有太大的差异。主要的差异是在服务上，社区版若是有问题能够经过开源社区的方式来解决，按照开源协议（Apache 2.0）的约定。而若是是企业版的话，那会提供企业版的严格的 SLA。另外，云这几年流行和增速也很是的快，云目前是在受邀公测的阶段。你们有什么兴趣能够联系咱们。
谢谢你们！