浅谈银行的数据仓库：分层架构篇

为什么要对数据仓库进行分层

自从大数据平台hadoop及其技术火起来之后，无论是政企、民企还是各类金融机构，都掀起了一股大数据技术转型、数据仓库重构、智能数据分析、AI 等一系列黑科技且高大上的热潮。其实，是否转型大数据技术以后，产品营销、风险管控、数据分析、管理决策等企业核心诉求都可以应有尽有呢？企业的数据管理核心——数据仓库又应该以何种形态来建设？要回答上述问题，必须要从理解数据仓库的本质与架构开始。

数据仓库，由数据仓库之父 Bill Inmon 在 1991 年出版的“Building the Data Warehouse”定义且被广泛接受的——面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策。从定义上来看，数据仓库的关键词为面向主题、集成、稳定、反映历史变化、支持管理决策，而这些关键词的实现就体现在分层架构内。

实现好分层架构，有以下好处：

1）清晰数据结构：每一个数据分层都有对应的作用域，在使用数据的时候能更方便的定位和理解。

2）数据血缘追踪：提供给业务人员或下游系统的数据服务时都是目标数据，目标数据的数据来源一般都来自于多张表数据。若出现目标数据异常时，清晰的血缘关系可以快速定位问题所在。而且，血缘管理也是元数据管理重要的一部分。

3）减少重复开发：数据的逐层加工原则，下层包含了上层数据加工所需要的全量数据，这样的加工方式避免了每个数据开发人员都重新从源系统抽取数据进行加工。

4）数据关系条理化：源系统间存在复杂的数据关系，比如客户信息同时存在于核心系统、信贷系统、理财系统、资金系统，取数时该如何决策呢？数据仓库会对相同主题的数据进行统一建模，把复杂的数据关系梳理成条理清晰的数据模型，使用时就可避免上述问题了。

5）屏蔽原始数据的影响：数据的逐层加工原则，上层的数据都由下一层的数据加工获取，不允许跳级取数。而原始数据位于数仓的最底层，离应用层数据还有多层的数据加工，所以加工应用层数据的过程中就会把原始数据的变更消除掉，保持应用层的稳定性。

了解了分层架构的好处，关键是该如何进行规划与建设。

数据仓库核心分层

目前市场上主流的分层方式眼花缭乱，不过看事情不能只看表面，还要看到内在的规律。从繁多的分层方式中，可以提炼出以下共性：

1）具备源系统数据归集到数仓的缓冲层，或称为贴源层。

2）具备数据标准化及合并全量数据的标准层。

3）具备主题划分及明细数据整合的主题层。

4）具备提供数据服务给下游系统使用的集市层，或称为应用层。

5）除上述核心分层，其他分层是从核心分层上细分得到的。

所以，数据仓库的核心分层为 ODM 贴源层、SDM 标准层、FDM 主题层、ADM 应用层，如下图所示：

ODM（Origin Data Manager）贴源层

主要用于源系统提供的 T-1 增量文本数据按源系统一致的数据结构入库到数据库。为什么要把源系统数据（简称源数据）入库到数据库，而不是直接合并到全量数据呢？存在以下原因：

1）直接处理文本数据的话，要先把文本数据加载到内存上，要是数据大小超过 GB 级别，对服务器内存压力可不小。所以该处理方式对服务器硬件要求高，假如把文本数据先通过数据库落地到磁盘上，可以减轻后续处理的硬件压力。另外，文本数据本身是没有结构的，直接处理时还得虚拟成二维表才容易处理，但是文本数据加载到数据库后自动形成二维表，便于后续处理。

目前有部分关系型数据库，支持建立外部表，使用二维表的方式读取文本数据，比如 greenplum，但是该方式的读取效率还是比不上把数据存放在数据库内。

2）由于 ODM 位于数仓的最底层，一旦源数据入库出错，可从最底层隔断后续的数据加工流程，避免把错误的源数据入库到标准层引发连环生产问题。

3）当发现上层数据异常时，可通过 ODM 排查根因是否出现在源数据上。

ODM 的建设分为源数据抽取及源数据入库两部分。源数据抽取的处理方式有两种，一种是由源系统的技术团队按照数仓要求的接口格式，抽取数据推送到数仓来实现，另一种是由专门的 ETL 团队负责源数据抽取及源数据入库的实现。部分企业会选择第一种实现方式，这是因为缺乏专门的 ETL 团队承担，或者不希望 ETL 团队多接活（接锅）。事实上，为了从根本上保证数仓的数据质量，还是用第二种方式实现才是最好的，这也是企业建设数仓时会忽略的一点。

ODM 看似是数仓里的最底层，也是最容易实现的层级，因为数据结构与源系统一致，保证数据正常入库即可。但是保证数据正常入库，真的是那么容易实现吗？大家是否遇到过以下问题：

• 源数据抽取到数仓，没有任何保证数据完整性的措施，过段时间后才发现数仓漏数了，又得从源系统进行数据初始化；

• 一旦源数据抽取出现异常，缺乏预警通知机制，只有在数仓加载数据时才发现数据尚未推送过来，影响后续数据加工；

• 源系统出现数据模型的新增或变更后，没有及时通知数仓，到数仓加载数据出现报错时才发现，逼着数仓进行紧急变更。

上述问题的出现，就是因为没有把握到 ODM 建设的核心，构建一条完善的数据抽取——数据入库的 ETL 路线。ODM 建设的核心有以下方面：

1）建立数据抽取——数据入库的全流程校验机制。进行数据抽取时，把落地的文本数据记录数与源系统抽取记录数进行匹对，即可完成数据抽取的完整性校验。进行数据入库时，把入库的记录数与文本数据的记录数进行匹对，即可完成数据入库的完整性校验。

2）使用元数据管理工具，定时同步源系统的数据结构到数仓进行比对，当发现差异时及时预警。

3）由于数据抽取及数据入库的处理流程都是固定的，可固化为一套程序，未来源系统出现新增或者变更需求时，只需处理好映射关系即可，无须重复开发处理流程。

4）建设预警机制，笔者比较推荐使用短信预警通知，这样无论是否在公司，都可以实时了解到 ETL 作业的执行情况，及时对异常进行处理。当然，由于生产环境的操作权限在运维团队手上，预警机制还需要运维团队配合一起实现。

SDM（Standard Data Manager）标准层

SDM 的数据处理主要分为两部分，一部分是源数据清洗及标准化，另一部分是合并全量数据。

由于源数据的质量参差不齐，为了使数仓内的数据是标准规范的，所以对源数据要按照数据标准，进行数据清洗和标准化转换（PS：由于源数据已入库到 ODM，所以数据清洗及标准化转换都是在数据库层面进行，再次体现 ODM 建设的必要性）。数据标准由数据管理团队负责制定的，所以数仓建设团队也要与数据管理团队深度合作才能做好数据标准化的动作。

这里可能有个疑问，数据清洗与标准化的动作能否放在 ODM 完成呢？答案是不能，因为 ODM 目标是要求入仓数据与源数据完全一致。若 ODM 已对源数据进行了清洗与标准化动作，未来排查数据异常时就不能根据 ODM 来排查根因是否出于源数据了。

合并全量数据的方式有三种，分别为全量更新、增量变更及增量流水。

全量更新，数据抽取时把源系统表的数据全量抽取过来，该更新方式只需把 SDM 对应表的数据先清空，在入库标准化后的数据即可。

增量变更及增量流水，数据抽取时把源系统表内变化的数据抽取过来。两者区别是，增量变更的数据除了包含新增数据外，还包含对历史数据有变更的数据，而增量流水的数据只包含新增数据。

增量流水的数据处理方法相对简单，直接把增量数据入库到表内即可。增量变更的数据一般采用拉链模型来处理，这样既保证可以查询到任意时刻的历史全量快照，也可以减少数仓的存储空间。拉链模型，顾名思义，就是把历史变化的数据一环扣一环，就像链子一样串联起来。当查询数据时，按照扣环上的时间标识进行查询即可。具体实现方式为第一次入库的全量数据，把开始时间记录为入库日期，结束时间记录为永久日期（比如 2999-12-31）。后续入库增量的数据涉及历史数据变更时，把出现变更的旧数据的结束时间记录为当前入库的日期，再把新数据的开始时间记录为当前入库的日期，结束时间记录为永久日期，并写入到表里。这样，要查询历史时点数据，根据开始日期和结束日期的范围查询即可。

然而，拉链模型有两个明显的缺陷，一个是当发现拉链表内某一扣环的数据异常时，拉链表应如何恢复准确性与完整性，另一个是随着数据不断增加，拉链表会越来越大，每日拉链操作的效率会越来越低，该如何优化数据存储方式来避免该问题，未来会展开新的文章说明。

FDM（Finance Data Manager）金融主题层

为了让复杂的源数据变得容易理解及使用，必须按照相同的金融主题把数据整合到同一套模型中，对 SDM 数据进行明细级的数据整合汇总。主题设计的数量不宜太多，否则整个 FDM 就达不到简化的作用。FDM 是数仓模型设计的关键，ODM 与 SDM 的数据结构都与源系统数据结构一致（SDM 的数据结构会多一层标准化），模型设计难度不大，但是 FDM 要化繁为简，非常考验建模师对业务的理解及建模经验。FDM 是后续数据分析及数据集市加工的基础，核心是数据关系的简化及复用，设计不好反而会成为整个数仓的累赘，食之无味弃之可惜。由于文章篇幅关系，FDM 的金融主题划分与建模思路未来会展开新的文章进行讨论。

可能会有疑问，能否不建设 FDM，集市数据及数据分析直接从 SDM 进行呢？答案是能，但是后续维护的代价非常大，主要有以下原因：

1）FDM 的核心之一是数据复用，缺乏 FDM 的话，相同数据加工都必须编写重复的处理逻辑实现，技术团队的开发量会大大增加；

2）FDM 的核心之二是数据关系简化，缺乏 FDM 的话，每个数据开发工程师都要理解各个源系统之间的数据关系，开发门槛极高，最终导致技术团队实施成本过高；

3）假如 ADM 是从 SDM 加工获得，源系统发生任意变更，都会影响到 ADM，这时 ADM 的稳定性就无从谈起。笔者的公司曾经试过信审系统重构从而新信审系统的数据模型变化极大，而当时数仓缺乏共性整合的 FDM，导致本次变更对依赖数仓的数据应用造成难以估量的影响。而且由于需求分析阶段没有识别到这个风险点，最终导致信审系统重构项目被迫延迟 2 个月才能上线，而数仓为了减少对数据应用的影响，把源系统的变更放在 SDM 内实现，这就是 FDM 的重要性。有 FDM 的话，所有源系统的变更都可以在 SDM 加工到 FDM 的过程进行屏蔽，这样数仓会更加适应源系统引发的变更。

另外，为什么 FDM 是明细级数据的加工呢？这是为了建设数据自助分析平台做准备的。假如是高度汇总的指标数据，业务人员一旦对指标口径发生变更，技术人员就会疲于奔命的变更指标的逻辑代码来满足业务人员的需求。而明细级数据可以为业务人员提供自由组合的业务逻辑，技术人员只需要不断扩展 FDM 就可以满足业务人员频繁变动的需求了。

ADM（Application Data Manager）应用层

应用层就是以特定业务场景为目标而高度汇总的数据，一般以数据集市的形态呈现，比如大家常说的营销集市、风险集市、绩效集市。由于数据集市的建设对应的是特定且独立的业务场景，几无共性可言，所以必须对每类集市进行单独说明。

小结

想要了解数据仓库的建设，必须要了解数据仓库的分层架构。然而仅了解分层架构的内容，对数仓的建设仍只停留在形而上学的阶段。知其然也知其所以然，真正了解分层架构划分原理及建设思路，才会对分层架构融会贯通，未来面对千变万化的业务形态及数据形态，仍有共性的手段来处理。

建设数据仓库犹如创造一条新的生命，分层架构只是这条生命的逻辑骨架而已。想要在骨架上长出血肉，就必须进行合适的数据建模，数据仓库的强壮还是孱弱，健美还是丑陋，就取决于建模的结果。

如果想要这条生命正常发挥力量，还需要搭配合适的技术平台，才能把力量发挥到点上，而不是有力使不出。最后，要想这条生命茁壮生长的话，还必须作息规律（流程规范）、了解自己（元数据管理）、做好身体检查（数据质量管理）及学会防身术（数据安全管理）。