银行数仓分层架构

一、为什么要对数仓分层

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

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

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

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

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

二、银行数仓常见的四层架构

银行数仓分层与阿里大数据之路的分层架构类似，核心思想都是分层治之
1）【贴源层】
具备源系统数据归集到数仓的缓冲层；

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

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

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

【总结】
这是银行项目常见的分层架构，在此基础上可以根据银行本身的业务特性继续细分，如标准层可在细化为：数据预处理、数据轻度汇总层等等

三、详解各层的主要职责

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、【SDM（Standard Data Manager）标准层】
SDM 的数据处理主要分为两部分，一部分是源数据清洗及标准化，另一部分是合并全量数据。

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

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

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

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

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

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

但是，拉链模型有两个明显的缺陷，一个是当发现拉链表内某一扣环的数据异常时，拉链表应如何恢复准确性与完整性，另一个是随着数据不断增加，拉链表会越来越大，每日拉链操作的效率会越来越低。

3、【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 就可以满足业务人员频繁变动的需求了。

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

四、对比与总结
银行数仓分为四层：贴源层、标准层、主题层、应用层。
阿里大数据之路将数仓分为四层：ODS层(源数据层)、DWD层(数据明细层)、DWS层(轻度汇总层)、DIM层(维度层)、ADS层(数据应用层)
若数仓数据量比较大，业务逻辑比较复杂还可以再次基础上，创建DWT层(数据主题层)，在轻度汇总层的基础上，再按照主题进行基于业务逻辑的汇总，方便数据数据应用层的调用和加工。