1) 指标梳理
指标口径的不一致使得数据使用的成本极高，经常出现口径打架、反复核对数据的问题。在数据治理中，我们将需求梳理到的所有指标进行进一步梳理，明确其口径，如果存在两个指标名称相同，但口径不一致，先判断是否是进行合并，如需要同时存在，那么在命名上必须能够区分开。
2) 指标管理
指标管理分为原子指标维护和派生指标维护。
原子指标：
- 选择原子指标的归属产线、业务板块、数据域、业务过程
- 选择原子指标的统计数据来源于该业务过程下的原始数据源
- 录入原子指标的英文名称、中文名称、概述
- 填写指标函数
- 系统根据指标函数自动生成原子指标的定义表达式
- 系统根据指标定义表达式以及数据源表生成原子指标SQL
派生指标：
- 在原子指标的基础之上选择了一些维度或者修饰限定词。
6. 数据表处理规范
1) 增量表
新增数据，增量数据是上次导出之后的新数据。
- 记录每次增加的量，而不是总量；
- 增量表，只报变化量，无变化不用报；
- 每天一个分区。
2) 全量表
每天的所有的最新状态的数据。
- 全量表，有无变化，都要报；
- 每次上报的数据都是所有的数据（变化的 + 没有变化的）；
- 只有一个分区。
3) 快照表
按日分区，记录截止数据日期的全量数据。
- 快照表，有无变化，都要报；
- 每次上报的数据都是所有的数据（变化的 + 没有变化的）；
- 一天一个分区。
4) 拉链表
记录截止数据日期的全量数据。
- 记录一个事物从开始，一直到当前状态的所有变化的信息；
- 拉链表每次上报的都是历史记录的最终状态，是记录在当前时刻的历史总 量；
- 当前记录存的是当前时间之前的所有历史记录的最后变化量（总量）；
- 只有一个分区。
7. 表的生命周期管理
这部分主要是要通过对历史数据的等级划分与对表类型的划分生成相应的生命周期管理矩阵。
1) 历史数据等级划分
主要将历史数据划分P0、Pl、P2、P3 四个等级，其具体定义如下：
- P0 ：非常重要的主题域数据和非常重要的应用数据，具有不可恢复性，如交易、日志、集团 KPI 数据、 IPO 关联表。
- Pl ：重要的业务数据和重要的应用数据，具有不可恢复性，如重要的业务产品数据。
- P2 ：重要的业务数据和重要的应用数据，具有可恢复性，如交易线 ETL 产生的中间过程数据。
- P3 ：不重要的业务数据和不重要的应用数据，具有可恢复性，如某些 SNS 产品报表。
2) 表类型划分
- 事件型流水表（增量表）
事件型流水表（增量表）指数据无重复或者无主键数据，如日志。
- 事件型镜像表（增量表）
事件型镜像表（增量表）指业务过程性数据，有主键，但是对于同样主键的属性会发生缓慢变化，如交易、订单状态与时间会根据业务发生变更。
- 维表
维表包括维度与维度属性数据，如用户表、商品表。
- Merge 全量表
Merge 全量表包括业务过程性数据或者维表数据。由于数据本身有新增的或者发生状态变更，对于同样主键的数据可能会保留多份，因此可以对这些数据根据主键进行 Merge 操作，主键对应的属性只会保留最新状态，历史状态保留在前一天分区 中。例如，用户表、交易表等都可以进行 Merge 操作。
- ETL 临时表
ETL 临时表是指 ETL 处理过程中产生的临时表数据，一般不建议保留，最多7天。
- TT 临时数据
TT 拉取的数据和 DbSync 产生的临时数据最终会流转到 DS 层，ODS 层数据作为原始数据保留下来，从而使得 TT&DbSync 上游数据成为临时数据。这类数据不建议保留很长时间，生命周期默认设置为 93天，可以根据实际情况适当减少保留天数。
7. 普通全量表
很多小业务数据或者产品数据，BI一般是直接全量拉取，这种方式效率快，对存储压力也不是很大，而且表保留很长时间，可以根据历史数据等级确定保留策略。
通过上述历史数据等级划分与表类型划分，生成相应的生命周期管理矩阵，如下表所示：
三、数仓各层开发规范
1. ODS层设计规范
同步规范：
- 一个系统源表只允许同步一次；
- 全量初始化同步和增量同步处理逻辑要清晰；
- 以统计日期和时间进行分区存储；
- 目标表字段在源表不存在时要自动填充处理。
表分类与生命周期：
- ods流水全量表：
- 不可再生的永久保存；
- 日志可按留存要求；
- 按需设置保留特殊日期数据；
- 按需设置保留特殊月份数据；
- ods镜像型全量表：
- 推荐按天存储；
- 对历史变化进行保留；
- 最新数据存储在最大分区；
- 历史数据按需保留；
- ods增量数据：
- 推荐按天存储；
- 有对应全量表的，建议只保留14天数据；
- 无对应全量表的，永久保留；
- ods的etl过程中的临时表：
- 推荐按需保留；
- 最多保留7天；
- 建议用完即删，下次使用再生成；
- BDSync非去重数据：
- 通过中间层保留，默认用完即删，不建议保留。
数据质量：
- 全量表必须配置唯一性字段标识；
- 对分区空数据进行监控；
- 对枚举类型字段，进行枚举值变化和分布监控；
- ods表数据量级和记录数做环比监控；
- ods全表都必须要有注释；
2. 公共维度层设计规范
1) 设计准则
- 一致性
共维度在不同的物理表中的字段名称、数据类型、数据内容必须保持一致（历史原因不一致，要做好版本控制）
- 维度的组合与拆分
- 组合原则：
将维度与关联性强的字段进行组合，一起查询，一起展示，两个维度必须具有天然的关系，如：商品的基本属性和所属品牌。
无相关性：如一些使用频率较小的杂项维度，可以构建一个集合杂项维度的特殊属性。
行为维度：经过计算的度量，但下游当维度处理，例：点击量 0-1000,100-1000等，可以做聚合分类。
- 拆分与冗余：
针对重要性，业务相关性、源、使用频率等可分为核心表、扩展表。
数据记录较大的维度，可以适当冗余一些子集。
2) 存储及生命周期管理
建议按天分区。
- 3个月内最大访问跨度<=4天时，建议保留最近7天分区；
- 3个月内最大访问跨度<=12天时，建议保留最近15天分区；
- 3个月内最大访问跨度<=30天时，建议保留最近33天分区；
- 3个月内最大访问跨度<=90天时，建议保留最近120天分区；
- 3个月内最大访问跨度<=180天时，建议保留最近240天分区；
- 3个月内最大访问跨度<=300天时，建议保留最近400天分区；
3. DWD明细层设计规范
1) 存储及生命周期管理
建议按天分区。
- 3个月内最大访问跨度<=4天时，建议保留最近7天分区；
- 3个月内最大访问跨度<=12天时，建议保留最近15天分区；
- 3个月内最大访问跨度<=30天时，建议保留最近33天分区；
- 3个月内最大访问跨度<=90天时，建议保留最近120天分区；
- 3个月内最大访问跨度<=180天时，建议保留最近240天分区；
- 3个月内最大访问跨度<=300天时，建议保留最近400天分区；
2) 事务型事实表设计准则
- 基于数据应用需求的分析设计事务型事实表，结合下游较大的针对某个业务过程和分析指标需求，可考虑基于某个事件过程构建事务型实时表；
- 一般选用事件的发生日期或时间作为分区字段，便于扫描和裁剪；
- 冗余子集原则，有利于降低后续IO开销；
- 明细层事实表维度退化，减少后续使用join成本。
3) 周期快照事实表
- 周期快照事实表中的每行汇总了发生在某一标准周期，如某一天、某周、某月的多个度量事件。
- 粒度是周期性的，不是个体的事务。
- 通常包含许多事实，因为任何与事实表粒度一致的度量事件都是被允许的。
