业务增益32% | NebulaGraph 在携程支付风控场景下的落地实践

前言

携程作为在线旅游代理(OTA)行业中的一家头部企业,处理着海量的在线实时交易订单。然而,随着订单数量的增加,潜在的欺诈风险也随之上升。为了更有效地识别团伙欺诈和黑产攻击,同时确保实时风控系统的高响应性,携程风控研发团队对多个图数据库进行了调研和试用,最终选择了 NebulaGraph 数据库,并成功将其投入线上使用,从而显著提升了业务效益

背景

在支付场景中,风控系统需要对用户的下单信息进行补充,以丰富用户的风险画像,从而更好地识别风险和防范欺诈。然而,在某些情况下,特别是对于新用户的识别,常规的技术手段存在一定的局限性。这种局限性可能导致风险被忽略,进而导致欺诈率升高。

具体而言,当一个新用户进行下单时,风控系统会根据支付订单中的信息实时评估该订单的风险。然而,由于新用户在携程内部的历史数据较少,其风险画像往往不够完善,这就增加了欺诈的可能性。统计数据显示,相较于老用户,新用户的欺诈风险高达六倍。在这种情况下,风控团队提出了利用图数据库来构建一个实时动态图的预期设想,以丰富新用户支付订单的风险画像,从而提高欺诈识别率。
业务背景

业务建模
我们的业务模型如下图所示,一笔新用户订单会包含 6 个元维度的信息,分别是用户 ID、邮箱、手机号、设备指纹、设备号以及账户信息,然后我们可以通过相同的元素关联出一阶和二阶邻居。比如使用相同邮箱号的两个用户,然后再通过 id-03 用户关联出 2 阶邻居的设备指纹,然后这样子就可以通过关联关系来补充。从新客的单一信息关联出它的一阶邻居,再关联出它的二阶邻居,然后综合这些关联信息来更好的对交易订单进行风险的识别。

图关联模型

下表是原始的数据格式示例,除了具体的元素信息,还包含当前订单的流水号 eventid,还有订单的请求时间 requesttime。

基于上表的原始数据格式进行图数据的建模,将这 6 个维度分别构成了 6 个点。由于这些是属于一笔订单里面的信息,所以将这些点都进行两两的关联,表示它们都是有相互关系的。

在点上设置了三个属性,第一个是 vid,就是该元素的唯一标志值,另外两个就是标识当笔事件的 eventid 和 requesttime。对于边而言,只有 requesttime 和 eventid 属性。

对于目前的业务场景还有一个需求,就是要保持一年内的实时关联图,对于超过一年之外的数据,它就不再参与这个图的关联了。所以我们用到了 NebulaGraph 图数据库的一个特性,就是它对于时间戳类型的属性,可以设置 TTL 存活时间。我根据业务的要求对所有点的 requesttime设置了一年的 TTL,一年之后的这个点就会自动过期,不会再参与实时图的关联,这样子就可以保证我们当前的这笔订单关联的是一年以内的窗口。

查询逻辑

我们基于刚才的模型,在构建查询过程中发现了两个问题,第一个问题是我们的查询存在热点问题如下图所示, 比如从 uid1 开始,它关联查询到了 N 个设备信息 client 的点,然后 N 个 clientId 又各自查到 N 个手机号 mobile,这样子就会导致整个关联查询的数量急剧膨大,甚至导致超时和服务器的宕机。

对于这样子的热点我们是需要排除的,因为它的数据价值不高,而且会因为查询超时而降低整体的查得率,影响风险判断的最终结果。

第二个问题是,像下图中的这笔订单刚进入风控系统时,由于图数据的写入是通过消息队列推送的方式,所以会存在这样的情况:当这笔订单中包含的 3 个元素(uid1、clientid1、mobile1)还没有被写入到图库时,风控规则就要求查询 uid1 的关联信息,那么此时是无法查询得到 mobile2 和 uid2 的信息的。我们就想到了一个解决方案,将单个查询改为群组查询。使得同一笔订单中的元素在尚未关联写入图库的前提下,就能查到这些元素的二阶关联邻居。
写入延迟示意图

解决方案

下面是一个我们的解决方案,首先针对第一个热点问题,我们会按照点的tag标签类型,去查询它的关联点,如果某一类关联数据(比如uid关联mobile)超过了规定的阈值就会进行舍弃,保证实时风控的高响应。

如下图所示,uid1 查询到的 client 数量超过了规定的阈值 9,我们就把这些 client 点进行剔除,不再参与下一阶的关联过程。然后将符合要求的一阶关联结果点进行合并去重,作为我们二阶关联的起始点,然后使用同样的策略去查询它的二阶邻居,最后进行数据的整理合并,这样就能以较小的代价来剔除热点的干扰。

针对上一节中提到的第二个问题,即同笔订单中的多个元素的关联写入延迟,导致无法查询的情况。我们也在下图中体现了解决方案,就是将当笔订单的多个元素(uid1、clientid1、mobile1)作为一个整体,并行地查询它们的关联邻居,然后将各自的结果去重合并到最终的结果中进行返回。

在上图所示的流程中,我们用到了一个关键的 nGQL,如下图所示。这个语句的含义是从一组起始点开始,按照它们的关联点的 tag 类别进行关联查询。对于超过热点阈值的某类关联数据,进行过滤剔除。如下图的这个例子,起始点关联到的 mobilephone 已经超过了 9 个,就形成了一个热点,符合剔除过滤的条件,所以 mobilephone 就会返回一个空列表,表示不再参与下一阶的关联查询过程中,从而避免了热点对实时风控系统的性能影响。

最终效果

我们借助 NebulaGraph 在对此风控业务场景进行落地实践的过程中,构建了一个实时图特征平台的应用逻辑闭环,如下图所示。

业务上线后,我们额外获取了 55% 的关联用户信息,通过这些新增特征信息,将相关的图模型 KS 值(模型区分度评估指标)提升了 2 个点,从而使该场景下的欺诈覆盖率相对提升了 32%,获得了良好的业务增益。
额外获取关联用户信息

未来规划

图数据库是一个比较新兴的技术领域,因其天然的关联属性和查询优势,十分适合于风控场景,尤其是挖掘互联网用户的特征。携程集团在调研了多个图库之后,选定 NebulaGraph 作为主流支持的图数据库。

携程风控研发团队目前正在积极地挖掘 NebulaGraph 的使用场景,后续会探索在血缘关系,欺诈团伙识别等场景的落地实践。

在此特别感谢 NebulaGraph 团队和社区的技术赋能,愿未来一路同行!

7 个赞

赞赞周老师!

:+1:,感谢分享!

从业务角度咨询下,这种风控的大点一般是没有意义的点吗?

在这个场景下, 这种热点一般是代理商或者是默认值. 我们的策略同事离线分析过这类热点, 发现对业务的影响是弊大于利的, 所以我们采用了适度舍弃的方案.

3 个赞

感谢!这些经验对其他人很有帮助,再次感谢分享!