数据开发及设计规范

数据模型开发规范

数据模型的公共层设计要遵循维度建模的思想和理念。数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。数据模型开发的基本原则如下。

1.数据要干净、有效

要保证进入数据模型的数据是经过清洗和规范的。

2.模型可扩展

核心模型要尽可能保持稳定，经常变化的业务可以通过扩展模型进行分离。

3.禁止逆向调用

禁止逆向调用,例如不能出现ODS 层调用M DS 层数据。

4.数据可回滚

数据模型多次重跑的结果数据必须保持一致。

5.成本控制

在构建数据模型时，要充分考虑计算和存储资源间的平衡。

 

 

数据表的命名规范

1.ODS层数据表的命名规范

表命名规则:ods_(数据源}_(原始表名)

字段默认使用源系统字段名称

2.DWD层数据表的命名规范

表命名规则:dwd_(数据域缩写/ust/ord/prd)_(业务过程缩写)[_自定义标签缩写]_(刷新周期标识)_(单分区增量全量标识)

例：dwd_ usr_visit_rel_m_i

3.DWS层数据表的命名规范

表命名规则:dws_(数据域缩写/usr/ord/prd)[_自定义标签缩写]_[刷新周期标识)[_单分区增量全量标识]

例:dws_usr_trd_d

4.维表的命名规范

表命名规则:dim_(维度定义)例:dim_usr

5.ADS层数据表的命名规范

表命名规则:ads_[_数据域缩写/usr/ord/prd][_业务应用缩写][_自定义标签缩写]_{刷新周期标识)

例:ads_usr_count_d

数据表的设计策略

1.DWD层数据表的设计策略

(1)根据业务过程来定义并建立事实表，在事实表内描述业务过程对应的原子粒度的事物信息。

(2)通过元数据系统查询判别当前建模对应的业务过程是否已有DWD层事实表,把相同业务过程的度量指标维护在同一个基础层模型表内。

(3)DWD层大维度表上的常用统计属性可以冗余到事实表中，以便引用和关联。

2.DWS层数据表的设计策略

(1)确定 DWS 层模型所对应的维度和度量信息。

(2)确定对度量进行的衍生计算方式，如求和统计、去重统计。

(3)确定数据的剧新周期。

 

 

数据开发规范

1.代码书写规范

1)代码结构规范

(1)所有代码都应该放人对应的目录中，如 DWD 层代码应该放入DWD 目录中，且以 DWD 为命名首字母。

(2)不允许 tmp、test 任务出现在目录结构中。

(3)如果需要临时创建tmp、test 任务，那么不可以将其配置为周期调度任务，并且使用完成后需要立即删除。

在开发环境中创建的tmp、test 任务,不可以被发布到生产环境中。

任务名称和产出表的名称需要保持一致，每个 SQL 语句的任务否少需要一个输出表。

(4)在代码最上面的部分，需要添加任务名称、开发者、创建时间、任务描述等注释。

(5)在代码中间的部分，需要添加目标表的 create table if not exists 语句，以确保表存在者被顺利构建。

(6)在代码的下面部分，需要添加 insert overwrite 语句，以确保数据真正插人。

2)任务命名规范

(1)任务需要以产出表的名称命名。

(2)如果是中间表，那么要以业务划分+mid 结尾。

(3)如果任务的业务逻辑复杂，需要用到子任务，那么要将任务和任务下的子任务放到同一个文件夹下。

3)代码格式统一

SQL语句中的关键字用大写，其余的语句用小写(包括函数)。

4)时间格式统一

(1)统一数据插人时间:yyyy-mm-dd hh:mi:ss.

(2)统一数据统计日期:yyyymmdd.

(3)统一带小时的时间格式:yyyy-mm-dd hh:mi:ss.

(4)统一日期格式:yyyymmdd.

5)通数使用建议

对于能封装成函数来使用的复杂逻辑，我们要尽量使用函数。

6)代码开发建议

(1)在表关联中尽量合理使用子查询完成数据的预处理，然后再进行关联。

(2)不使用 select*语句。

(3)子查询只查询必需的列。

(4)如果脚本需要支持重跑，那么注意覆盖原有数据。

(5)代码要有缩进规范，要便于阅读理解，要有关键注释

7)周期调度配置

(1)目前支持的任务调度周期有五种:天、周、月、分钟小时。

(2)调度规则--任务实例是否能完成需要看以下条件:

① 上游任务实例是否都运行成功。若所有上游任务实例都运行成功，则触发任务进入等待时间状态。

② 是否已经到了任务实例的设定时间。任务实例进入等待时间状态后会检查是否到了本身的设定时间，如果时间到了，那么进入等待资源状态。

③ 当前调度资源是否充足。任务实例进入等待资源状态后，检查当前本项目的调度资源是否充足，若充足则可以运行。

(3)调度周期和调度时间参数配合使用。

8)参数配置说明

(1)当涉及系统的业务日期、业务实际发生的日期、数据被生产出的日期等日期变量时，使用参数${system.bizdate}，默认格式为yymmdd。

(2)当涉及系统任务实例的定时运行时间等日期变量时，使用参数${system.cyctime}，默认格式为yyyymmddhh24miss.

(3)注意:参数${system.cyctime}得到的日期默认为参数${system.bizdate}得到的日期的后一天，在正常调度时两个参数由系统代人，在测试运行或手动执行时我们需要手动输入参数值。

(4)测试和补数据都是手动生成的任务实例，需要选择业务日期才能够顺利执行。

9)动态分区的使用

如果数据延迟，那么我们需要刷新以前的分区数据，可以使用动态分区。动态分区是指在插人数据时不指定具体分区，而按照查询出来的数据判断数据应该插人哪个分区。

 

 

2.任务发布规范

1)任务发布前提

(1)已配置好周期调度

(2)已配置好上游依赖。

(3)已配置好相应的参数。

(4)任务测试运行通过。

(5)已测试并验证过数据产出的正确性。

2)任务发布流程

为了将开发环境和生产环境隔离，数据运维人员需要将数据开发人员提交的作业发布至生产环境，并且在生产环境里运行成功，要尽量防止出现生产故障。

3)任务发布的注意事项

(1)我们要查看需要发布的任务是否在等待发布的任务中，如果在等待发布的任务中，那么无法进行新的发布，需要将等待发布的任务中的相应任务删除，才可以进行重新发布，要避免由于版本冲突带来的业务逻辑出错。

(2)我们可以把需要发布的任务打包进行一次性发布，要避免多次发布。

 

 

3.任务运维规范

1)失败任务运维

(1)数据运维人员需要及时查看状态为失败的任务，由于不允许存在失败状态的任务实例，如果有任务失败，那么我们需要及时处理。

(2)对于失败任务，数据运维人员需要查看失败任务运行的代码，找到失败的原因。如果代码有问题，那么我们需要先在开发环境中修改代码，再将修改完善后的代码发布到生产环境中。在发布代码之后，我们需要在运维中心找到报错的对应任务，点击任务让其重新运行。

(3)如果重新运行的任务继续报错，那么我们要按此流程重新操作，直至实例成功。

(4)对于失败任务可手动进行相应的补数据。

2)未运行任务运维

理论上当天业务日期下面的实例都应该成功运行(未到运行时间的任务除外)。如果出现未运行的任务,那么我们需要检查原因(例如，可能是上游的任务报错导致下游的任务未运行)，需要按照失败任务的处理方式进行处理，使得上游任务成功，下游任务自动开始运行。

3)补数据任务运维

补数据任务不可存在失败或未完成状态。如果失败，那么应该修改任务的相关代码，然后点击当前的补数据任务，使其重新运行，而不能新发起一个补数据任务。

4)周期任务的报警

(1)对于以上失败、未完成的周期性任务实例，应当添加报警任务、报警任务可以及时通知相关人员进行处理。

(2)每个任务都需要有明确的对应责任人。

 

 

4.数据质量核查规范

(1)检查数据的行数是否符合预期。

(2)检查数据不可为空的列是否有空值。

(3)检查是否有数据不符合规范的格式。

(4)检查表的主键值是否唯一。

(5)将检查规则脚本配置为周期调度的任务，对每日周期性任务的数据产出进行数据质量的检查。

①在dqm( data quality monitor)目录对应任务的目录下创建周期性的工作流任务，目录结构一定要和正式任务的目录结构保持一致。

②在工作流任务中添加逻辑检查节点，有几个内部任务节点就对应几个逻辑检查节点。

③ 在内部节点中实现数据质量检查逻辑的代码运行。

④配置被检查的任务为上游依赖，然后提交任务。