史诗级干货：银行数据仓库体系建设实战（一）

知识普惠 2020-03-29

871

11842 字 | 30 分钟阅读

本系列课程分以下模块详细介绍银行数仓建设过程：

银行数据仓库体系建设实战（一）

一、银行数据仓库简介

二、银行数据仓库体系架构

三、银行数据仓库数据架构

银行数据仓库体系建设实战（二）

一、银行数仓建设之数据抽取和加载

二、银行数仓建设之数据转换

三、银行数仓建设之调度系统

银行数据仓库体系建设实战（三）

一、银行数仓建设之数据模型设计及流程

二、银行数仓建设之主数据模型设计

三、银行数仓建设之主题模型

银行数据仓库体系建设实战（四）

一、汇总指标层和数据集市模型设计

二、数据仓库开发管理系统及开发流程

三、数据管理和数据治理

银行数据仓库体系建设实战（五）

一、数据应用之监管报送

二、数据应用之财务、营销及风险分析

三、银行数据仓库发展趋势

银行数据仓库体系建设实战（一）

本文系作者在银行从事系统开发多年经验总结，经历过股份制银行、城商行、互联网银行的系统建设。对银行系统架构，特别是数据仓库类系统有较丰富的经验积累，并将这些经验整理成文，为自己工作做个总结梳理，并能够与大家互相探讨，共同学习。

一、银行数据仓库简介

数据仓库之父Bill Inmon在1991年出版的《Building the Data Warehouse》一书中所提出的定义被广泛接受：数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。Bill Inmon在书中提出数据仓库的特征：

面向主题的 (Subject-Oriented)

集成的 (Integrated)

保留历史的 (Time-variant)

面向决策支持的 (Decision Support)

面向全企业的 (Enterprise Scope)

最明细的数据存储 (Atomic Detail)

数据快照式的数据获取 (Snap Shot Capture)

建立数据仓库的目的是为企业业务分析、市场营销、成本控制、战略决策提供所需要的数据支持。在银行中，数据仓库汇聚了银行主要系统的客户、业务、财务等数据，为银行的日常运营分析、市场营销、风险控制、财务分析、内部审计、监管报送提供数据支持和服务。

银行系统群介绍及数据仓库的定位

银行作为我国金融体系中的支柱行业，银行业务涉及种类众多，业务流程复杂，且像工行、建行等国有银行服务亿级的客户，每天交易量和BAT等互联网公司不相上下，同时不能造成1分钱的误差。因此没有健壮高效的信息系统做支撑，银行的业务是无法快速发展的。

由于业务的复杂性和高业务量，银行的软件系统也错综复杂且不断迭代，小的银行可能是几十上百个系统，国有大银行可能有成百上千个系统。银行的软件系统从功能划分主要有交易类系统、数据类系统；

1、交易类系统

交易类系统是承载业务流程的实时交易系统，它们一般是7*24小时运行，是银行业务正常运转的关键系统，交易系统主要分为渠道系统和业务系统（账务系统）两类：

渠道系统：渠道系统就是客户接触银行的系统，这些系统大家都比较熟悉并经常使用，如ATM、手机银行、网上银行等系统。

业务系统：主要进行账户管理、业务逻辑和账务处理的系统，如核心系统、个贷系统、票据系统等。

以前银行的核心系统包括了存款、贷款、中间业务等所有业务功能，但随着客户数、交易量的增加以及信息技术架构的发展，目前许多银行的核心系统已经按业务或功能进行了拆分，演变成了多个系统，如个人贷款系统、公司贷款系统、票据系统、总账系统、基金理财系统等，从系统上看这样演变系统间耦合性更低，扩展性更好，从业务上看，各系统的业务分工更加明确。

随着核心系统的拆分，系统间的交互原来从核心系统内部的模块调用变为了系统间的调用，如从手机银行查询客户存款账户的余额，那需要手机银行发送交易到核心系统查询。

随着越来越多的子系统独立出来，系统间的交互也更加频繁。因此很多银行在2000年后就开始建立了交易总线系统并规范系统间调用的服务，所有系统请求方的系统请求都先发送到交易总线系统，由交易总线系统进行转发到服务提供方并将结果返回，统一了系统交互的协议、并且制定了系统间交互的规范。

2、数据类系统

由于交易类系统属于面向联机事务处理（OLTP），需要确保交易的稳定和高效，因此消耗大量计算资源的数据加工分析不适合在交易系统中进行，数据类系统主要汇集各交易类系统的数据并进行加工，为各业务部门提供运营管理、风险控制、精准营销所需的数据和报表。

数据类系统面向联机分析处理（OLAP）。时效性和可用性没有交易系统高，但是处理的数据量大，业务分析逻辑更复杂。常见的数据类系统有客户关系管理系统、审计系统、监管报送、报表系统等。

那数据类系统的数据主要源于各交易系统，是否每个数据类系统都各自去从交易系统获取数据并各自加工呢？答案显然是否定的，这样做不仅浪费系统获取数据、加工数据的资源，也会使各系统加工口径不一致。

因此许多银行会建立数据仓库或者叫数据总线的系统，统一从交易系统抽取数据并进行存储计算。因此数据仓库在整个银行的系统中是作为全行的数据中心、数据流转的枢纽，从系统架构的定位来看主要有以下功能：

1）数据抽取：采用统一工具从源系统获取数据。

2）数据存储：存储源系统的数据以及加工计算的数据结果，按时间进行数据的积累。

3）数据加工计算：对源系统数据进行关联、清洗、转换、汇总计算。

4）数据分发：对源系统数据以及加工计算结果进行分发到目标系统（数据应用系统）。

数据仓库发展已有几十年，期间也出现了不少新的数据架构，数据仓库架构也不断演变、完善和发展。以下简单介绍几个常见的数据架构以及与数据仓库的关系。

数据仓库和ODS

和数据仓库经常一起出现的是ODS（操作型数据存储），有些银行叫ODS，而有些银行则叫数据仓库，那两者有何区别呢？ODS是集成的、反映当前数据值的、经常更新的和详细的数据集合，用来满足企业集成的操作型的处理需求。和数据仓库相比主要区别在于：

1） ODS侧重于操作型查询，查询数据范围较小，DW则侧重于分析型，查询数据范围以及时间跨度较大；

2）ODS对响应速度要求较高，通常在秒级；

3）DW侧重于历史数据，ODS以当前为主，历史较少；

4）ODS偏重于准实时更新，也可批量加载，DW偏重于批量加载；

5）DW采用主题范式化建模，ODS多采用与业务系统同构方式建模；

6）DW将对数据进行清洗和整合，ODS则尽量保持源数据原貌，以满足那些强调原样数据的需求，同时为数据质量检查提供原始资料。

举个例子，如业务需要每隔1分钟统计下手机银行的交易量，或者统计某个网点在1小时内的存取现金情况都属于ODS的范畴，如统计去年每个月的手机银行交易量以及变化趋势，并分析那个时间段是手机银行访问的高峰期则属于数据仓库的范畴。

但随着技术平台以及银行数据需求的发展，银行的数据仓库或ODS逐渐合二为一，也就是说在同一个平台既能满足ODS实时或准实时的数据查询也能满足数据仓库的全行范围近几年的数据统计和趋势变化分析。因此从功能和作用上来看，银行的ODS和数据仓库其实说的就是同一个系统了。

数据仓库和数据集市

数据集市（Data Mart）是数据仓库的一个子集，用于从数据仓库获取相关的数据加工后提供给用户，数据集市通常面向特定的业务或者团队，如市场部门有对应的营销数据集市，运营部门有运营数据集市等。

银行的数据集市主要有财务、营销、风险等集市，这些集市为各对应的数据系统进行数据加工，另外也会为各业务部门数据分析人员提供分析集市，由数据仓库提供相关数据后，由业务人员自行进行数据探索分析。银行的数据仓库体系一般包括了数据集市，将数据集市作为数据仓库体系的一部分。

数据仓库和数据湖

数据湖是一个集中化存储海量的、多个来源，多种类型数据，并可以对数据进行快速加工，分析的平台。数据湖以其本源格式保存大量原始数据，包括结构化的、半结构化的和非结构化的数据。在需要数据之前，没有定义数据结构和需求。那与数据仓库的区别主要在以下几方面：

1）数据格式：数据湖保留了数据的原始格式，包括图片、WORD、PDF等文档、影像、语音等多种数据格式，而数据仓库一般是将原始数据进行一定处理后，获得结构化的数据放到关系数据库中。

2）数据存储：数据湖采用大容量低成本的存储，目前流行使用Hadoop进行数据湖数据存储和计算, 数据仓库以前常用MPP架构并行处理数据库，存储成本较高，目前互联网公司也采用Hadoop进行数据仓库的建设；

3）数据使用：数据湖数据不需要提前定义数据模型，主要进行探索分析，数据湖中的数据通过map-reduce等大数据技术来处理，而进入数据仓库中的数据一般是已经有确定的使用用途，达到一定的分析目标，常使用SQL、数据分析软件如SAS等方式进行分析处理。

笔者认为数据湖和数据仓库是互相补充的关系，原始数据的保留为数据分析提供更多的尝试。目前随着Hadoop生态发展越来越成熟，许多银行已经将Hadoop平台纳入到了数据仓库体系中，作为非结构化数据的存储和计算平台，因此也具备了数据湖的功能，但是银行的数据分析人员还是习惯于使用结构化的数据即数据仓库中的数据进行业务分析。

数据仓库和数据中台

数据中台这个概念是由阿里首次提出，阿里现在拥有众多业务分支系统，如淘宝，天猫，阿里妈妈，阿里巴巴等，每套系统都有自己的体系和数据源，都在各自的系统上做了很多服务，但数据在各系统之间无法共享，各系统之间还会有功能和数据，服务和应用的冲突，为了解决这些问题，阿里开始整合挖掘数据，打造数据中台，从一开始知识做数据的监测和统计到后来的数据化运营和分析，再到搜索个性化，定制化营销，再到智能化，渐渐让各个体系融合在一起，建立统一的体系，就算再扩展业务也是纳入这个中台，用相同的技术和模式进行运营。

所以数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层（数据模型，算法服务，数据产品，数据管理），进而为客户提供高效服务。这些服务跟企业的业务有强关联性，是这个企业独有的且能复用的，是企业业务和数据的沉淀。比如企业自建的2000个基础模型，5万个标签。数据中台还包括了数据技术，比如采用统一的技术及框架对海量数据进行采集、计算、存储、加工的一系列技术集合。

数据中台不仅能降低重复建设，减少烟囱式协作的成本，也能快速提供业务数据进行分析，使数据产生价值，同时数据中台通过为业务场景提供数据服务，业务场景也不断产生新的数据及分析模型反馈，滋养给数据中台，使数据中台不断发展。

那从银行来说，银行数据仓库体系应该包括数据中台的功能，许多银行特别是国有银行和股份制银行借鉴国外先进银行的经验和架构，在2000年后都开始建立数据仓库，进行了各业务数据的整合并统一提供数据服务，有些金融集团也在集团层面上整合了各子公司的数据。

在数据规范和整合方面许多银行已经完成，数据平台技术架构也已经统一，但是在数据意识、数据思维方面和互联网企业还是有不少差距，许多银行业务拓展更多依赖经验、客户经理、简单的数据统计，大多应用往往集中在报表、监管报送、审计、风险控制等管理应用，在客户行为分析、精准营销、风险控制等方面还未深挖，在机器学习、AI方面的新技术使用也较迟缓。

互联网公司在发展初期着重于产品功能及用户拓展，需要依靠数据来了解客户，分析客户，虽然一开始没有数据中台，各产品各自获取产品、客户相关数据并进行分析挖掘。通过数据发现用户在使用产品中的阻碍和问题，找出客户的痛点。那随着多个产品的成熟以及发展，数据量快速增加，数据分析工作越来越复杂，数据分析知识经验也需要沉淀，所以数据中台也为了各产品能更好的共享经验、共用数据而应用而生。

二、银行数据仓库体系架构

UML对系统架构的定义是：系统的组织结构，包括系统分解的组成部分，它们的关联性，交互，机制和指导原则，例如对系统群就是定义各子系统的功能和职责，如贷款系统群可能分为进件申请、核额、交易账务、贷后管理、管理台等子系统，对于系统就是定义各模块的功能和层次，例如管理台包括权限管理、用户管理、交易管理、逾期管理、统计分析等功能。

技术架构是指从技术实现层面描述系统，主要是根据系统架构组成部分确定每层使用什么技术框架，例如中间件、WebService等。

那对于数据仓库系统群具体可以分为哪些部分以及他们的具体实现技术如何呢？以下是银行数据仓库的系统功能图：

1、数据源：主要是指行内交易系统、外部采购或合作的第三方数据等3类、包括结构化数据以及非结构化的数据，结构化数据主要是存储在各个行内系统数据库中的表数据，非结构化数据包括图片、语音、文档等类型的数据。

2、数据采集：即如何将数据从数据源获取到数据仓库中，就是我们常说的ETL随着数据仓库功能的发展这部分不仅仅包括批量数据获取还包括实时数据流以及数据库数据实时采集：

1）批量采集

主要包括从数据源获取大批量的数据，这是银行数据仓库主要的数据采集方式，批量采集的采集数据频率较低，一般是每日凌晨获取上一天的数据，有些场景也可以每小时采集一次，由于采集的数据量一般较大，对数据源也有IO的影响，因此不建议采集频率太高。批量采集需要支持从关系型数据库、内存数据库、文件中批量获取并加载到数据仓库中。

在技术实现中，批量采集工具需要能支持多种数据源的采集和加载，批量采集可选择的工具较多，可以采用商业化软件如IBM的DATASTAGE以及INFORMATICA公司的INFORMATICA，也可以采用开源的SQOOP和KETTLE。也可以采用各关系型数据库以及HADOOP自带的文件导出和导入功能。

2）实时采集

指实时同步源系统的数据库数据到数据仓库，这样可以在数据仓库中实时分析数据。实时采集通过专门的工具监控源系统数据库日志进行数据同步，数据源系统无需改造，这种采集方式针对数据统计时效性非常高的场景。

在技术实现中，实时采集工具需要支持从多种类型数据源到多种类型目标数据库的实时同步，这块商业化软件比较成熟，如ORACLE的GOLDENGATE、IBM的InfoSphere Change Data Capture等软件。开源软件中kettle也支持数据库实时同步，但需要在源表增加时间戳字段。

3）数据流采集

即通过Queue的方式从数据源系统获得数据流消息，数据仓库实时获取Queue中的消息进行实时数据流计算。这种数据采集方式也是面向统计时效非常高的场景，需要数据源系统增加实时发送消息的功能。

在技术实现中，由于数据流计算在互联网公司使用广泛，涌现出许多优秀的开源软件，如开源的KAFKA、ROCKETQUEUE等QUEUE工具，可以支持实时监控文件、数据库的变化并将变化数据发送到QUEUE中的开源软件FLUME。对于MYSQL也可以通过BINLOG和SHYIKO监控MYSQL日志，将数据变化发送到QUEUE中，那在商业化软件中IBM的MQ是各银行经常使用的中间件。

3、数据存储/计算：数据存储计算是数据仓库的主要功能。数据存储主要指结构化数据和非结构化数据的按格式存储，计算指基于存储的数据进行关联、汇总、数值计算等批量处理、实时流计算和复杂的机器学习。

实时流计算主要指对大规模流动数据在不断变化的过程中实时地进行分析，比如实时展示目前银行所有转账的笔数和汇总金额。需要将每笔转账进行不断计算。目前在银行中应用场景还较少，但随着互联网渠道的发展后续也将出现更多的应用场景。

机器学习是专门研究计算机怎样模拟或实现人类的学习行为，以获取新的知识或技能，重新组织已有的知识结构使之不断改善，简单来说就是通过数据来发现规律，累积经验，并对新的数据进行分类或预测。比如通过学习近1年的上证指数及交易量的变化来预测明天的上证指数。目前炒的人工智能、深度学习也是属于机器学习范围。目前银行在风控、反欺诈、精准营销等方面也逐步在使用多种机器学习算法来提高成功率。

由于数据仓库是银行的数据枢纽，银行的所有业务数据都会在数据仓库保留，因此数据量较大，一般小银行数据量在TB级，股份制银行大概在PB级，国有大银行在ZB级。因此存储和计算的的可扩展性、性能都很重要。那在目前银行中数据仓库的存储和计算一般采用MPP数据库（大规模并行数据库）和HADOOP相结合的技术方案。

1）MPP数据库：主要是面向结构化数据存储、批量计算和机器学习。在HADOOP出现前，商用的MPP数据库是数据仓库的主流技术平台，它使用简单，同时具有超大规模计算能力和良好的计算性能、扩展性。如TERADATA公司的TERADATA数据库、ORACLE公司的ORACLE一体机、IBM的NETEZZA一体机。其中TERADATA公司的TERADATA数据库在早期是一枝独秀，我国国有大银行的数据仓库最早建立时大部分都采用了TERADATA数据库。

近年来ORACLE的EXADATA市场占有率也逐步提升，开源的MPP数据库最有名的是由商业转为开源GREENPLUM，目前腾讯云的TIBASE、阿里云的HybridDB for PostgreSQL都是基于GREENPLUM优化的。

2）HADOOP平台：HADOOP平台支持结构化数据和非结构化数据的存储和计算。由于MPP数据库价格高，且扩展性也有一定局限。很难满足互联网公司超大数据量及非结构化数据的计算需求，因此HADOOP软件生态体系应运而生并发展越来越成熟，成为互联网公司大数据处理的标配平台。2015年左右，随着HADOOP平台的完善及商用（商用版本如华为、星环科技；开源版本如CLOUDERA、Hortonworks），银行也逐步使用HADOOP平台和MPP数据一起作为数据仓库的存储和计算平台。

其中批量计算一般使用HIVE和SPARK，流计算一般使用STORM和SPARKSTREAMING，机器学习可以采用HADOOP生态的SPARKMLLIB、MAHOUT，也可以使用TENSORFLOW、SAS、R等支持HADOOP平台专门的机器学习工具，目前许多公司在研发推出的人工智能平台（机器学习建模平台）也都把HADOOP平台作为数据存储和计算平台，如第四范式、星环科技等。

4、数据服务：数据服务主要指如何为银行其它系统提供数据服务，随着数据仓库体系的发展，数据仓库不仅仅能按批量的方式提供数据计算结果，还可以实时提供数据服务。

1）批量接口：按约定的接口方式将数据批量提供给数据应用系统，一般每天1次，可以按文件的方式放到约定的服务器，也可以通过数据采集部分提到的ETL工具直接将数据同步到应用系统的数据库中。

2）在线查询：提供实时查询的接口，并发布到银行交易总线，由其他业务系统或数据系统实时调用，比如银行的每年的账单总结（类似支付宝每年账单）一般由数据仓库根据每个客户1年的交易流水，统计出转账、消费、收入等数据并提供给渠道系统如手机银行、网上银行进行展示。那在技术实现方面，接口服务开发一般按各行的开发规范来实现，如web service或http+xml，大部分银行使用JAVA进行开发，如果接口TPS不高，一般的MPP数据库也足够支持，无需进行数据移动，如果TPS比较高，可以将数据加工结果放到HADOOP HBASE进行数据存储和查询。

3）实时同步：实时同步主要是实时数据流计算后将结果实时同步给数据使用系统，同时将结果发布到QUEUE中，由目标系统进行订阅，实时获取。

5、数据应用：数据应用主要是将数据通过数据服务提供给各应用系统，由各系统进行数据分析和成果展示。那主要有以下几类：

1）数据应用系统：主要指使用数据的系统，在银行包括客户关系管理、管理会计、绩效管理、新资本协议系统群等数据系统，也包括核心、贷款等交易系统。

2）报表平台：报表平台能将数据快速展示成图表、能通过建立数据立方体（CUBE）提供数据钻取（向上或向下变换数据分析维度）功能，方便业务人员快速查询和分析数据。那报表工具目前商用的比较成熟，展示也更美观，常见的有COGNOS、润乾报表、TABLEAU等，开源的报表工具功能较弱，常用的有birt、ireport、jasperreport、KYLIN（基于hadoop建立CUBE）等。

3）分析探索：有的银行也叫数据实验室或分析集市，主要指提供给业务人员自行分析的平台，银行业务部门的分析人员经常使用SQL自行分析数据，也会使用SAS或R、PYTHON进行数据挖掘，随着AI技术的深入，也逐步在尝试TENSORFLOW等深度学习的工具来分析银行数据。由于数据分析工作时间不固定，且消耗计算资源较大，因此一般都是单独给业务人员搭建一套或多套的分析环境，每套环境包括HADOOP或数据库作为数据存储，SAS、R、TENSORFLOW等作为分析引擎。同时还需要定期（一般T+1）更新分析环境的数据，提高数据分析的及时性。

6、调度平台：调度平台主要进行各数据采集、加载、计算作业的任务编排和自动运行，比如并行调度作业A、B、C，都结束后调度作业D；调度平台需要支持多操作系统、可运行多种类型脚本或程序，并具有良好的扩展性和可用性，调度平台不仅仅调度数据仓库的加工作业，也需要调度各数据类系统的数据处理任务。

使各系统作业能无缝衔接，将数据从源系统到数据仓库、到数据应用系统和数据结果应用全流程串联起来。一般的银行的调度平台每天调度的作业上万个，一些大行每天调度任务数十万个，因此一个稳定、高效、易操作的调度系统不可缺少。目前调度工具比较多，商业化的有IBM CONTROL-M、先进数通的MOIA等，开源的如azkaban、OOZIE等，由于调度系统需要调度各系统并和行内的监控系统进行集成，因此实施时需要一定的客户化工作。

7、运维监控：主要对数据仓库体系中各系统进行技术监控以及调度作业监控，ETL工具、MPP数据库以及HADOOP体系软件都带有监控工具，但还是需要进行一些客户化工作和各银行自有监控体系相结合，在统一界面进行监控、预警、按优先级进行生产问题处理。

8、数据管理：那数据仓库有那么多数据，我们怎么知道需要的数据在哪里？数据质量怎么样？某一个数据字段发生变化会有什么影响？那就需要对数据进行管理或者治理，数据管理就是对数据仓库中的元数据、数据定义、数据质量进行管理，确保数据的规范性、及时性、可追溯性，主要包括以下几个方面：

1）数据标准：数据标准是指制定和推广应用统一的数据分类分级、记录格式及转换等标准，简单说就是定义各数据表字段的格式及代码值，例如货币种类定义10位长度，其中USD表示美元、CNY表示人民币……那数据标准应该是银行整体的标准，适用于全行的所有系统，但由于各系统建设时已经各有定义，所有一般数据标准都在数据仓库进行标准化，将各源系统字段代码转换到数据标准定义的字段代码，即数据仓库的字段代码。那数据标准系统主要是定义了各字段的类型、长度、精度、代码值以及源系统字段代码值转换到数据标准代码值的映射关系。

2）元数据管理：元数据指描述数据的数据，比如数据表和数据字段的定义以及关系，那在元数据中除了查询数据仓库中各表和字段的定义外，最重要的还有两个功能：血缘分析和影响分析。血缘分析指字段X是由哪些源表字段按什么规则加工而成的，也就是说字段X的“祖宗”是谁；那影响分析指字段X变化了，比如增加了字段长度或字段含义发生了变化，那会影响到后续哪些字段，也就是字段X的“子孙”是谁；那这两个功能在日常数据分析中使用较多，特别是影响分析，源系统已采集的表结构有变化就会需要分析影响并进行同步修改。

3）数据质量：数据质量是指数据的可用性、标准规范性、正确性的检查以及数据质量整改的管理流程。由于数据源系统因为人工录入标准不清晰、录入差错、系统异常等原因导致数据差错，例如企业类型字段应该填写大、中、小微3种类型，客户经理对认定的标准不清晰将中型企业填写为了大型企业。例如对公客户地址大部分字段都没有填写；那如何发现这些数据质量问题并通过一系列流程进行数据修改，提高数据准确性和可用性就是数据质量需要做的事情。因此数据质量不仅仅是一个系统、许多数据检验规则，还有一整套数据修改和管理的流程。

以下是平台各部分的技术参考实现，数据管理的系统、运维系统由于客户化程度较高就暂不提供参考：

目前各种云平台已经也提供了数据仓库的技术服务，那从技术功能、性能、可扩展性上可以满足银行的需求，但由于银行的用户数据相当敏感和重要，数据安全非常重要。短时间看，银行数据仓库上共有云还不太现实，但在银行引入私有云及数据仓库技术组件是现阶段更可能实现的方式。

以上是银行数据仓库的整体架构，也可供其他各行业数据仓库架构设计参考。

三、银行数据仓库数据架构

狭义的数据仓库数据架构用来特指数据分布，广义的数据仓库数据架构还包括数据模型、数据标准和数据治理。即包含相对静态部分如元数据、业务对象数据模型、主数据、共享数据，也包含相对动态部分如数据流转、ETL、整合、访问应用和数据全生命周期管控治理。

数据架构层面通过数据分类、分层部署等手段，从非功能性视角将数据合理布局。通过整体架构管控和设计，支持业务操作类和管理分析类应用（系统），满足业务发展及IT转型对数据的需求，架构的扩展性和适应性能够提升数据分析应用的及时性、灵活性和准确性。

那实际情况下各个银行的数据架构体系会有所不同，根据各行的业务发展、客户数据量、交易数据量、功能需求等会有不同的演变路径以及发展方向。一般国有银行、股份制银行等全国性的银行业务较复杂，数据量也较多，数据架构也因此进化较快。常见的数据架构分区如下图所示：

1、数据采集层

数据缓冲区的数据主要是将数据从源系统加载到数据仓库中，作为数据在数据仓库的起点，数据缓存区数据只保留7-10天，以备数据问题处理，数据缓冲区的数据除了标准化的处理，最好直接获取源系统未经加工的数据，以便一次抽取，多次使用。

那标准化处理主要有编码统一转化、异常字符清理等，以便后续处理。数据采集层不仅仅只应用于数据仓库相关，也可以适用于各交易系统的批量数据或文件传输和交换，所以在全行系统层面制定规范。

2、存储计算层

1）主数据区

结构化数据的主数据区，这部分数据包括了所有的基础明细数据以及历史数据，其它区域的结构化数据都是由主数据区数据加工而来。那主数据区主要有两种模型：近源模型层和整合模型层。一般在实践过程中可以两个区域都有，也可以只有任意一个区域。这两个区的数据都通过历史拉链或历史流水的方式保留历史数据，如果有数据标准，这两个区的数据按数据标准进行字段属性如代码值、长度、精度的标准化，那这两个区的数据主要在模型设计方面有所不同：

近源模型区：表结构设计和源系统类似，在源系统表基础上增加标准化字段以及历史数据保存算法的数据日期字段，近源模型层的特点是保留源系统表所有信息，在建模和运行效率上比较高，但数据整合性不高，一些交易系统设计的表结构并不直接适用数据分析和加工。

整合模型区：整合模型区按主题进行数据整合、表设计以三范式为主，模型稳定，数据冗余少，那这里模型稳定是指即使源系统表结构如何变化，只要实体之间关系和属性不变，那整合模型也可以保持基本不变。模型稳定的一个好处就是可以屏蔽源系统变化，避免下游应用系统重复改造。

举个栗子：个人信贷系统升级，将使用新的系统，那所有表结构都会发生变化，如果直接使用近源模型区数据，那对于后续加工变化很大，同时时间跨度较大的分析（如年报）需要分别考虑新旧个人信贷系统的数据加工规则，如果使用整合模型，那整合模型变动不会太大，对于历史数据也能同时存在于一个模型(一套表)中，对于后续应用加工影响较小。

同时整合模型会在客户、账户、签约等各主要维度进行分析梳理，形成整体视图，有利于从全行视角分析。例如客户整合可以区分客户唯一性，获得客户视图；产品和签约的整合可以清楚看到客户在行内的购买的所有产品和签约。方便后续客户分析。

整合模型保留源系统的主要业务字段，因此需要考虑到后续的应用情况，建模的经验要求会比较高，各数仓的实施公司都有一套成熟的行业模型，可以快速建立起模型，但整合模型在后续建模和维护、开发相对成本较高。同时3范式的设计直接给应用系统使用会存在关联过多，性能效率不高。

所以一般在源系统新建时可以考虑先入近源模型区，等业务做大且较稳定时可以考虑入整合模型区，以避免初期投入较多人力。

2）指标汇总区

由于主数据区的数据并不合适直接提供给数据系统分析使用，因此指标汇总区是整合各数据应用的加工需求，按事实表（宽表）和维度表进行模型设计，对主数据区数据进行关联、公共指标加工，提供给多个数据应用使用，那指标汇总区可按协议（账户）、产品、客户、科目、机构等逐层汇总，指标汇总区可以消除各系统对于同一个指标分别加工导致的口径差异。

3）集市区（仓内）

仓内集市主要指和数据仓库在同一个物理平台中的集市，可以直接访问主数据区，指标汇总区数据、减少数据批量转移的成本，利用数据仓库平台分析性能快速进行数据加工，那数据集市的划分可按业务部门或下游系统关联度进行集市划分，如财务集市面向管理会计等财务分析应用进行专门的数据加工、使用者主要为计划财务部。监管集市主要面向给人行、银监进行监管报送报表的加工，涉及多个业务管理部门。

4）批量接口区

数据仓库给各下游数据应用系统、仓外集市的数据接口加工区，按双方约定的数据格式提供给数据应用系统，批量接口区按接口协议做简单关联，不做复杂加工，如果平台支持视图，接口区可以只有视图提供给下游接口，减少数据冗余。

5）非结构化数据存储计算区

主要对非结构化数据进行存储计算，按一定的数据类型、来源、用途进行区域划分，方便实时查看和分析；

6）历史数据区

面向主数据区和非结构化数据区的历史数据归档和查询。主数据区和非结构化数据区一般只保留1-3年的数据，之前的数据使用率低，可专门归档到历史数据区，提高主数据区的性能；同时历史数据区可以采用成本较低的设备，降低成本。

7）实时数据区

实时数据区主要面向流式数据的加工和处理，同时对于流处理所需的主数据区数据可以直接访问也可以存储一份在实时数据区。

8）在线访问区

在线访问区数据是数据加工结果数据，以实时数据接口方式提供给外部使用。改部分数据可以采用HBASE提供在线查询服务。

3、仓外集市数据区

仓外数据集市和仓内数据集市区别只是和数据仓库不在同一物理平台，但一样面向特定的数据应用进行加工分析，一般随着数据量的增加，数据仓库的平台负荷过大往往会将集市从仓内移到仓外，或者对于需24小时随时提供数据处理的数据集市，为了不与数据仓库平台竞争资源，也一般选择在仓外建设数据集市。

4、报表区

报表区数据是加工后的报表结果数据，为报表平台提供展示数据，因为报表系统往往是7*24小时提供服务，因此在数据平台外单独建立报表平台，减少耦合性，在行内可以建设统一的报表平台，对报表的开发、整合、维护、下线进行统一管理，减少重复报表开发。

5、数据探索区

数据探索区是提供给各业务部门进行数据探索的区域，该区域的数据根据业务分析需求从数据仓库进行加载，并T+1进行更新，由业务同事对数据进行自由分析和挖掘。该平台一般性能要求也比较高，可以使用MPP数据库或HADOOP平台进行技术实现。由于业务人员使用比较随意，该区域需要注意历史数据的清理，避免过多冗余无用的数据占用大量空间。

从数据分层来看，存储计算区是最为核心的部分，存储计算区大部分银行是由MPP数据库和HADOOP平台共同来实现，部分互联网银行单独使用HADOOP平台来实现。以下是一种常见的MPP和HADOOP平台协作的存储计算数据区的技术实现: