2000年以后，多数商业银行都在建设数据仓库，经过前期的数据积累，数据质量的提升，数据仓库建设成功率较高。

商业银行数据仓库的建设一般都采用分阶段建设的策略。

第一阶段，基本实现对数据的集中处理，特别是对内部重要报表系统提供数据支持。

第二阶段，进一步实施诸如资产负债管理、客户关系管理或者某些灵活报表查询等较为复杂的管理分析类应用。

第三阶段是在第二阶段的基础上，实施数据挖掘分析、商业智能等应用。

对于商业银行来说，建设数据仓库是基本功，缺点是实施的周期较长，统一标准困难，见效慢，是一个典型的高投入和慢回报的建设项目。

但是随着时间的流逝，建设数据仓库或者不建设数据仓库给商业银行的发展带来了不同的影响。例如，如果某些商业银行在5年前或者10年前就开始重视数据仓库的建设，比那些不重视数据仓库建设的商业银行发展态势要好很多。也就是说，后期投入的成本就越高。

一些商业银行在建设数据仓库时面临很多的困难，例如很多银行为每一个应用系统建设数据库，当多个应用系统建设完成之后，增加了数据管理的难度。因为数据标准不统一，所以整合难以实现。

举例来说，客户使用银行服务的渠道很多，除了传统的营业网点，还包括网上银行、手机银行等渠道，这会导致同一个客户可能会拥有多个账户信息，那么识别唯一客户需要大量的数据整合和集成工作。如果不能对客户信息进行唯一识别，就很难进行商业智能分析。

目前商业银行数据仓库面临很多瓶颈，包括业务价值、系统性能、数据质量和后续运维等，如图9-40所示。

(www.daowen.com)

图9-40 目前商业银行数据仓库面临的瓶颈

（1）业务价值

对于大部分的商业银行来说，数据仓库基本上停留在业务报表和供数层面上，业务价值体现得不够充分。商业银行有大量的数据，有的银行也做了很多的数据分析，但是没有把业务分析结果转换为业务行动。国外很多银行都会把分析结果转变成业务规则或者业务事件，然后和银行的业务系统糅合到一起，最终形成一个闭环结构。国内商业银行的高端分析应用不多，也就是没有把对业务的分析结果转换为业务行动。

（2）系统性能

对于商业银行来说，如果数据仓库系统的数据链路过长，例如数据从核心业务系统加载下来，然后再通过交换系统、缓冲区，经过ETL加工，最后到应用系统。这种方式必须考虑数据的混合负载，也就是数据加载、数据加工和前端访问同时进行，可以进行批量加载和实时加载。这种工作负载是混合的，需要重点考虑资源的分配问题。

（3）数据质量

对于大部分商业银行来说，基本上都是先有数据仓库，然后才进行数据标准的建设，这样会导致数据标准很难在数据仓库中落地。大部分商业银行实行了数据质量检查程序，对数据仓库的上游、中游和下游进行全生命周期的质量管理，但是对于前台业务系统，也可能有数据质量问题，所以需要统一起来。

（4）后续运维

当数据仓库建好之后，每天都在加载数据，模型也在不断扩充，如果有新的数据源加进来，模型就需要变化，ETL程序也需要修改，这样维护的工作量非常大。同时还需要考虑数据自助服务，开放数据接口，也就是业务人员通过接口自助服务，临时取数。但是一般来说，这种灵活查询不能全部开放，因为数据仓库的数据量非常巨大，有可能一个查询会影响整个数据仓库系统，对于开放的查询只能开放一些汇总数据层的数据。而关于明细的基础数据层、交易层的数据是不能开放的。