【数据中台】数据仓库设计规范

为了解决数据仓库建设过程中出现的各种痛点，我们从模型与规范两个方面进行建设，并提出设计统一归口。

1. 模型

规范化模型分层、数据流向，从而降低研发成本，增强指标复用性，并提高业务的支撑能力。

 

1.1. 模型分层

为了保证数据层的稳定又要屏蔽对下游的影响，并且要避免链路过长，我们将分层进行统一定义为四层：

ODS（Operational Data Store）：定义为存储层，仅以技术手段(存储快照形式)保留历史数据，不作任何转换，与业务侧db实体保持同构。压缩采用 Snappy，存储采用 orc，根据需求创建分区表并采用列式存储。

DWD（Data Warehouse Detail）：定义为明细层，对数据进行规范化（编码转换、清洗、统一格式、脱敏、维度退化和降维，隔离等），很多同学不是很理解隔离的重要性，在构建整个数仓的过程中，不可避免会发生源业务系统的表结构或者表本身发生变化，如果没有一个中间层进行隔离的话，如果对应的底表被多个下游表使用，那么模型的修改代价是非常大的。因此该层主要对原系统变更进行隔离，尽可能保证对外的模型接口不变。

DWB（Data Warehouse Basic）：定义为汇聚层，集中建设通用性维度和指标，降低业务需求开发成本。

DWS（Data Warehouse Service）：定义为主题宽表层，对DWD、DWB各信息进行联合整合。

APP：定义为应用层，面向业务需求进行定制开发。

DIM（Dictionary Data Layer）：定义为维度表。

TMP：定义为中间层临时表（建议在一定的周期内删除）。

BAK：定义为备份表。

1.2. 模型数据流向

稳定业务按照标准的数据流向进行开发，即ODS–>DWD–>DWB–>DWS–>APP或者ODS–>DWD–>DWB–>APP。

非稳定业务或探索性需求，可以遵循ODS->DWD->APP或者ODS->DWD->DWS->APP两个模型数据流。在保障了数据链路的合理性之后，又在此基础上确认了模型分层引用原则：

· 正常流向：ODS>DWD->DWB->DWS->APP，对于使用频度非常低的表允许DWD->DWS。

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

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

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

· 禁止出现反向依赖，例如DWS的表依赖APP的表。

1.3 模型开发规则

1. 所有任务都必须严格配置任务依赖，如果没有配置任务依赖，会导致前一个任务没有正常产出数据的情况下，后一个任务被调度起来，基于错误的数据空跑，浪费资源，同时增加了排查故障的复杂度；

2. 任务中创建的临时表，在任务结束前应该删除，如果不删除，会发现有大量的临时表存在，占用空间；

3. 任务名称最好跟表名一致，方便查找和关联；

4. 生命周期的管理，对于 ODS 和 DWD，一般尽可能保留所有历史数据，对于DWS/ADS/DM 需要设置生命周期，7～30 天不等；

5.  DWD 层表宜采用压缩的方式存储，可用 lzo 压缩。

2. 规范

模型是整个数仓建设基石，规范是数仓建设的保障。为了避免出现指标重复建设和数据质量差的情况，我们统一按照最详细、可落地的方法进行规范建设。

2.1 词根

词根是维度和指标管理的基础，划分为普通词根与专有词根，提高词根的易用性和关联性。

· 普通词根：描述事物的最小单元体，如：类型-type。

· 专有词根：具备约定成俗或行业专属的描述体，如：智能咨询-qa。

(词根标准需大家一起收集并统一标准)

2.2 表命名规范

· 蛇形命名法---全小写，单词之间用下划线分隔。

· 表名、字段名采用一个下划线分隔词根（示例：clienttype -> client_type）。

· 每部分使用小写英文单词，属于通用字段的必须满足通用字段信息的定义，如英文单词过长，可使用英文首字母代替，并加入专有词根。

· 表名、字段名需以字母为开头。

· 表名、字段名最长不超过64个英文字符。

· 优先使用词根中已有关键字（数仓标准配置中的词根标准），定期Review新增命名的不合理性。

· 在表名自定义部分禁止采用非标准的缩写。

2.3.  表命名规则

2.4 任务命名及工作流组织规范

任务是组成工作流的最小单位，也是完成一次 ETL 的最小开发单位，同时也是调度任务进行失败重试的最小单元。我们要求一个任务只写一张目标表，同时任务的命名中必须包含该目标表的表名。

工作流是一次调度应用的最小单元，它将一组具有相关性的共同调度频率的任务组织在一起。

在没有工作流组织规范之前，我们的工作流组织因人而异显得五花八门。杂乱的工作流同样不利于数据仓库的管理和维护。于是我们将同一主题、同一分层且同一调度周期的任务组织成一个工作流。

2.5 指标命名规范

结合指标的特性以及词根管理规范，将指标进行结构化处理.

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

2.6 字符集

Hadoop和hive 都是用utf-8编码的，在建表时可能涉及到中文乱码问题，所以导入的文件的字符编码统一为utf-8格式。

2.7 约定

理论上在数仓落地的表不应该出现null未知类型，对于可能出现null的字段，如果为字符型统一为空字符串，如果是数值则给0。

3. 模型设计文档

结合模型与规范，形成模型相关设计文档。模型设计文档涉及内容：

· 需求映射关系表：描述实现某一需求时所涉及的ODS、DWD、DWB、DWB层各个表的详细信息。

· 数据流图：画出从ODS层—->DWD层—->DWB—->DWS—->APP层表之间的数据流向关系图，作为数仓的储备知识库和ETL开发向导。

· 物理模型表结构设计：表所有字段、类型、含义等。

· 词根表：将该物理模型表的新词根由审核人员核验后，更新到文档中（需要wiki文档支持）。

· 贴源层库表来源文档：记录数据源的详细信息。

4. 调度shell脚本

调度脚本主要是通过跑shell脚本，shell脚本的注意点：

1）命名与所跑的目标表名相同，注释要完善，后缀以.sh结尾。

2）脚本头需要加上分割线、作者、日期、目的、描述等信息。

5. 数据生命周期

一般原始数据和明细数据，会保留完整的历史数据。而在汇总层、集市层或者应用层，考虑到存储成本，数据建议按照生命周期来管理，通常保留几天的快照或者分区。