大数据技术在民生贷款系统运维的应用实践

随着大数据乃至人工智能技术的不断演进，其在各领域的应用也越来越广泛，未来或演变为一项基础能力及服务。但归根结底，技术是为解决问题服务的，如何结合运维领域特点，充分发掘大数据技术的优势及潜力，解决运维问题，是摆在运维人面前的挑战。本文试图在这方面进行一点粗浅的尝试，希望能够起到抛砖引玉的效果。

张新亮

毕业于清华大学电子工程系，之后在IBM公司从事SAP系统实施，2011年加入民生银行，先后参与民生银行新核心系统建设项目，以及新一代零售信贷体系建设。目前负责零售资产类相关系统的运维工作，对大数据，人工智能在运维及风控领域的应用有浓厚兴趣。

一

问题背景

贷款的交易栈

一笔借据在从发放到结清的整个生命周期中，前后交易具有很强的关联性，如果之前的交易造成贷款数据模型中含有错误，那么后面的交易再基于这些数据进行，就会错上加错，待发现问题时再修复数据，需要将后面的交易冲回，直到回到问题发生前的状态。

所以一笔贷款的贷后交易记录可以看做是一个栈，栈底是贷款发放交易，之后贷款生命周期中的所有交易都以此交易为前提，并且按照发生的时间顺序依次入栈，冲销交易可以类比为出栈，需要从位于栈顶的最近一笔交易开始，依次向前倒序进行。

贷款的复杂性

贷款数据模型可以说是银行业务领域中最复杂的模型之一，以一笔借据为核心，星形向外扩展关联到不同的业务领域，包括客户，账户，额度，押品，档案，账务等。贷款自身又有主数据，金融条件，现金流等多个子领域，一条典型的贷款数据需要上百个字段来描述。

其次，贷款交易链条较长，一笔典型的还款交易包含七或九个步骤，横跨七个系统。

再次，贷款账务处理较复杂，尤其是涉及一些特殊交易时，例如资产证券化，不良资产转让等。

分布式架构带来的运维困境

分布式架构的优势自不必说，但从运维角度看，分布式带来的更多是挑战，这个话题的展开讨论不在本文进行。

本文仅以数据管理层面举例看，分布式架构下，数据分散在多个库中，给后台运维带来挑战。

一是从管理单个库扩大到管理多个库。

二是查询数据时需要先定位数据位置，加之可能涉及跨库联合查询或者查询结果合并，传统手段不仅效率低，遇到复杂查询还可能会对生产库带来不必要的压力，影响生产运行。

解决办法之一是将常用的运维需求工具化，形成专用的运维模块，在数据访问层采用与业务应用相同的方案，但涉及大批量数据的复杂查询依然存在风险。

办法之二是采用大数据技术手段，要么基于每日日终抽取到下游的全量数据，要么采用旁路实时数据处理技术，实现运维功能。指导原则是将运维场景与生产库解耦，同时能够充分发挥大数据技术的优势，应对海量数据及复杂查询。

二

应用场景

架构图

批扣结果检查及衍生场景

批量扣款是贷款系统中最重要的批处理作业，在每笔贷款扣款日当天，客户还款户余额充足的情况下，系统会帮助客户进行自动还款，无需客户干预。

由于是后台批量作业，每天至少会处理十几万借据，高峰日处理量接近百万，在一个批处理任务中完成如此大量的账务操作是一件高风险的事情，又涉及到客户账户扣款的敏感操作，要慎之又慎。

首先保证每笔贷款的试算金额是精确无误的，需要代码逻辑完全按照业务需求实现，没有缺陷。

其次是在筛选当日的待扣数据环节，要做到不漏不重，避免发生遗漏扣款和重复扣款的情况。

再次是扣款完成后的入账环节，通过高质量代码来保证不出现差错。

为使整个扣款作业结果更加一目了然，提前发现可能出现的重扣，漏扣等影响客户账务的问题，设计了批扣结果检查功能。

它基于前一天日终后贷款系统的数据，由大数据平台按照业务逻辑加工出当天需要进行自动扣款的待扣款借据数据，当日日终结束后，与实际扣款结果进行比较，可以得到以下数据：

1）足额扣款数据

2）不足额扣款数据

3）漏扣数据及原因

4）按产品及渠道的扣款统计数据

5）各指标的变化趋势

首先关注的是漏扣数据，如果存在漏扣则必须由运维人员介入确认原因。其次，统计指标应当是随时间有规律地变化，如果发生了异常突变则需要关注。再次，可以通过提醒客户日初未足额还款，降低客户非主动逾期率，改善客户体验。

每日代扣结果显示

贷款实时业务情况

目前我行运维监控体系日益完善，在系统不同层面从基础环境到应用探活，乃至服务调用均有对应的监控手段，本功能意在监控版图上添加独特的板块：业务场景监控。

实现上主要采用了基于应用日志的实时流计算技术，在应用端使用代理实时采集应用日志，发送至Kafka队列，供运行在实时计算集群上的流处理程序消费后，解析出所需要的业务字段并持久化存储，同时，通过全局唯一的23位流水号将不同系统属于同一交易的应用日志收集到一起，组装成交易链条，供问题分析用。

前台应用读取结构化的业务数据，并按照业务场景予以展现，新交易做到秒级延时体现，支持交易场景下按照不同维度进行统计，例如按机构，按渠道，按产品的放款笔数，放款金额等。

本功能的意义在于，一是丰富现有的系统监控维度，增加了业务场景维度，为异常分析及评估业务影响范围提供了基础，二是使运维人员更加全方位了解系统，深入到业务场景层面，是进一步提高系统运维水平的前提。

业务场景可视化

贷款数据质量巡检

应用异常，代码缺陷等通常会带来有问题的业务数据，如果不加以干预，会一直潜伏在系统中，直到后续客户发起交易时报错，或者更坏的情况是后续交易不报错，但错误一直累积到某一时刻集中爆发，会给运维人员处理带来很大的压力，同时也严重影响客户体验。

贷款系统由于数据模型以及业务场景的复杂性，此类问题表现尤为明显，造成了大量的修改单和业务人员不停的抱怨。为了先于客户发现系统潜在的问题，将可能的投诉降至最低，数据质量巡检功能应运而生。

每日日终数据抽取至下游大数据平台后，运行预先定义好的数据质量巡检作业，检查数据的一致性以及完整性，将检查出来需要后续关注的数据明细存储在HBase中供查询。

目前已实现四大类20个明细检查指标，包括贷款执行利率是否一致，贷款结清后尚有应还项等，还在根据生产实际情况不断丰富中。由于此类检查都涉及复杂的数据查询SQL和加工处理，根本无法在生产库上执行，当前方案是相对较优的选择。

上线后，通过该功能主动发现缺陷四个，已完成修复及数据清理，避免出现客户投诉及问题扩大化。

交易场景检查指标

征信报送数据预估

如今征信对每个公民的重要性不言而喻，银行负担着向人行如实准确地报送每笔贷款征信情况的责任，需要做到对客户负责。贷款系统不是征信报送的直接责任系统，但从贷款系统可以预估出数据量，和实际征信报送量进行印证，防止大规模数据差错对我行造成的不利影响。

三

展示及通知

上述功能点涉及的通知及告警需求统一纳入零售资产板块的异常处理框架，该框架负责处理批量作业以及异步处理中遇到的，业务人员或前台操作人员没有感知的异常。由运维主导设计，落地在iLoan及RCS系统。

通知告警作为框架的一部分，整合了不同种类不同方式的通知渠道，包括泰岳系统，邮件以及业务待办任务等，上述功能按照需要调用即可，实现问题从发现，通知到处理的完整流程。

在文章的末尾，要特别感谢一直以来紧密合作的开发人员，包括陈深龙的贷款团队，罗京的DC团队和王开煊的ROD团队，他们对安全生产的重要性有深刻认识，除了本文涉及的运维功能，还有其他非功能性需求，很多都是在开发预算紧张，进度冲突的情况下优先实现的，充分体现了民生科技开发人员的安全生产意识和对民生，对客户，对工作认真负责的态度。