共计 4448 个字符，预计需要花费 12 分钟才能阅读完成。
本文首发于 Nebula Graph Community 公众号
互联网金融的借贷同传统信贷业务有所区别，相较于传统信贷业务，互联网金融具备响应快、数据规模大、危险低等特点。众安保险次要业务是做信用保障保险，为了服务业务，大数据团队搭建了风控系统用于解决互联网借贷的决策问题。本文次要讲述 Nebula Graph 是如何通过众安保险的选型，以及 Nebula Graph 又是如何落地到具体业务场景帮忙众安保险解决风控问题。
业务背景
有别于传统银行的信贷业务十天、半个月的申请审核时长，互联网金融借贷第一个特点便是申请审核十分快，可能用户上一秒刚在手机端提交授信申请，下一秒零碎便会返回授信申请的后果。此外，互联网金融借贷还有一个特点：数据信息的真实性难以保障，用户填写的信息：年收入、家庭关系、联系人都会存在信息不实的状况。而这两个互联网金融的特点催生了一个产业，就是网络黑产。艰深来说，网络黑产就是用户薅“借贷”羊毛的行为。因为网络借贷隐匿性强，一旦黑产账号施行了欺诈行为后，通过互联网很难追踪到特定的人。此外，因为借贷审批时效性的关系，黑产账号能很不便地做到走量、薅到更多的钱。基于此，催生互联网金融的风控需要，须要零碎甄别欺诈场景。
那如何甄别网络黑产呢？通过用户与不同实体、设施、GPS 与手机号之间的关联关系，以及社群发现查看社群中的个体是否有欺诈危险、进行反欺诈的个案考察，能很好地进行借贷风控。目前，众安保险的风控是基于 Nebula Graph 实现的。
为什么抉择 Nebula Graph
在众安保险技术选型之初，团队成员调研过图数据库市场的产品，首先筛选出了 JanusGraph、OrientDB。
先来说下 JanusGraph，在众安金融事业技术团队外部 JanusGraph 有一大劣势：团队成员对它相熟，不少工程师应用过 JanusGraph，这从某种程度上升高了图数据库开发、上手老本。应用过 JanusGraph 的研发都晓得它是一个分布式图数据库，存储、索引依赖开源组件，例如：HBase（存储）、Elasticsearch（索引）。而之前公司的某个业务线曾应用过 JanusGraph，底层搭载线上 HBase 存储服务，而该业务绝对独立和其余外围业务不存在强依赖关系。“不同的国家有不同的国情，一旦雷同机制硬搬到不同的国家，可能会呈现水土不服问题”，目前众安保险风控业务的根底数据存储在 HBase 中，如果风控系统应用 JanusGraph 的话，将上百亿图数据齐全导入 HBase 会对 HBase 集群产生影响、减少查问毛刺，导致其余业务线受到影响。此外，在大规模写入速度性能方面，JanusGraph 导入较慢。综合上述起因，即使 JanusGraph 具备低上手老本，但其强依赖其余组件、导入性能差，所以 JanusGraph pass。
在图数据库产品调研过程中，咱们发现 OrientDB 在 DB-Engine 排名较前、功能完善。通过性能测试，发现在小规模数据集下应用 OrientDB 体感良好，但一旦 Mock 数据过亿，大规模数据集下应用 OrientDB 会遇到 Server 端频繁报错问题。查阅 OrientDB 官网文档无果之后，众安保险向 OrientDB 官网 GitHub 仓提交了 issue。然而 OrientDB 反馈响应慢，在提交 issue 的过程中，咱们还发现大规模数据集 Server 端频繁报错问题社区用户两年前提交过，issue 仍未解决处于 open 状态。此外，在大规模数据写入性能方面，写入点的速度尚可承受，但写入边的 QPS 只有 1-2k，用这个速度开始图数据建模的话耗时将在天级别，这是不可承受的。综上，尽管 OrientDB 排名靠前、功能完善，但大规模数据频繁 Server 报错、社区 issue 响应慢、大规模写入速度不佳导致最初咱们没有抉择 OrientDB。
而 Nebula Graph 参加技术选型的契机是，在众安保险开始图数据库选型时，征询其余公司（京东、携程…）从业人员公司所用图数据库时，他们统一举荐 Nebula Graph。因而，Nebula Graph 成为众安保险图数据库选型的选项之一。而在理论测试中，咱们发现 Nebula Graph 大规模写入速度十分快，生产环境测试数据能达到 10w+ QPS。此外，Nebula Graph 存储和索引依赖于本地 RocksDB 库，不依赖于其余大数据组件，合乎业务需要。在大数据生态反对方面，Nebula Graph 反对支流的 Spark（nebula-spark-connector）和 Flink（nebula-flink-connector）。在社区响应和反馈时效上，Nebula Graph 也给了咱们比拟好的体验。
这里额定讲下社区反对，在整个图数据库调研过程中，咱们发现相较于成熟的诸如 MySQL、Oracle 此类的 SQL 数据库，图数据库倒退工夫较短，由此产生的问题是遇到局部图数据库产品问题，搜索引擎能提供的信息较少。像之前 OrientDB 的频繁报错问题，如果社区未能提供及时的技术反馈，对于使用者来说他可能要花费大量工夫来浏览源码去 Debug，人力老本便会急剧回升、性价比极低。
而 Nebula Graph 在社区反对跟反馈方面给了众安保险十分良好的体验。作为他们的客户，包含在最晚期的 1.0，众安保险给 Nebula Graph 提交了不少应用问题和 bug，Nebula 研发同学都能及时回复和 fix bug。到 2.0 部署时，咱们遇到生产部署问题他们也能及时提供技术支持。这一点相比于其余的图数据库厂商，是十分值得举荐的。这也是咱们抉择 Nebula Graph 作为图数据库来撑持众安保险业务的根本性起因。
金融风控业务实际
下图为众安保险基于 Nebula Graph 的风控系统架构图，它集数据处理、加工荡涤、计算、图服务利用为一体。
如上图所示，最底层为业务库，不同的业务关系数据存在不同的业务库中，包含用户附件、设施、GPS、IP 等等信息。
再下层，是由离线数仓和实时数仓形成的图数据库加工荡涤层，离线数仓通过 DataX 进行每天 T+1 的数据回流，回流业务库的数据存到 ODPS 中，Nebula Graph 通过 Spark 来读取当中数据并写入到数据库中。在实时数仓方面，通过众安保险外部的监听组件 BLCS 将数据写到 Kafka，再通过 FlinkSQL 搭建的实时数仓进行数据荡涤加工，最初通过 Flink 实时地写入到 Nebula Graph 中。为了保证数据的一致性，实时数仓每天进行数据校验，如果数据存在不统一，则会应用离线数据补齐缺失的数据。
数据荡涤加工层下面则是存储 & 计算层，存储层不用说天然是 Nebula Graph。而计算方面，通过 Nebula Graph 提供的 Spark Connector 组件，将图数据库中的数据读取到 Spark 平台通过 GraphX 执行预测模型，最初将后果写回 Nebula Graph 中。
最初，通过众安保险的微服务零碎将图数据库存储 & 计算对接给下层图利用，提供图摸索服务、风控特色、个案考察、预测模型等图服务。
关系图谱
这里简略解说众安保险外部的图社群摸索的关系图谱，通过上图的关系图谱解说具象化地介绍众安是如何利用图数据库甄别欺诈场景，如何应用图数据库实际风控个性。
上图有 2 类节点：
- 人（蓝色节点）
- 手机（绿色节点）
存在 3 类关系：
- 人 -[申请]-> 手机
- 手机 -[联系人]-> 人
- 人 -[绑卡]-> 手机
第一眼看到下面的图，很显著看到 2 个浓密热点，热点手机号被五、六十填为他的家庭联系人的手机号。按常识来说，当代中国大多独生子女家庭，加上旁系关系，也很难呈现五、六十个人同时将同一个手机号填为他的家庭联系人的手机号。所以，这个手机号关联人可能是欺诈团伙分子，黑产团伙可能通晓借贷评分零碎中有一环节是对家庭联系人的手机号进行信用评分，团伙心愿通过关联高信用分的手机号从而进步信用分。
基于上述特色，咱们能够查问用户所在社群的规模、用户是否在疑似欺诈社群中对他进行一个初步风控判断。这里讲述下，即使某个用户处于异样关系网络中也不代表他是个欺诈用户，处于异样社群是个判断用户是否为欺诈分子的充沛不必要条件。因为存在一种可能，用户自身并非是欺诈分子，但直系亲戚参加了中介代办、团伙欺诈，此时便会呈现失常用户和异样用户都存在同一关系网络的状况。
下一步，咱们须要深刻开掘用户和异样核心的“密切”离散度，探寻它们的门路间隔。通过联合 Nebula Graph 自身的门路查找性能，剖析离散度（凑近异样点，还是处于社群边缘）从而判断某位用户是否是有欺诈嫌疑。
这里以手机号为例，来帮忙大家了解众安是如何通过 Nebula 来辨认用户的欺诈场景的。其实众安保险外部还有设施、IP 等等关系图谱，这里不开展赘述。
图模型预测
这部分来介绍下图预测模型，
- Connected Component（贷前）
- Label Propagation（贷中）
- Degree Statistical
刚下面局部介绍的关系图谱是通过联通重量（Connected Component）算法计算得出的，次要利用在贷前的用户授信申请环节。
再来是标签流传（Label Propagation），不同于联通重量，标签流传更多地利用于贷中环节。标签流传次要是通过一个确定的点 Y 去流传、衍生出它相干点。举个例子，贷中用户名单中某个用户是重大逾期人员，这个人员便是打上逾期标签的确定点 Y，联合既定的风控规定查看点 Y 关联延长的点中哪些点呈现类似逾期行为，从而判断这些点是否属于重大逾期的社群。这便是贷中的标签流传算法。
最初一个算法是 Degree Statistical，全图关系度数，次要供风控人员应用。风控人员在做风控特色时，可能会提出几十、上百个图特色，基于这些特色数据须要用历史的数据去验证，查看哪些特色能够真正地辨认出欺诈用户或是重大逾期用户。而这个验证过程，如果应用传统数仓通过 ODPS 做深度查问的话，无论在执行效率、耗时，还是在 SQL 代码编写方面，都是一个十分低效的过程。但，通过 Nebula Graph 将点数据读取到 GraphX 中进行全图关系度计算，将 7 度或者是 10 度关系以行的模式写回到 ODPS 中，提供给风控人员应用，能够帮忙他们更快地实现风控规定制订、实现风控工作。
将来瞻望
版本布局
在主题分享时，众安保险所用的 Nebula 版本为 2.0.1，后续 Nebula v2.5.0 中新增水位线 watermark 性能去避免查问遇到浓密热点占用内存过高拖垮 storage 过程的状况。众安保险这边会在测试环境部署 v2.5.0 版本进行验证，验证通过之后，业务线逐渐切到 v2.5.0 版本中。
更多利用场景
后续 Nebula 可能利用在数仓的表与字段的血统依赖、调度平台工作关系的治理中，众安保险根底平台部的同学正在入手用 Nebula Graph 去替换已有的传统实现计划。
本文整顿自众安保险的图实际主题分享，可观看上面视频来理解更多详情。
交换图数据库技术？退出 Nebula 交换群请先填写下你的 Nebula 名片，Nebula 小助手会拉你进群~~
关注公众号