数据仓库分层设计_数仓标准层

美团配送数据治理实践

美团配送数据治理实践 - 美团技术团队

数据仓库分层没有绝对的规范，适合的就是最好的，特别是企业已经有一个初版的数仓的时候，需要做好改造成本和可理解性之间的平衡。

数据仓库是一套方法论，从规范定义、模型设计到数据服务，再到数据可管理、可追溯、可复用。

背景

在之前的文章

高威：浅谈数仓模型（维度建模）​zhuanlan.zhihu.com

中，有读者比较关注数仓分层的意义和作用，以及如何建立一个比较完善且能落地的数仓体系，所以在这里单独开一栏主要介绍数仓的分层原理，和针对不同阶段公司或者业务过程中数仓搭建主要关注的点。

定义：

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

说到数仓不可避免的和传统的数据库进行比对：

所以数仓是面向分析型的，主要集中在数据的ETL、数仓模型的建立、数据治理、数据质量的监控、数据资产的沉淀、数据指标体系的搭建，为了方便快速的达到数据获取和数据支撑的目的，同时规避了数据指标不统一造成的数据准确性不足的问题以及重复建设的冗余而建立的一套公司层面或者业务支撑层面的一套规范化数据流向的方案。

目的：

数仓的核心是解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题，并提供给分析人员一个清晰可用的展现层，方便快速的业务支撑。

特征：

1、集成（面向主题）

数据是分散的，由于事务处理应用分散、蜘蛛网问题、数据不一致问题、外部数据和非结构化数据。数据仓库中的数据是为分析服务的，而分析需要多种广泛的不同数据源以便进行比较、鉴别，因此数据仓库中的数据必须从多个数据源中获取，这些数据源包括多种类型数据库以及文件系统等，它们通过数据集成而形成数据仓库中的数据。

这块的集成主要集中在数据源大量的数据预处理工作（ETL），通常的模型方式是通过E-R模型进行数据整合。目的将各个系统中的数据以整个企业角度按主题进行相似性组合和合并，并进行一致性处理，为数据分析决策服务，但是并不能直接用于分析决策。

特点：

1. 一般是公司总栈层面的整合，所以需要全面了解企业业务和数据；
2. 实施周期非常长，需要整合全部的数据，并在企业业务角度对数据进行相似性组合和合并，并进行一致性处理；
3. 对建模人员的能力要求非常高；

2、相对稳定（非易失）

数据仓库中的数据是经过抽取而形成的分析型数据，不具有原始性，主要供企业决策分析之用，执行的主要是‘查询’操作，一般情况下不执行‘更新’操作。同时，一个稳定的数据环境也有利于数据分析操作和决策的制订。

但这也不等于数据仓库中的数据不需要‘更新’操作。一般来说会建立数仓模型一些数据的生命周期管理，依据数仓数据的重要程度、数据调用情况等等指标，对已有的数据进行规范化管理。

3、反映历史变化（全量或者增量变更）

数据仓库中的数据必须以一定时间段为单位进行统一更新，因为数仓数据是支撑公司层面业务数据从开始到发展过程中的所有数据变化，所以需要进行数据全量存储，并记录历史变化的过程，方便业务数据能够溯源。

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

全量更新，数据抽取时把源系统表的数据全量抽取过来，这个一般是每天建立一个时间分区，保留全量的数据，不过缺点很明显就是太占存储空间。

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

增量流水的数据处理方法相对简单，直接把增量数据入库到表内即可。增量变更的数据一般采用拉链模型来处理，这样既保证可以查询到任意时刻的历史全量快照，也可以减少数仓的存储空间。

拉链表的实现方式：

高威：HIVE拉链表实现​zhuanlan.zhihu.com

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

所以在拉链和全量更新的时候，是根据业务表的具体情况来进行选择的。一般来说，数据量很大，但是每天更新的占的比重很少，才会选择拉链的模式。

数仓建设解决的痛点：

1、使用门槛高：数据工作是一个专业性特别强的一个工作，对于人员的要求比较高。在一些数据的工作当中需要人员有专业的数据基础能力，这样就导致了数据人力的缺失，可能会影响业务的数据支持力度；
2、口径不一致：在使用数据过程当中，口径不一致是特别常见的一种问题，这种问题可能会导致一种数据使用和分析的差异，而且会降低业务的数据分析效率，最终对业务决策造成严重影响；
3、数据可靠性低：在生产过程中，降低业务的数据分析效率，最终会对业务决策造成严重的影响，不仅数据链路过程很长，其中还会引入很多数据质量问题。并且，由于环节过多，也带来了生产时间延迟的问题，可能直接影响到后续核心报表，推荐、模型的优化；
4、跨业务难度大：因为缺少一个统一的数据建设的规划、标准和规范，所以难以指导各个业务或者整个生产链路的各个环节，以拥有一个标准化的生产和处理过程，就导致了多个业务的数据难以融合，难以发挥更大的数据价值；
5、接入成本高：这主要应用在一个新的业务场景下，也就是说，如果有新的业务接入或者新的场景需要使用数据，很多工作都需要人工处理。去申请各种资源、权限、找数据并且串联整个数据的采集、生产、计算、同步和展示等各个环节，这是一个耗时长、效率低，最终还是很容易出错的过程；
6、获取数据难：可能在大家日常工作中会发现，我们数据的生产到最终使用，中间可能要经历一个比较长的时间周期或者一个比较宽的团队跨度，用户可能无法很快地找到想要的数据，或者数据团队生产出来的数据并没有真正触达到业务，来达到它的数据价值；
7、数据资产模糊：这个点可能和获取数据难有一点点关联，数据资产模糊的话更多的是在说我们需要对公司的数据资产做一个整体的管理，如果没有这个整体的管理，就会导致对数据资产的级别和我们自己拥有什么数据资产都很模糊。最终就是导致数据的优势难以发挥出来，而且虽然我们耗费了很多计算资源、人力资源、存储资源，但没有带来相应的价值，最终导致资源效率极低。

针对上面的痛点，一般来说先是能够达到快速的业务支撑的目的，在期间不可避免的出现重复建设和数据指标不统一的问题，在业务发展到一定程度再去补充数据治理的能力和数据指标监控能力能力。治理工作的内容主要包括对数据和任务进行日常审计，然后通过数据血缘和使用情况，对数据的冗余度进行有效评估，并进行相应的优化，以减少资源和人力的浪费。同时在生产过程中，如果出现生产不稳定的情况，我们也可以快速地发现问题，进而优化整个的生产链路，提高整个数据生态的健康度。

不过有一点，在数仓模型建设过程中，需要先规范好一些维度：
1、数据表创建的约束性：比如我们需要对表有的命名规范要求，如果没有一个工具去管理，可能会因为大家对规范的理解不一致，最终导致落地过程中依然存在各种各样的差异性；

2、数据信息的可描述性：指在创建表的过程中，为了快速地满足业务，很少去添加一些相关的描述信息，导致数据缺少描述性。所以需要要求用户在数据创建的过程中把信息描述的足够精细，方便后续的数据使用过程；

3、数据建模体系的完整性：指在数据开发过程中，要有整体的业务考虑，落地一些通用性的维表，避免用户为了快速地满足业务需求跳过某些过程，最终导致建模的扩展性较差；

4、数据关系的维度与指标管理的系统性：数据的血缘关系、数据指标建立的标准、对外输出统一的指标和维度，促使我们后续数据表和字段的相互关系是有记录可查询的，而且数仓的指标是唯一和准确的。

当然上面针对具体的公司，数仓这块的侧重点可能不一样，需要做的工作也不尽相同。目前我们公司的架构如图：

数仓分层

很多人都关注数仓分层的具体分法和逻辑，而且目前市场上主流的分层方式眼花缭乱，不过看事情不能只看表面，还要看到内在的规律，不能因为分层而分层。

分层的目的解决当前业务快速的数据支撑目的，为未来抽象出共性的框架并能够赋能给其他业务线，同时为业务发展提供稳定、准确的数据支撑，并能够按照已有的模型为新业务发展提供方向，也就是数据驱动和赋能。

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

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

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

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

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

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

一般来说数仓分层有一下几个共性：

1、数据湖，源系统数据归集到数仓的缓冲层，或称为贴源层（ODS）；

主要收集来自各业务线或行业内的外部数据并对数据进行汇总，ODS层不承担任何的数据清洗和治理的工作，在数据上和业务系统保持一致，ODS层采用分区表的形式按批次存储据,ODS层保留了业务系统的原始数据，不对外开放查询。

ODS层主要以全量方式同步数据，保留全量数据恢复的能力，同步的数据为T+1的新增和变更记录，永久保存历史数据。

2、数据仓库层，具备数据标准化及合并全量数据的标准层，其中数仓建模主要集中在这一层（DW）。

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

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

当然这个分层可以进一步拆分，其中最主要的是DW层的模型建立：

其实相对来说数仓模型的建设并不复杂，只要关注以下几点就行：

1、OneData：数仓所有数据只加工一次，对应到数仓的设计层面，要求有统一的维度，对于明细层数据，相同粒度的度量只加工一次，对于汇总层的数据，相同粒度的指标只存在一份。避免重复建设的问题；

2、OneIndex：数仓指标体系都具有唯一性，通过原子指标+派生指标来规范所有的指标系统，避免数据不一致性的问题；

3、OneService：数据服务划清了数据和应用的边界，数据服务提供的是加工好的指标数据，应用通过数据服务，直接获取计算的结果，强制把公共计算逻辑下沉到数据层面，提高了数据的共享能力，避免通过不同层次获取数据导致的数据准确性和安全性的问题；

4、OneLine：最大程度上保障数据流转的透明性，不同层级做不同层级的数据处理逻辑，不可逆向依赖，方便后续数据血缘关系、数据地图的建立，避免数据杂乱，无法溯源；

5、OneEntity：这块主要是模型方面的建设，同一个用户，在同一个模型中，可能存在重复的记录，如何识别两个 ID 是同一个用户，做到所有用户只有唯一的 ID 标识，这个是 OneEntity 要解决的问题，其实归根结底就是ID-Mapping问题。

参考文献：

浅谈银行的数据仓库——分层架构-InfoQ​www.infoq.cn存储成本降低80%，有赞数据中台成本治理怎么做的？-InfoQ​www.infoq.cn

网易严选如何打造数仓规范和评价体系？-InfoQ​www.infoq.cn

数仓这块真正的难点不在于数仓设计，而是在于后续业务发展起来，业务线变的庞大之后的数据资产治理、数据质量监控、数据指标体系的建设这块。

数仓设计：按照主题域、业务过程，分层的设计方式，以维度建模作为基本理论依据，按照维度、度量设计模型，确保模型、字段有统一的命名规范。
数据资产：主要作用是梳理数据资产，基于数据血缘，数据的访问热度，做成本的治理。
数据质量：主要是通过丰富的稽核监控规则，对数据进行事后校验，确保问题数据第一时间被发现，避免下游的无效计算，分析数据的影响范围。
指标系统：管理指标的业务口径、计算逻辑和数据来源，通过流程化的方式，建立从指标需求、指标开发、指标发布的全套协作流程。
数据地图：提供的是元数据的快速检索，数据字典、数据血缘、数据特征信息的查询，相当于元数据中心的一个门户。

后续有时间在更新这块内容。