理论教育 商业银行数据仓库建设思路与系统情况分析

商业银行数据仓库建设思路与系统情况分析

时间:2023-06-06 理论教育 版权反馈
【摘要】:组织架构很多商业银行缺少与数据治理相关的人员角色和岗位,不能保证业务部门和IT部门的目标是一致的,导致数据仓库的建设缺乏长远的、与商业银行的业务战略一致的规划。关于商业银行数据仓库的目标数据架构,主要包括源数据层、数据交换平台、数据服务层、应用层。

商业银行数据仓库建设思路与系统情况分析

1.商业银行建设数据仓库时遇到的挑战

商业银行建设数据仓库时遇到的挑战主要包括高可用性、组织架构、数据质量和性能/数据延迟性,如图9-42所示。

(1)高可用性

在单一物理环境中集中了数据缓存、ODS、数据仓库和数据集市,这样会严重影响系统的高可用性,同时会引发一系列关于性能、可扩展性可维护性等问题。

因为缺乏对负载的管理或者是相关政策实施监管不到位,所以造成了资源的相互争夺,使得系统不能提供很好的服务。

(2)数据质量

由于如果数据仓库中存在大量的不一致的数据和冗余的数据,则对于数据质量的维护来说是非常被动的,所以应该保证数据仓库中的数据都是有用的。

(3)组织架构

很多商业银行缺少与数据治理相关的人员角色和岗位,不能保证业务部门和IT部门的目标是一致的,导致数据仓库的建设缺乏长远的、与商业银行的业务战略一致的规划

(4)性能/数据延迟性

978-7-111-50289-0-Chapter09-48.jpg

图9-42 商业银行建设数据 仓库时遇到的挑战

对于很多商业银行的数据仓库来说,查询的并发度是一个很大的挑战,多用户使用数据仓库运行的报表或者是即席查询的时候,系统很难进行扩展和对负载进行优先级的处理。

2.商业银行数据仓库架构问题及案例分析

(1)第一个案例

商业银行在建设数据仓库的时候,可能会存在其他某商业银行的数据仓库架构问题,下面分析一下对这类数据仓库有哪些可以改进的地方,如图9-43所示。

978-7-111-50289-0-Chapter09-49.jpg

图9-43 某商业银行的数据仓库架构

现状:

该商业银行的业务系统每天将文件放入到数据仓库中,如今的数据仓库在压缩前存放着大约80TB的数据,压缩后有45TB,日增量大概有300~400GB,在峰值时可能会有800~900GB的数据。

需要优化的地方:

整体的数据架构需要优化,面临着数据如何迁移,缺少统一的数据管控体系,缺乏大数据处理机制,数据模型没有统一规划等很多问题。

在核心银行业务系统向数据仓库传送文件的过程中缺少文件交换平台,文件被直接送入到数据仓库中,缺少数据缓冲区。因为业务系统与数据仓库之间缺少缓冲区,这意味着数据仓库缺少了一道屏障。

首先,因为数据仓库存储着大量的历史数据,同时为多个应用提供服务,所以系统的效率可能是个瓶颈,如果再与多个业务系统建立连接,会大大降低数据仓库系统的高效性。

其次,缓冲区相当于数据进入到数据仓库系统的一道闸门,很多事情可以在缓冲区完成。例如,对数据质量的校验,对“垃圾”数据的“清洗”,目的是保证数据的一致性和正确性。然后从缓冲区中将数据迁移至数据仓库,保证流到数据仓库的数据都是高质量的数据。(www.daowen.com)

最后,数据仓库面对的是数据缓冲区这唯一的数据源,把该缓冲区当作唯一可信的数据源,只需要建立一个连接即可,会大大提高数据仓库系统的性能。

同时该系统缺乏库内集市和库外集市的合理规划,根据性能的要求,应用可以分成库外数据集市和库内数据集市。划分的原则是需要考虑性能问题,如果数据访问量很大,计算复杂,则需要用库外数据集市;如果访问量小,计算简单,则考虑库内数据集市。

(2)第二个案例

下面看一下某商业银行的数据仓库数据架构,如图9-44所示。

978-7-111-50289-0-Chapter09-50.jpg

图9-44 某商业银行的数据仓库数据架构

现状

从主机对公系统、主机个人系统和开放平台,每天通过文件传输平台,到ETL服务器,数据通过解压、压缩,每天传输的数据量是450GB,先放入临时区(该临时区一般只存储一周的数据)。该临时区的数据是为了做数据加工准备的,是贴数据源的。从临时区出来分了两条路径,所谓的数据集成平台相当于ODS系统。如果应用是不跨系统的,同时要求数据的时效性高,则该应用从数据集成平台中取数据;如果该应用要求跨系统取数,但是要求的时效性不高,则该应用从企业级的数据仓库中取数据。

企业级的数据仓库分成基础数据层、汇总数据层。针对数据仓库的应用也可以分成库外的数据集市和库内的数据集市,原则是考虑性能的问题。如果数据访问量很大,要求的时效性高,则需要考虑库外的数据集市。如果数据访问量小,则可以考虑使用库内的数据集市,也就是在数据仓库内做视图。

需要优化的地方

该商业银行的数据仓库逻辑架构存在问题,例如时间窗口过长,也就是数据的链路太长。解决的办法是通过主机直接连到数据集成平台,可以通过产品实现。在时间调度上,如果某个业务的数据很快加载完了,就可以先提供访问,不需要等所有的业务全部加载完之后再提供数据访问。可以通过ETL将业务之间的相互关系拆开,在没有相互依赖的情况下,某个业务的数据加载完之后就可以提供访问了。

3.对商业银行数据仓库目标数据架构的建议

对于数据仓库的目标数据架构,可以提供以下建议,如图9-45所示。

978-7-111-50289-0-Chapter09-51.jpg

图9-45 数据仓库的目标数据架构

1)在数据源层和数据服务层之间建立一个数据交换平台。数据服务层内部的数据流动和数据交换都通过数据交换平台。ODS相当于数据的集成平台,存储的都是实时性的数据,而数据仓库存储的都是历史数据。

2)数据仓库可以分成数据基础区、数据汇总区和集市区。

3)数据沙盘的使用。如果某个应用从数据源层通过数据交换平台到ODS,到数据仓库层,再到数据集市层,可能数据的链路过长,从而影响应用的时效性,这样就可以建立一个数据沙盘,可以直接从ODS取数,或者从数据仓库、数据集市中取出数据,当稳定和固化后,再把应用挪到ODS或者数据仓库、数据集市中。

4)所有的数据流动都有统一的调度工具进行调度。

5)同时建立对数据的分布和流转的管控,包括元数据管理、数据质量管理、数据标准管理和数据生命周期管理等内容。

关于商业银行数据仓库的目标数据架构,主要包括源数据层、数据交换平台、数据服务层、应用层。源数据层对于各个OLTP生产系统,如一些核心业务系统等,时效性要求较高,一般只存储生产数据,不存储历史数据。它一般作为数据仓库的主要数据来源。源数据层还可能包括文件系统、Web等非结构化数据源。

数据服务层为数据仓库所在层,通过对历史细节数据的存储和汇总数据的加工,支持后续的应用。数据服务层结合业务的需要可以设计成库内集市或者库外集市。

应用层将数据服务层加工出的数据,通过静态报表、动态OLAP等处理方式提供给用户。

免责声明:以上内容源自网络,版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。

我要反馈