首页  思维导图  详情

数据仓库建设规范(指南)

2022-06-14 14:58:10   21  举报





AI智能生成

数据仓库建设规范(指南)

数据仓库

作者其他创作

大纲/内容

一、数据模型架构原则

1、数仓分层原则

概述

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

需要满足哪些条件

清晰数据结构

数据血缘追踪

减少重复开发

数据关系条理化

分层

ODS(Operational Data Store-操作存储数据层)

是最接近数据源中数据的一层，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可

DWD(Date Warehouse Detail-数据明细层)

从 ODS 层中获得的数据按照主题建立各种数据模型

DWM(Date Warehouse Middle-数据中间层)

该层会在 DWD 层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。

DWS（Date Warehouse Service-数据服务聚合层）

DWS 层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于 DWD 层上的基础数据，整合汇总成分析某一个主题域的服务数据，一般称为宽表

DIM(Dictionary Data Layer-维表层)

一些维度属性表，从哪些角度可以分析数据

APP(应用层)

主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、 PostgreSql、Redis 等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用

2、主题域划分原则

1）按照业务或业务过程划分

业务过程：指企业的业务活动事件，如下单、支付、退款都是业务过程。不过需要注意的是，一个业务过程是一个不可拆分的行为事件，通俗的讲，业务过程就是企业活动中的事件。

2）按照数据域划分

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。

3、数据模型设计原则

1）高内聚和低耦合

将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型；

将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。

2) 核心模型和扩展模型要分离

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

3)公共处理逻辑下沉及单一

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

4)成本与性能平衡

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

5)数据可回滚

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

6)一致性

相同的字段在不同表中的字段名必须相同。

7)命名清晰可理解

表命名规范需清晰、一致，表命名需易于下游的理解和使用。

8)其他

一个模型无法满足所有的需求。
需合理选择数据模型的建模方式。
通常，设计顺序依次为：概念模型->逻辑模型->物理模型。

二、数仓公共开发规范

1、层次调用规范

开发顺序

稳定业务

按照标准的数据流向进行开发（ODS-DWD-DWS-APP）

非稳定业务或者探索性需求

ODS-DWD-APP

ODS-DWD-DWM-APP

引用原则

正常流向：ODS -> DWD -> DWM -> DWS -> APP，当出现 ODS -> DWD -> DWS -> APP 这种关系时，说明主题域未覆盖全。应将 DWD 数据落到 DWM 中，对于使用频度非常低的表允许 DWD -> DWS。

尽量避免出现 DWS 宽表中使用 DWD 又使用（该 DWD 所归属主题域）DWM 的表。

同一主题域内对于 DWM 生成 DWM 的表，原则上要尽量避免，否则会影响 ETL 的效率。

DWM、DWS 和 APP 中禁止直接使用 ODS 的表， ODS 的表只能被 DWD 引用。

禁止出现反向依赖，例如DWM的表依赖DWS的表

2、数据类型规范

针对不用的数据库，可能有不同的规范。

需统一规定不同的数据的数据类型，严格按照规定的数据类型执行

金额

NUMBER

字符串

VARCHAR2

ID类

VARCHAR2

时间

DATE

状态

CHAR(1)

3、数据冗余规范

冗余字段要使用高频，下游3个或以上使用。

冗余字段要使用高频，下游3个或以上使用。
字段引入不应造成本身数据产生过多的延后。

字段和已有字段的重复率不应过大，原则上不应超过60%，如需要可以选择join或原表拓展。

4、异常字段处理规范

NULL字段处理规范

对于维度字段，需设置为-1

对于指标字段，需设置为 0

5、指标口径规范

保证主题域内，指标口径一致，无歧义

指标梳理

我们将需求梳理到的所有指标进行进一步梳理，明确其口径，如果存在两个指标名称相同，但口径不一致，先判断是否是进行合并，如需要同时存在，那么在命名上必须能够区分开。

指标管理

指标管理分为原子指标维护和派生指标维护。

6、数据表处理规范

1）增量表

新增数据，增量数据是上次导出之后的新数据。

1、记录每次增加的量，而不是总量；
2、增量表，只报变化量，无变化不用报；
3、每天一个分区。

2）全量表

每天的所有的最新状态的数据。

1、全量表，有无变化，都要报；
2、每次上报的数据都是所有的数据（变化的 + 没有变化的）；
3、只有一个分区

3）快照表

按日分区，记录截止数据日期的全量数据。

4）拉链表

按日分区，记录截止数据日期的全量数据。

1、记录截止数据日期的全量数据。
2、拉链表每次上报的都是历史记录的最终状态，是记录在当前时刻的历史总量；
3、当前记录存的是当前时间之前的所有历史记录的最后变化量（总量）；
4、只有一个分区。

7、表的生命周期管理

这部分主要是要通过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵。

1）历史数据等级划分

主要将历史数据划分P0、P1、P2、P3 四个等级，其具体定义如下：

P0 ：非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、集团 KPI 数据、 IPO 关联表。

P1：重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据。

P2 ：重要的业务数据和重要的应用数据，具有可恢复性，如交易线 ETL 产生的中间过程数据。

P3 ：不重要的业务数据和不重要的应用数据，具有可恢复性，如某些 SNS 产品报表。

2）表类型划分

1、事件型流水表（增量表）

数据无重复或者无主键数据，如日志。

2、事件型镜像表（增量表）

业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发生变更。

3、维表

维表包括维度与维度属性数据，如用户表、商品表。

4、Merge 全量表

Merge 全量表包括业务过程性数据或者维表数据。由于数据本身有新增的或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行 Merge 操作，主键对应的属性只会保留最新状态，历史状态保留在前一天分区中。例如，用户表、交易表等都可以进行 Merge 操作。

5、ETL临时表

ETL 临时表是指 ETL 处理过程中产生的临时表数据，一般不建议保留，最多7天。

6、缓存数据

7、普通全量表

很多小业务数据或者产品数据，BI一般是直接全量拉取，这种方式效率快，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略。

三、数仓各层开发规范

1、ODS层设计规范

同步规范

1、一个系统源表只允许同步一次；

2、全量初始化同步和增量同步处理逻辑要清晰；

3、以统计日期和时间进行分区存储（GP的分区策略待探索）；

4、目标表字段在源表不存在时要自动填充处理;

表分类和生命周期

ods流水全量表

ods镜像型全量表

ods增量数据

ods的etl过程中的临时表

数据质量要求

1、全量表必须配置唯一性字段标识；

2、对分区空数据进行监控；

3、对枚举类型字段，进行枚举值变化和分布监控；

4、ods表数据量级和记录数做环比监控；

5、ods全表都必须要有注释；

2、DWD层设计规范

1）存储及生命周期管理

2）事务性事实表设计准则

基于数据应用需求的分析设计事务型事实表，结合下游较大的针对某个业务过程和分析指标需求，可考虑基于某个事件过程构建事务型实时表；

一般选用事件的发生日期或时间作为分区字段，便于扫描和裁剪；

冗余子集原则，有利于降低后续IO开销；

明细层事实表维度退化，减少后续使用join成本。

3）周期快照事实表

周期快照事实表中的每行汇总了发生在某一标准周期，如某一天、某周、某月的多个度量事件。

粒度是周期性的，不是个体的事务。

通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许的。

4）累计快照事实表

多个业务过程联合分析而构建的事实表，如采购单的流转环节。

用于分析事件时间和时间之间的间隔周期。

少量的且当前事务型不支持的，如关闭、发货等相关的统计。

3、DWS层设计规范

1）聚集的基本原则

一致性。聚集表必须提供与查询明细粒度数据一致的查询结果

避免单一表设计。不要再同一个表中存储不同层次的聚集粒度

聚集粒度可不同。聚集并不需要保持与原始明细粒度数据一样的粒度，聚集只关心所需要查询的维度

2）聚集的基本步骤

第一步：确定聚集维度

在原始明细模型中会存在多个描述事实的维度，如日期、商品类别、卖家等，这时候需要确定根据什么维度聚集，如果只关心商品的交易额情况，那么就可以根据商品维度聚集数据。

第二步：确定一致性上卷

根据具体的需求，考虑按什么进行汇总。而且要考虑，聚集后如何下钻。

第三步：确定聚集事实

在原始明细模型中可能会有多个事实的度量，比如在交易中有交易额、交易数量等，这时候要明确是按照交易额汇总还是按照成交数量汇总。

3）公共汇总层设计原则

数据公用性

汇总的聚集会有第三者使用吗？基于某个维度的聚集是不是经常用于数据分析中？如果答案是肯定的，那么就有必要把明细数据经过汇总沉淀到聚集表中。

不跨数据域

数据域是在较高层次上对数据进行分类聚集的抽象。如以业务

区分统计周期

在表的命名上要能说明数据的统计周期。如 _Id表示最近1天，_td 表示截至当天，_nd 表示最近N天。

4、公共维度层设计规范

设计准则

1、一致性

共维度在不同的物理表中的字段名称、数据类型、数据内容必须保持一致（历史原因不一致，要做好版本控制）

2、维度的组合和拆分

组合原则

将维度与关联性强的字段进行组合，一起查询，一起展示，两个维度必须具有天然的关系，如：商品的基本属性和所属品牌。

无相关性：如一些使用频率较小的杂项维度，可以构建一个集合杂项维度的特殊属性。

行为维度：经过计算的度量，但下游当维度处理，例：点击量 0-1000,100-1000等，可以做聚合分类。

拆分与冗余

针对重要性，业务相关性、源、使用频率等可分为核心表、扩展表。

数据记录较大的维度，可以适当冗余一些子集。

四、数仓命名规范

1、词根设计规范

根据不同的业务业务领域，有相应的词根版本。可以理解为术语字典，包含数仓分层、周期/数据范围、部门、业务域、主题域等

数仓层次

公用维度：dim

DM层：dm

ODS层：ods

DWD层：dwd

DWS层：dws

周期/数据范围

日快照：d

增量：i

全量：f

周：w

拉链表：l

非分区全量表：a

2、表命名规范

常规表

规范：分层前缀[dwd|dws|ads]_部门_业务域_主题域_XXX_更新周期|数据范围

中间表

规范：mid_table_name_[0~9|dim]

临时表

规范：tmp_xxx

维度表

规范：dim_xxx

手工表

规范：dwd_业务域_manual_xxx

3、指标命名规范

1）公共规则

所有单词小写

单词之间下划线分割（反例：appName 或 AppName）

可读性优于长度 (词根，避免出现同一个指标，命名一致性)

禁止使用 sql 关键字，如字段名与关键字冲突时 +col

数量字段后缀 _cnt 等标识...

金额字段后缀 _price 标识

天分区使用字段 dt，格式统一（yyyymmdd 或 yyyy-mm-dd）

小时分区使用字段 hh，范围（00-23）

分钟分区使用字段 mi，范围（00-59）

布尔类型标识：is_{业务}，不允许出现空值

2）指标命名规范

1、基础指标词根管理

2、业务修饰词

3、日期修饰词

4、聚合修饰词

5、基础指标

6、派生指标

7、普通指标

4、命名流程