摘要

在银行日常经营中，无论是风险防控还是客户营销，都有较多的关联关系数据分析场景，如担保圈、洗钱模型、资金链追踪等。因传统关系型数据库的数据建模和数据储存结构原因，其在关联关系分析的应用方案弊端较多。本文介绍了某省农信社将图数据库和图算法等知识图谱理论的相关技术应用于系统建设，完成了行内知识图谱的搭建工作，并基于此开发了多个业务模型，在关联关系数据分析方面取得良好的效果。

第1章 概述

1.1背景

近年来，随着金融监管要求不断提高、金融机构内部管理和经营迅速发展，对于客户、账户、员工、资金关系等关联关系分析的要求也越来越高，在实际应用过程中，资金链、担保圈、客户关联关系分析也越来越多的在金融机构的不同领域被提及，而在传统的关系型数据库中，对于关联关系分析的效率极低，一般都是使用迭代等方式进行层级计算，尤其在涉及金融机构的海量交易流水数据时，往往只能分析3度以内的数据，而金融机构实际的风险管控、合规管理等要求的此类分析多数需要沿着关联关系链条进行更深层次的挖掘，分析对象呈指数级增长，无法在合理的时间内计算出模型计算结果。

知识图谱及图数据库作为一种较为新兴的技术，能够很好的展现和处理现实世界中的各种实体和关系，特别是复杂的网络关系。以海量流水信息为基础建立基础的客户关联关系、资金流、担保圈等知识图谱，并在此基础上进行模型研发，对内控合规、风险管控、内部审计乃至业务拓展和客户营销等多个领域均有良好指导意义，可以有效解决传统数据库技术在这类场景中的问题，降低模型开发难度，提高数据分析效率。

知识图谱技术则很好的解决了此类问题。在知识图谱中,用 “点”和“边”构成的图来表示显示世界的实体和关系，图数据库是知识图谱数据的读写和存储工具。一方面，与传统关系型数据库相比，图数据库更擅长建立复杂的关系网络，在关联查询的效率上比传统的存储方式有显著提高，尤其是涉及到3度以上关系查询。另一方面，基于图的存储在设计上会非常灵活，一般只需要局部的改动即可。知识图谱使用图的数据结构还原真实世界的数据，是挖掘数据关联关系最好的方式。

因此,我行在2018年与北京明略数据合作，实施和知识图谱项目，通过知识图谱技术的应用解决传统关系型数据在分析客户关系或资金链场景中效率低下、分析手段缺失的问题。

1.2应用场景

在银行中，最受关注的是风控领域，与客户关系和资金链相关的非常多，例如信贷业务重点的担保圈、受托支付、客户关系排查，内部审计的员工行为排查，反洗钱业务中的各类模型。

1.2.1 担保圈分析

担保贷款是信贷业务的一种，客户之间互相担保会放大信贷经营风险，因此一直是信贷部门重点排查对象之一。但是受限于上面的分析，已有的技术手段只能发现部分问题，例如一个客户给多个客户担保，多个客户为一个客户担保或者两个客户互相担保。对于三个或三个以上的客户形成的环状担保，则无法分析。这部分问题属于知道存在，却难以无法发现。

1.2.2 贷款回流

内部审计的员工行为排查内容之一，是行内员工与贷款客户之间的资金往来,关注是否存在利益输送。在实际操作中，贷款客户可能会将资金直接或间接转至员工配偶、父母、子女的账户中。目前的数据分析手段无法综合分析自然人之间的关系和账户之间的关系，排查范围仅限于员工名下账户与借款人名下账户之间的直接交易数据。受限于模型开发难度和模型运行时间成本，大量的违规数据还没有被甄别出来。

1.2.3 反洗钱模型

基于传统关系型数据库的反洗钱模型，通常只能关注1度的交易行为。在图数据库中进行数据分析，通常以5度交易为分析范围。以频繁汇入模型为例，传统模型筛选条件是5日内汇入金额大于5000元、转入次数超过50次的账户，且该账户在5日内将资金集中转出，转出次数低于5次、余额小于10元，即在所有的B->A->D的资金交易中找到满足条件的A。因图数据库在关联关系分析方面的便利性，可以在较短的运行时间内完成模型的运行，识别出5度资金链条，即C->B->A->E->F中满足条件的A。随着分析深度和广度的增加，单个模型涉及的账号通常成指数级增长，可以从大的数据维度上判断交易是否可疑，提升交易甄别的准确性。

1.2.4 客户群体划分

实体的属性是图数据一个重要数据维度，与标签功能类似。通过对自然人相关数据的分析，例如交易关系、消费数据、手机银行定位位置、担保关系等，能够提炼出用户特征信息，是存贷款数据的重要补充，这些数据有助于我们更好的理解客户。
在应用时，可以通过API查询具有一个或多个属性的客户列表，例如查询日均存款大于10万元、手机银行常用登陆地为西安城六区、年龄大于40岁、性别为男性这一群体的客户列表。

1.2.5 失联客户管理

此应用场景与社交网站中“你可能认识的人”的推荐功能类似。现实中，不少借款人在借款成功后出现不还款并且失联的现象，使得催收人员无从下手。在关系分析模块中，通过2度或3度关系分析发现可能与借款人认识的潜在联系人，从而帮助催收人员提高催收成功率。

1.3重大风险提示与管理

1.3.1需求分析

知识图谱技术属于新兴的技术领域。每个项目项目经理所要面临的问题之一是如何尽可能展示新技术的优势。如果项目一期实施效果不理想，可能会导致业务部门对该技术失去兴趣转而关注其他系统或技术的使用，严重的还可能导致后续项目建设的搁置或系统停止开发。因此，在项目建设初期，要多与业务部门沟通，明确了解他们的痛点，原有技术手段无法解决的原因，新技术手段可以解决哪些问题。避免有些业务人员认为新技术无所不能，导致最后产生落差，例如有些人认为利用知识图谱开发反洗钱模型后，可以代替反洗钱系统向上级部门报送数据。

1.3.2逐步实施

各个银行的数据体量通常都很大，数据质量层次不齐。部分数据可以较为明确进行分析，例如客户、账号、合同等。但部分数据可能较为模糊，例如APP登录的IP、MAC地址等。还有部分数据与当前业务需求相关，例如ATM、主机设备等设备信息。如果将所有数据统一进行数理分析，工作量巨大，耗时较长。随着需求的新增或变化，部分数据的标注分类也会发生变化。这样的开发模式，周期较长，难以适应当前业务的快速发展，也带来了无效的工作量。工作量越大、项目周期越长，外界不可控因素就越多，越容易导致项目延期。

因此，在整体规划时因该用迭代的开发思想。在项目实施时紧贴需求，项目一期完成主要数据的分析和标注，后续根据新增的数据源和新增的需求，不断拓展接入数据的外延，例如第三方数据。在此过程中不断与源系统就数据质量问题进行沟通，通过源系统的改造提高知识图谱的质量。

1.4关键技术选型

知识图谱理论为系统建设的理论基础，以图数据库为应用软件。图数据库由两个非常重要的部分组成：图的存储和图处理引擎。根据其特点分为原生存储及处理引擎和非原生存储及处理引擎，简称原生图数据库/非原生图数据库，代表产品分别Neo4j和Titan。

原生图数据库Neo4j的优点是相应的开源社区较为活跃，部署、使用较为简单，性能与Titan相比有一定优势。Neo4j的缺点一是它不是真正的分布式架构，数据量超过单机的承载能力后无法处理，商用版通过上层封装实现了类似于集群的功能；二是Neo4j底层存储是自主研发，整体架构具有一定的封闭性，只能选用独立安装的部署方式。

非原生图数据库Titan的优点是完全开源，并且能够很好地与Hadoop大数据平台结合在一起，底层存储支持HBase，索引插件支持Elasticsearch，能与Spark结合进行OLAP分析。Titan的缺点是为了与HBase的列存储模式适配，再读写性能方面有一定的损失。

本次项目建设引入的图数据库组件Titan，为开源产品。2012年Titan的第一个版本0.1.0在开源社区发布。2014年Spark在新发布的1.0版本中加入GraphX算法工具包，开始支持Titan应用。因为Titan与Hadoop平台天然的融合性，使其被众多大数据厂商采用，用于开发自身的知识图谱类产品，应用非常广泛，近几年呈爆发式增长，技术趋于成熟。

第2章 设计方案

2.1 预期目标

罗马不是一天建成的，知识图谱技术的应用应采用敏捷开发的思想，逐步实施、分批落地。
项目第一阶段主要的工作目标为：
1、完成知识图谱平台搭建工作。主要以银行自有的数据为分析对象，完成对核心、信贷系统中主要的实体、关系和属性数据的分析梳理，例如客户、账户、合同、抵质押物等，在此基础上建立资金关系图谱和客户关系图谱。
2、以担保圈排查和员工行为排查为主要的应用场景，用图算法在基础的资金和客户关系网络中进行数据分析和挖掘。让业务部门看到新技术的优势，便于后期的拓展。

2.2 架构设计

2.2.1整体架构设计思路

知识图谱项目建设的总原则是以hadoop平台软硬件环境为基础，以平台化思想为设计理念，以完备统一的数据标准为开发规范。确保平台上的各条数据处理流程互不影响、各模块功能互相配合。

2.2.2ETL流程

数据类系统都离不开ETL流程，知识图谱系统也不例外。系统ETL流程主要分为两步：构建基础网络和主题模型分析。
1、构建基础网络
在知识图谱理论中，数据分为实体、关系和属性三类。实体包括客户、账号、机构、抵质押物等。关系指实体之间可被清晰确认的关系类型，如客户和机构之间是隶属关系，账号与账号之间是支付、收款或资金往来关系，客户与客户之间是配偶、法定代表人、母公司等关系。属性则指实体或关系的相关特征，不同实体或关系的特征个数和内容都不一样，如账号的属性包括状态、余额、开户日期，支付关系的属性包括交易时间、交易金额，配偶关系的属性则仅包括建立时间。
贴源数据到达系统内后，首先经过标准化落地，存入标准层。图数据的ETL过程是按照人工预先设定的规则，将二维数据表拆解为实体、关系和属性三要素，按照图数据库格式组合后HBase中。例如，客户在柜面取现，那么客户账户这个实体的属性之一余额就会发生变化。
这一步中完成了资金流转网络和客户关系网络两大基础网络的构建。为加快查询速度、支持模糊查询，实体的关键属性会被存入ES中，如姓名、证件号码、账号等。
2、构建主题模型
在基础网络中，可以查询出各种类型实体、属性以及实体之间的关系。但是这些只是账务数据的图谱展示，还不能体现数据价值。在具体的应用场景中，我们对于期望获得的数据都有明确的业务规则。构建主题模型就是运用图算法将这些业务规则变为图析模型，在第一步的基础网络的海量数据中进行分析挖掘，分析得到的结果按主题存放。

2.2.3逻辑架构图

系统从逻辑上可以划分为五层，如上图所示分别是数据源层、标准化数据层、知识图谱层、主题模型层及前端应用层。其中：
数据源：包括行内主要的业务系统，是大数据平台的数据源，例如数据仓库、CRM等。随着应用的不断深入，后期还会将第三方数据纳入进来。
标准化数据：各个业务系统的源数据质量良莠不齐，长度、精度、格式等均不统一，无法直接使用。通常源数据都需要经过标准处理后才能使用。标准化的过程通常有行内专有系统来完成，便于全行统一管理。对于本系统来说，这一层存储各业务系统标准化后的数据。
知识图谱：依据知识图谱所需数据模型，将各业务系统的源数据抽取为实体数据、关系数据及特征数据等，构建基础的网络关系。这一步需要多次、充分的与原系统的开发人员和业务人员进行沟通，在了解业务的基础上梳理数据资产。将以传统的关系型数据库为基础的数据资产转换为知识图谱的数据资产。例如，账号以那种表为准，客户的手机号从那个表的那个字段中获取，受托支付关系如何获取等。
主题模型：与具体应用场景相对应，例如反洗钱的频繁汇入、频繁汇出、环状等资金流模型。
前端应用：包括主题模型的可视化展示和手工操作两部分。主题模型可视化展示是指将模型的分析结果以知识图谱的方式展示出来，让用户直观的看到分析结果具体涉及什么问题。不需要业务人员手工画图去掌握资金流向或客户关系，大大降低了应用分析结果的难度。手工操作是指用户可以在界面上直接知识图谱的相关操作，例如实体查询、关系扩展、关系推演等。

除此之外，本系统还可以以批量文件的方式向其他系统提供数据服务，通常以夜间批量的方式进行。

2.2.4技术架构图

如上图，总体技术架构分为三层，包括数据ETL层、大数据存储层及大数据服务层。

数据ETL层：数据ETL层将银行业务系统的海量结构化数据（少量非机构化）进行整合，提取出有用的数据并进行清理，以保证数据的正确性。此过程与数据仓库等平台系统的处理方式类似，为后续的数据有效利用打好基础。
大数据存储层：大数据存储层实现对数据的解析和存储，将数据抽象为“实体-关系-事件-属性”，提供面向知识图谱数据的存储与访问。采用混合存储模型结构，用Titan作为图数据库，底层以HBase文件格式。Spark实现通过批量运行模型构建基础网络，GraphX实现对隐性关系的挖掘计算，MySQL实现对关联、社群发现、机器学习等模型的管理，Phoenix提供二级索引，加速复杂即席查询的效率；Tensowflow及MLlib提供分布式的数据挖掘框架，支持预警模型建模及紧密关联关系建模等。
大数据服务层：大数据服务层提供可视化、图形化的图析查询、批量图计算、机器学习等功能，提供交互的Restful API接口，大数据服务层提供对数据相关操作，包括实体查询，实体扩展，事件碰撞，索引查询等。

2.3 关键技术难点

2.3.1平台化设计

在传统业务系统中，数据库服务器、应用服务器、ETL服务器等都是成套存在，系统间互相独立。为保证性能和数据容量，Hadoop平台的基础硬件通常在几十台以上。因此，受硬件成本和开发成本所限，大数据平台的建设通常是以模块化方式进行。以Hadoop和底层硬件为平台，上层采用拼积木的方式，知识图谱项目就属于平台上的模块之一。
平台上的各个模块使用相同的组件或工具，夜间批处理也会在很大程度上占用相同的时间窗口。因此，在初始设计时，要规划好整体框架，制定好开发规范。整体框架能保证各个模块之间在不冲突的情况下有效使用集群资源，开发规范能够有效降低后期运维成本。随着hadoop平台上模块和功能的不断增多，任何一个底层调整对后期开发运维的成本都是巨大的。

2.3.2构建基础网络

ETL的第一步是构建基础网络。前提条件是已经完全搞清楚数据中，那些应该是实体、那些是属性。但是在实际开发过程中，很多是莫能两可的。例如，行内客户A是一个实体，其配偶应该是另一个实体B，A和B是配偶关系。由于各种源系统的原因，源系统中没有该配偶的基本信息，或关键信息缺失。

2.3.3构建业务模型

模型构建无论是在传统领域还是知识图谱领域都属于高阶开发人员的工作内容。在业务模型的开发过程中，主要问题有两个，规则转化和模型效率。
规则转化是指在收集和分析需求的基础上，通过对已有业务数据的了解，将需求中的业务规则转换为符合图数据结构的、可开发的代码逻辑。关键岗位人员需要有较为深厚的业务背景，同时又熟悉数据现状和知识图谱技术。这一步是业务模型开发的基础，决定着模型结果的可用性。
模型效率通常很难被关注，但却很重要。模型运行一般放在日终批中执行，只要能在营业前结束，耗时长短不是模型的关键指标。而数据量、集群性能不同等原因，模型效率很难横向对比。但从运维角度来看，随着模型数量的增加，夜间批处理时间最终将会变成一个头疼的问题。在上线前优化，能够降低优化成本和后期运维成功。从实际项目实施过程来看,模型也确实都可以进一步调优提升效率。建议组织多名开发经验丰富和图算法水平较高的开发人员，进行多次代码检视，优化模型逻辑，进而提升模型运行效率。

第3章 运营成效

通过对我行主要业务系统的数据分析，梳理出10余种近2亿个实体，30余种近3亿条关系。将客户的社会关系、投资关系、担保关系、业务信息、资金交易情况等信息进行了整理和完善，搭建了个人客户和对公客户的关系网络及资金交易网络图。在此基础上，通过贷款担保、资金密切往来、投资控股、法定代表人、实际控制人等关系来识别利益共同体，通过图形化的方式实现多个账户、客户间的资金流转分析，展示指定的多个账户、客户间，符合时间段、金额区间段条件的资金往来情况。我行在信贷业务方面，使用图算法开发的图数据模型，发现了大量的较为明确的可疑数据集。与原系统的分析手段相比，新技术极大的提升了数据分析的深度和广度。