| 编辑推荐: |
| 本文来自于infoq，本文通过阐述大数据体系规划以及数据采集和配置，介绍了民生银行大数据体系架构设计与演进。 |
|
近年来，随着大数据与人工智能相关技术的迅速发展，新技术逐步在全社会各行各业得到应用。银行业作为一个高度信息化的行业，首当其冲面临着互联网新技术应用的挑战。民生银行在2013年开始布局分布式、大数据及人工智能技术等领域，在全行凤凰计划的牵头下，逐步的将新技术与我行发展战略业务实施策略进行了深度融合，为金融科技银行的发展奠定了扎实的基础。
一、大数据简介
大数据起源于互联网，在2003年左右由Google发布GFS和MapReduce论文为节点拉开了新技术应用的序幕，介绍了一种利用普通PC服务器构建大规模分布式系统，来解决海量数据的存储和计算问题。在此论文基础上发展出来的Hadoop开源体系逐步成为海量数据处理的一种通用技术框架。2008年左右Hadoop技术被广泛的使用在各个互联网企业中，极大的推进Hadoop技术体系的成熟，随着早期Single
Point of Failure问题被解决，在MAP-REDUCE两阶段的计算模式上，诞生了更丰富的Spark、Flink等计算框架。2013年左右批量数据的计算模式逐步成熟，在需求的推动下互联网开始进一步的攻坚实时数据计算领域。同年部分银行开始尝试引入Hadoop大数据技术。民生银行作为银行业第一批，在2013年从互联网引入了大数据专业才人，启动了Hadoop大数据体系化的建设。
新技术的应用首要是解决问题，提高数据使用的效率，降低数据使用成本，最终推动业务数字化、智能化转型。在大数据体系化规划下，以服务用户为目标，以解决问题为抓手逐步推动大数据技术落地。民生银行大数据整体规划如下图：
图1、大数据平台体系规划
在整个规划的指导下，按照不同阶段的主力需求，民生银行大数据建设可以简单分为三个阶段：
第一个阶段是面向客户的在线存储查询阶段：
银行有很多面向客户的数据，数据积累非常快也非常多，以流水数据为例，为了保证系统服务质量，通常是缩短可查询的周期，依托大数据的海量数据存储能力，基于分布式体系构建了历史数据管理平台来满足业务场景中海量数据的存储和查询服务需求。
第二个阶段是离线的批量数据计算及智能数据分析阶段：
在2015年全面启动凤凰计划建设后，各领域系统性的梳理了业务战略和实施策略，配合凤凰计划中数字化战略的落地，业务流程和模式中涌现出大量的批量数据加工计算和结果数据服务的应用场景。在这个阶段根据数据流转周期和服务场景，结合整体的数据管控需求，建立了企业级数据开发模型，逐步推动和完善了全行统一的数据服务中台，先后为数十个业务场景提供数据支持。同时随着数据中台的成熟，原始数据的积累，基于数据的机器学习人工智能分析等场景逐步涌现，为了降低新技术的使用门槛，快速迭代场景下的机器学习算法模型，在这个阶段同步建设了可视化的机器学习平台，对接数据中台，为个性化推荐、风险预警及运营多个领域内的细分场景提供服务能力输出。
第三个阶段是全面推动在线实时数据计算及分析阶段：
随着批量数据体系的成熟，业务场景对实时数据的需求迅速涌现，我行科技启动了全面的实时数据体系建设，对实时风控和实时事件驱动的营销和运营形成了全面的支撑。
通过三个阶段，在支撑业务应用场景发展的同时，目前平台层面已初步完成如下几大平台建设：
1.数据采集分析平台
2.Hadoop数据加工整合平台
3.可视化机器学习平台
4.实时推荐引擎
5.数据开放平台
图2、大数据主要平台视图
在数据采集层通过行为数据平台和外部数据平台，丰富了整个数据体系。通过数据整合平台（DC），打通以用户为中心的全维度的数据视图，为后续的机器学习和人工智能应用提供了可行的数据基础，通过可视化的机器学习平台完成数据与算法的结合，由数据服务层统一管控输出。
目前随着大数据多个平台的建设，为我行多个战略级项目提供了全面的底层数据和模型能力输出，包括支持了凤凰计划项目指南针预警项目、数据化平台型授信决策变革项目、运营风险监控体系项目、新一代零售信贷体系、村镇银行等多个项目的建设。
二、数据采集平台
背景及目标
银行在过去的信息化建设中，更多的注重是交易数据的积累，对用户的使用偏好、浏览点击行为、停留时间等行为层面的数据较少涉及。随着大数据的发展，通过对用户数据的收集，整合，分析，挖掘，能够很好的对用户是谁，用户从哪来，要到哪里去等问题进行定义和解析。在交易数据的基础上，对用户行为数据和外部数据进行补充建设，有了这些数据，首先可以在我行的APP、网站以及ATM等与用户密切相关的场景里，提供更贴心，更优质的服务；其次对公司内部各个金融业务产品用户体验优化等方向上提供用户数据反馈支撑。
行为数据采集及分析
图3、行为数据平台
从行为数据的采集、数据分析整合及数据应用三个方面统筹进行规划和设计，完成了行为数据平台（GD）的建设。数据采集部分作为整个项目的数据来源层，完成对用户产生的原始行为数据的收集和存储。数据分析部分作为GD的中间层，对收集来的用户行为数据进行统计分析，大致可以得到三类数据，一类是反应应用整体运营情况的指标数据，第二类是反应用户行为轨迹、地理位置轨迹等的用户生命周期数据，还有一类是标识每一个微观用户的标签数据。数据应用部分作为GD对外展示和服务层，一方面为实时推荐、精准营销等应用提供数据支持，一方面通过后台管理系统，供应用运营方进行查看。
在数据采集层通过构建采集客户端SDK，嵌入我行统一的移动开发框架Firefly以及前端开发框架Apollo中，结合无码采集的技术能力运用，使得我行所有基于同一框架开发的移动端APP和Web网站天然具备用户行为数据采集和分析的能力。
行为数据平台自2015年上线到现在为止，已经接入了手机银行、直销银行、乐收银及客户化运营等民生银行大部分APP应用，对这些应用中的用户的行为数据进行采集，2017年又增加了对网页端行为数据采集的功能。目前每天采集的数据超过千万条，累积的行为数据已经达到数十亿条，通过大数据分析技术，对采集到的数据进行了报表统计和分析，已得到五类的统计报表数据，包括应用中用户的新增数目、活跃数目、累计数目及用户的设备分布、地域分布、操作系统、留存情况、用户浏览时长统计、点击事件统计及应用的错误统计等，目前进一步的在推动行为数据对营销和风控的实时数据补充。
外部数据采集及分析
图4、外部数据平台
在启动外部数据平台建设之前，我行外部数据由各业务条线独立规划实施，各个技术团队建设了自己业务领域内的外部数据链路及服务，形成了“烟囱”式的数据加工服务模式。随着Hadoop大数据平台的推进，2016年在统一外部数据管理及使用的思想下，启动了外部数据平台的建设，核心定位在于：负责所有外部数据的统一存储、统一加工以及统一的查询服务，要求支持海量的结构化、非结构化外部数据的引入分析能力。
外部数据平台OMDS于2016年9月完成上线，目前已经整合接入包括征信、工商、法院、公安、千里眼、百度、银联、世联评估、行业分析、万德财报等约二十种外部数据的统一管控和服务。
三、配置化的数据加工整合平台
背景及目标
Hadoop数据整合平（DC）在行内大数据体系中承担着承上启下的角色，汇集各渠道的数据到大数据平台，经过统一清洗、加工、治理，进而向上游应用提供服务，从后台走到中台，直接、快速地向应用系统提供数据服务和大数据能力，发挥数据内在的威力。数据的获取并不是目的，如何利用大数据平台技术，实现数据的管理和信息的加工提炼，并对上游系统提供各类数据支支持。针对这些问题和挑战，DC从数据和技术两个方面着手对平台进行构建。
数据层次
图5、DC数据层次
为方便数据的管理、加工和使用，DC将数据进行了分层：近源层和共性加工层，其中近源层为来自于MDS、OMDS、GD和EDW的原始数据，包含行内数据、外部数据、行为数据、分行数据和数仓数据。
近源层数据经过关联、汇总和分析之后，针对上游应用的需求，进行数据共性加工，包括流水加工、应用统计、指标加工、标签计算、风险领域和运营领域。
通过OpenFile（批量文件服务）实现数据的订阅管理，提供了近源层、共性加工层等数据的查看、订阅功能。
技术架构
基于上述数据架构及应用需求，DC从数据处理、任务调度、数据管理和开发辅助四块进行平台的建设，技术架构如下图：
图6、DC技术架构图
1、 数据处理体系
数据的存储、计算和分析为基于Hadoop生态体系，包括Hadoop、Spark、Inceptor、HBase等分布式计算及存储框架，来完成数据的存储、计算、分析整个生命周期。
数据处理自下到上包含数据获取RouterIn、数据清洗(DataClean)、共性加工(SparkSql/Inceptor
Sql)和批量数据访问服务OpenFile。
通过Router实现不同数据平台间的数据交互，屏蔽平台间的差异，配置化开发，提升了开发效率，降低了人为失误导致的问题，实现了数据的快速接入和分发。
基于Inceptor和SparkSql设计开发了数据共性加工模块DcCore和Dispose，实现了数据的快速加工，并支持模板式的配置开发，有效提升了共性加工的开发效率。
2、 任务调度体系
为实现调度批次轻量化，精细化数据依赖，避免批次等待，通过任务组织模块化，来实现作业调度的导出与上线。
系统间的调度通过CPS，实现批量作业执行，系统内部调度通过moia联动，可支持更小粒度的作业调度，实现了作业调试的效率和灵活。
3、 开发辅助体系
开发人员需要对数据处理及任务调度单独开发一系列的代码和配置文件，人为操作不仅效率低，而且易出错。通过辅助开发工具，可根据每个模块的规范，自动生成代码及配置文件，并提供可视化界面，提升开发效率，降低成本和风险。
支持的功能分为自动化创建、自动化校验、调度管理、模型管理和元数据管理。
4、 数据管理体系
数据管理体系建设目的是为了降低运维成本，对源数据、加工数据、数据质量、作业运行进行统计分析，分析结果通过Web页面展示以方便对系统及数据的查看管理，并对于重要信息进行监控告警，其核心模块包括信息采集模块、数据质量管理、系统运行分析和监控告警。
DC的构建在民生银行中起到承上启下的作用，汇集了各渠道的数据，经过统一清洗、关联整合，并对数据进行深层的分析挖掘，进而向上游应用提供服务，从后台走到中台，直接、快速地向应用系统提供数据服务和大数据能力，发挥数据内在的威力。目前DC系统管理了近源数据5000余项、共性加工数据800余项，为包括风险领域、运营领域、移动互联领域等8个领域，20余个系统，50余个场景提供数据或计算支持。
四、在线机器学习平台
背景及目标
目前的机器学习技术，尤其是智能算法，具有很高的技术门槛，需要顶级专业团队的持续投入，每个项目单独去关注技术的变化并落地代价太高。模型研发实践亟需一个统一的机器学习平台，用以规范模型开发流程，封装和简化各类算法的使用，支持多种多样的数据预加工，提供和管理模型预测服务。最终满足数据分析师、业务专家、软件开发等不同角色的不同层次的模型研发实践诉求。
机器学习平台建设旨在：
1.基于Hadoop技术栈的平台型环境，提供业内最新的模型算法；
2.基于Hadoop技术栈的分布式环境，支持超大规模的模型场景；
3.为一般模型研究人员提供便捷的基于算子和工作流的图形环境；
4.为高阶模型研究人员提供全面的基于编程的模型开发管理环境。
机器学习平台要能够适配各种已有的数据源，如传统关系型数据库，TeraData数据仓库等，提供数据的各种可视化探索及建模挖掘；并能对数据和模型基于角色进行完善的权限管理；对于研究人员精心挑选调试而来的模型，平台能够将其一键部署为在线服务，将经验数据及时转化为对未来的精准预测能力。
图7、机器学习平台功能架构图
建设现状
项目一期中建设了机器学习平台系统核心模块，覆盖了模型研发的主要流程，主要分为调研平台和预估服务两大子模块。海量样本学习、高维特征分析处理和自动特征组合能力是其最大亮点，示意图如下：
图8、机器学习平台系统基本示意图
整个平台主要通过网站交互式功能为用户提供服务。模型生命周期内的几个大的阶段都已经封装成算子的功能模块，模型的研发过程就是在一块“画布”上，通过拖拽算子，串联模型研发的各个阶段，绘制创意蓝图。如下图所示：
图9、拖拽算子进行模型研发
对于训练好的模型，平台支持一键发布为在线预测服务。从研发到服务，不再需要庞杂的代码与流程。只要对学习模型有概念，对于领域问题有好的创意。就能在拖拽之间，点选之后获得一个高性能的，高可用的预测服务。就能实现业务决策的更加精确化、智能化。
典型案例
平台目前对接了以下几方面的应用：
运营风险监控之可疑境外取现
运营风险监控之可疑境外取现场景，通过机器学习方法分析已掌握的可疑取现行为特征，自动发现其中模式，从而更全面、更及时地发掘可疑取现账号。经过头脑风暴，我们抽取了销卡/重开/换卡次数、开户机构、交易地域/时段/频率/金额、资金流入流出渠道/时间差、客户基本信息等特征，精确率从~65%提升到了~90%，缓解了人工复核阶段的开销。
零售风险申请反欺诈评分实验
零售风险管理之申请/反欺诈评分实验探索--结合信用风险和反欺诈两方面，建立统一的小微反欺诈评分模型。期望通过机器学习平台系统的新机器学习算法和高维特征处理能力使我行小微申请反欺诈评分模型的效果有比较明显的提升和优化，提高对信用风险和欺诈风险的识别能力。通过对数TB的征信、工商、设备和客户基本信息加以聚合分析，抽取了近千个特征字段，特征自动组合阶段又发现了数十个高效特征，再结合平台内置算法模型的
AUC 达到了0.9，KS值提升20%。
五、智能化实时推荐引擎平台
背景及目标
实时推荐引擎是我行大数据体系中面向应用场景建立的应用层面的通用智能引擎，该引擎将大数据基础平台的多种底层数据产出系统，包括标签系统、机器学习平台、大数据平台及实时数据平台，通过应用场景链接起来，构建了具备实时推荐能力的数据服务层。实时推荐引擎的核心是实时数据处理体系以及机器学习推荐模型。实时推荐引擎的建设，为精细化的客群经营、个性化客户服务提供了千人千面的支持，成为大数据能力落地、转化为效益的重要环节。实时推荐建设的目标包括：
1.构建在线推荐系统，建设提供各场景的实时推荐服务的基础能力；
2.打通用户实时点击行为链路，将实时数据结合到在线推荐服务中；
3.打通机器学习平台模型推荐结果，将模型结果数据融合到在线推荐服务中；
抽象用户、产品数据模式，建设推荐层面规则引擎，支持业务策略灵活配置，并支持融合在线实时行为推荐结果以及机器学习批量模型结果等数据。
系统架构
从技术上实时推荐引擎分为数据加工体系和数据服务体系两部分，通过Redis层来将两部分链接起来。
数据加工上涉及到后端多平台上的数据加工，在通用类数据加工上，包括了通过数仓平台建立的集市层数据加工以及DC平台完成的行为和外部数据标签加工。这部分加工的数据作为客户的属性数据，灌入到Redis中供引擎层快速查询和过滤使用。同样在后端数据加工上，还涉及到算法层面的数据加工，通过机器学习平台完成客户购买预测，将基于批量持有信息的计算结果，通过T-1每日批量的模式推入Reids作为推荐结果集的数据来源之一。对于用户实时点击的数据，通过GD的行为数据采集，推送到实时数据处理平台上，通过流式作业计算在线实时的相关性矩阵，将用户的实时行为通过协同过滤算法体现到推荐结果中去。对于服务层，着重建设了核心的引擎（包括算法引擎和规则引擎），用户访问将触发引擎访问Redis对应模块的数据，通过业务策略以及在线的算法对各推荐结果备选集进行筛选和排序，最终给出最适合的结果。
图10、实时推荐引擎
典型案例
手机银行理财产品推荐
当前手机银行上推荐的理财是基于客户资产、持仓以及在售理财产品信息，按照相应推荐规则计算得到，使用的数据维度少，灵活性较差。因此为了进一步为了提升客户体验，在手机银行上实现个性化的理财推荐服务。
财富圈资讯推荐
以万德的新闻资讯数据为基础，依据客户在我行的产品购买，交易行为以及上线之后的浏览行为等信息，推荐符合客户投资、阅读偏好的新闻资讯，并且在推荐过程中对新闻的价值作出简要判断，以对客户形成简要的投资支持。
六、数据开放平台
背景及目标
如何实现大数据价值转化是其中非常重要的课题，从当前数据应用的趋势来看，一是越来越看重数据的时效性，从数据分析到数据提供，都要求从离线走向在线；二是注重场景化，要求数据能够灵活和快速地适配各类应用场景。为适应这样的趋势，大数据的服务层就必须设计相应的机制。场景化数据开放平台从大数据服务的顶层设计出发，为统一服务出口，增强数据输出规范，对外使用上提供统一的API服务网关，提供服务流量的汇聚点，为数据服务模型服务的共享和迭代提供可能。
在数据开放平台中，API是数据基础。在各类数据规范的指引下，对数据进行分门别类，维度切分后，以在线API的方式提供包括数据接入、数据供给等各类服务，供各应用场景实时、组合式调用。通过统一的开放网关实现服务接入、发布、鉴权、访问、统计和监控，实现数据安全与管控。
功能架构
数据开放平台整体上包含管理网站和网关系统两部分。管理网站负责API的接入、发布、维护、监控，访问统计数据的展示和API的访问申请审批。网关系统是访问API请求的统一出入口，负责请求的鉴权、访问控制、流量控制、统计监控等功能。
图11、功能架构图
技术架构
管理网站将API数据、鉴权数据和访问控制配置信息等持久化到MySQL数据库，同时将这些数据和配置信息通过Zookeeper服务同步到网关系统。为了实现对请求的灵活管控，网关系统针对黑名单、身份验证、权限校验、流量控制等功能采用插件化开发，且每个插件均能动态开关。每个请求的处理日志信息通过异步方式发送到事件队列，并由单独的日志收集进程进行收集，大数据实时计算平台对收集的日志进行分析处理将访问统计数据存储到数据库供用户查看。
图12、技术架构图
建设现状
数据开放平台上的API服务分为客户行为类、客户资产类、行外数据类、基础服务类等，其中基础服务类中已经接入了实时数据接收API，该API用于接收各个系统实时数据供后续实时计算任务消费。已经开发完成客户行为类API共16个、客户资产类API共6个、行外数据类API共13个，OpenAPI平台属于初步完成建设，后续会有更丰富的数据服务API通过数据开放平台对外服务。
总结
民生银行大数据建设之路是一个配合业务场景需求反复迭代前进的一个线路，发展到今天，从多个不同的平台、模块逐步的形成了几大体系：数据采集体系、数据服务体系、批量数据分析体系、实时数据分析体系以及智能数据分析体系。对于数据服务体系，主体是整体规划中提到的数据中台演化而来，是数据业务化输出的重要承载体。数据服务体系形成统一的数据服务目录，由开放平台层面的网关统一进行把控，通过场景化数据服务中台对数据和模型应用进行服务化，为对数字化、场景化的业务转型提供了坚实的底层支撑能力。 |
