数据仓库设计规范文档
#数据仓库设计规范文档
| 版本 | 更新内容 | 备注 |
|---|---|---|
| v1.0 | 创建文档 | 2020-08-11 |
| v1.1 | 新增词根相关 | 2020-08-31 |
一. 数仓建设
1.1. 数据模型架构规范
分层是为了解决 ETL 任务及工作流的组织、数据的流向、读写权限的控制、不同需求的满足等各类问题。
总体来说，数仓划分为操作数据层、数据仓库层和数据集市层三部分
数据层次的划分
-
ODS：Operational Data Store，操作数据层，在结构上其与源系统的增量或者全量数据基本保持一致。它相当于一个数据准备区，同时又承担着基础数据的记录以及历史变化。
-
DW: 数据仓库层 细分为DWS和DWA。它的主要作用是完成数据加工与整合、建立一致性的维度、构建可复用的面向分析和统计的明细事实表以及汇总公共粒度的指标。
-
维度层: 基于维度建模理念思想，建立整个企业的一致性维度
-
DWS (Data Warehouse Service)，明细数据层,以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。可以结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当的冗余，即宽表化处理
-
DWA (Date Warehouse Aggregation)，汇总数据层。
-
临时层: 生产明细表和聚合表的时候，不可避免地会产生许多中间结果。所有这些中间结果并不承担对外提供服务的职责——它们对数据仓库的使用者是不可见的。为此单独设计了一个临时层来存放数仓层加工过程中可能产生的各种结果。临时层是在 Hive 上额外开辟的一个数据仓库开发人员专用的库。它承担了数据生产过程中问题数据的跟踪，也是数据存储清理时优先考虑的一块空间
-
-
DM：Data Mart，数据集市层。
1.2. ODS层设计规范
ODS层主要是解决：1）导表的冲突，2）落后的数据仓库中间层建设和日益增长的业务需求之间的矛盾。
- 导表的冲突
由于数据源有各种各样的库，源表表名重复是很正常的情况。因此我们需要给每个表加上主题域前缀，从而避免来自不同主题域的同名表之间的冲突。当同一主题域下出现同名表时，我们辅以额外的表后缀来区分。
落地层解决了统一导表的落地问题，也承担着全局 ETL 中的第一轮 Extract。原则上是使落地层里的数据和业务数据保持一致，这也是为了方便将来数据问题的排查与核对。
- 数仓建设和业务需求之间的矛盾
当时我们的人力完全无法满足众多需求方对数据的需求——数据中间层的建设赶不上飞速奔跑的业务需求。于是，一个折中的方法是让业务方直接使用落地层，自行处理一些不跨主题域的需求。这里有业务方非常熟悉的原始表，他们能非常迅速地获得所需要的数据。这也有利于快速、低成本地进行一些数据方面的探索和尝试。
####ODS层命名规范
-
表命名规范
-
表命名规则：主题域_项目名_原表名[_可选的后缀]。
-
可选的后缀的含义
- _incr ： 只包含了增量部分
- _tmp{从0开始的序号} ：ODS ETL过程的临时表
- _hh ： 按小时同步的全量表
- _incr_hh ：按小时同步的全量表
示例:
pc_mysql_minieastdaypc_config_newsrank ： 项目pc从mysql:minieastdaypc中全量导入的config_newsrank
pc_mysql_minieastdaypc_config_newsrank_incr ：项目pc从mysql:minieastdaypc中增量导入的config_newsran
pc_oracle_minieastdaywap_config_newsrank ： 项目pc从oracle:minieastdaypc中全量导入的config_newsrank
h5_log_active ： 项目h5 active日志
表命名不要怕长，要能一眼看清楚含义，表注释要清晰，类似 ods抽取的mysql业务表注释写: 从127.0.0.1/pc:config_newsrank 抽取。
- 字段命名规范
- 字段默认使用源系统的字段名。
- 字段名与关键字冲突时，在源字段名后加上col，即源字段名col。
####数据存储及生命周期管理规范
| 数据表类型 | 存储方式 | 最长存储保留策略 |
|---|---|---|
| ODS流水型全量表 | 按天分区 | 不可再生情况下，永久保存 日志:视情况保留 |
| ODS镜像型全量表 | 按天分区 | 重要的业务表及需要保留历史的表视情况保存 ODS全量表的默认生命周期为2天，支持通过dt=max_pt(tablename)方式访问数据 |
| ODS增量表 | 按天分区 | 有对应全量表，最多保留最近14天分区数据。 无对应全量表，需要永久保留数据。 |
| ODS ETL过程临时表 | 按天分区 | 最多保留最近7天分区 |
1.3. DW 数仓层设计规范
1. 维度层
- 表命名规范
dim_[业务/pub]{维度定义}[_{自定义命名标签}],其中的pub与具体业务无关，各个业务部都可以共用，例如时间维度。
示例:
dim_pc_config_newsrank
2. DWS (Data Warehouse Service) 明细数据层
- 表命名规范
dws_主题域[_可选的二级主题域]_相关描述
示例:
dws_pc_active
dws_pc_show
dws_pc_img_show
3. DWA (Date Warehouse Aggregation)，汇总数据层。
- 表命名规范
dwa_主题域_聚合维度
示例:
dwa_pc_softtype_qid_uid_pv ：根据softtype,qid,uid聚合的表
4. 临时层
- 表命名规范
tmp_项目名_业务名_时间
mid_项目名_业务名
示例:
tmp_pc_information_20200810: 以tmp开头和时间结尾的临时层表可以直接删除
mid_pc_active: 以mid开头的临时层的表可以删除数据
1.4. DM 数据集市层设计规范
数据集市层 (Data Mart) 根据主题域的不同在物理上进行划分——它表现为多个相互独立的库，各个数据集市之间不允许做数据依赖。每个数据集市可以由该主题域的使用方在数据仓库规范下自行开发和建设。
主要依据是以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段来物理化模型
整体参考:
| 分层数据库 | 数据库名 | 表命名规范 | 示例 | 备注 |
|---|---|---|---|---|
| ODS 落地层 | ods | 主题域_项目名_原表名[_可选的后缀] | pc_mysql_minieastdaypc_config_newsrank pc_oracle_minieastdaywap_config_newsrank h5_log_active |
mysql根据实际情况按照拉链表或者增量导入 log表类似pc_log 开头即可 表做好注释，这样能看出从哪里导入的 |
| 明细层 | dw | dws_主题域[_可选的二级主题域]_相关描述 | dws_pc_active dws_pc_show dws_pc_img_show |
|
| 聚合层 | dw | dwa_主题域_聚合维度 | dwa_pc_softtype_qid_uid_pv | 根据softtype,qid,uid聚合的表 |
| 通用维度层 | dw | dim_[业务/pub]{维度定义}[_{自定义命名标签}] | dim_pc_config_newsrank | 其中的pub与具体业务无关，各个业务部都可以共用，例如时间维度。 |
| 临时层 | tmp | tmp_项目名_业务名_时间 mid_项目名_业务名 |
tmp_pc_information_20200810 mid_pc_active |
以tmp开头和时间结尾的临时层表可以直接删除 以mid开头的临时层的表可以删除数据 |
| 数据集市 | dm_dc :dc报表数据集市 dm_interface :对外接口数据集市 |
rt_业务相关描述 根据实际情况设计表名 |
1.5. 其他规范
1. 词根
词根是维度和指标管理的基础，划分为普通词根与专有词根，提高词根的易用性和关联性。
· 普通词根：描述事物的最小单元体，如：类型-type。
· 专有词根：具备约定成俗或行业专属的描述体，如：智能咨询-qa。
(词根标准需大家一起收集并统一标准)
2. 公共规范
- 所有命名都要按照蛇形命名法 (snake_case)——全小写，单词之间用下划线分隔
- 所有表，列都需要注释
- 表名、字段名需以字母为开头。
- 表名、字段名最长不超过64个英文字符
- 优先使用词根中已有关键字（数仓标准配置中的词根标准），定期Review新增命名的不合理性。
公共字段定义规范
-
数据统计日期的分区字段按以下标准：
- 按天分区：dt(YYYYMMDD)。
- 按小时分区：hh(00-23)。
- 按分钟：mi (00-59)。
-
is_{业务}：表示布尔型数据字段。以Y和N表示，不允许出现空值域。
3. 指标命名规范
结合指标的特性以及词根管理规范，将指标进行结构化处理.
A. 基础指标词根，即所有指标必须包含以下基础词根（需大家共同维护）：
| 基础指标词根 | 英文全称 | Hive数据类型 | Oracle数据类型 | 长度 | 精度 | 词根 | 样例 |
|---|---|---|---|---|---|---|---|
| 数量 | count | Bigint | Number | 10 | 0 | cnt | |
| 比率/占比 | ratio | Decimal | Number | 10 | 4 | ratio | 0.9818 |
B.业务修饰词，用于描述业务场景的词汇，例如trade-交易。
C.日期修饰词，用于修饰业务发生的时间区间。
| 时间类型 | 全称 | 词根 | 备注 |
|---|---|---|---|
| 小时 | hour | h | |
| 日 | daily | d | |
| 周 | weekly | w | |
| 月 | month | m | |
| 季 | quarter | q | |
| 年 | year | y |
D.聚合修饰词，对结果进行聚集操作。
| 类型 | 全称 | 词根 | 备注 |
|---|---|---|---|
| 平均 | average | avg | |
| 周累计 | wtd | wtd | 本周一截止到当天累计 |
| 总量 | total | tol | |
| 标准差 | standard | deviation | std |
| … | … | … |
E.基础指标，单一的业务修饰词+基础指标词根构建基础指标 ，例如：交易金额：trade_amt。
F.派生指标，多修饰词+基础指标词根构建派生指标。派生指标继承基础指标的特性，例如：安装门店数量：install_poi_cnt。
G.普通指标命名规范，与字段命名规范一致，由词汇转换即可以。
H.日期类型指标命名规范，命名时要遵循：业务修饰词+基础指标词根+日期修饰词。将日期后缀加到名称后面.例如：7日交易金额：trade_amt_7d
I.聚合类型指标，命名时要遵循：业务修饰词+基础指标词根+聚合类型+日期修饰词。将累积标记加到名称后面.如：7日平均交易金额：trade_amt_avg_7d
4. 数据开发规范
-
表别名定义约定
建议将所有的表加上别名。一旦在SELECT语句中给操作表定义了别名，在整个语句中对此表的引用都必须惯以别名替代。考虑到编写代码的便捷性，约定别名尽量简洁，同时避免使用关键字。- 表别名采用简单字符命名。
- 多层次的嵌套子查询别名之前要体现层次关系，SQL语句别名或分层的命名，从第一层次至第四层次，分别用P、S、U、D表示，取意为Part，Segment，Unit，Detail。也可用a、b、c、d来表示第一层次到第四层次。对于同一层次的多个子句，可以在字母后加1、2、3、4区分。
- 必要时，为表别名添加注释
待续。。。。
3. 任务命名及工作流组织规范
任务是组成工作流的最小单位，也是完成一次 ETL 的最小开发单位，同时也是调度任务进行失败重试的最小单元。我们要求一个任务只写一张目标表，同时任务的命名中必须包含该目标表的表名。
工作流是一次调度应用的最小单元，它将一组具有相关性的共同调度频率的任务组织在一起。
同一主题、同一分层且同一调度周期的任务组织成一个工作流。
-
工作流命名规范
- 同步任务命名规范 ：imp_项目名_{源系统表名}
- 同步节点导出任务 ：exp_项目名_{源系统表名}
待续
1.6. 主题域的划分
主题域的考虑可以从数据仓库层或者数据集市层出发，考虑将全域的数据分散到若干个主题中存放。就像图书管理员需要将书籍分门别类一样，主题域的划分是为了将相关的数据组织在一起，从而使其更容易被寻找和使用。
1.7. 权限的设计
待定：根据后续实际情况
1.8. 数据字典
业务表字段都需要加注释
元数据管理是一个单独的模块
1.9. 任务的优先级
在 Hadoop 的环境下，任务之间不可避免会出现集群资源竞争的关系。如果没有一个优先级规则，那么大量任务运行时，产出时间的波动是不可控的。需要任务的优先级，在调度层面让高优先级的任务优先进入队列，从而更容易获得资源。
待定…
参考:
- 有赞数据仓库实践之路