数据仓库|数据模型该如何设计？

数据仓库数据模型设计是构建数据仓库的核心过程之一。其目的是将多个数据源中的数据整合到一个统一的数据模型中，以支持业务分析和决策。然而，在数仓建设的过程中，由于未能完全按照规范操作， 从而导致数据仓库建设比较混乱，常见以下问题：

数仓分层不清晰：数仓的分层没有明确的逻辑，导致数据难以管理和维护。 数据域划分不明确：没有明确的数据域划分，导致数据冗余和不一致。 模型设计不合理：模型设计没有考虑到业务的实际需求，导致数据质量低下。 代码不规范：代码不符合规范，导致维护困难。 命名不统一：命名不统一，导致数据难以理解和使用。 主题域划分不完整：主题域划分没有涵盖所有业务需求，导致数据缺失。

本文主要探讨关于数仓数据模型建设的一些方法论和经验，通过此篇文章你可以收获：

应用层和公共层模型设计的方法 如何定位各个分层之间的边界 各个分层模型设计该注意什么 数仓分层标准

ODS:操作型数据(Operational Data Store)，指结构与源系统基本保持一致的增量或者全量数据。作为DW数据的一个数据准备区，同时又承担基础数据记录历史变化，之所以保留原始数据和线上原始数据保持一致，方便后期数据核对需要。

CDM：通用数据模型，又称为数据中间层(Common Data Model)，包含DWD、DWS、DIM层。

DWD：数据仓库明细层数据(Data Warehouse Detail)。对ODS层数据进行清洗转化，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可以结合企业的数据使用特点，基于维度建模思想，将明细事实表的某些重要属性字段做适当冗余，也即宽表化处理，构建明细宽表。

DWS：数据仓库汇总层数据(Data Warehouse Summary)，基于指标需求，构建初步汇总事实表，一般是宽表。基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标。
DIM：建立一致数据分析维表，可以降低数据计算口径不统一的风险，同时可以方便进行交叉探查。以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。

ADS：面向应用的数据服务层(Application Data Service)。整合汇总成分析某一个主题域的服务数据，面向应用逻辑的数据加工。该层主要存放数据产品个性化的统计指标数据，这一层的数据直接对接数据的消费者，是产品、运营等角色可以直接感知理解的一层，大多数这一层的表都可以直接在BI上通过图表的形式直接透出。

开发流程

只有上面的分层标准显然是不够的，还需要有一个具体的实施路径，这样才可以一步一步地去开发实现。关于该如何开发，其实也是有一个标准的，具体如下：

数据调研

1、了解业务系统数据，表关系，字段含义

2、分析具体的业务需求，比如需要哪些指标，具体口径是什么

数据域划分

所谓的数据域，即是对业务过程或维度进行抽象，比如交易、流量、用户等等

构建总线矩阵

1、明确业务过程所属的数据域

2、明确业务过程与分析维度的关系

明确统计指标

通常情况下，需要明确原子指标与派生指标

模型设计

1、构建一致性维表(DIM)

2、构建一致性事实表(DWD)

3、构建公共汇总模型(DWS)

4、构建应用汇总模型(ADS)

代码开发

数据业务逻辑开发，测试、数据验证

部署运维

1、上线任务

2、任务监控

3、DQC监控

其实，面对不断发展变化的业务以及永远做不完的需求，往往会陷入短期的需求导向的怪圈，从而出现了各种各样的烟囱，从而导致数据混乱低效，成本不可控。

一些常见的问题 分层的边界是什么

在一些特殊情况下，一般为了快速开发，直接从回流的ODS表开发相应的ADS表，导致ADS与DWS边界不清晰，竖立了一个又一个小烟囱。

模型设计全凭经验，不同的人有不同的理解，最终的模型也是各不相同 明确分层定位 ODS：把操作系统数据几乎无处理的存放在数据仓库系统中，采用增量或全量同步，根据业务需要保存历史数据、清洗数据。 公共层：通过抽象复用，从而提升ADS层的开发效率，确保一些共性逻辑保持全局一致性，由于是复用，要考虑模型的易用性和稳定性 ADS：专注支持业务需求，提升开发效率，确保口径一致。面向具体应用场景构建，场景间松耦合，一般为专表专用，快速满足业务需求 高内聚和低耦合

一个逻辑和物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑：

将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型； 将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。

核心模型与扩展模型分离

建立核心模型与扩展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化或是少量应用的需要，不能让扩展字段过度侵入核心模型，破坏了核心模型的架构简洁性与可维护性。

公共处理逻辑下沉

越是底层公用的处理逻辑更应该在数据调度依赖的底层进行封装与实现，不要让公共的处理逻辑暴露给应用层实现，不要让公共逻辑在多处同时存在。

成本与性能平衡

适当的数据冗余换取查询和刷新性能，不宜过度冗余与数据复制。

数据可回滚

处理逻辑不变，在不同时间多次运行数据结果确定不变。

指标一致性

相同的字段含义在不同表中字段命名必须相同，必须使用规范定义中的名称。

命名清晰可理解

表命名需清晰、一致，表名需易于消费者理解和使用。

层次依赖合理

dwd应严格遵守层次依赖，理论上只可引用ODS、DIM和部分DWD数据，不可引用处于下游层次的ADS等数据，以避免出现“反向引用”的情况； dws应严格遵守层次依赖，理论上只可引用DIM、DWD数据，不可引用处于下游层次的ADS等数据，以避免出现“反向引用”的情况。

关于ODS层的处理很简单，基本上是将业务系统数据原封不动的回流即可，一般采用增全量的方式。

公共层主要通过抽象、复用、沉淀物理或逻辑的模型，以提升整体架构的数据效率并确保口径一致性。整体公共层设计要点在于需求上识别共性逻辑，设计上抽象复用模型，实现上平衡易用性和稳定性。

一般情况下，一个比较好的公共层遵循一下几个原则：

1、数据域的划分是建设公共层的前提，但是数据域不是一成不变的，由于业务不同，对应的数据域划分也自然各不相同，有时候需要灵活处理，并且要根据业务的发展而调整相关数据域的划分。 2、其实，数据域的目的是为了给数据分类，所以尽量可以更好地以业务分析视角去组织公共数据，从而更好地保持数据的独立性，切不可大一统的简单划分粗略的一个域。 1、DWS层的原则：DWS的核心诉求是通过空间换时间，在节约成本、提升效率的同时，实现数据口径的一致性。既然是这样，那就不能为了加工DWS而加工DWS数据，要基于是否是业务的核心指标判断是否要沉淀公共层，另外，如果是事后沉淀公共层，那要看下需要沉淀的指标的应用场景有多少，假如只在一个地方使用，那也就没有沉淀DWS的必要了 2、DWD的原则：一般情况下，DWD的模型相对好设计一些，核心是基于维度建模，冗余维度属性，降低频繁关联，提升基础数据模型的易用性

公共层模型不是为某一应用场景单独设计的，而是面向大部分的应用场景进行设计，因此需要进行一定的抽象以提升通用性，从而尽可能覆盖更多的应用场景

复用性

指标复用性抽象：转变不可累加指标为可累加指标，如比率型建议保留分子分母； 粒度复用性抽象：以最大公约数的逻辑抽象复用，比如上游表ADS1是子公司粒度、表ADS2是一级类目粒度，那就可以设计出sku粒度的DWS表

易用性

在不影响模型产出时效性的情况下，需尽量考虑模型易用性，提升应用研发的使用效率。易用性的设计主要指的是宽表设计和水平切分，用于降低下游理解和多表关联。

DWS模型易用性上，通过冗余维度属性、采用大宽表方式构建，以提升下游易用性。 DWS冗余相对不易变的维度属性，减少下游频繁关联； 如无时效性问题，同数据域同粒度进行宽表设计，提升下游易用性； DWD模型易用性上，通过采用星型模型、维度冗余和信息完善度进行设计，以提升下游易用性，模型设计应以星型模型为主。

稳定性

通过大宽表的建设方式，公共层极大提升了模型的易用性，但因应用场景差异化，时效性也对应有不同的要求。公共层需进行必要的的稳定性设计，满足下游重要应用高时效性产出的要求。

扁平化设计提升稳定性：公共层整体需扁平化设计，进行不要依赖层级过深

DWS稳定性设计：结合访问热度、数据稳定情况，进行必要的解耦设计，以提升DWS模型的稳定性；比如根据访问的热度，将1d、nd、td的数据模型进行垂直拆分， 对于DIM维表也可以根据垂直拆分的方式，保证核心维度的产出效率，将低热度的扩展维度属性与核心维度属性进行拆分 一般情况下，对于数据量比较小的场景，可以优先构建DWD，后构建DWS，在构建DWS的过程中，可以优先构建细粒度的DWS表(为了扩展性)，最后沉淀粗粒度的DWS表 对于数据体量比较大的情况，可以优先构建粗粒度的DWS，对于DWD的构建，可以采用水平拆分的方式，比如不在冗余半结构的字段(attributes扩展字段)，从而提升产出的时效，提升下游的使用效率。

应用层的定位为根据特定业务诉求，按照业务角度组织数据以快速满足业务需求。应用层研发核心关注研发效率、口径一致性，以及核心应用的稳定性。

一个好的应用层模型需要重点关注以下几个原则：

需求驱动构建集市：按需最小原则设计，除非有明确的业务延续，否则不做过度的扩展设计。应用层的设计需要考虑业务定制的需求，提供面向业务定制的应用数据，如报表数据、大宽表等，供线上系统使用。

与公共层类似，以高内聚低耦合的原则对集市进行划分，让单集市数据研发聚焦在某一领域的业务需求实现；集市间应该避免互相依赖，避免复杂度的提升。 ADS也可以抽象出公共部分，通过依赖ADS数据，提升开发的效率和产出效率

减少直接引用ODS表，降低源系统变更带来的改造成本，架构合理上考虑，公共层针对复用性的场景进行模型沉淀，当源系统变更时，通过公共层适应性改造屏蔽下游变更。

本文主要讨论了应用层和公共层模型设计的方法、如何定位各个分层之间的边界、各个分层模型设计该注意什么三方面的内容，当然在实际的应用过程中，需要灵活处理，希望本文对你有所帮助。