离线数仓经验之谈三-数仓流程规范_数仓加工流程

数仓流程规范

目录

1. 目的

2. 适用范围

3. 总体流程

• 3.1. ETL开发流程

• • 3.1.1. 需求分析
• • 3.1.2. 数据来源与数据探查
• • 3.1.3. 数据模型设计
• • 3.1.4. ETL开发
• • 3.1.5. 测试
• • 3.1.6. ETL上线
• • 3.1.7. 数据质量校验
• • 3.1.8. 验收

• 3.2. 数据服务开发流程

• • 3.2.1. 需求分析
• • 3.2.2. 数据来源
• • 3.2.3. 模型设计与开发
• • 3.2.4. 模型数据测试
• • 3.2.5. 数据服务开发
• • 3.2.6. 测试
• • 3.2.7. 上线
• • 3.2.8. 验收

• 3.3. 数据拉取流程

• • 3.3.1. 需求分析
• • 3.3.2. 数据来源
• • 3.3.3. 需求实现
• • 3.3.4. 测试
• • 3.3.5. 结果导出
• • 3.3.6. 验收

4. 测试

• 4.1. 单元测试

• 4.2. 联调测试

• 4.3. 全链路测试

• 4.4. 准入测试标准

5. 任务标准

• 5.1. 完整性

• 5.2. 准确性

• 5.3. 一致性

• 5.4. 及时性

1. 目的

• 确保数据的准确性、及时性、一致性、完整性
• 数据开发过程中避免重复无效沟通、信息不完整

2. 适用范围

数仓开发、报表开发、数据分析、数据BP等数据相关人员

3. 总体流程

数据流程总体分为：数仓开发、报表开发、数据拉取。

• 数仓开发：将源数据抽取到指定目标的过程。

• 数据服务：将指定数据通过图表方式进行可视化的过程。

• 数据拉取：根据业务需求通过代码实现数据输出的过程。

工期超过3个工作日，需要给出相应的排期计划；工期超过5个工作日，需要提供相应的设计文档。

所有的QS都必须提交测试，是否需要测试由测试决定。

• 代码审核

3.1. 数仓开发流程

3.1.1. 需求分析

• 了解需求背景
• 分析需求所需要实现的功能，确认需求范围
• 理解需求后与需求方确认双方理解一致
• QS状态为【接受】与工期评估

3.1.2. 数据源与数据探查

• 确认数据来源

a) 业务数据库确认连接信息；日志数据确认日志服务器与日志目录

b) 梳理需要同步的数据清单（如：库、表、日志、数据范围）

• 数据探查

数据来源分两类：一类业务数据（DB）;一类行为数据（日志）。两类数据都需要对结构、字段、字段值、字段解释进行探查。

• • 表、日志结构

表结构或日志结构实际是否与文档描述一致，如：业务方说某字段在表中是唯一，但实际表结构并未设置唯一键问题；防止发生少表问题。

• • 字段

实际是否与文档描述一致，防止发生缺少字段、新加字段问题。

• • 字段值

实际检查枚举值、状态值等是否与文档描述一致，防止与业务方描述不一样问题。

• • 解释

表结构、日志结构、字段都应当有具体文档解释说明。

3.1.3. 数据模型设计

数据仓库中的ODS、DW层统一由ETL开发完成，ETL开发需要负责ETL数据过程与目标表设计与创建。

• ODS层模型

ODS层模型结构与源数据结构基本上是完全一致的，只有在特定情况下会新增字段。如：分表、分库表则会添加一个source_table字段用来区分数据来源。

• DW层模型

• • 范式设计

1. 对业务数据不熟悉且又需要满足业务数据需求

• • 合并

1. 数据粒度一样，如：用户信息，用户扩展信息等
2. 数据业务，业务数据80%都会一起使用，可以将属性信息合并

• • 拆分

1. 数据量非常大属性信息非常多且部分数据没有关联。可进行数据拆分存储

• • 实体建模

• DM层模型

• • 维度建模

1. 星型模型
2. 雪花模型
3. 星座模型

• • 用户画像

1. 用户画像

• DA层模型

DA层模型则根据具体业务需求设计。

3.1.4. ETL开发

• 确定数据抽取频次（时、天、周、月）
• 确定数据抽取口径（全量、增量）
• 确定数据清洗逻辑（非ODS层，ODS层暂不做处理）
• 确定数据装载策略
• • 增量（不会更新）
• • 全量
• • Merge
• 实现ETL开发
• • 确定数据主表
• • 确定主表关系（1：1、N：1）
• • 公用数据创建数据临时表
• • 多指标计算使用union all后聚合

3.1.5. 测试

• 任务开发脚本和数据测试在测试库完成；
• 如果是表结构变更需要在测试库将历史数据跑全；
• 按业务重要等级区分备份与下游依赖重要等级区分备份；
• 正式上线表切换Rename脚本准备；
• 表切换前先前目标表进行备份；（备份表上线一周后手动清理）

# 切换操作
alter table 库名.目标表 rename to test.目标表_QSID_old;
alter table test.目标表 rename 库名.目标表;

# 回滚操作
alter table 库名.目标表 rename to test.目标表_QSID_new;
alter table test.目标表_QSID_old rename 库名.目标表;
1
2
3
4
5
6
7

3.1.6. ETL上线

• 代码部署系统上线
• 【项目开发】创建Hive脚本，仅对HQL\SQL脚本
• 【调度系统】创建定时调度，配置任务依赖、调度时间、任务试跑
• 常规ETL任务错误邮件预警必须在一个工作日内处理完成；对外提供服务的ETL任务错误邮件预警必须在一个小时内处理完成。
• 调度系统调度的任务脚本必须是GitLab管理脚本；调度任务之间任务依赖设置

3.1.7. 数据质量校验

• 常规任务必须配置至少一条以上校验规则
• 对外提供服务数据至少两条以上校验规则，必须是交叉验证规则
• 周一至周五收到调度、数据质量邮件预警必须在一个小时处理完成，周六周日收到调度、数据质量邮件预警则必须当天处理完成

3.1.8. 验收

需求开发完成上线通知数据使用方验收，确认当前数据没有问题即可。

3.2. 数据服务开发流程

3.2.1. 需求分析

• 了解需求背景
• 分析需求所需要实现的功能，确认需求范围
• 理解需求后与需求方确认双方理解一致
• QS状态为【接受】与工期评估

3.3.2. 数据来源

• 与数据BP确认每个字段数据来源
• 将自己理解与数据BP讲解确保双方理解一致

3.2.3. 模型设计与开发

• 确认维度指标且采用维度建模方式
• 模型数据代码开发

3.2.4. 模型数据测试

3.2.5. 数据服务开发

• 固定报表开发

• • 确定报表数据表名称与数据集
• • 确定报表控件、格式、布局、显示名称
• • 《数据报表平台》报表菜单配置

• 数据分析开发

• • 根据《数据分析系统》接入模板填写

• 数据文件开发

• • 根据需求开发完成后，将文件同步接口维护到《数仓数据服务清单.xlsx》文档中

• API接口开发

• • 根据需求开发完成后，将API接口维护到《数仓数据服务清单.xlsx》文档中

3.2.6. 测试

• 固定报表测试

• • 报表数据可视化和数据测试在测试目录完成；
• • 按业务重要等级区分备份；
• • 报表切换前先将目标报表进行备份；（备份上线一周后手动清理）

# 切换操作
报表另存为【报表名_QSID_old】
将测试报表Rename【报表名】

# 回滚操作
将已上线的报表Rename【报表名_QSID_new】
将【报表名_QSID_old】Rename【报表名】
1
2
3
4
5
6
7

• 分析报表测试

创建临时表将原表数据导入后，然后同时将临时表Rename成正式表，正式表Rename成旧表。参考报表测试操作。

• 数据文件测试

测试文件数据与源表数据一致且数据导出过程中出错通过调度任务邮件预警。配置数据质量预警，如：规定时间未出数据。

• API接口测试

API接口数据与源表数据一致且调用接口时查询与源表数据一致。配置数据质量预警，如：规定时间未出数据。

3.2.7. 上线

• 《数据报表平台》报表菜单用户权限访问配置

• 按照《数据分析平台》接入模板填写将QS转交给志强无问题

• 指标录入《元数据系统》

• 接口、数据文件按维护到《数仓数据服务清单.xlsx》文档中

3.2.8. 验收

• 数据BP将报表访问地址开放给需求方且需求方验收没有问和关闭QS

3.3. 数据拉取流程

3.3.1. 需求分析

• 了解需求背景
• 分析需求所需要实现的功能，确认需求范围
• 理解需求后与需求方确认双方理解一致
• QS状态为【接受】与工期评估

3.3.2. 数据来源

• 与数据BP确认每个字段数据来源
• 将自己理解与数据BP讲解确保双方理解一致

3.3.3. 需求实现

• 实现数据需求代码开发，遵守开发流程与开发规范

3.3.4. 测试

3.3.5. 结果导出

• 根据需求导出数据上传QS且通知数据BP，代码则按data-analysis规范合并到项目中

3.3.6. 验收

• 数据BP核验无误将数据结果提交给需求方，需求方验收没有问题和问关闭QS

4. 测试

4.1. 单元测试

4.2. 联调测试

数据环节有依赖关系时需要进行联调测试，前提必须先做完单元测试；比如：报表开发，可以分两个环节测试，第一步测试数据是否装载到DM表且导入到可视化查询存储（MySQL、Kylin）。第二步测试报表查询结果。

4.3. 全链路测试

暂无

4.4. 准入测试标准

准入测试标准如下：

1. 单元测试无误
2. 提供相关的需求文档
3. 提供相应的目标表ETL字段级映射文档
4. 提供涉及到目标表加工处理流程图（注：标注哪些是新增表、已有的表）
5. 提QS给到产品负责人由产品负责人转接测试人员
6. 提供上线影响范围（数据层面、代码层面）

5. 任务标准

确保数据的准确性、一致性、完整性、及时性

月新QS任务数据问题不超过3次，月历史QS任务数据问题不超过2次

数据问题定义：一个QS任务包含ETL开发、调度任务、数据质量、报表开发等环节，如其中某个环节出错，则表示此QS是有数据问题；相同一个任务出错N次则算N-1次数据问题

注：所有QS开发的前提是遵循《数仓开发规范V1.0》和《数仓流程规范V1.0》

5.1. 完整性

完整性是指数据信息是否缺失，信息缺失分为：记录缺失，字段缺失

• 记录缺失

记录缺失是指数据的记录数丢失，如：100万条变成90万条数据问题。

• 字段缺失

字段缺失是指表数据记录中缺少某个字段数据。

5.2. 准确性

是指数据仓库【源】到【目标】、【源】到【可视化】整个过程的数据准确性

a) 数据处理后不存在处理逻辑BUG，导致数据不准确。

b) 数据中记录的信息和数据是准确的，不存在异常或者错误的信息。

5.3. 一致性

数据一致性可分为：业务一致性，数据一致性

• 业务一致性

是指业务指标分支，对于同一份数据，指标结果必须保证一致性。

• 数据一致性

是指数据仓库数据统一数据格式、数据处理后数据致是一致

如：相同字段数据类型、格式不一样、字段错位；数据处理后变成乱码等问题。

5.4. 及时性

及时性分为：任务及时性，数据及时性，报表及时性

• 任务及时性

任务在合理的预估工期内按质量完成任务

• 数据及时性

对外服务的数据需要在8点之前将任务数据跑出；其它API、数据文件则按业务方需求按时出数据；

DW层单个脚本执行时长不能超过2k秒，DM层单个脚本执行时长不能超过1K秒。

• 报表及时性

对外服务的报表数据打开页面响应时长不超过3秒，明细数据除外但需要满足业务方需求。

注：展示在《数据报表平台》、《数据分析系统》上的指标录入《元数据管理平台》