共计 4876 个字符，预计需要花费 13 分钟才能阅读完成。
本文整顿自 Akulaku 反欺诈团队在 nMeetup·深圳场的演讲，B 站视频见：https://www.bilibili.com/video/BV1nQ4y1B7Qd
这次次要来介绍下 Nebula 在 Akulaku 智能风控的实际。分为以下 6 个局部内容：
- 图的基本概念与利用场景概述
- 图数据库选型
- 图数据库平台建设
- Nebula 利用案例
- 图模型的训练与部署
- 总结与瞻望
先来解说下图的基本概念，图是由节点和边形成的形容关联关系的汇合。图最大的劣势就是比拟形象，比方上图便是一个脱敏之后的欺诈团伙的图构造，能够看到某个用户和其余节点的关联关系是否存在异样。如果咱们应用的是单纯的行式数据库（关系型数据库）是看不出来异样的，然而从图的角度就能够很容易地发现数据的异样。
再来解说下图的利用场景，在 Akulaku 的场景中次要是图谱关系开掘和可视化剖析，以及图查问代替简单查问。这里解释下图查问代替简单查问，你的利用背景可能和图无关，然而波及的后端操作具备肯定的深度，用图的关系进行查问建模，就比拟容易了解查问语句和保护操作。
再者是图数据库选型这块，先来讲一下 Akulaku 在图数据库选型上踩过的坑。刚开始咱们应用 Neo4j，次要做一些关联性特色，Neo4j 查问效率较高然而可扩展性是短板，分布式的 Neo4j 性能和单机版效率相差不大。咱们也尝试过其余图数据库，这里要说下咱们的业务需要：
- 良好的可扩展性
- 疾速的数据导入
- 良好的查问效率
开展来讲，Neo4j 不具备良好的可扩展性，所以 pass。因为咱们的图规模十分大，次要是面向金融风控场景，图的规模能达到十亿节点、百亿级别边，所以须要疾速的数据导入来做初始化。这里要说下咱们尝试用过 Dgraph，之前咱们浏览过它的相干学术论文，论文写得十分的好然而工程实现欠佳。尤其是批量导入这块，当你导入的数据超过一定量级之后会产生相似内存透露的问题，所以 Dgraph pass。
最初一点是良好的查问效率，这里要讲下 JanusGraph，它的长处是后端能够集成其余存储引擎，这也是过后测试 JanusGraph 的次要起因。然而当咱们导入和初始化数据之后，发现它的查问效率十分的蹩脚。
这里看下 Akulaku 团队对 Nebula Graph 做的可扩展性和查问性能测试：
- 图规模 ：10 亿点，100 亿边
- 测试形式 ：nebula-bench https://github.com/vesoft-inc/nebula-bench
查问语句 ：
- 两个一度查问
- 两个二度查问
- 一个三度查问
- 随机源 ：注册手机号随机抽样 500 W 个 phone
压测时从随机源 phone 随机查问其中 1 个数据。横轴为并发，纵轴为 QPS，不同色彩的曲线代表并发节点的个数，这里能够看到整个 Nebula Graph 的查问性能是比拟好的。
图上能够看到，可扩展性大略在 12 台机器的时达到较高的性能，后续再增加节点个数，分布式的开销就要开始大于并发带来的效益。所以你会看到这个节点个数进步，查问性能会有所降落。这里说下咱们做的查问，随机抽取 500 万个节点，进行多批查问，每一批查问中蕴含两个一度查问，两个二度查问和一个三度查问。测试过程中，咱们还遇到热点问题，上图是最初验证的后果。
压测时，应用的 Nebula 版本是 v1.x，起初 Nebula v2.x 公布之后，Akulaku 团队开始尝试降级。但刚降级尝试 2.0.1 时，发现一些问题：
Leader change
- 导入数据的时候频繁呈现 leader change，导致写入失败
- 查问数据的时候没有发现
- 察看到 CPU 负载较高，次要是超大子图导致
第一个问题次要产生在导入数据的时候，会频繁呈现 leader change，这个问题会影响到线上调用效率。还有个察看到的景象是，CPU 负载高，这是由局部超大节点导致的负载过高。所以就先回滚到了 v1.2 版本。在 v2.5.0 公布之后，Akulaku 团队又从新做了一个测试，和之前的压测形式差不多。
- 图规模 ：10 亿点，100 亿边
- 机器配置 ：7 台，256G，32 核
- 测试形式 ：nebula-bench https://github.com/vesoft-inc/nebula-bench
查问语句 ：
- 两个一度查问
- 两个二度查问
- 一个三度查问
- 随机源 ：注册手机号随机抽样 500 W 个 phone
在这个版本中，之前遇到的 leader change 和 CPU 负载过高的问题解决了。所以 Akulaku 团队尝试将 v2.5.0 利用到业务中。
上图右侧是并发数，左侧是 QPS。
上面来讲下图剖析平台，次要围绕两块引擎：图数据库平台 Nebula Graph 和实时图计算引擎。因为 Akulaku 这边次要对接的利用场景为反欺诈，对实效性要求高，所以须要一系列的实时图算法。为了开发图算法，图剖析平台须要一个实时图计算引擎。这些引擎依赖于离线调度，比方：landsat 任务调度平台、离线数仓、实时数仓的监控和工作监控等等模块。这块内容底层又依赖于大数据集群，比方常见的 Spark、Hive、Hadoop、Flink、HBase 等等。
所以这张图从上到下就是利用 - 平台 - 基础设施。
如果咱们独自看一个图数据库平台：
图数据库平台搭建这块，Akulaku 团队次要做了两件事件：一个是数据导入和高可用，数据导入的话它是基于离线数仓，它既有批量写入，也有基于实时数据源的实时写入。实时的数据源这块，图数据库存储有两种模式：
一种是双集群的主备，即线上服务由两个主从集群提供，实时数据源会对主从集群做双写；
另外一种是单集群的计划，即每个利用能够有独自实例。
这样构建图数据库存储，撑持平台须要监控（服务和数据）、敏感数据沙箱、集群扩缩容、调度零碎等等这些撑持模块。
从业务角度，整个平台的建设是为了基于图关系进行摸索和可视化展现，上图只是个示意图并非业务中理论应用的图。
上文说到利用场景，当初来具体讲下 Nebula 在 Akulaku 的具体利用案例。
首先，次要利用在可视化欺诈案例剖析与深度关联开掘。第二，设施 ID 关联计算。最初也是最常见的一个利用，用于各种图模型的部署，包含标签流传等等。上面具体来解说下。
上图是图可视化的欺诈案例的剖析，上图仍旧是个示意图并非实在数据图。反欺诈的考察人员通过图关系，应用图数据库的可视化的工具，对关联关系进行开展剖析，包含图谱的下段等等操作，去查看的节点属性。
第二个案例，是设施 ID 关联计算，这属于方才图概念局部说到的，它可能自身跟图没什么关系，只是用图来示意比拟天然，而且也更加容易保护。具体开展来说，设施的 ID 须要通过一系列的因素来计算，然而欺诈分子会通过不停变更这些因素来试图绕过反欺诈策略。但其实变更因素时，它只能变更某一因素，其余因素和该因素还是放弃着肯定的关联。通过肯定规定，用关联关系就能把它理论的映射关系找到。这个查问深度并不深，就是个一度的查问，其次要的难度并不在于逻辑，而是数据的一致性。举个例子，并发地操作计算设施的 ID 的话，那就会有数据一致性的问题。比方，删了一条不该删的边，加了一个不该加的数据，所以这个过程就须要对数据加锁。
具体加锁的办法，就是加锁某批波及计算设施 ID 信息的节点，等计算实现后再开释节点，而后其余过程才可能对这个数据进行批改。
第三大类利用是图模型训练与部署，比方像部署子图开展类的图模型。这里来解释下图模型，就是这个模型的后果是抽取的子图通过计算失去，这里的子图个别由核心节点开展失去。具体的子图开展的图模型有哪些？比方，以以后节点为核心的子图特色，基于以后子图的标签流传的后果，或者是图卷积的模型。上面说下这里的难点在哪？
第一，回测上逻辑简单。回测，次要指的是数据回溯，依据场景要求需获取事件产生时的图关系，进行特色抽取和模型构建，逻辑绝对简单。此外，在图模型的部署上时效性要求也很高。如果这个模型是反欺诈场景的话，个别要将模型部署在授信或者是下单环节，时效性要求较高。依据图模型训练与部署利用场景的不同特点，会有下列 4 个思考的角度：
- 业务环节的时效性要求。比如说，授信环节相对来说它的时效性要求会比下单环节要低一些；
- 子图规模。看部署模型波及到的子图规模是多大，如果很大的话，允不容许取样？如果取样不容许的话，咱们用什么办法解决？
- 图更新频率和模型调用量相比，谁比拟多？
- 回测复杂度，它的数据量是大还是比拟小？
上面举几个例子。
第一个例子，授信环节的子图特色。
具体来说，授信环节时，须要取得一个 uid 所属的子图的特色计算，比如说，N 度子图节点的占比或者是拓扑特色。这个业务环节的时效性要求绝对低一些，这是第一个特点。第二个特点，子图规模可能大，可能会遇到爆炸节点的状况，但又不容许取样。第三个特点，子图更新数据量是远远大于模型的调用量。这代表什么呢？就是单位工夫授信申请的授信额度申请量，是远小于图更新的频率。第四个特点，回测比拟小。
针对下面的 4 个特点，采取什么计划呢？因为它更新的数据量远远大于模型的调用量，所以最好是在模型调用的时候间接去计算它的特色，而分数回测是能够基于图数据库的，就是说间接依照历史模型调用的事件来做分数的回测。因为模型计算是在业务环节调用时去做查问，所以须要确保这个图数据库集群的可用性。
第二个例子是下单环节的标签流传。
具体来说，标签流传是从节点上的一个标签，比方黑灰标签或者特定的业务属性标签，依据肯定的规定做流传。那么，标签流传场景有什么特点？
第一点，业务环节的时效性要求会比拟高，因为它是下单环节，不能有很大的提早，否则就会卡单。第二点，子图规模和下面一样，存在爆炸子图的可能。比如说，三度子图可能是几百万的数量级，而且这个子图不能采样。为什么不能采样呢？因为标签流传波及业务规定，采样可能会影响分数的稳定性，所以一般来说不容许采样。第三点，更新的数据量是远小于模型的调用量，即图更新的频率小，然而调用的次数多。那，什么时候做子图计算呢？在数据更新的时候进行计算，这样须要计算的数据量比拟小。而下单环节的标签流传回测的数据量会比拟大，单纯从数量来说，下单的数量会远大于授信申请的数量。
针对上述特点，更新数据量小于模型调用量（在业务环节调用分数的数量）的话，在图更新时去计算模型的后果。这样做有个益处，就是你调用后果和模型计算的过程，和调用分数的过程是解耦的。也就是说，业务环节间接调用分数，计算又不是理论环节的调用，只是这里须要容许肯定的提早。这样解决，相当于有两个流程，一个是离线流程，T+1 做分数校对；一个是实时流程，上图右侧实时图模型的部署。实时数据源的数据一更新，零碎便去更新标签流传的值，而业务环节的分数调用是通过模型后果的查问服务来调取，而不是间接去查图数据库，这样就拆散了查问和计算，甚至能做到无痛降级图数据库，也不影响线上服务。
下面的解决计划因为有两个数据流（离线数据流和实时数据流），所以零碎复杂度较高，而且须要保持数据的同步。
第三个例子，下单环节的图卷积。
具体来说，基于属性图的节点属性计算图卷积，下单环节调用图卷积后果。它的特点和上一个例子有点类似，业务环节的时效性要求高。子图规模也可能存在爆炸子图，同样也不容许取样。这个场景下，它和后面第二个例子一样，更新的数据量会小于模型的调用量，下单环节下单量比拟大，回测的数据量也是比拟大。所有咱们有一个上图右侧的架构解决，就是零碎有一个 T+1 的校对。即每天有个整体的 T+1 的图卷积过程去更新图卷积后果，并且实时地通过实时数据源去驱动分数的部分更新。所以，它是一个 T+1 的全量刷新，加一个实时的部分刷新。
以上为 Nebula 在 Akulaku 团队的三个利用。
总的来说，Nebula 对 Akulaku 最大的价值是优异的导入性能，以及可扩展性。这里说下它的导入速度，十分的快，QPS 可能达到 11 万，当然是异步写入。这个数据比其余的图数据库好很多，当然可扩展性也十分好。具体利用上，Nebula Graph 其实利用到 Akulaku 图学习模型的部署的很多场景中，后续咱们会着力于进步这个平台的稳定性，继续地反馈倡议到社区来共建产品。此外，会进一步优化图剖析的平台，升高图模型、回测和模型部署的难度。
