NUC 2022｜图数据库在中国移动金融风控的落地应用

各位朋友上午好，我是来自中国移动的算法工程师汪海涛。接下来我主要聊一聊图数据库在中国移动，特别是金融风控场景的落地应用。

>>>>

1. 图平台建设概况

1.1 为什么选择 NebulaGraph

首先我们聊一聊中国移动是如何建设图平台。

中国移动有非常多的数据，全国大概 9 亿的用户每天都会产生海量的数据。如何从这么大数据里面挖掘出有用的信息，然后用到金融风控场景？这就是我们需要做的事情。

之前，我们往往是以手机号为维度去提取特征，然后去做一些模型或规则判断一个手机号是否是有违约风险。但仅仅基于手机号很难综合去考虑风险情况，因此我们就想采用图计算技术去综合看一个手机号以及周围的其他手机号的信息，然后共同评判它的风险。

最开始是基于消费金融的场景，从比如说像蚂蚁金服、微信以及京东白条这样一些产品切入，通过用户通话数据、短信数据、设备等多维度的一些信息，去判断用户风险。但中国移动数据量这么大，不管我们要做什么，最大的诉求就是需要有一个非常高性能的平台去支撑数据分析。因此，我们最开始的时候也是对市场上的一些图数据库产品和图计算框架去做了一些调研。

我们最早是采用了 JanusGraph 加上 Spark 去建设我们平台，但是通过一些测试，我们发现 JanusGraph 的查询性能以及导入性能都比较一般，然后 GraphX 的话，它的计算性能其实也比较一般，特别是它需要的内存量特别大，因此我们后来又开始去调研了市场上很多的图产品，并且对一些图产品做了测试，包括国外的产品，像 TigerGraph 之类的等等，但是因为一些特殊原因，中国移动是在美国商务部的实体清单上，所以很多外国的产品我们是没法去采购和使用的。

然后还有一些比如说国外之前用的 Dgraph ，但国外一些产品涉及到比如说寻求支持可能会很不方便的情况，因此最后，我们是选择国内的几家厂商进行了一些测试和比较，最后选择了以 NebulaGraph 作为图数据库，然后以 Plato 作为图计算引擎这样一个整体的架构。

1.2 图平台整体大图

我们整体的架构解析如下：

最底层是我们的数据源，中国移动建设有一个全国大数据中心，主要包括通话数据、位置数据、消费数据、设备数据、用户数据和 APP 数据等等，我们每月把这些数据抽取到 HDFS 里面，然后把其中有用的数据抽取到 NebulaGraph 数据库里面，那么这里用的就是 Nebula 的一个导入工具，这是我们图数据存储这一层。

再上一层是计算分析层，这也是我们建模和业务分析人员主要使用的一些框架。首先第一个是 Plato，它是腾讯之前开源的一个图计算引擎，但是据我所知腾讯现在已经不维护这一套引擎了，因此我们也是专门找一些工程师，然后去维护这里面的一套框架，以及修复一些小 bug 之类的。

那么它包含的算法其实很多的，这里我主要是列举了两个社区发现算法、Louvain 算法和 HANP 算法。它里面还包含一个 LPA 算法，因为 LPA 算法的话是 HANP 算法一个简化版，所以这里我没有列出来。

然后里面还有一个我们有可能后面会用到的关于随机游走类的算法，主要是基于随机游走得到一个节点序列，会为我们后面用于图神经网络训练做一个前期数据预处理的工作。

第三个是 GNN，就是图神经网络。图神经网络是最近几年兴起的一个领域，我们现在主要是基于这些模型做一些简单的产品，看看能不能取得比以往的方法更好的一些效果。最后就是基于 NebulaGraph 查询语言，主要就是 GO 语句和 FETCH 语句做一些简单查询。

再上一层的话就是应用层。首先是关联风险分，关联风险分主要是基于配套的社区发现算法来做的，后面会再详细做介绍。第二个号码风险分和最后一个催收分析主要是基于 Nebula 的查询语句来做的，主要就是查询用户跟一度、二度联系人以及一些违约用户，或是催收专用号码进行一些主动或被动的呼叫。

第三个信用评分卡，它是基于图神经网络来做的，最开始主要是用逻辑回归或者决策树之类的模型，这里的话我们也希望通过图神经网络做一些提高。

>>>>

2. 图技术的落地应用

2.1 中国移动的数据情况

在介绍我们具体的应用之前，我们先谈一谈有关中国移动的数据情况。中国移动数据总共分成了 6 大类，第一类是身份信息类，主要包括入网时长，最近入网的往往风险就会比较高，比如说一些欺诈用户或者是这种电信诈骗用户，很多都是最近入网的这些新用户。

然后就是身份证。中国移动规定一个身份证下最多申请五个手机号，但是一个设备下插多少个卡这就管不了了。所以很多时候会去看一个设备会不会对应多个手机号，如果对应了很多手机号，有可能是个风险用户，比如羊毛党或者欺诈用户，后面还有一些在网状态、手机所属区域等等。

第二个人际交往类，比如你这个月跟多少人有过联系、每个人联系的频次怎么样，如果他跟每个人联系频次比较少，就说明他可能没有特定的一些交往圈。这里提到一个关于图网络一级管理，二级管理，主要指的就是我们用户的一度联系人和二度联系人这样的一些情况。

第三个是通信行为，我们会有一个金融机构的维表，可以提取到用户最近几个月来跟银行的通话或信息，再基于这些信息去做一些分析，看他有没有多头借贷。

第四个是关于位置的信息，中国移动的定位跟 GPS 完全不一样，我们是基于基站定位，意思就是说我们只能去识别到你当前是处于哪个基站下面。在城市密集区大概是 500x500 这样一个精度，如果是在郊区或比较偏远地区的话，可能是在 3000 米到 5000 米这样一个精度，相对精度是比较差的。我们主要做一些工作地和居住地的识别，以及在申请时是否跟填写表一致这样一些工作。

第五个是消费信息，就是在一些移动公司的消费，比如说他在淘宝或者是京东这样消费还是查询不到的。然后最后一类是关于兴趣爱好类，兴趣爱好类主要是关于 APP 来做的，你安装过哪些 APP，比较喜欢购物，还是喜欢比较喜欢旅游，或者你有没有安装过很多借贷类的 APP，如果有的话就说明可能会有些多头借贷或者风险的情况。

2.2 目前的图数据结构

基于以上这些 Tag，我们会把这些关系类的数据导入到图数据库里面。我们目前整体的图平台还不是很大，资源相对比较有限，现在总的存储资源大概是在 20 个 T 左右，如果放入太多数据的话，我们可能就存不下了，因此我们就挑一些比较重要的放在数据库里面做一些分析和建模工作。

• 点数据

点数据主要是有四类，第一个是手机号，手机号也是我们最重要的点数据，因为中国移动几乎所有维度特征都是基于手机号的，主要是包括比如这手机号它是属于哪个市的，然后是否发生过停机，每个月停机的天数是多少等等这样，还有一些消费信息。

第二个是地理位置，主要基于基站。第三个身份证的话，作为唯一身份证识别，可能会有年龄或学历之类的一些标志。最后一个设备，比如手机它就会有一个设备值，那么会有对应的型号、设备系统等。

• 边数据

然后边数据的话，一个是用户跟用户的通话数据，那么这个就不详细讲，然后第二个手机号和身份之间一个对应关系。第三个是手机号和设备之间对应关系，第四个是手机号跟地理位置之间对应关系，那么这是我们在图数据库里面保存的一些数据。

在最开始的时候我们在数据库里面的话会有一个文件，它是以 key value 形式存储的，如果我们直接以 ID 作为一个 key 的话，那么最后就数据量特别大，原因是我们库里所有数据都是加密的，我们看不到明文，然后我们采用加密方式是 SM4 的方法，最后加密的结果是 48 字节。

如果我们直接用这样一个 ID 存储的话，它存储量实在太大了，所以我们最后是选择把我们这些手机号、地理位置、身份证和设备都进行一个编码，一般手机号是从 0 开始的，其他可能会从一个特定数字开始，编码完成之后以编码作为一个 ID 放到图数据库里面，一个是为了降低平台存储量，第二也是为了和后面 Plato 计算引擎进行适配——因为 Plato 只接受以数字作为 ID 进行建模，不支持字符串或其他，所以如果你是字符串的话，就需要自己再进一步进行编码。那么我们采用这种数字的方式的话，也是为了兼容两个平台。

2.3 号码风险分中的应用

然后就开始讲我们的模型，首先第一个是号码风险分模型。

我们友商都已经有类似关于号码分这样的一个模型，比如说像电信和联通，中国移动在大数据这一块相对起步是比较晚的。号码风险分最开始是希望用在羊毛党识别这个场景，我们会根据用户的通话流量位置以及手机行为信息去判断一个号码，是不是可能是个羊毛党，主要是四个模块，第一个是接码模块，我们会跟一些外面数据公司合作，判断一个号码有没有可能是一个接码号码，如果是，我们就会认为这个号码是薅羊毛的可能性就很大。

第二个行为异常号码，比如说这个手机号是否当月一次通话都没有，然后是不是每月都基本只有固定的月租这样的消费，对于这种号码的话，我们认为它可能是一个小号，或者是专门用来去薅羊毛的号码。

第三个是位置异常号码，比如说这个手机是否一个月下来就是在一个位置从来没有动过，可能只是放在家里偶尔用一下，不会带出去这种。对于这种号码的话，我们认为它的风险也是相对比较大的。

那么这是前三个模型，但是这个的话跟我们图技术关系并不大，我们图技术主要是用于第四个模型。

所谓第四个模型的话就是染灰模块，基于前三个模块的结果以及一些数据厂商以及银行客户的数据，我们首先获得了一批已经确定的羊毛党用户，那么我们可不可以发现他的一些共同特征？比如说可能有几个羊毛党（号码）是属于同一个用户的，那么我们是不是可以看看这个用户下面其他手机号是不是也可能是羊毛党？

另外，如果发现有一堆手机号是同之前在同一个设备上使用过，我们可能也会认为这个设备上对应的其他手机号也可能会是一些羊毛党，那么这个更多是专业的羊毛党，比如说他们会采用卡池这种设备专门去薅羊毛，然后用这种技术可以发现识别。

第三个其实我们还是刚才讲过，我们希望通过采用地理位置的方式去识别，因为羊毛党可能是在同一个位置的，但是我刚才也说了，中国移动它的位置数据只能精确到 500×500 这样一个范围，所以我们目前还没有关于位置这样一些模型出来。

2.4 关联风险分中的应用

然后是关联风险分。关联风险分也是我们最开始就讲过的，立项时候采用了这样一个查询做立项。我们当时采用的思想就是近朱者赤近墨者黑，在平时交际圈，如果你的违约可能性比较低，那么周围人可能违约性也会比较低。

基于这样一种想法，我们主要做法就是首先基于移动所有用户构建一个关系网络，然后再采用一些社区发现类的算法去挖掘这个社区，比如说个人的一些评分以及个人之间的关系，然后去对这个社区进行打分，然后去识别出这个社区它是否是一个欺诈社区或者是一个低信用的社区，这是我们主要一些想法。

关联风险分的主要应用场景就是欺诈领域，在信贷欺诈、交易欺诈、营销欺诈、支付欺诈以及账户欺诈等等多个方面。它最关键一点其实是在于我们原先的数据处理，最开始构建用户关系网络的时候，主要用到三方面的数据，一个是用户通话关系，就是我这个月和你通话过多少次，以及我们通话时长有多少。我们会根据通话次数跟通话时长去计算一个用户关系的强度，然后作为两个用户之间一条边。

第二个种关系就是用户身份证，如果两个手机号是属于同一个身份证，我们会给这两个手机号之间加一条边，一般来说这个还比较好做，因为一个用户下面现在就最多一般只有五个手机号，但设备的话相对就会难做一点，目前采用的方法，如果一个设备下面的手机号特别多的话，我会直接把这个设备给砍掉，就是这种大节点会直接砍掉。

这是关于关联风险分，关联风险分我们实际做的时候就是建好我们的关系网络之后，我们是采用 Plato 头里面的 HANP 算法和鲁汶算法，我们会专门去调一些参数，然后看看哪个最后结果比较好。

• 难点一：计算困难

但是在实验的时候会遇到几个问题，首先第一个是节点 ID 不连续的问题，因为我们之前为了跟 NebulaGraph 数据库兼容，我们的 ID 是提前编码好的。

那么现在要构建网络的话，大概会用到所有用到过的号码大概是有 50 亿左右，50 亿其实已经超过 int 型表上限，就是 43 亿这个值了。然后 Plato 只能支持连续性的 ID 编码，要解决这样一个问题，我们是采用两种方法，一种是在数据量不超过 43 亿的情况下，我们是直接解除了对 ID 最大值的限制，如果是数量确实超过 43 亿的话，就对它进行编码，编码完成之后就压缩到 43 亿以内，但这样速度比较慢，我们后面会再讲。

第二个问题是 HANP 算法不支持节点超过 2 的 31 次方，这应该算是一个小 bug，因为 HANP 算法底层有一个allgether 的这样一个函数，它是采用的是一个 API 框架的聚合，这个聚合采用 Int max 是 2 的 31次方，我们对它进行一个多次聚合来解决这个问题。

第三个是编码速度过慢的问题，Plato 本身采用的是哈希表进行编码，但这个其实比较适应于特别稀疏的一个场景，但是我们这个场景其实没有那么稀疏，比如说我们最大的案例它大概是 50 亿左右，但实际我们的 ID 数目大概就有 10 亿，其实大概是 1/5 的这样一个比例没有特别稀疏。采用这种哈希表的编码方式速度并不快，因此后面可能会考虑就直接采用统排序，然后自己去（控制）最大编码这样一种方式来做。

• 难点二：建模困难

后面讲一下我们建模的困难。第一个是我们数据噪声比较大的问题，大家平时跟朋友或者亲戚一些交流，应该都不会采用手机通话，而用微信来沟通了，手机通话更多时候可能是快递或是外卖。因此我们怎么去处理数据噪声的问题？

目前我们是采用两种方式，一种根据手机号平时的通话以及行为去判断它是否是一个外卖员或者快递员的号码，我们有专门模型去做一个识别。第二个我们还是跟外面的厂商进行一个合作，他们会提供一个手机号，它是否是一个营销号码，或者是其他一些特别的号码，基于这些标签把号码从我们的库里直接进行删除，或者进行一些处理，这样剩下来的应该是能比较真实表示通话意愿的一些数据。

第二个是社区大小不平衡的问题，我们在用 HANP 算法或者鲁汶算法会发现，一个社区里面可能有几千甚至上万个这样一个点，如果对这么大数据进行分析的话，可能它并不能代表我们每个用户的真实的一些风险。因此，Louvain 算法我们会通过设置参数，可以提前停止聚合；HANP 算法我们可以提前提供条件。虽然社区小，但也有可能会导致我们模型的准确度不高，所以这个的话也是我们目前一个比较大的问题。

当然了，通过第一种删除一些大节点的方法，我们也可以去设计个阈值，比如说我和你之间每月通话大概只有一次，每次通话时间不超过一分钟，就认为我们之间可能是一个偶然的联系，就直接不把它放到我们的库里面。

但是综上，我们其实并不能完全解决这个问题，这个问题现在其实也还是比较困扰我们的一个问题。

第三个是打标样本不足的问题，现在的样本基本是来自一些客户样本，就是银行样本，银行会给我们一些欺诈标签，然后我们再基于这些数据进行一些建模，但是这个标签相对来说数据量还是比较少的，想支撑全图一个建模还是比较不足，因此我们最后一个模型的结果相对来说并不是通用性那么强，可能只针对一小部分用户有比较好的识别效果，这是三个问题。

2.5 图神经网络（GNN）在中国移动的应用

最后是关于图神经网络类的一些应用。我们是在今年才开始建设这个图神经网络平台，目前相对来说比较简陋，就简单讲一下。它的应用场景主要是基于用户的金融风控信用评分卡这样一个场景，过去我们用做信用评分卡大部分都是首先提取用户一些特征，再然后训练一个逻辑回归模型或者是角色数字类的模型。

那么现在，我们想看看能不能通过图神经网络做一些模型，我们用到的关系，主要就是用户之间通话数据，同样的处理方式跟之前差不多，然后我们会基于他近三个月主动通话、被动通话以总通话次数是否达到要求，去判断要不要保留这样一条边。

我们大概提取 100 多个主要的特征去录模，这里的模型相对来说比较简单，目前是尝试了一个双塔的模型，左边的是关于图神经网络聚合的这样一个模型，右边用户的特征本身的一个全连接网络做了这样 MLP 的模型。左边的神经网络聚合，是比较简单也是最常用的——GCN、GrapSAGE 和 GAT 这三个模型。我同事大概尝试了一下，最后结果是跟逻辑回归差不多接近，还没有特别大的提升，一方面是目前模型相对比较简单，第二我们想做更大模型也会受到一些计算资源的困扰，所以后面可能会考虑增加模型的一些复杂度，或者是考虑就对数据进行预处理，来提升模型的效果。

另外我们现在采用的是一个同构图的网络建模，后面可能会考虑异构图，比如说考虑用 HAN 这样的一些异构图的模型去建模，把用户的身份证和设备以及位置信息这些点都归纳进来，然后一起进行建模。

>>>>

3. 图数据应用的未来展望

首先是数据血缘，因为现在中国移动大数据中心会提供给大概 30 多家客户的 50 多个项目进行一个共同的建模，建模工作里包含的数据维表会特别多，因为我们会给每个用户都匹配数据，然后帮他们生成特征，最后会把结果表也保存在数据库里面，大概现在有 1000 多张数据表，平时基本靠人工管理，后面看看能不能通过数据血缘的方式去做一个归纳。

但我们现在最大的困难并不是关于数据库这一块，而是整个大数据平台要跟图数据库平台打通，才能够去完美解决数据血缘的问题。如果中间的端口打不通的话，平台部署上去可能也得需要人工的方式，这是我们目前最大的一个痛点。

第二个是图神经网络，刚才讲到中国移动的大数据中心，还有一个人工智能中心，那里有很多的 GPU 资源进行人工神经网络的训练，但是这两个平台之间是不通的，所以后面看怎么去解决这个问题；今天我也想听一下 DGL 平台是怎么用机器训练来解决这个问题的。

以下为本次分享的视频，搭配文字不要太香~

本文转载自公众号：Nebula Graph Community