银行数据仓库简介
数据仓库之父比尔（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出的定义被广泛接受：数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。比尔在著作《Building the Data Warehouse》中提出数据仓库的特征：
建立数据仓库的目的是为企业业务分析、市场营销、成本控制、战略决策提供所需要的数据支持，那在银行中，数据仓库汇聚了银行主要系统的客户、业务、财务等数据，为银行的日常运营分析、市场营销、风险控制、财务分析、内部审计、监管报送提供数据支持和服务。
银行系统群介绍及数据仓库的定位
银行作为我国金融体系中的支柱行业，银行业务涉及种类众多，业务流程复杂，且像工行、建行等国有银行服务亿级的客户，每天交易量和BAT等互联网公司不相上下，同时不能造成1分钱的误差。因此没有健壮高效的信息系统做支撑，银行的业务是无法快速发展的。
由于业务的复杂性和高业务量，银行的软件系统也错综复杂且不断迭代，小的银行可能是几十上百个系统，国有大银行可能有成百上千个系统。银行的软件系统从功能划分主要有交易类系统、数据类系统；
1、交易类系统：交易类系统是承载业务流程的实时交易系统，它们一般是7*24小时运行，是银行业务正常运转的关键系统，交易系统主要分为渠道系统和业务系统（账务系统）两类：
以前银行的核心系统包括了存款、贷款、中间业务等所有业务功能，但随着客户数、交易量的增加以及信息技术架构的发展，目前许多银行的核心系统已经按业务或功能进行了拆分，演变成了多个系统，如个人贷款系统、公司贷款系统、票据系统、总账系统、基金理财系统等，从系统上看这样演变系统间耦合性更低，扩展性更好，从业务上看，各系统的业务分工更加明确；
随着核心系统的拆分，系统间的交互原来从核心系统内部的模块调用变为了系统间的调用，如从手机银行查询客户存款账户的余额，那需要手机银行发送交易到核心系统查询。随着越来越多的子系统将独立出来，系统间的交互也更加频繁。因此很多银行在2000年后就开始建立了交易总线系统并规范系统间调用的服务，所有系统请求方的系统请求都先发送到 交易总线系统，由交易总线系统进行转发到服务提供方并将结果返回，统一了系统交互的协议、并且制定了系统间交互的规范。
2、数据类系统：由于交易类系统属于面向联机事务处理(OLTP)，需要确保交易的稳定和高效，因此消耗大量计算资源的数据加工分析不适合在交易系统中进行，因此数据类系统主要汇集各交易类系统的数据并进行加工，为各业务部门提供运营管理、风险控制、精准营销所需的数据和报表。数据类系统面向联机分析处理（OLAP）。时效性和可用性没有交易系统高，但是处理的数据量大，业务分析逻辑更复杂。常见的数据类系统有客户关系管理系统、审计系统、监管报送、报表系统等。
那数据类系统的数据主要源于各交易系统，是否每个数据类系统都各自去从交易系统获取数据并各自加工呢？答案显示是否定的，这样做不仅浪费系统获取数据、加工数据的资源，也会使各系统加工口径不一致。因此许多银行会建立数据仓库或者叫数据总线的系统，统一从交易系统抽取数据并进行存储计算。因此数据仓库在整个银行的系统中是作为全行的数据中心、数据流转的枢纽，从系统架构的定位来看主要有以下功能：
数据仓库发展已有几十年，期间也出现了不少新的数据架构，数据仓库架构也不断吸收和演变，不断完善和发展。以下也简单介绍下与几个常见的数据架构以及和数据仓库的关系。
数据仓库和ODS
和数据仓库经常一起出现的是ODS（操作型数据存储），有些银行叫ODS，而有些银行则叫数据仓库，那两者有何区别呢？ ODS (操作型数据存储)是集成的(Integrated)、反映当前数据值的(Current-valued)、经常更新的(Volatile(including update)和详细的(Detailed)数据集合，用来满足企业集成的操作型的处理需求。和数据仓库相比主要区别在于：
ODS侧重于操作型查询，查询数据范围较小，DW则侧重于分析型，查询数据范围以及时间跨度较大；
举个例子，如业务需要每隔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方面的新技术使用也较迟缓。
互联网公司在发展初期着重于产品功能及用户拓展，需要依靠数据来了解客户，分析客户，虽然一开始没有数据中台，各产品各自获取产品、客户相关数据并进行分析挖掘。通过数据发现用户在使用产品中的阻碍和问题，找出客户的痛点。那随着多个产品的成熟以及发展，数据量快速增加，数据分析工作越来越复杂，数据分析知识经验也需要沉淀，所以数据中台也为了各产品能更好的共享经验、共用数据而应用而生。
————————————————
版权声明：本文为CSDN博主「acumen_leo」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/acumen_leo/article/details/90348500