TiDB 在 360 金融贷款实时风控场景应用

背景

近几年来基于互联网渠道的现金贷业务发展十分迅猛，不管是新兴的互联网企业仍是传统的金融机构，都想在这个领域快速占领市场，攫取客户。然而在线贷款业务与其余互联网业务有着明显的不一样，源自金融的基因决定了重视风险的必要性，这不只关系到产品的收益，也直接影响了产品是否能够成功。

将业务推到线上意味着没法准确的获取客户信息，只能经过有限的渠道验证客户的真实性和偿还能力，极大的增长了风险成本。若是申请步骤过于繁琐则下降了用户体验，不利于产品的推广和客户的使用。所以对于互联网贷款风控的一项挑战就是可以在尽量短的时间内，有限数据的状况下，给出明确的风险判断。

应用

创建风险策略的过程当中，使用各类风险变量以及相关的衍生变量，经过专家模型进行评分，是一种较为典型的方法。实际应用中，咱们发现除了已经被普遍使用的消费行为数据，基本收入数据等，基于特定维度的用户间社交关系也是比较有效的模型变量。

在使用这些变量的过程当中，咱们面临最直接的问题是数据量。若是考虑将用户手机通信录中出现的电话号码做为一项关系关联的形式，假设每位用户通信录中联系人的个数平均为 100 个，那 100 万个注册用户就有对应大约 1 亿个联系人。事实上，在系统上线大约 1 年不到的时间内，咱们几张存储社交关系的表已经达到了大约 50 亿左右的规模。

相对于数据存储，变量的衍生加工和查询匹配是个更加有挑战性的工做。一我的的社交关系是个很典型的「图」数据结构。而不少专家模型中的规则是须要匹配某个用户 3 层以上关系的，最简单的就是匹配用户经过联系人关系，跃进 3 层后，命中系统黑名单的人数。咱们仍是按照平均 100 个联系人来估算，跃进 3 层后，须要匹配的关联人数为 100 100 100，即 100 万。而相似计算量的规则不在少数，须要调用这些计算规则的业务场景也较为频繁，同时对响应时间的要求也高。

V1.0 版本的解决方案

在评估阶段，咱们考虑了几种方案，各有利弊。首先被淘汰的是使用 MySQL 的解决方案。使用关系型数据库的优点是在查询方面的便捷性。在开发效率上，SQL 是开发人员和数据分析人员的必备技能，可以较快的在功能上实现需求。可是在数据存储和计算层面，MySQL 的表现则差强人意。在面对大数据量时，MySQL 能采起的水平扩展策略无非是分库分表，这样的后果就是查询逻辑变的很是复杂，不易维护，且性能降低的较为严重。

另外一个方案是把 HBase 做为数据存储的解决方案。它的优势很明显，能够水平扩展，数据量再也不是瓶颈。可是它的缺点也一样明显，即对开发人员不友好，查询的 API 功能性较差，只能经过 key 来获取单条数据，或是经过 scan API 来批量读取。更关键的是 HBase 对图这样的数据结构支持的很差，只能经过使用 tall table 和存储冗余数据的形式来模拟。

第三个方案是使用纯粹的图数据库。首先咱们考察了开源的 Titan，发现这个项目已经废弃了，主力团队貌似研发了一个新的商业图数据库，并成立了公司。并且 Titan 的存储引擎也是使用了 HBase 和 Cassandra(根据需求二者选一)，性能并不能知足咱们的要求。接着咱们考察了两款开源的商业产品 Neo4j 和 OrientDB。他们二者都提供了免费的社区版本，固然在功能上比商业版少了些。其中 Neo4j 的社区版不支持 HA，只能在单机上运行。而 OrientDB 的数据版支持 HA 和 Sharding。在编程接口上二者都支持各类主流的编程语言。Neo4j 提供了自家首创的，基于模式匹配的查询语言 cypher。OrientDB 则提供了类 SQL 的语法 API，可谓各有所长。

最终上线的方案是混用了 HBase 和 Neo4j 两种存储。HBase 使用了 9 台 32G 内存，16 核的服务器集群，主要负责存储业务对象的基本信息，和第一层的关联信息。Neo4j 则负责图数据结构的存储，使用了单台 256G 内存 2T SSD 的服务器。上线后，相关实时分析接口的 TPS 大约为 300，90% 的相应时间保持在 200ms。部分表的数据量保持在 3000 万 ～ 6 亿的规模，部分核心表大约在 30 亿左右。

V2.0 版本 - 引入 TiDB 和优化

系统上线后整体较为稳定，可是仍然存在一些亟需解决的问题。Neo4j 做为存储图数据的系统，在社区版本的功能上只能支持单节点，没法进行水平扩展，虽然现阶段来看不管是性能上仍是功能上均可以知足业务的需求，可是能够预见在不久的未来就会有瓶颈。而 HBase 的缺点在于数据结构过于简单，没法给 OLAP 的系统和分析人员提供易用的数据接口，只能经过批量的 ETL 来同步数据至数据仓库，实时性较弱。

在和 PingCAP 的技术团队进行交流后，了解到了 TiDB 这个由国人本身研发的分布式数据库。TiDB 中吸引咱们的特色有不少，其中能帮助咱们解决现有问题的主要集中于两点。其一是可以在近似无限的水平扩展的同时保证事务特性。这样不只避免了分库，分表的繁琐，也让海量数据可以以关系模型进行存储变为可能。其次是可以高度兼容 MySQL 协议，不只为开发人员及数据人员都提供了良好的应用接口。基于这些特性，咱们发现线上 OLTP 和 OLAP 的界限已经很是模糊，在某些业务场景已经能够彻底的融为一体。

与 PingCAP 的技术同事沟通后，咱们很快的设计了一套新的技术方案（V2.0）。为了考虑到技术方案迁移的稳定性，咱们先使用 Kafka 做为一条数据旁路，将全部的基础数据在 TiDB 集群中存储一份。同时将 Neo4j 中大约 70 亿个 vertex 和相关 edge 数据迁出，移入 TiDB 中存储。而后咱们基于关系模型的 SQL 接口实现了功能所需的部分图算法，包括最短路径，多节点连通性检查等。虽然在实现过程当中要比使用 Neo4j 工做量多一些，可是在性能上，特别是吞吐量上有很多提高。原先 Neo4j 的事务模型较为笨重，在更新 vertex 时较多，且并发量大的时候很容易形成长时间的事务锁，严重下降系统的吞吐性能。

最终上线时，咱们为 TiDB 部署了 9 台服务器的集群。其中 3 台做为 PD 和 TiDB 的服务器，6 台做为 TiKV 的存储服务器。在运行一段时间后，除了一些业务逻辑上的 bug，表现一直很稳定，从未出过一次问题。并且随着业务量的增大，TPS 指标 也提高至 5000 左右，整个数据库平台的峰值计算能力提高了10 倍左右，可是平台总体的吞吐量和响应时间都没有特别的抖动，一直稳定在可接受范围内。

对于风险分析人员，最大的提高就是就是能够用他们熟悉的 SQL 工具直接链接生产的 TiDB 库进行分析工做。不只实时性大大增长，工做效率获得了质的提高，也省却了部分 ETL 的工做。

Next Step

在对 TiDB 有了实际的认识和应用经验后，咱们计划使用 TiDB 来取代 HBase，存储用户风险模型的相关数据。同时尝试在 TiDB 中慢慢迁入 Neo4j 的数据，最终回到关系模型的架构下，只是咱们手中再也不是日渐老去的 MySQL，而是新一代的分布式数据库 TiDB。

做者：金中浩，360 金融 / 数据智能部 / 部门总监