商业银行混合型数据仓库架构的应用

Posted 2021-04-24 黎慧剑个人随笔

引言：该文为2015年作者在广东华兴银行工作期间的数据仓库设计，采取混合技术搭配来支持实时、历史、归档数据的仓库建设和应用，整体思路目前看来仍未过时，其中数据总线最具特点，实时数据仓库的实现方案过于复杂，当前已有更为合适的替代落地方案（计划在后续的随笔中提出）。

  注：该文已发表在《金融科技治理与研究》杂志2016年第4期，总第20期。

随着银行业务规模和交易数量的增长，为了实现全行统一的数据存储及分析，各商业银行普遍实施了以Teradata、GreenPlum等为代表的中高端数据仓库系统项目，通过汇总银行内部各交易系统的数据，并根据数据标准化要求，进行清洗、转换，最终统一存储用于行内数据统计与分析。但近几年，面对互联网金融的挑战，银行业务已经发生巨大变化，各种结构化、非结构化海量数据蜂拥而至，而基于海量数据下的精细化管理以及快速业务决策需求正成为一种普遍情况，对数据应用的时效性、复杂性提出了巨大的挑战，因此形成了对传统数据仓库解决方案的质疑：难以支持实时数据服务、过高的海量数据存储成本、无法支持非结构化数据处理等等。

由此广东华兴银行创新的提出了混合型数据仓库架构，将数据仓库定义扩大为全行统一的数据服务中心，整合了内存数据库、关系型数据库、Hadoop等多种数据处理技术，根据不同业务场景对数据应用的需求，灵活提供数据服务，同时满足低成本、安全性、可用性、敏捷性、自动化的需求。目前该混合架构已在广东华兴银行实现了第一阶段的功能落地，对商业银行特别是中小型商业银行具有重大的借鉴意义。

 

一、数据应用的发展方向

数据仓库（Data Warehouse）广泛被接受的定义由比尔·恩门（Bill Inmon）于1990年提出：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，主要用于信息共享和高层的管理决策。近几年来，国内外很多金融机构从支持商业智能和优化业务的角度出发，相继开展数据仓库的建设，数据仓库及数据分析技术在业界引起广泛探讨和实践。

随着金融服务的不断创新，以及互联网技术的快速发展，金融机构对于数据的应用已不再局限于经营报表、管理决策等传统数据分析需要，而是期望在更多的金融服务场景发掘数据的应用价值。在这样的背景下，除了企业内部产生的各类交易和管理数据，部分金融机构已开始通过从互联网，以及第三方合作机构获取外部数据进行补充；同时除了已明确定义的结构化数据外，也开始尝试挖掘音频、视频、地理信息、文件、资讯信息等无法直接进行分析的非结构化数据的价值。

从各个渠道所获取的数据数量庞大、种类多样、实时性强，传统的数据仓库技术难以完全支持相应数据的处理，因此近几年大数据的概念逐渐流行起来，同时针对大数据的存储、处理和分析技术也得到了迅速的发展，例如Hadoop等开源大数据项目，或Yonghong Z-Suite等商业大数据BI工具。但大数据技术也存在其局限性，例如Hadoop技术在超大文件、流数据处理、分布处理等方面具有较大优势，但在低延迟数据访问、数据多次写入、大量小文件处理的支持上还存在较大缺陷。

在进行数据仓库项目的建设选型中，采取传统数据仓库技术难以支持大数据的处理，而采取Hadoop等大数据技术又在传统数据应用支持上存在缺陷，因此，华兴银行提出一种混合型数据仓库架构，以发挥各类数据技术的优势，同时形成技术短板的互补，以应对金融机构的各种数据应用场景需求。

 

二、数据仓库的能力设计

传统数据仓库更多用于支撑数据分析和数据挖掘应用，通过分析各种常见业务需求，并考虑数据仓库为全行数据中心的定位，可以扩充数据仓库对于各类业务场景的应用支持：

（1）实时数据共享：支持各业务系统通过接口查询数据仓库的各类实时数据，例如支持各渠道系统实时展示客户全资产负债视图，由数据仓库实时汇集客户最新的资产负债信息，则各类渠道系统（如网上银行、手机银行等）只需访问数据仓库实时获取信息，无需分别到各个产品系统获取客户产品余额再组合；

（2）批量数据获取：支持通过接口或文件方式获取批量数据，例如综合报表系统通过文件方式批量获取数据仓库的每日数据，用于进行各类经营管理报表的生成和展示；

（3）历史数据查询：支持通过接口或文件方式查询金融机构开业以来的各类报表、回单、单据等静态数据，以及支持查询开业以来的各系统的归档数据；

（4）非结构化数据处理：支持对文件、影像、视频、音频等非结构化数据进行存储及查询访问。

 

考虑到以上的各类数据应用场景，数据仓库架构应提供以下核心能力支持：

（1）数据时间范围：可在数据仓库中访问各个时点的数据，包括当日实时数据和所有历史数据；

（2）数据访问性能：可根据访问需求保证数据的访问性能，如当天的数据用于实时交易要求在毫秒级响应；历史数据用于分析挖掘可在分钟级响应；

（3）数据类型支持：可支持正常结构化数据的存储和处理，也可支持视频、音频、文件等非结构化数据的存储和处理；

（4）访问方式支持：可支持数据的实时报文查询，也可支持数据的批量文件查询；

（5）数据标准支持：数据仓库的结构化数据应遵循数据标准，以保证外部数据使用的易用性和一致性。

 

三、混合数据仓库的整体架构

基于数据仓库的核心能力设计，并针对各类数据仓库方案的技术优势，可按以下架构开展数据仓库的建设（见图1）：

图1 数据仓库整体架构

 

根据数据时间范围、数据访问性能、访问方式支持、数据类型支持等不同，数据仓库的整体架构可分为实时数据仓库、历史数据仓库、归档数据仓库、数据总线这四大模块：

（1）实时数据仓库

实时数据仓库所存储数据时间范围为T日的实时数据及近期（T+7日），主要提供业务系统需高访问频度数据，并包含实时的轻度汇总数据（如客户资产总额）。其通过源系统信息推送方式实时获取交易系统及外部的数据，实现价值信息实时而高效的获取，为业务系统的数据查询和分析型系统的实时决策等提供数据支持。

由于实时数据仓库需要支持数据的实时更新和实时访问，其应对场景为需及时响应、高并发的交易场景，因此在技术选型上可采用内存数据库，利用高效内存计算技术，进行实时汇总、整合处理，同时可以支持高频读写的应用访问场景。

（2）历史数据仓库

历史数据仓库所存储数据时间范围为T+1日至3年，每日日终从全行各源系统批量获取T+1的数据，采用统一模型策略，集成全行各业务系统有商业价值的基础数据，实现对基础明细数据的存储、整合和加工处理。

历史数据仓库的定位和能力要求与传统的数据仓库一致，主要是为经营分析和管理决策提供全方位、多角度、深层次的数据支持，满足分析型应用需求，因此可采取传统的数据仓库技术搭建。

（3）归档数据仓库

归档数据仓库所存储数据时间范围为3年以上的历史数据，以及各类文件、音频、视频、图像等非结构化数据，主要用于在线长期保存历史数据仓库、文服和下游各应用系统的离线归档数据，为客户交易明细历史查询等历史数据查询提供支持，同时可支持非结构化数据的存储、查询和处理。

归档数据仓库存储的数据量巨大，且涉及非结构化数据的支持，应用上较为符合大数据的处理要求，因此可采用Hadoop等大数据平台搭建，除满足基本的数据归档和查询需求外，还可支持后续对非结构化数据及大数据处理的扩展。

（4）数据总线

数据总线定位为针对外围应用系统访问实时、历史、归档数据仓库的数据查询服务，通过统一的接口服务，实现外围应用对跨系统、跨周期数据的查询。数据总线提供联机的查询服务，满足高并发、小数据量的查询；对于大数据量的查询，采取异步方式，在数据总线中生成数据文件后，通过通用文件服务平台进行文件的传输和处理。

数据总线主要是向外围应用提供访问数据仓库的服务，因此在功能要求上与企业服务总线（ESB）类似，可采用企业服务总线类似的架构和技术。

 

四、混合数据仓库的详细设计和实现

1、实时数据仓库设计

（1）详细设计

实时数据仓库需要满足实时数据的大量并发读写和毫秒级响应要求，因此在核心技术选型上选择基于Redis数据库（一款开源的Key-Value内存数据库）搭建，架构设计如下图（见图2）：

图2 实时数据仓库架构设计

 

实时数据仓库的架构主要分为两层，数据存储层和应用层：

• 数据存储层

数据存储层使用最基本的数据库功能进行数据模型的落地和数据存储，Redis数据库用于存储交易明细和轻度汇总数据，mysql数据库用于每日日终与历史数据仓库进行明细数据和汇总数据的核对，以保证可自动发现由于交易实时推送出错导致的数据不不一致问题。

其中Redis数据库采用主从集群方式提高读写性能和系统可用性，此外也使用Redis数据库的AOF（掉电保护文件）模式来确保服务器宕机后可通过物理文件进行数据库的恢复。

• 应用层

由于数据存储层不支持数据的逻辑处理，需通过应用层部署各类数据服务功能，包括数据服务池模块、事务处理模块、批处理模块、SQL适配器、管理后台功能等。

数据服务池：提供对外接口服务的管理，包括处理标准服务数据的标准组件、处理特殊服务或业务逻辑的专用组件、接口及组件定义的参数配置和对外服务的管理发布。

事务处理模块：由于Redis不支持事务，需通过应用层的事务处理模块实现事务提交或回滚，在明细同步和轻度汇总处理中如果出错，需控制进行数据回滚，保证数据的一致性。

批处理模块：提供日终批次处理服务，主要用于与历史数据仓库的明细和汇总数据核对处理。

SQL适配器：封装对Reids和MySQL等数据库的访问。

管理后台：向管理员提供系统参数配置、日志查看、系统运行情况监控的管理界面功能。

 

（2）关键技术总结

由于实时数据仓库采用的Redis数据库为Key-Value类型数据库，与传统的关系型数据库无论在数据存储结构还是数据查询语言上都有极大的不同，如果每类数据在Redis数据库上的落地都需要进行特殊设计和开发，将导致后续的维护成本非常高。为解决该问题，在方案中实现了传统关系型数据库表结构和Key-Value类型结构的转换模型，以保证关系型数据库的任意表结构均可直接在Redis数据库上落地；此外也针对Redis数据库设计了专用SQL适配器，让开发人员可以直接使用标准SQL操作和查询Reids数据库的数据。

• 数据存储模型

a.  关系型数据表的每行记录在Redis中存储为一个Key-Value值；

b.  Key值字符串格式为“Detail:表名:主键字段1值||主键字段2值||…”；如果数据表并无主键，则自动生成一个不重复的自增序号作为主键，以便可区分记录并进行数据访问；

c.  Value存储的是一个Hash类型，存放1行表记录的所有“字段名-字段值”键值对（Key-Value）；

d.  如果可确定要访问数据的主键值，可通过“HGETALL key”命令直接访问行记录的hash对象，或通过“HGET key field”命令获取记录指定字段的值；

 

• 索引模型

对于检索非主键字段值的查询需求，需要建立相应的字段索引，以提高数据的访问速度。

a.  关系型数据表的每个字段的每一类值，可建立一个Key-Value键值对存储相应的索引信息；

b.  每插入一行数据，需在现有索引值Key-Value上增加对应的key字符串，或新增一类索引值Key-Value键值对；

c.  字符型字段的索引Key值字符串格式为“Index:表名:主键名:字段名:字段值”，Value值为对应记录主键字符串列表；

d.  数字类型字段的索引Key值字符串格式为“Index:表名:主键名:字段名”，Value为sorted-sets结构，其中字段值直接作为sorted-sets结构的分数(score)，对应记录的主键字符串为sorted-sets结构的值，通过对分数(score)排序来提高检索数据的效率；

 

2、历史数据仓库设计

历史数据仓库基本沿用传统数据仓库的技术方案，方案上与传统数据仓库的区别仅在于数据标准转换的落地工作在源系统实现，历史数据仓库内部直接使用经过数据标准转换后的数据，无需转标的处理，架构设计如下图：

图4 历史数据仓库架构设计

 

历史数据仓库的设计基本采用传统数据仓库的方案，说明如下：

（1）使用Oracle数据库，通过Oracle RAC实现数据库的高可用性；

（2）在数据仓库的建设过程中同步制定相关的数据标准，以及设计对应的数据标准接口，由源系统按数据标准要求实现标准转换后，再将已实现标准转换的数据供给数据仓库进行处理；

（3）由于数据标准已在源系统落地，数据仓库内部的层级只设计4层，与传统数据仓库的5层结构有所区别；

（4）ETL过程与传统数据仓库方案一致，通过统一调度服务实现ETL的调度。

 

3、归档数据仓库设计

归档数据仓库主要存储两大类数据，第一是来源于历史数据仓库的明细数据归档，该归档为结构化的数据，通过数据总线提供查询服务；第二是非结构化数据归档，针对对账单、报表等非结构化数据，可以通过数据总线进行查询。

归档数据仓库的总体架构设计如下图：

图５　归档数据仓库架构设计

 

归档数据仓库的核心技术是利用开源的Hadoop集群及相应组件，提供数据库存储、文件存储、数据检索、分布计算等功能，同时在对外的应用层中封装数据交互接口、文件处理、文档检索、数据查询等常用功能，对外提供相应数据服务。

 

4、数据总线设计

数据总线功能要求上与企业服务总线（ESB）类似，因此采用企业服务总线类似的架构和技术实现，总体架构设计如下图：

图６ 数据总线架构设计

 

  数据总线的架构说明如下：

（1）外部服务接口层

接收外部WebService请求，经过安全模块检查通过，发送报文消息给消息服务层，等待消息服务层返回响应交易报文消息，取回响应报文返回外部。

接受流量监控接口层流量进行控制。

（2）安全模块层

进行交易报文的检查，操作人员权限检查，系统安全检查。

（3）服务控制层

接收消息服务层指定消息队列消息，分拆请求报文，发出调用数据接口交易的消息给消息服务层，等待消息服务层返回消息，解析返回消息，组合成响应交易报文，发送响应消息报文至消息服务层。

接受流量监控服务层流量进行控制。

（4）消息服务层

接收消息服务层指定队列消息，转发至指定消息队列。对阻塞的消息进行缓存，并在适当时候重新载入消息队列。

（5）数据访问层

接收消息服务层指定消息队列消息，解析数据访问信息，调用制定的数据访问适配器，访问对应数据仓库，得到返回数据，组织成返回消息，发送至消息服务层。

接受流量监控访问层流量进行控制。

（6）流量控制模块

监控接口层、服务层、接口层的报文，依据设定的参数进行流量控制。超出流量的直接返回系统流量控制超出信息。

负载均衡在系统接近流量控制时，启动备机资源，进行负载均衡。

（7）公共模块

配置化管理、参数管理、文件管理。

 

五、混合数据仓库的应用

广东华兴银行在2015年按照混合数据仓库的架构进行了可行性研究，并于当年按照混合架构启动了数据仓库项目，该项目于2016年5月完成建设，实现了混合架构中的数据总线、实时数据仓库、历史数据仓库的投产和实际应用。

在历史数据仓库的建设中，尝试了源系统落地数据标准，以标准接口向数据仓库供转换后数据的实施方式，目前已按该模式顺利完成了贷款类数据的数据标准制定及数据入仓，并对应完成了贷款类数据报送集市的投产应用，主要效果如下：

（1）由于入仓数据均在源系统进行标准转换，可通过该模式推动源系统建设中注重对数据标准落地执行，以应对传统数据仓库建设无法推动数据标准在全行各系统落地执行的难点；

（2）由于入仓的数据均已完成了数据标准转换，历史数据仓库的开发人员无需熟悉源系统数据结构，只需专注于业务数据的处理和应用本身，可降低开发人员的经验和能力要求，降低项目实施难度；

（3）源系统建设过程中的数据结构变更，只需在该源系统上对应调整标准转换逻辑，数据仓库及下游应用无需进行改造，可有效降低源系统数据变更的业务影响，并减少数据仓库及下游应用的成本投入。

另外，通过数据总线和实时数据仓库的建设，实现了实时业务场景的数据支持，并取得了良好的业务效果。主要的业务场景是在手机银行向客户展示实时的全资产视图，客户在广东华兴银行进行转账、理财购买、基金购买等金融交易后，交易及账户余额信息将实时推送至实时数据仓库进行客户资产视图的汇总，手机银行等电子渠道只需直接访问实时数据仓库即可快速获取客户全资产信息，并且不会对核心、理财等账户管理系统造成性能压力。以下是广东华兴银行手机银行客户全资产视图应用的效果截图：

图7 手机银行总资产及各类资产查询截图

 

混合型数据仓库架构的应用，不仅改变了数据仓库项目的实施方式和技术选型，更重要的是扩展了数据仓库的在实时数据和大数据两方面的服务能力，让数据仓库的应用不再局限于报表展示、分析决策等交易后的业务场景，而是可以直接为交易前、交易中的业务处理提供数据支持，进一步扩大了数据应用的价值体现。