共计 2876 个字符，预计需要花费 8 分钟才能阅读完成。
作者：朱劲松，量化派研发中心系统架构师，主要参与了基础组件开发、API Gateway 等项目，现在致力于公司风控系统相关业务的架构设计和研发。
一、公司简介
量化派（QuantGroup）创办于 2014 年，是数据驱动的科技公司，是国家高新技术企业。量化派以「MOVE THE WORLD WITH DATA, ENLIGHTEN LIFE WITH AI」（数据驱动世界，智能点亮生活）为愿景，利用人工智能、机器学习、大数据技术。为金融、电商、旅游、出行、汽车供应链等多个领域的合作伙伴提供定制化的策略和模型，帮助提升行业效率。量化派已与国内外超过 300 家机构和公司达成深度合作，致力于打造更加有活力的共赢生态，推动经济的可持续发展。
我司从 2017 年年中开始调研 TiDB，并在用户行为数据分析系统中搭建 TiDB 集群进行数据存储，经过一年多的应用和研究，积累了丰富的经验。同时，TiDB 官方推出 2.0 GA 版本，TiDB 愈发成熟，稳定性和查询效率等方面都有很大提升。我们于 2018 年 7 月部署 TiDB 2.0.5 版本，尝试将其应用于风控业务中。风控系统主要是在用户申请放款时，根据风控规则结合模型和用户特征进行实时计算并返回放款结果。
二、业务背景
风控系统中用到的数据主要可以分为两部分：
一类是原始数据，用于分析用户当前的特征指标。
一类是快照数据，用于计算历史指定时间点的特征指标，供模型训练使用。
原始数据主要分为三种：
产生自公司内各个产品线的业务系统数据。
爬虫组提供的用户联系人、运营商、消费记录等数据。
经过处理后的用户特征数据。
由于我们的风控策略中用到了大量的模型，包括神经网络模型，评分模型等，这些模型的训练需要依靠大量的历史订单以及相关的用户特征，为了训练出更多精准、优秀的模型，就需要更多维度的特征，此时特征的准确性就直接影响了模型的训练结果，为此我们在回溯每一个订单的用户在指定时间的特征表现时，就需要用到数据快照。
我们可以通过拉链表的方式来实现数据快照功能，简单说就是在每张表中增加三个字段，分别是 new_id、start_time、end_time，每一次记录的更新都会产生一条新的数据，同时变更原有记录的 end_time，以记录数据的变更历史。
通过上面的介绍可以看到，业务数据和爬虫数据本身数据量就很大，再加上需要产生对应的拉链数据，数据量更是成倍增长。假设每条数据自创建后仅变更一次，那拉链表的数据量就已经是原始表的两倍了，而实际生产环境下数据的变更远不止一次。
通过上述的介绍，我们总结风控系统下的数据存储需求应满足以下几点：
业务数据。
业务数据拉链表。
爬虫数据，如联系人信息、运营商数据，消费记录等。
爬虫数据拉链表。
其他数据，如预处理数据等。
三、当前方案
以前方案主要是采用 HBase 进行数据存储。它的水平扩展很好的解决了数据量大的问题。但是在实际使用中，也存在着比较明显的问题，最明显的就是查询的 API 功能性较弱，只能通过 Key 来获取单条数据，或是通过 Scan API 来批量读取，这无疑在特征回溯时增加了额外的开发成本，无法实现代码复用。
在实时计算场景中，为了降低开发成本，对于业务数据的获取则是通过访问线上系统的 MySQL 从库来进行查询；爬虫数据由于统一存放在 HBase 中，计算时需要将用到的数据全量拉取在内存中再进行计算。
在回溯场景中，针对业务特征回溯，通过查询订单时间之前的数据进行特征计算，这种方式对于已经变更的数据是无能为力的，只能通过 HBase 里的数据快照来实现，但无形增加了很多的开发工作。
3.1 TiDB 为我们打开一片新视野
通过上面的介绍，我们知道要构建一个风控系统的实时数仓环境，需要满足下面几个特性：
高可用，提供健壮、稳定的服务。
支持水平弹性扩展，满足日益增长的数据需求。
性能好，支持高并发。
响应快。
支持标准 SQL，最好是 MySQL 语法和 MySQL 协议，避免回溯时的额外开发。
可以发现，TiDB 完美契合我们的每个需求。经过 TiDB 在用户行为数据分析系统中的长期使用，我们已经积累了一定的经验，在此过程中 TiDB 官方也给予了长期的技术支持，遇到的问题在沟通时也能够及时的反馈，而且还与我司技术人员进行过多次技术交流及线下分享，在此我们深表感谢。伴随着风控系统需求的持续增长，我们对整体架构进行了新一轮的优化，新的数据接入及存储架构如图 1。
<center> 图 1 优化后的架构图 </center>
通过图 1 可以看到，线上业务系统产生的数据统一存放在 MySQL 中，将这些孤立的数据归集在 TiDB 中，能够提供基于 SQL 的查询服务。通过 binlog 的方式直接从 MySQL 实例进行接入，接入后的数据以两种不同的形式分别存放：
一种是去分库分表后的源数据，降低了实时特征计算的实现及维护成本。
另一种是以拉链数据形式存储实现数据快照功能。
经过调研，针对第一种场景，可以通过阿里的 otter 或者 TiDB 周边工具 Syncer 来快速实现，但对于第二个需求都没有现成的成熟解决方案。最终，我们基于阿里的 canal 进行客户端的定制化开发，分别按照不同的需求拼装合并 SQL 并写入到不同的 TiDB 集群中；同时还可以按需将部分表的数据进行组装并发送至 Kafka，用于准实时分析场景。
对于来自爬虫组的数据，我们采用直接消费 Kafka 的方式组装 SQL 写入到 TiDB 即可。
在实际是使用中，通过索引等优化，TiDB 完全可以支持线上实时查询的业务需求；在特征回溯时只需要通过增加查询条件就可以获得指定时间的特征结果，大大降低了开发成本。
3.2 遇到的问题
风控业务中用户特征提取的 SQL 相对都比较复杂，在实际使用中，存在部分 SQL 执行时间比在 MySQL 中耗时高。通过 explain 我们发现，他并没有使用我们创建的索引，而是进行了全表扫描，在进一步分析后还发现 explain 的结果是不确定的。
经过与 TiDB 官方技术人员的沟通，我们进行了删除类似索引、analyze table 等操作，发现问题仍然存在。通过图 2 可以看到完全相同的 SQL 语句，其执行结果的差异性。最后按官方建议，我们采用添加 use index 的方式使其强制走索引，执行时间由 4 分钟变成了 < 1s，暂时解决了业务上的需求。
<center> 图 2 explain 示意图 </center>
同时 TiDB 技术人员也收集相关信息反馈给了研发人员。在整个问题的处理过程中，TiDB 的技术人员给予了高度的配合和及时的反馈，同时也表现出了很强的专业性，大大减少了问题排查的时间，我们非常感谢。
四、展望
目前我们已经搭建两个 TiDB 集群，几十个物理节点，百亿级数据量，受益于 TiDB 的高可用构架，上线以来一直稳定运行。
如上，TiDB 在我们风控业务中的应用才只是开始，部分业务的迁移还有待进一步验证，但是 TiDB 给我们带来的好处不言而喻，为我们在数据存储和数据分析上打开了一片新视野。后续我们会继续加大对 TiDB 的投入，使其更好地服务于在线分析和离线分析等各个场景。我们也希望进一步增加与 PingCAP 团队的交流与合作，进行更深入的应用和研究，为 TiDB 的发展贡献一份力量。
