大家好，我是leo，一个ITer，在银行从事系统开发多年。经历过股份制银行、城商行、互联网银行的系统建设。对银行系统架构特别是数据仓库/ODS等数据类系统有一定的经验积累，准备将之前的一些经验整理成文，一来为自己工作做个总结梳理，二来也希望能和大家互相讨论，共同学习，探讨新技术、新架构以及趋势。以下是第一部分简介。
银行数据仓库简介
数据仓库之父比尔（Bill Inmon）在1991年出版的“Building the Data Warehouse”（《建立数据仓库》）一书中所提出的定义被广泛接受：数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。比尔在著作《Building the Data Warehouse》中提出数据仓库的特征：
面向主题的 (Subject-Oriented)
集成的 (Integrated)
保留历史的 (Time-variant)
面向决策支持的 (Decision Support)
面向全企业的 (Enterprise Scope)
最明细的数据存储 (Atomic Detail)
数据快照式的数据获取 (Snap Shot Capture)
建立数据仓库的目的是为企业业务分析、市场营销、成本控制、战略决策提供所需要的数据支持，那在银行中，数据仓库汇聚了银行主要系统的客户、业务、财务等数据，为银行的日常运营分析、市场营销、风险控制、财务分析、内部审计、监管报送提供数据支持和服务。
银行系统群介绍及数据仓库的定位
银行作为我国金融体系中的支柱行业，银行业务涉及种类众多，业务流程复杂，且像工行、建行等国有银行服务亿级的客户，每天交易量和BAT等互联网公司不相上下，同时不能造成1分钱的误差。因此没有健壮高效的信息系统做支撑，银行的业务是无法快速发展的。
由于业务的复杂性和高业务量，银行的软件系统也错综复杂且不断迭代，小的银行可能是几十上百个系统，国有大银行可能有成百上千个系统。银行的软件系统从功能划分主要有交易类系统、数据类系统；
1、交易类系统：交易类系统是承载业务流程的实时交易系统，它们一般是7*24小时运行，是银行业务正常运转的关键系统，交易系统主要分为渠道系统和业务系统（账务系统）两类：
（1）渠道系统：渠道系统就是客户接触银行的系统，这些系统大家都比较熟悉并经常使用，如ATM、手机银行、网上银行等系统；
（2） 业务系统：主要进行账户管理、业务逻辑和账务处理的系统，如核心系统、个贷系统、票据系统等；
以前银行的核心系统包括了存款、贷款、中间业务等所有业务功能，但随着客户数、交易量的增加以及信息技术架构的发展，目前许多银行的核心系统已经按业务或功能进行了拆分，演变成了多个系统，如个人贷款系统、公司贷款系统、票据系统、总账系统、基金理财系统等，从系统上看这样演变系统间耦合性更低，扩展性更好，从业务上看，各系统的业务分工更加明确；
随着核心系统的拆分，系统间的交互原来从核心系统内部的模块调用变为了系统间的调用，如从手机银行查询客户存款账户的余额，那需要手机银行发送交易到核心系统查询。随着越来越多的子系统将独立出来，系统间的交互也更加频繁。因此很多银行在2000年后就开始建立了交易总线系统并规范系统间调用的服务，所有系统请求方的系统请求都先发送到 交易总线系统，由交易总线系统进行转发到服务提供方并将结果返回，统一了系统交互的协议、并且制定了系统间交互的规范。
2、数据类系统：由于交易类系统属于面向联机事务处理(OLTP)，需要确保交易的稳定和高效，因此消耗大量计算资源的数据加工分析不适合在交易系统中进行，因此数据类系统主要汇集各交易类系统的数据并进行加工，为各业务部门提供运营管理、风险控制、精准营销所需的数据和报表。数据类系统面向联机分析处理（OLAP）。时效性和可用性没有交易系统高，但是处理的数据量大，业务分析逻辑更复杂。常见的数据类系统有客户关系管理系统、审计系统、监管报送、报表系统等。
那数据类系统的数据主要源于各交易系统，是否每个数据类系统都各自去从交易系统获取数据并各自加工呢？答案显示是否定的，这样做不仅浪费系统获取数据、加工数据的资源，也会使各系统加工口径不一致。因此许多银行会建立数据仓库或者叫数据总线的系统，统一从交易系统抽取数据并进行存储计算。因此数据仓库在整个银行的系统中是作为全行的数据中心、数据流转的枢纽，从系统架构的定位来看主要有以下功能：
（1）数据抽取：采用统一工具从源系统（数据提供系统）获取数据；
（2）数据存储：存储源系统的数据以及加工计算的数据结果，按时间进行数据的积累；
（3）数据加工计算：对源系统数据进行关联、清洗、转换、汇总计算；
（4）数据分发：对源系统数据以及加工计算结果进行分发到目标系统（数据使用系统）；
图1.1
数据仓库发展已有几十年，期间也出现了不少新的数据架构，数据仓库架构也不断吸收和演变，不断完善和发展。以下也简单介绍下与几个常见的数据架构以及和数据仓库的关系。
数据仓库和ODS
和数据仓库经常一起出现的是ODS（操作型数据存储），有些银行叫ODS，而有些银行则叫数据仓库，那两者有何区别呢？ODS (操作型数据存储)是集成的(Integrated)、反映当前数据值的(Current-valued)、经常更新的(Volatile(including update)和详细的(Detailed)数据集合，用来满足企业集成的操作型的处理需求。和数据仓库相比主要区别在于：
（1） ODS侧重于操作型查询，查询数据范围较小，DW则侧重于分析型，查询数据范围以及时间跨度较大；
（2）ODS对响应速度要求较高，通常在秒级；
（3）DW侧重于历史数据，ODS以当前为主，历史较少；
（4）ODS偏重于准实时更新，也可批量加载，DW偏重于批量加载；
（5）DW采用主题范式化建模，ODS多采用与业务系统同构方式建模；
（6）DW将对数据进行清洗和整合，ODS则尽量保持源数据原貌，以满足那些强调原样数据的需求，同时为数据质量检查提供原始资料；
举个例子，如业务需要每隔1分钟统计下手机银行的交易量，或者统计某个网点在1小时内的存取现金情况都属于ODS的范畴，如统计去年每个月的手机银行交易量以及变化趋势，并分析那个时间段是手机银行访问的高峰期则属于数据仓库的范畴。
但随着技术平台以及银行数据需求的发展，银行的数据仓库或ODS逐渐合二为一，也就是说在同一个平台既能满足ODS实时或准实时的数据查询也能满足数据仓库的全行范围近几年的数据统计和趋势变化分析。因此从功能和作用上来看，银行的ODS和数据仓库其实说的就是同一个系统了。
图1.2
数据仓库和数据集市
数据集市（Data Mart）是数据仓库的一个子集，用于从数据仓库获取相关的数据加工后提供给用户，数据集市通常面向特定的业务或者团队，如市场部门有对应的营销数据集市，运营部门有运营数据集市等。
银行的数据集市主要有财务、营销、风险等集市，这些集市为各对应的数据系统进行数据加工，另外也会为各业务部门数据分析人员提供分析集市，由数据仓库提供相关数据后，由业务人员自行进行数据探索分析。银行的数据仓库体系一般包括了数据集市，将数据集市作为数据仓库体系的一部分。
数据仓库和数据湖
数据湖是一个集中化存储海量的、多个来源，多种类型数据，并可以对数据进行快速加工，分析的平台。数据湖以其本源格式保存大量原始数据，包括结构化的、半结构化的和非结构化的数据。在需要数据之前，没有定义数据结构和需求。那与数据仓库的区别主要在以下几方面：
（1）数据格式：数据湖保留了数据的原始格式，包括图片、WORD、PDF等文档、影像、语音等多种数据格式，而数据仓库一般是将原始数据进行一定处理后，获得结构化的数据放到关系数据库中。
（2）数据存储：数据湖采用大容量低成本的存储，目前流行使用Hadoop进行数据湖数据存储和计算, 数据仓库以前常用MPP架构并行处理数据库，存储成本较高，目前互联网公司也采用Hadoop进行数据仓库的建设；
（3）数据使用：数据湖数据不需要提前定义数据模型，主要进行探索分析，数据湖中的数据通过map-reduce等大数据技术来处理，而进入数据仓库中的数据一般是已经有确定的使用用途，达到一定的分析目标，常使用SQL、数据分析软件如SAS等方式进行分析处理。
笔者认为数据湖和数据仓库是互相补充的关系，原始数据的保留为数据分析提供更多的尝试。目前随着Hadoop生态发展越来越成熟，许多银行已经将Hadoop平台纳入到了数据仓库体系中，作为非结构化数据的存储和计算平台，因此也具备了数据湖的功能，但是银行的数据分析人员还是习惯于使用结构化的数据即数据仓库中的数据进行业务分析。
图1.3
数据仓库和数据中台
数据中台这个概念是由阿里首次提出，阿里现在拥有众多业务分支系统，如淘宝，天猫，阿里妈妈，阿里巴巴等，每套系统都有自己的体系和数据源，都在各自的系统上做了很多服务，但数据在各系统之间无法共享，各系统之间还会有功能和数据，服务和应用的冲突，为了解决这些问题，阿里开始整合挖掘数据，打造数据中台，从一开始知识做数据的监测和统计到后来的数据化运营和分析，再到搜索个性化，定制化营销，再到智能化，渐渐让各个体系融合在一起，建立统一的体系，就算再扩展业务也是纳入这个中台，用相同的技术和模式进行运营。
所以数据中台是指通过数据技术，对海量数据进行采集、计算、存储、加工，同时统一标准和口径。数据中台把数据统一之后，会形成标准数据，再进行存储，形成大数据资产层（数据模型，算法服务，数据产品，数据管理），进而为客户提供高效服务。这些服务跟企业的业务有强关联性，是这个企业独有的且能复用的，是企业业务和数据的沉淀。比如企业自建的2000个基础模型，5万个标签。数据中台还包括了数据技术，比如采用统一的技术及框架对海量数据进行采集、计算、存储、加工的一系列技术集合。
数据中台不仅能降低重复建设，减少烟囱式协作的成本，也能快速提供业务数据进行分析，使数据产生价值，同时数据中台通过为业务场景提供数据服务，业务场景也不断产生新的数据及分析模型反馈，滋养给数据中台，使数据中台不断发展。
那从银行来说，银行数据仓库体系应该包括数据中台的功能，许多银行特别是国有银行和股份制银行借鉴国外先进银行的经验和架构，在2000年后都开始建立数据仓库，进行了各业务数据的整合并统一提供数据服务，有些金融集团也在集团层面上整合了各子公司的数据。在数据规范和整合方面许多银行已经完成，数据平台技术架构也已经统一，但是在数据意识、数据思维方面和互联网企业还是有不少差距，许多银行业务拓展更多依赖经验、客户经理、简单的数据统计，大多应用往往集中在报表、监管报送、审计、风险控制等管理应用，在客户行为分析、精准营销、风险控制等方面还未深挖，在机器学习、AI方面的新技术使用也较迟缓。
互联网公司在发展初期着重于产品功能及用户拓展，需要依靠数据来了解客户，分析客户，虽然一开始没有数据中台，各产品各自获取产品、客户相关数据并进行分析挖掘。通过数据发现用户在使用产品中的阻碍和问题，找出客户的痛点。那随着多个产品的成熟以及发展，数据量快速增加，数据分析工作越来越复杂，数据分析知识经验也需要沉淀，所以数据中台也为了各产品能更好的共享经验、共用数据而应用而生。
数据仓库管理着整个银行或公司的数据，数据结构复杂，数据量庞大，任何一个数据字段的变化或错误都会引起数据错误，影响数据应用，同时业务的发展也带来系统不断升级，数据需求的不断增加，数据仓库需要不断的升级和维护，才能保证为全行提供持续完整准确的数据服务。所以数据仓库基本上是全行或全公司版本最多的系统，如何保证在频繁的变化中保证数据的准确和系统的稳定，需要数据仓库的开发管理必须做到高效、有条不紊。
１、数据仓库开发流程
１.１、规范先行
数据仓库从开发上看，数据加载和导入的程序相对固定，开发工作主要是数据转换的SQL脚本的分析和开发。那SQL的分析和开发最主要的还是基于业务逻辑进行编写，所以对数据字段的理解以及对业务规则的熟悉是数据仓库模型人员和开发人员都需要具备的知识，同时数据和规则又会不断变化，那如何确保快速开发，开发的代码具有可读性、模型设计具有一致性，最重要的是在数据仓库建立时就制定相应的规范，使整个团队能按规范同步进行开发、设计。那在数据仓库中主要有以下规范：
（1）命名规范：包括ETL作业、数据库或大数据平台的对象（表、字段、存储过程、schema名或库名）、脚本名、文件名等都需要按一定的规则进行命名，以便快速定位。
（2）ETL开发规范：包括抽取、加载作业的开发规范、调度工具的使用规范、SQL脚本或作业的开发规范、开发流程规范等：
（3）数据模型设计和维护规范：主要对主模型区、汇总指标层、集市层的模型设计原则、方法、重要规则（如客户ID）进行统一。
通过规范先行，能在数据仓库建设及后续维护中能快速统计数据仓库的运行情况，如系统作业的关键路径、表数量以及空间使用情况，源系统变化的影响情况等，避免产生混乱，比如许多数据仓库或系统随着不断变化和增加，连哪些表在使用，哪些数据已经不更新了、目标表使用了哪些源系统数据字段都不能马上分析出来，需要花费人力来梳理，一段时间后又回归混乱。这种情况不仅无法有效分析数据仓库的实际运行情况，更会带来生产问题的安全隐患。
１.２、开发流程
之前已经提到数据仓库从头建设的流程，那现在以某个数据应用对数据仓库提出需求来看整个系统维护的开发流程，主要步骤如下，
（1）需求分析，确定数据集市和数据仓库的接口字段和内容，明确数据需求；
（2）模型开发和维护：分析现有模型是否满足所有接口字段需求，如果不满足则需要从源系统增加入仓的表数据，并分析更新主数据区、汇总指标区和数据集市的逻辑模型、物理模型，并确定数据接口字段的映射关系，如果满足则只需确认映射规则；
（3）ETL开发：开发数据库或大数据平台的数据脚本以及作业脚本，并根据测试和生产验证的情况修正逻辑模型；
1.3、分工及职责
数据仓库团队主要分为模型人员、ETL开发人员和测试人员，其中模型人员主要是进行需求分析和模型维护，ETL开发人员负责代码实现和系统维护，开发流程中各角色工作如下：
那在许多银行实际开发中，根据公司团队规模不同模型人员的职责也会有所差别，模型人员有的属于数据仓库开发团队，只负责数据模型维护，有的属于科技规划团队即又称SA，模型人员除了模型维护可能还兼顾项目经理、系统分析的角色。那模型人员也可能分别负责主模型区、汇总指标区和数据集市。所以模型团队内部也需要定期同步数据模型的变化和更新，统一设计规则和数据分布边界；
2、数据仓库开发管理系统
通过规范、标准流程和分工协作可以保证数据仓库开发工作有条不紊，但如何高效执行整个开发流程，提高代码开发效率。则需要有数据开发管理工具的支持。
之前在ETL开发中也介绍了一些开发实践，如标准的数据采集和加载作业、按ETL算法和数据映射自动生成数据转换脚本，那这些都可以通过工具整合并管理。通过开发管理工具对整个开发流程的模型数据、ETL数据和代码进行管理和维护，通过系统化来协助模型设计和开发，那对于一个数据仓库开发管理系统，主要有以下几方面功能：
2.1数据模型维护功能
模型维护的功能许多是有文档来进行，通过系统的整合可以提高效率，增加信息的可统计性。
（1）对于源系统调研信息进行管理，可对源系统的每个表和字段调研备注信息进行存储修改，同时针对每个需求新增的表和字段都进行维护，以便沉淀经验。
（2）逻辑模型管理，这个功能如果已经是通过ERWIN或POWERDESIGN等工具进行管理，可以只将结果和历史版本进行维护。如果自己开发，可以集成一些开源工具的逻辑模型功能，统一在开发管理系统中维护。
（3）物理模型管理：物理模型主要是根据逻辑模型可以自动生成物理模型，模型人员和ETL开发人员在这个基础上进行物理化，增加索引、压缩、分区等信息。开发管理系统需要对物理模型进行存储和记录版本变更记录，那各个数据区的物理模型都可以在开发管理系统中维护，同时针对每次版本的变更，自动生成数据库或者大数据平台的数据库脚本。
2.2 ETL作业信息配置及代码生成
（1）数据映射：管理第5节介绍的数据转换作业映射文档，在配置算法等信息后，自动生成数据转化作业代码；
（2）数据采集和加载：管理数据采集作业和加载作业的信息，具体可见第4节，并自动生成采集和加载作业的脚本；
（3）调度作业：可以集成调度工具测试环境，根据ETL作业脚本信息，自动生成调度作业的脚本并同步作业信息到调度系统，并在调度工具中配置依赖关系后并测试后形成上线的调度作业配置版本。
2.3 打通测试环境和版本管理工具
数据仓库的代码主要是ETL脚本，无需编译，只需放在规范的目录下即可，由于生成代码后还需要提交到版本管理工具以及测试环境进行测试，因此可以直接调用版本管理工具的命令进行生成的代码更新，再通过版本发布工具发布到测试环境。如果没有版本发布工具，可以直接在开发管理工具中集成脚本传输的功能，在测试环境验证后再更新版本管理工具上的代码分支。
通过打通测试环境和版本管理工具，可以提高自动化，确保从系统自动产生代码和脚本，使维护的信息和生产脚本确保一致。
来源：https://www.jianshu.com/p/14822821c239；https://www.jianshu.com/p/bd1d922d1241
推荐文章：大数据项目落地实施路线
