本文原文刊自《五分钟学大数据》，此处修正了原文的部分错误，增加了部分内容和细节。

1. 数仓模型设计原则

1.2. 数仓模型设计目标

• 高内聚、低耦合
  • 即主题内部高内聚、 不同主题间低耦合；
  • 明细层按照业务过程划分主题，汇总层按照“实体+ 活动”划分不同分析主题，应用层根据应用需求划分不同应用主题。
• 核心模型和扩展模型要分离
  • 核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要；
  • 不能让扩展模型的字段过度侵入核心模型，以免破坏核心模型的架构简洁性与可维护性。
• 公共处理逻辑下沉及单一
  • 越是底层公用的处理逻辑，越应该在数据调度依赖的底层进行封装与实现；
  • 不要让公用的处理逻辑暴露给应用实现，不要让公共逻辑多处同时存在。
• 成本与性能平衡
  • 适当的数据冗余可换取查询和刷新性能；
  • 同时不宜过度冗余与数据复制。
• 数据可回滚
  • 处理逻辑不变，在不同时间多次运行数据结果确定不变。

1.2. 数仓模型设计经验

• 分层是解决数据流向和快速支撑业务的目的；
• 必须按照主题域和业务域进行贯穿；
• 层级之间不可逆向依赖；
• 如果依赖ODS层数据可以完成数据支撑，那么业务方直接使用落地层这也有利于快速、低成本地进行一些数据方面的探索和尝试。
• 确定分层规范后，后续最好都遵循这个架构，约定成俗即可；
• 血缘关系、数据依赖、数据字典、数据命名规范等配套先行；

2.层次调用规范

2.1. 不同需求阶段的调用关系

• 稳定业务，
  • 按照标准的数据流向进行开发，即 ODS –> DWD –> DWS –> APP；
• 非稳定业务或探索性需求，
  • 遵循 ODS -> DWD -> APP 或者 ODS -> DWD -> DWM ->APP 两个模型数据流。

2.2 分层引用原则

在保障了数据链路的合理性之后，也必须保证模型分层引用原则：

• 正常流向：
  • 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.3. 数据流向

3. 表结构及数据内容规范

3.1. 数据类型规范

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

例如：

• 金额：
  • double 或 使用 decimal(28,6) 控制精度等，明确单位是分还是元；
• 字符串：
  • string；
• id类：
  • bigint；
• 时间：
  • string；
• 状态：
  • string；

常见的数据类型：

3.2. 数据冗余规范

宽表的冗余字段要确保：

• 冗余字段要使用高频，下游3个或以上使用；
• 冗余字段引入不应造成本身数据产生过多的延后；
• 冗余字段和已有字段的重复率不应过大，
  • 原则上不应超过 60%，如需要可以选择 join 或原表拓展。

3.3. NULL值处理规范

• NULL 不代表 0，也不代表 0 长度的字符串；
• NULL 含义：
  • 真未知；
  • 尚未知；
  • 不适用；

NULL 的长度不是 0 ！

• 同一个数据库，对于 Null 值的处理应有统一的原则；
• 数据质量要求不高的，默认值可以为 Null，然后对特殊字段特殊处理；
• 数据质量要求较高的，默认值均为 Not Null，然后特殊字段特殊处理；

3.4. 范式建模 Null 值使用原则

• 主数据表：
  • CODE 为主键，不可以为空；
    • 未知的值，可以按以下方式赋值：
      • 未知；
      • 不适用；
      • 非法；
      • 未分类；
  • NAME 不可以为空；
    • 默认值可设为空字符串 ‘‘；
• Xref 表：
  • 多字段构成联合主键，不可以为空；
    • 主要关心的的是多对多关系；
• 事务表：
  • 引用主数据表的字段、设为主键，不可以为空；
  • 为防止聚合计算时出现错误，应充分考虑 Null 值的处理方式，比如增加特殊字段；

3.5. Null 存在的隐患

• 数学计算
  • 任何值和 Null 计算，结果都是 Null；
  • 1 + Null = Null；
  • 1 / Null = Null；
• WEHRE 子句
  • 使用 <>、全选时，Null 值所在的这条记录，会被忽视掉；
• Join
  • Null 和 Null 做 Join 操作的时候，是不会有结果的；
• 聚合函数
  • Null 在计算的时候，没有参与聚合计算；
  • 若 Null 重设为 0，则 AVG、MIN、MAX、COUNT 都会受到影响；
• 子查询
  • 使用 NOT IN 的时候，会出现错误；
  • 使用 NOT EXISTS，才能保证正常结果；

3.6. 键设计注意问题

• 表更新的复杂性
  • 多系统合并、需要多个自然键组合做主键时，尽量不要使用复合键；
  • 可以使用 Checksum key，即对多系统的自然键进行 MD5 计算，用 MD5 结果值作为单键主键；
• SQL 语句复杂性
  • 当 SQL 需要多表关联的时候，SQL 复杂性会迅速增加。
• 空间占用
  • 自然键：
    • 维度表，需要空间比较少；
    • 事实表，通常需要更多空间；
    • 整体来说，需要更多空间；
  • 代理键：
    • 维度表，需要更多空间；
    • 事实表，需要更少空间；
    • 整体来说，需要更少空间；
• SQL 语句资源消耗
  • 代理键为整型，查询性能较好；
  • 自然键如是 VARCHAR，性能比较差；
  • 单键的性能较好；
  • 复合键的性能差；
  • 当数据量达到百万级的时候，性能差异会凸显；
• 数据加载速度
  • 自然键：
    • 维度表，直接从源系统过数据，额外开销比较少；
  • 代理键：
    • 维度表，代理键插入必须计算最新插入的代理键，需要时间，但和自然键差别不大；

4. 主题域划分规范

4.1. 按照业务域划分

• 业务
  • 指业务模块、业务线。
• 业务过程
  • 指企业的业务活动事件，如下单、支付、退款都是业务过程，通俗的讲业务过程就是企业活动中的事件。

4.2. 按照数据域划分

• 数据域，是指面向业务分析，将业务过程或者维度进行抽象的集合。
  • 其中，业务过程可以概括为一个个不可拆分的行为事件，在业务过程下，可以定义指标，维度是指度量的环境，如买家下单事件，买家是维度。
• 为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动；
• 在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时便于被包含进已有的数据域中、扩展新的数据域。

4.3. 按照部门划分

• 运营域，如工资支出分析、活动宣传效果分析等主题；
• 技术域。

4.4. 根据需求方划分

• 如财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题。

5. 指标设计规范

5.1. 指标规范设计目的

• 指标定义标准化：
  • 名称：
    • 原子指标的英文名称、中文名称、概述；
  • 口径：
    • 主题域内，指标口径必须一致；
    • 统一对外输出的数据口径，避免同一指标不同口径的情况发生。
  • 含义：
    • 主题域内，无歧义；
  • 数据出口：
    • 通过数据分层，提供统一的数据出口；
    • 方便平台化开发。

5.2. 指标分类

• 原子指标：
  • 原子指标三要素：
    • 业务过程；
    • 度量值；
    • 聚合逻辑；
• 派生指标：
  • 在原子指标的基础之上，进行一系列逻辑运算得出。

5.3. 指标梳理

• 原子指标的归属产线、业务板块、数据域、业务过程；
• 原子指标的统计数据，来源于该业务过程下的原始数据源；
• 指标计算函数；
• 根据指标函数，自动生成原子指标的定义表达式；
• 根据指标定义、表达式以及数据源表，生成原子指标SQL；
• 注意：
  • 在数据治理中，我们将需求梳理到的所有指标进行进一步梳理，明确其口径；
  • 指标口径的不一致，使得数据使用的成本极高，经常出现口径打架、反复核对数据的问题；
  • 如果存在两个指标名称相同，但口径不一致，先判断是否是进行合并，如需要同时存在，那么在命名上必须能够区分开。

6. 数据表处理规范

6.1. 增量表处理规范

• 增量数据是上次导出之后的新增数据；
• 记录每次增加的量，而不是总量；
• 增量表，只报变化量，无变化不用报；
• 每天一个分区。

6.2. 全量表处理规范

• 每天的所有的最新状态的数据。
• 全量表，有无变化，都要报；
• 每次上报的数据，都是所有的数据（变化的 + 没有变化的）；
• 只有一个分区。

6.3. 快照表处理规范

• 按日分区，记录截止数据日期的全量数据。
• 快照表，有无变化，都要报；
• 每次上报的数据都是所有的数据（变化的 + 没有变化的）；
• 一天一个分区。

6.4. 拉链表处理规范

• 记录截止数据日期的全量数据；
• 记录一个事物从开始，一直到当前状态的所有变化的信息；
• 拉链表每次上报的，都是历史记录的最终状态，是记录在当前时刻的历史总量；
• 当前记录存的，是当前时间之前、所有历史记录的最后变化量（总量）；
• 只有一个分区。

7. 表的生命周期管理

7.1. 表的等级划分

• 表的等级划分，主要将历史数据划分P0、Pl、P2、P3 四个等级；
  • P0
    • 非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、集团 KPI 数据、 IPO 关联表；
  • P1
    • 重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据；
  • P2
    • 重要的业务数据和重要的应用数据，具有可恢复性，如交易线 ETL 产生的中间过程数据；
  • P3
    • 不重要的业务数据和不重要的应用数据，具有可恢复性，如某些 SNS 产品报表。

7.2. 表类型划分

• 事件型流水表（增量表）
  • 事件型流水表（增量表）指数据无重复或者无主键数据，如日志；
• 事件型镜像表（增量表）
  • 事件型镜像表（增量表）指业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发生变更；
• 维表
  • 维表包括维度与维度属性数据，如用户表、商品表；
• Merge 全量表
  • Merge 全量表，包括业务过程性数据或者维表数据；
  • 由于数据本身有新增的或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行 Merge 操作，主键对应的属性只会保留最新状态，历史状态保留在前一天分区中。
  • 例如，用户表、交易表等都可以进行 Merge 操作。 -ETL 临时表
  • ETL 临时表是指 ETL 处理过程中产生的临时表数据，一般不建议保留，最多7天。
• TT 临时数据
  • TT 拉取的数据和 DbSync 产生的临时数据最终会流转到 ODS 层，ODS 层数据作为原始数据保留下来，从而使得 TT & DbSync 上游数据成为临时数据；
  • 这类数据不建议保留很长时间，生命周期默认设置为 93天，可以根据实际情况适当减少保留天数。
• 普通全量表
  • 很多小业务数据或者产品数据，BI一般是直接全量拉取；
  • 这种方式效率快，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略。

7.3. 表生命周期管理规范

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

8. ODS 层设计规范

8.1. 0DS 层表同步规范

• 一个系统源表只允许同步一次；
• 全量初始化同步和增量同步处理逻辑要清晰；
• 以统计日期和时间进行分区存储；
• 目标表字段在源表不存在时要自动填充处理。

8.2. 表生命周期管理规范

• ods 流水全量表：
  • 不可再生的永久保存；
  • 日志可按留存要求；
  • 按需设置保留特殊日期数据；
  • 按需设置保留特殊月份数据；
• ods 镜像型全量表：
  • 推荐按天存储；
  • 对历史变化进行保留；
  • 最新数据存储在最大分区；
  • 历史数据按需保留；
• ods 增量数据：
  • 推荐按天存储；
  • 有对应全量表的，建议只保留14天数据；
  • 无对应全量表的，永久保留；
• ods etl 过程中的临时表：
  • 推荐按需保留；
  • 最多保留7天；
  • 建议用完即删，下次使用再生成；
• BDSync非去重数据：
  • 通过中间层保留，默认用完即删，不建议保留。

8.3. ODS 层数据质量规范

• 全量表必须配置唯一性字段标识；
• 对分区空数据进行监控；
• 对枚举类型字段，进行枚举值变化和分布监控；
• ods表数据量级和记录数做环比监控；
• ods全表都必须要有注释；

9. DIM 层设计规范

9.1. DIM 层维度表设计流程

• 选择维度
  • 要确保维度一致性有且只允许有一个维度定义。
• 确定主维表
  • 主维表一般是ODS 表，直接与业务系统同步。
• 确定相关维表
  • 确定哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。
• 确定维度属性
  • 一方面，尽可能生成丰富的维度属性；
  • 另一方面，尽量沉淀出通用的维度属性，确定那些是核心属性。

9.2. DIM 层维度表设计规范

• DIM 层一致性
  • 在不同的物理表中的字段名称、数据类型、数据内容必须保持一致（历史原因不一致，要做好版本控制）；
  • 两个维度的公共维度属性结构和内容相同
• DIM 层共享维表
  • 重要的公共维度维表只能有一个，基于这些公共维度进行的交叉探查、不会存在任何问题；
• 变化维的处理方式
  • 直接覆盖
    • 使用的较少，主要用于及其缓慢变化的维度表；
  • 新增一列
    • 用以存储新、旧两次属性；
    • 适用场景：适用于变化的维度属性较少；
  • 新增一行
    • 每次变化都会新增一行；
    • 适用场景：维表数据量较大，且用户关注历史变化。(一般采用拉链表的方式实现)
  • 天级快照
    • 当维度数量较少时，可以每天保留一份全量快照数据；
    • 缺点是重复存储严重。
• DIM 层维度表组合
  • 水平整合
    • 是指不同的来源表包含不同的数据集，会使得维度本身的记录数变多，是对原有维度的记录数上的补充；
    • 这里需要考虑：
      • 多个来源表是否存在重复，如果有就需要去重；
      • 多个数据源表的自然键是否存在冲突，是否需要重新组合形成新的超自然键；
  • 垂直整合
    • 简单来说就是增加字段；
    • 不同的来源表包含相同的数据集，维度本身记录数不会变，只是会对维度属性进行补充；
• DIM 层维度表拆分
  • 针对重要性，业务相关性、源、使用频率等可分为核心表、扩展表；

整合&拆分原则：出于扩展性、产出时间、易用性等方面的考虑，主要目标是保证主维表信息的全面性和稳定性，不因为个别维度的加入而导致维表产出不稳定。

• DIM 层特殊维度处理
  • 递归层次
    • 如服务记录的叶节点和根节点，可以选择打平或者降低粒度；
  • 行为维度
    • 这类维表一般是快速变化维。如果维表太大且采用了拉链表时，可以考虑把快速变化的维度属性拆出来；
  • 多值维度
    • 一条记录的一个维度属性有多个值
      • 比如一笔电商订单有多个商品，每笔订单能关联到商品维表多条记录；
    • 一般采用降低粒度、多字段、桥接表的方式；
  • 多值属性
    • 维表中的某个属性字段同时有多个值，称之为“多值属性”；
    • 这种一般要么降低粒度，每个值一条，要么不拆，将字段整合到一个字段或者多个字段当中；
  • 杂项维度
    • 由操作型系统中的指示符、或者标志宇段组合而成的维度，一般使用频率较小；
    • 这种一般来说是会保留在事实表当中较好；
    • 也可以构建一个集合杂项维度的特殊属性；
  • 关联属性组合
    • 将维度与关联性强的字段进行组合，一起查询，一起展示，两个维度必须具有天然的关系，如：商品的基本属性和所属品牌；
  • 适当的聚合分类
    • 经过计算的度量结果值，但下游当维度处理的，可以做聚合分类；
    • 如：点击量 0-1000,100-1000；
• DIM 层冗余
  • 数据记录较大的维度，可以适当冗余一些子集。

10. DWD 层设计规范

10.1. 事务型事实表设计准则

• 基于数据应用需求的分析、设计事务型事实表；
  • 结合下游、较大的针对某个业务过程和分析指标需求，可考虑基于某个事件过程、构建事务型实时表；
  • 一般选用事件的发生日期或时间作为分区字段，便于扫描和裁剪；
• 维度退化原则
  • 维度退化：
    • 当一个维度没有数据仓库需要的任何数据时就可以退化此维度。需要把退化维度的相关数据迁移到事实表中，然后删除退化的维度。
  • 维度退化的优点：
    • 在 DWD 层，事实表维度退化，可以减少后续使用 join 成本；
    • 在 DWS 层，维度退化会提高 SQL 的执行速度，也会让数据关系更直观清晰；
    • 简单的模式比复杂的更容易理解，也有更好的查询性能。
• 适当冗余原则
  • 有利于降低后续 IO 开销；

10.2. 快照事实表设计准则

• 周期快照事实表
  • 周期快照事实表中，每行汇总了发生在某一标准周期，如某一天、某周、某月的多个度量事件；
  • 粒度是周期性的，不是个体的事务；
  • 通常包含许多事实，任何与事实表粒度一致的度量事件、都是被允许的。
• 累积快照事实表
  • 多个业务过程联合分析而构建的事实表，如采购单的流转环节；
  • 用于分析事件时间和时间之间的间隔周期；
  • 少量的且当前事务型不支持的，如关闭、发货等相关的统计。
• 快照表生命周期管理
  • 按天分区：
    • 3个月内最大访问跨度<=4天时，建议保留最近7天分区；
    • 3个月内最大访问跨度<=12天时，建议保留最近15天分区；
    • 3个月内最大访问跨度<=30天时，建议保留最近33天分区；
    • 3个月内最大访问跨度<=90天时，建议保留最近120天分区；
    • 3个月内最大访问跨度<=180天时，建议保留最近240天分区；
    • 3个月内最大访问跨度<=300天时，建议保留最近400天分区；

11. DWS 层设计规范

• 数据仓库的性能，是数据仓库建设是否成功的重要标准之一；
• 聚集的主要作用，是通过汇总明细粒度数据来获得改进查询性能的效果；
• 通过访问聚集数据，可以减少数据库在响应查询时必须执行的工作量，能够快速响应用户的查询，同时有利于减少不同用访问明细数据带来的结果不一致问题。

11.1. DWS 聚集的基本原则

• 一致性
  • 聚集表必须提供与查询明细粒度数据一致的查询结果；
• 避免单一表设计
  • 不要在同一个表中存储不同层次的聚集数据；
• 聚集粒度可不同
  • 聚集并不需要保持与原始明细粒度数据一样的粒度，聚集只关心所需要查询的维度。

11.2. DWS 层聚集的基本步骤

• 第一步：确定聚集维度
  • 在原始明细模型中会存在多个描述事实的维度，如日期、商品类别、卖家等，这时候需要确定根据什么维度聚集，如果只关心商品的交易额情况，那么就可以根据商品维度聚集数据。
• 第二步：确定一致性上钻
  • 这时候要关心是按月汇总还是按天汇总，是按照商品汇总还是按照类目汇总，如果按照类目汇总，还需要关心是按照大类汇总还是小类汇总。
  • 当然，这么做的只是了解用户需要什么，然后按照他们想要的进行聚集。
• 第三步：确定聚集事实
  • 在原始明细模型中可能会有多个事实的度量，比如在交易中有交易额、交易数量等，这时候要明确是按照交易额汇总还是按照成交数量汇总。

11.3. DWS 层设计原则

除了聚集基本的原则外，公共汇总层还必须遵循以下原则：

• 数据公用性
  • 需要思考汇总的聚集是否有多个用户使用，基于某个维度的聚集是不是经常用于数据分析中；
  • 如果答案是肯定的，那么就有必要把明细数据经过汇总沉淀到聚集表中。
• 不跨数据域
  • 数据域是在较高层次上对数据进行分类聚集的抽象。如以业务区分统计周期；
  • 在表的命名上要能说明数据的统计周期，如 _Id表示最近1天，_td 表示截至当天，_nd 表示最近N天。

11.4. 关于宽表的误区

• 宽表的概念
  • 宽表，通是把很多的维度、事实上卷或者下钻之后关联到某一个事实表中，形成一张既包含了大量维度又包含了相关事实的表。
• 宽表的优点
  • 宽表的使用，有其一定的便利性，使用方不需要再去考虑跟维度表的关联，也不需要了解维度表和事实表是什么东西。
• 宽表的缺陷
  • 随着业务的增长，我们始终无法预见性地设计和定义宽表究竟该冗余多少维度，也无法清晰地定义出宽表冗余维度的底线在哪里。
  • 一个可能存在的情况是，为了满足使用上的需求，要不断地将维表中已经存在的列增加到宽表中。这直接导致了宽表的表结构频繁发生变动。
• 宽表问题应对方法
  • 根据主题域和业务域，将某个业务的所有节点梳理清楚；
  • 将关键节点的数据作为事实表依据，然后横向扩充其他事实表上卷数据（包含一些统计指标），同时纵向的添加该节点上一些主键对应的维度；
  • 宽表的涉及不依赖具体的业务需求而是根据整体业务线相匹配；
  • 尽量用维度建模代替宽表；

11.5. 用维度建模代替宽表的原因

• 就算字段和数据会冗余，维度建模的方式也会表全量数据的宽表模式较好；
• 维度建模是以某一个既定的事实为依据，既然是事实表，那么这块的业务如果不变动的情况下，事实表的粒度基本不会改变；
• 事实表和维度表解耦，维度表的变更事实表基本不会影响，结果表也只需要回刷一下数据流程即可；
• 新增维度完全可以按照星型模型或者雪花模型动态添加新维度；
• 维度模型可以作为宽表的基础，一旦确定全部的数据流程，可以通过维度模型再生成对应宽表进行快速的业务支撑；

12. 数仓命名规范

12.1. 词根设计规范

词根的作用，就是用来统一命名，比如表名、字段名、主题域名、索引名、键名等，使相同字段表达同一个广为人知的含义。

词根属于数仓建设中的规范，属于元数据管理的范畴，现在把这个划到数据治理的一部分。完整的数仓建设是包含数据治理的，只是现在谈到数仓偏向于数据建模，而谈到数据治理，更多的是关于数据规范、数据管理。

• 表命名
  • 很大程度上是对元数据描述的一种体现，表命名规范越完善，能从表名获取到的信息就越多;
  • 比如：
    • 一部分业务是关于货架的，英文名是：rack， rack 就是一个词根，那就在所有的表、字段等用到的地方都叫 rack，不要叫成别的什么。
    • 指标体系中有很多“率”的指标，都可以拆解成 XXX+率，率可以叫 rate，那我 们所有的指标都叫做 XXX+rate。
• 示例：
  • 以流程图的方式来展示，更加直观和易懂，本图侧重 dwm 层表的命名 规范，其余命名是类似的道理：

第一个判断条件是该表的用途，是中间表、原始日志还是业务展示用的表 如果该表被判断为中间表，就会走入下一个判断条件：表是否有 group 操作 通过是否有 group 操作来判断该表该划分在 dwd 层还是 dwm 和 dws 层 如果不是 dwd 层，则需要判断该表是否是多个行为的汇总表（即宽表） 最后再分别填上事业群、部门、业务线、自定义名称和更新频率等信息即可。

• 分层：表的使用范围；

• 事业群和部门：生产该表或者该数据的团队；

• 业务线：表明该数据是哪个产品或者业务线相关；

• 主题域：分析问题的角度，对象实体；

• 自定义：一般会尽可能多描述该表的信息，比如活跃表、留存表等；

• 更新周期：比如说天级还是月级更新；

12.2. 数仓层次命名规范

• 公用维度：dim
• DM层：dm
• ODS层：ods
• DWD层：dwd
• DWS层：dws
• DIM层：dim
• ADS层：ads

12.3. 周期/数据范围命名规范

• 日快照：d
• 增量：i
• 全量：f
• 周：w
• 拉链表：l
• 非分区全量表：a

12.4. 常规表命名规范

• 常规表是我们需要固化的表，是正式使用的表，是目前一段时间内需要去维护去完善的表；
• 范例：<分层前缀[dwd|dws|ads]>_<部门>_<业务域>_<主题域>_<表内容>_<更新周期|数据范围>；
  • 业务域、主题域我们都可以用词根的方式枚举清楚，不断完善；
  • 更新周期主要的是时间粒度、日、月、年、周等；

12.5. 中间表命名规范

• 中间表一般出现在 Job 中，是 Job 中临时存储的中间数据的表；
• 中间表的作用域只限于当前 Job 执行过程中，Job 一旦执行完成，该中间表的使命就完成了，是可以删除的；
• 按照自己公司的场景自由选择，有写公司会保留几天的中间表数据，用来排查问题。
• 范例：<mid>_<table_name>_<[0~9|dim]>_20200101
  • table_name 是我们任务中目标表的名字，通常来说一个任务只有一个目标表，这里加上表名是为了防止自由发挥的时候表名冲突；
  • 末尾后缀，可以自由发挥起一些有意义的名字，或者简单粗暴使用数字代替，各有优劣谨慎选择；
  • 遇到需要补全维度的表，这里使用 dim 结尾；
  • 如果要保留历史的中间表，可以加上日期或者时间戳。

12.6. 临时表命名规范

• 临时表是临时测试的表，是临时使用一次的表，就是暂时保存下数据看看，后续一般不再使用的表，是可以随时删除的表；
• 范例：<tmp>_<xxx>
  • 只要加上 tmp 开头即可，其他名字随意；
  • 注意 tmp 开头的表不要用来实际使用，只是测试验证而已。

12.6. 维度表命名规范

• 维度表是基于底层数据，抽象出来的描述类的表；
• 维度表可以自动从底层表抽象出来，也可以手工来维护；
• 范例：_
  • 维度表，统一以 dim 开头，后面加上，对该指标的描述。

12.7. 手工表命名规范

• 手工表是手工维护的表，手工初始化一次之后，一般不会自动改变，后面变更，也是手工来维护。
• 一般来说，手工的数据粒度是偏细的，所以暂时统一放在 dwd 层，后面如果有目标值或者其他类型手工数据，再根据实际情况分层。
• 范例：_<业务域>__
  • 手工表，增加特殊的主题域，manual，表示手工维护表。

12.8. 指标命名规范

• 公共规则
  • 所有单词小写
  • 单词之间下划线分割（反例：appName 或 AppName）
  • 可读性优于长度 (词根，避免出现同一个指标，命名一致性)
  • 禁止使用 sql 关键字，如字段名与关键字冲突时 +col
  • 数量字段后缀 _cnt 等标识…
  • 金额字段后缀 _price 标识
  • 天分区使用字段 dt，格式统一（yyyymmdd 或 yyyy-mm-dd）
  • 小时分区使用字段 hh，范围（00-23）
  • 分钟分区使用字段 mi，范围（00-59）
  • 布尔类型标识：is_{业务}，不允许出现空值

13. 指标管理规范

13.1. 指标管理体系的必要性

数仓模型中，最重要的模块可能就是数据治理，我们在建立数仓分层的时候，虽然解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题，但是在给业务方提供不同数据需求的情况下不可避免的会发生一下几个问题：

• 指标定义不够清晰明确，两个页面上的指标定义其实是不同的，但是展示给商家看到的可能是同一个中文名称。又或者同样一个含义的指标在不同的界面上展示的名称却不相同，让人产生歧义。

• 同一个指标因为由不同的数据开发同学来制作，可能会被重复开发，不但造成资源浪费，还会造成维护困难。

• 对于需要新开发的指标，不仅缺少开发工具简化开发流程，甚至该使用哪些表，不该使用哪些表很大程度上都要凭借数据开发同学与数仓同学的经验。如果稍微马虎一点或者缺乏经验，比如使用了某些业务域下特有的表或者不是由数仓提供的统一中间层的表就可能会使用错误的数据，造成后期返工等情况。

• 而且在数据需求越来越多，数据中台提供的指标也日益丰富。但是指标定义混乱，描述不清会严重影响数据的可信度和数据开发的成本，所以就需要搭建一个指标系统，来维护已有的数据指标，并为未来可能新增的指标建立相应的规范。

13.1. 指标管理体系建设规范

• 原子指标
  • 原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词；
  • 如支付金额。原子指标描述的其实是一种指标的类型，比如订单支付金额，支付订单数，下单订单数，PV，UV 等等。

  • 在数仓分层的时候，进行维度建模，那么就必须指定好相应的主题域和事实表处理的最小逻辑（也就是事实），那么在这个基础上可以先定义原子指标。

  • 但业务方更关心的指标，是有实际业务含义，可以直接取数据的指标。比如：
    • 店铺近1天订单支付金额就是一个派生指标，会被直接在产品上展示给商家看。
    • 这个指标却不能直接从数仓的统一中间层里取数（因为没有现成的事实字段，数仓提供的一般都是大宽表）。
    • 需要有一个桥梁连接数仓中间层和业务方的指标需求，于是便有了派生指标。
• 派生指标
  • 派生指标 = 业务域 + 维度 + 原子指标 + 修饰词。
  • 当维度，原子指标，修饰词都确定的时候就可以唯一确定一个派生指标，同时给出具体数值。
  • 例如：店铺近1天订单支付金额中店铺是维度，近1天是一个时间类型的修饰词，支付金额是一个原子指标。
  • 业务方制作每一个派生指标都是通过选择维度，原子指标，修饰词三种元数据来定义的，相对于使用名称来区别不同指标，更可以保证指标的唯一性。
  • 如果2个派生指标是不同的，那他们的组成部分一定会有区别，或是不同维度，或是不同原子指标，修饰词。
  • 在数仓搭建的时候，业务域、维度、原子指标都是已经明确的，而修饰词是维度的某一些特殊的值，对应 SQL 中的 where 过滤条件。
  • 如果在数据产品的层面在某个业务域对指标数据定义、生产、使用等过程的流程规范化与平台化，那么就能够从源头上解决上面出现的数据指标不统一、重复开发、指标体系不好维护的问题。

13.3. 指标库

• 在指标管理的过程中，指标库给予每个指标一个精确且唯一的定义。通过指标库可以快速且规范的查询，开发和使用指标。

• 指标库主要提供如下服务：

  • 通过设置指标的组成要素来唯一精确定义每个指标（派生指标）。
  • 通过指标在业务域内唯一的性质，解决指标重复定义，重复开发，部分数据对不上的问题。
  • 通过将数仓中间层录入指标库为新制作指标提供指导性的 SQL 或库表推荐。
  • 打通其他各数据平台：
    • 打通数据开发平台和统一数据服务平台，为指标的定义，调度，在线使用提供一条龙服务，简化开发流程。
    • 打通数据资产管理平台，沉淀指标的资产价值。
    • 打通 BI 平台，提供拖拽维度，指标生成报表的功能。

  

• Previous
  数仓建模：数仓建模的概念详解
• Next
  数仓建模：数据建模命名规范