数据仓库规范调研

一、模型层次

 

数据模型总体分为操作数据层（ODS）、数据明细层（DWD）、数据汇总层（DWS）、统一维度层（DIM）、数据应用层（ADS）。

操作数据层（ODS），存储各类未处理的操作数据。

• 同步：结构化（业务数据库）数据全量或增量同步。
• 结构化：非结构化（日志）结构化处理后并存储。

数据明细层（DWD），存储明细事实数据，保持与ODS层相同的颗粒度，进行数据清洗与规范化操作，剔除异常错误数据，适当扩展相关维度。

数据汇总层（DWS），存储轻度汇总数据，在DWD的基础上进行相关维度组合的汇总，提高下游任务的计算效率。

数据明细层与数据汇总层，以维度建模理论为基础，主要使用维度退化的方法，将维度退化到事实表中，减少事实表与维表的关联，提高数据的易用性。

统一维度层（DIM），该业务板块内建立一致性分析维度，统一口径和算法，提高复用性，减少重复加工。

数据应用层（ADM），存储粗粒度的汇总数据，在DWD与DWS的基础上得到的个性化指标或主题相关宽表，用于OLAP、报表查询、数据分发等。

二、基本原则

高内聚和低耦合

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

核心模型与扩展模型分离

核心模型包括的字段支持常用核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的字段过度影响核心模型。

公共处理逻辑下沉及单一

底层公用处理逻辑在底层进行封装与实现，不要让公共处理逻辑多处同时存在。

成本与性能平衡

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

数据可回滚

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

一致性

具体相同含义的字段在不同表中的命名必须相同。

命名清晰、可理解

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

三、表命名规范

ODS层与DWD、DWS、ADS层隔离。日志解析可无需新建库可均放到同一个库中，是否新建库由分析师判断是否新增业务域或服务域。

数据表命名应使用直观，易于理解具体特征、业务、功能、分区类型，易于查找定位的名称。应按如下方式定义：

{前缀}_{业务|应用}<{_业务|_应用}><{_功能}><{_修饰词}><{_后缀}>

说明：

1. 所有部分均为小写字母，各部分之间以“_”连接。
2. <{业务|应用}>：可选，指数据表所属业务或应用的缩写。可与数据库名该部分一致。若一个应用包含多个业务，或一个业务包含多个应用，会出现{应用}_{业务}或{业务}_{应用}的命名情况。
3. <{功能}>：可选，指数据表所属功能域，如支付为pay、播放为play、会员为member、KPI为user等。
4. <{修饰词}>：可选，为了便于区分识别表而增加的额外修饰词，使用时可作为功能的补充，允许有多个部分以“_”间隔，可自行定义。
5. <{_后缀}>：可选，部分类型的表为必选。

四、指标命名规范

指标名称应按如下方式定义：

<{聚合修饰词}>{业务修饰词}{基础指标词根}<日期修饰词>

 

五、表与字段命名通用规范

• 字段命名要按照蛇形命名法 (snake_case)——全小写，单词之间用下划线分隔
• 表名、字段名需以字母为开头。
• 优先使用词根中已有关键字，定期Review新增命名的不合理性

重点：词根表的维护上，及如何维护，决定了规范的有效开展