某银行大数据平台架构设计及应用 | 最佳实践

Posted 2021-04-11 twt企业IT社区

【摘要】 某农信社的新目标是 通过提升农信系统大数据应用能力，促进数据应用与具体业务场景相结合，全面推动行内大数据工作平台化、链条化运营。 本文介绍了该行如何借鉴国内外同业的先进经验，同时结合行内实际业务需求，采用大数据平台和配套产品，进行混搭大数据技术架构设计及平台落地。

【作者】社区ID kappyy，目前在省农信社负责大数据平台架构和运维工作，对大数据平台这块具有丰富的实践经验。

---

1、背景

银行业是一个数据密集型行业，也是一个数据驱动的行业，数据一直是银行信息化发展的主题词。而今，在互联网金融时代，伴随着商业银行经营转型的持续深入，各家银行对大数据应用的需求日益多元化，迫切希望借助大数据应用，践行以金融科技赋能业务创新及服务体验升级。建设银行、招商银行、平安银行等，在360客户视图、精准营销、实时风控、产品创新等应用场景，通过借助大数据手段成功实现在客户体验、运营管理和产品服务等方面的数字化创新转型。农信社作为农村金融、普惠金融、民生金融的主力军，始终贯彻落实“创新驱动、科技引领”发展战略，不断加强在小微企业金融、个人金融等方面的大数据应用探索，旨在促进产品创新和服务升级，为用户提供更加安全、便捷、实惠的金融服务。因此，通过提升农信系统大数据应用能力，促进数据应用与具体业务场景相结合，全面推动行内大数据工作平台化、链条化运营是我们的新目标。

借鉴国内外同业的先进经验，同时结合行内实际业务需求，采用某大数据平台和配套产品，进行混搭大数据技术架构设计及平台落地。充分发挥大数据技术的特点与优势，提升农信社大数据服务能力，助力业务推广应用。我们的总体目标是建立起符合农信社特色的大数据应用体系，利用特有的大数据能力，挖掘数据的潜在价值，以提供更统一、更高效、更完整、更灵活的大数据服务，逐步由支撑业务到引领业务迈进，最终实现数据驱动业务的转型升级。

2、需求分析

在大数据时代，银行从以交易为中心转向以数据为中心，以应对更多维、更大量、更实时的数据和互联网业务的挑战。大数据平台从多方面解决现在行内存在的问题，具体如下。

2.1   历史数据查询

提供全行结构化的交易明细类数据的历史数据归档保存，支持全量数据归档、增量数据归档，支持指定频率周期性归档，支持大文件归档与小文件归档、提供半结构化和非结构化日志文件的归档。实时查询用户的历史交易明细，能够将查询范围从1年提升到7年以上；能够实现百TB级历史数据表的毫秒级查询。

2.2   数据应用服务体系

优化数据存储，提升数据计算能力，实现数据服务的可视化、可配置、可扩展，完成数据前中后台的解耦，通过对行内海量数据及外部数据进行统一管理，分析加工，提供数据的应用及服务，并对数据应用进行业务场景封装，提升业务数据应用能力。

2.3   客户画像标签体系

客户画像，即客户信息标签化，通过收集客户社会属性、消费习惯、偏好特征等各个维度的数据，对客户特征属性进行剖析，完美地抽象出一个客户在银行的信息全貌，为银行进一步精准、快速地分析用客户行为习惯、金融消费习惯等重要信息，提供快速、精准地识别定位客户功能，从而提升客户服务能力，完成对客户的全方位标签刻画，为客户管理、实时风控、反欺诈、精准营销、风险预警奠定基础。

2.4   外部数据管理能力

实现全行级爬虫体系架构，定时爬取行外有价值数据，引入大数据平台，为展示、分析、挖掘等其他应用提供基础，并在后期丰富爬虫能力。统一管理外联前置接口和数据，设置数据的有效期，通过对外部数据的统一管理，避免重复请求外部数据，减少资源消耗。

2.5   数据挖掘模型建设

结合同业大数据场景应用及供应商模型积累、场景应用优势，充分理解并利用大数据、机器算法、人工智能等技术，利用挖掘工作平台进行数据挖掘模型、应用场景的建设，通过对行内实时和非实时的数据分析及挖掘，完成“客户流失预警模型、贷款违约概率预测模型”2个模型的建设及应用。并同步对数据挖掘工作平台进行功能优化及算法丰富，实现大数据在营销管理、风险管理等方面的支撑。

3、技术难点及应对措施

3.1   Hbase多实例

为Hbase多实例的管理存在难点。通过配置不同的hbase客户端的配置文件，调度代码从相应位置获取并加载配置文件，从而解决多实例管理问题。

3.2   安全模式重启认证

客户端在安全模式下，需要24小时后定时重启一次客户端。采用crontab自动执行定时shell脚本的方式去定时重启jar包，解决了定时重启的问题，保证项目能自动化部署并实现高可用。

3.3   API接口

数据服务平台DASP与该大数据平台各组件API对接困难。该大数据平台目前提供API对接方式，但是缺乏对接经验，官方文档不足，调试接口不稳定。目前，DASP应用服务平台系统暴露RESTFUL接口，解决跨平台使用，实现了项目解耦、扩展性、易用性、安全等问题。

3.4  多组件开发

大数据平台组件较多，包括Loader，Hdfs，Hive，Hbase，Kylin，Es，Redis等，各组件的安全认证、数据传输和联通测试流程的稳定性与安全性需要反复验证。

3.5  数据服务能力

以往，数据服务是通过定义数据服务接口的方式加以实现。随着数据应用服务需求的不断增加，数据接口难管理问题日益凸显。本次数据应用服务平台，主要通过定义DSL，对不同技术语言进行SQL的转化，从而真正实现SQL on Hadoop的数据服务能力，提高平台适用性。

3.6  系统健壮性

大数据管理平台，以微服务的方式进行系统架构开发和部署，不同的功能由不同的服务程序支撑。各服务可集中部署于一台服务器，也可分别部署于多台服务器，服务之间通过http方式进行信息交互，敏感数据以密文传输。服务之间完全解耦，单一服务支撑的功能不受其他服务的功能性故障影响。

由于微服务方式架构，避免了所有功能部署于统一的web中间件，从而规避了由中间件灾难引发的单点灾难，系统健壮性得到提升。

3.7  模型选择

在数据挖掘模型建设前期，花费较多时间调研农信的业务普及性、数据完整性等现状，在建设过程中，根据实际情况采用不同算法模型进行试验比较、反复参数调优等，均较为耗时。

4、技术原理

1、数据采集

利用大数据平台自带的数据采集组件Flume、Kafka、Sqoop， 同时结合第三方采集工具，如CDC、OGG、FTP，兼容各种数据源，包括流式数据（业务消息流/日志消息流等），磁盘文件，各种数据库，其他存储系统等。采集后的数据落地到大数据平台分布式存储中，其中流式数据也可不落地直接进入实时处理应用中。

2、分布式存储

利用大数据平台HBase组件和HDFS组件的特性，为海量数据提供存储，支持部署在价格相对便宜的x86服务上，理论上支持无限拓展，线性扩展能力强，数据存储灵活。

3、资源调度

多租户是大数据平台大数据集群中的多个资源集合，具有分配和调度资源的能力。资源包括计算资源和存储资源。多租户将大数据集群的资源隔离成一个个资源集合，彼此互不干扰，用户通过“租用”需要的资源集合，来运行应用和作业，并存放数据。在大数据集群上可以存在多个资源集合来支持多个用户的不同需求。

4、实时处理

大数据平台内存数据库Redis、分布式消息队列Kafka和实时处理引擎Flink，实现实时数据传输、实时数据缓存和实时数据流处理的高速处理过程。

5、离线处理

Spark和ELK为海量结构化数据和非结构化数据的离线分析处理提供技术支撑。

6、数据挖掘

预置机器学习算法库和数据分析挖掘算法，提供可视化分析挖掘平台，提高数据挖掘效率和能力。

7、数据服务

整合大数据平台各组件接口，对外提供实时数据和离线数据服务，提高大数据平台接口安全性的同时，也减少了后续接口改造工作量。

5、架构设计

5.1 大数据基础平台

大数据基础平台分为四个子系统：数据采集层、存储分析层、数据服务层、运维管理功能。

5.1.1  数据采集层

采集层是大数据平台数据输入的唯一来源，负责数据入口与管理的子系统，提供实时采集和批量采集功能。兼容各种数据源，包括流式数据（业务消息流/日志消息流等），磁盘文件，各种数据库，其他存储系统等。提供统一的数据集成平台，对各种数据源、各种数据采集方式、各种数据采集通道的统一管理、执行和监控。

5.1.2  存储分析层

1、存储层

存储层是大数据平台数据采集及数据交互后的数据存储区域。大数据平台中数据贴源存储，保留数据原始细节，同时对数据进行轻度汇总，数据模型灵活。支持结构化数据、半结构化数据和非结构化数据存储，同时根据不同的数据类型及不同的业务需求，在文件系统里规划了不同的存储目录供不同计算引擎调用访问。

2、分析层

支持实时分析挖掘和离线分析挖掘。提供大数据平台批处理计算能力和基于内存的分布式计算框架，提供一站式数据分析能力，包括小批量流式处理、离线批处理、SQL查询、数据挖掘等，用户可以在同一个应用中无缝结合使用这些能力。提供类SQL语言操作结构化数据，对大数据平台存储的海量数据进行查询和分析。

5.1.3  数据服务层

服务层是大数据平台对外提供数据应用支撑的唯一通道，主要提供批量数据服务和实时数据服务。整合大数据平台各组件接口，将其分成两类：实时接口和离线接口，同时对各组件接口的参数进行归纳整理，制定出统一的对外参数规范。通过在服务信息表配置如接口类型、调用方式、对应组件名称及接口分类等信息，实现各组件接口和对外服务接口的一一对应关系。

服务层定义了大数据平台对外提供的服务类型、数量及调用方式。服务层使得大数据平台各组件接口对外部系统不可见，提高大数据平台的安全性和易用性。

5.1.4  运维管理功能

运维管理功能模块为部署在集群内的服务提供统一的集群管理能力。

• 支持大规模集群的安装部署、性能监控、告警、用户管理、权限管理、审计、服务管理、健康检查、日志采集、升级和补丁等功能。

• 提供重要组件的操作管理功能，为各个重要组件定制满足其关键特性的可视化操作功能。

• 提供系统所有组件从安装、运行到归档的日志全生命周期管理功能。

5.2  大数据应用服务平台

大数据应用服务平台（DASP）以大数据平台为基准构建数据的应用服务，平台封装各个大数据平台组件，形成应用组件，最后使用平台路由组装成数据场景服务应用。平台对接分为三部分：

• 大数据平台：各个组件应用封装，使用接口方式进行调用。

• DASP上游主要为数据接入来出来，针对的系统现阶段分为ODS数仓（FTP/SFTP文件）、外联前置、实时的流数据、第三方应用系统关系库等。

• DASP下游为平台所提供的数据服务提供应用分为：应用接口的直接使用接口或文件的方式提供对外服务。

DASP产品主要包含了：数据管理功能平台、数据服务业务组件、数据服务中间件、数据接口与连接组件。数据服务体系架构具体如下图所示：

1、从数据采集到数据计算，主要使用了某厂商大数据平台的功能组件。通过数据采集组件将数据通过离线和实时的方式，传输到大数据平台的HDFS中进行数据持久化操作。其中重要的组件如下：

• OGG数据同步组件：主要是通过实时批量的方式，将数据从Oracle同步到数据仓库的GBase中。

• ETL数据抽取组件：包括了传统的ETL作业、FTP脚本、Sqoop组件和Load组件，可以实现数据的跨库离线传输。数据链路为：业务系统到数据仓库，再到大数据平台HDFS的过程。

• Flume和Kafka组件：主要实现流式数据的抽取，其中包括了系统日志和数据库操作日志的采集传输。

2、数据在进入大数据平台内部生态组件后，可实现离线、近线和实时的计算要求。具体采用的组件有MR（MapReduce）组件、Hive组件、Spark组件、Spark SQL组件和Flink组件。在传统的大数据加工组件中，通常我们用Hive和Spark SQL组件通过开发数据作业方式完成数据的加工计算。本次项目通过DASP数据工厂，完成数据的可视化加工和Mapping代码自动生成工具，实现数据的离线加工计算过程。

3、数据通过DASP数据加工后，形成多维线性表存储在HDFS中，由于Hive和Spark SQL组件的应用响应时间的局限性，无法像传统数据库一样，直接开始事务的操作。因此我们需要针对不同的应用场景进行大数据生态技术组件选型。在此，我们选择了mysql/Oracle、Kylin、HBase、Redis和ElasticSearch组件作为满足数据应用服务的技术组件。具体如下：

• MySQL/Oracle，主要实现大数据平台中的元数据的管理与维护，并且作为DASP的主要应用数据库，保存平台的操作功能数据。

• Kylin，为Apache顶级子项目国产开源软件。通过该组件，能够实现数据源为Hive、Spark和Kafka的数据对接，将结构化的数据创建成数据立方体的格式，保存在HBase中。同时，提供ODBC、JDBC和RESTful的数据连接与操作，并且能够实现亚秒级的数据响应请求。

• HBase，主要提供海量数据的查询应用需求。该No-SQL数据库为数据应用服务的主要数据库，不仅保留Kylin创建的数据立方体数据，也保存了与Hive和Spark计算生成的数据表。能够之前通过前端Java进行数据访问。

• Redis，用以保存需要快速响应业务需求和计算的应用需求。例如：客户的动态标签计算和某些场景的实时性计算要求。最常见的应用是将部分数据从HBase的全量数据结构中，抽取部分的截面数据保存在Redis中，予以满足数据的快速响应计算请求。

• ElasticSearch，该组件主要实现了多条件的数据检索查询应用需求。例如：历史数据的灵活查询应用需求内容。

4、数据服务中间件，主要为某厂商提供的数据服务中间件技术套件予以实现。其中包括了：DSL SQL解析、规则路由、决策引擎、计算引擎和数据缓存（或是：模型缓存）。具体如下所示：

• DSL SQL解析，主要是将多语言的数据操作转换为表顺的SQL操作语句，予以实现对数据服务技术组件的SQL操作。其过程包括了：主题、逻辑Query、物理Query、Query拆分、SQL执行和结果合并六个步骤。

• 路由规则，则是将解析完的标准SQL发送到制定的数据服务技术组件中进行运算。由此，数据服务所使用的技术组件和数据库，都需要在规则路由中进行注册。通过元数据的管理模式，定位到相应的组件，实现内部跨组件数据应用操作。

• 决策引擎，主要是将业务规则或者业务流程，通过可视化的功能界面进行在线配置，生成逻辑计算规则，并进行发布的功能组件。其本质是将业务逻辑配置生成规则代码。

• 计算引擎，主要是将决策引擎生成的代码通过数据服务技术组件，具体实现程序操作的过程组件。

• 数据缓存，主要实现数据操作后的结果进行保留，以便能够重复利用的中间技术组件。

通过以上的中间件技术组件，实现数据服务业务中间的数据组装需求。常用业务数据服务有：历史数据灵活查询视图、客户画像数据服务、个性化营销推荐和风险监测与反欺诈，以及个性化定制的数据视图等。每一个数据服务业务组件在DASP中以项目的方式进行挂载，因此只要在机器性能满足的条件下，该机制保证了数据服务的具备横向、灵活的支撑各类数据应用需求。

6、经验教训

大数据平台的建设过程中分享的经验如下：

1、使用微服务架构可有效实现系统横向扩展、快速解耦、抗单点故障等能力，符合分布式、高可用、高效率的技术潮流。

2、使用Oauth2.0技术实现单点登录有利于在多子系统架构模式下各系统在人机交互时快速长效（token生命周期内）无缝对接，无需统一用户权限体系，减少冗余垃圾数据，便捷子系统间分合。

3、建设一套管理系统对开源组件、第三方系统进行统一的管控和应用封装，有利于聚焦业务场景，在“业务保障”的约束下实现统一的资源调度、行为规范、风险规避、合成增效。

4、以大数据平台为核心，增加数据可视化、数据权限管控、异构数据管理、数据实验室、规则引擎、领域语言处理等技术，实现大数据的跨平台整合管控，支持多数据集实时同步，实现数据互联互通。

5、需要支持多渠道数据资源管理，获取来自Oracle、Gbase、Ftp、Hive、Redis等数据源的外部数据，实现多源异构数据的整合管控。

6、支持实时、离线数据处理，提供完善的大数据分析基础运行环境以及统一的数据服务。

7、全流程管控，通过统一平台实现数据交换，平台内实行严格的权限管理及服务状态实时监控，保证数据和服务的安全性。

7、总结

1、搭建符合农信系统的混合架构的大数据体系，完成了数据应用的基础架构转型

基本形成了以大数据平台（Hadoop）和数据仓库（MPP）混合架构的大数据基础体系，为后续数据应用奠定了坚实基础。大数据平台负责历史数据、外部数据、非结构化数据、数据挖掘、客户画像、风控等场景的支撑，数据仓库负责传统报表、指标等负责的统计分析场景，两者相辅相成，共同支撑着整个数据条线的应用。

2、搭建了统一的数据服务体系，对外提供标准、统一的数据服务

通过数据服务层的建设，实现前台应用与中后台数据加工的解耦，为各应用提供报表、指标、查询、实时等形式的标准服务，提供系统与系统之间批量、单笔交易的数据服务。

3、探索大数据在精准营销领域的应用

实现内外部数据的统一接入，统一管理，标准化数据加工处理、统一服务流程，结合行内客户的基础信息及行为信息、业务交易信息等刻画客户画像，精准识别客户身份、偏好，为定向投放本行产品营销广告、个性化推荐产品及服务提供依据，缩减服务成本提高营销成功率。同时利用已有的客户营销数据总结客户营销经验，对潜客进行营销模板匹配，降低获客成本，提高客户转化率。通过建立客户流失预警、贷款违约预警数据模型，提早预测挖掘潜在的流失客户，贷款违约等经营风险，有针对性的进行客户挽留、贷款管理，降低经营风险减少经营损失。

但目前农信大数据应用仍有较长的路要走，大数据应用成果与人工智能、机器学习等技术相结合，将大数据服务从单纯提供数据管理、加工、再由业务进行组装拼接的形式转为提供“产品+数据+应用”全方位一体化自动化的完整解决方案。通过大数据技术与业务流程的深度融合，实现“运营数据化、数据资产化、资产效益化”以数据驱动运营的大数据应用。

标题：某银行大数据平台的架构设计及应用实践经验

如有任何问题，可点击文末阅读原文，到社区原文下评论交流

觉得本文有用，请转发或点击“在看”，让更多同行看到

 资料/文章推荐：

• 
  

下载 twt 社区客户端 APP

或到应用商店搜索“twt”