1、词根设计标准

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

• 数仓层次

• 公用维度：dim

• DM层：dm

• ODS层：ods

• DWD层：dwd

• DWS层：dws

• 周期/数据范围

• 日快照：d

• 增量：i

• 全量：f

• 周：w

• 拉链表：l

• 非分区全量表：a

2、表命名标准

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

• 中间表：mid_xxx

• 临时表：tmp_xxx

• 维度表：dim_xxx

1、历史数据等级划分

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

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

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

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

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

2、生命周期管理矩阵

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

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

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

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

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

1、高内聚和低耦合

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

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

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

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

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

4、成本与性能平衡

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

5、数据可回滚

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

6、一致性

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

7、命名清晰可理解

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

8、其他

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