数仓规范详解

一、设计规范

1.1 数据模型设计

横向分层

分层设计是数据架构设计的产出之一，在模型设计环节做为强制规范遵守。

分层规范

ODS：

• 贴源层，原始数据不做变化或者仅做最简单的补全后存入。
• 数据域划分，依据是数据源。

DWD：

• 对数据源做清洗、转换、补全、编码转换后加载到明细数据层。
• 数据域划分，依据参考下边的纵向分域。

DWS

• 汇总数据层+主题宽表

• 数据域划分，依据参考下边的纵向分域

ADS：

• 应用层，面向最终应用。

• 主题域划分，依据是最终应用。生命周期也与应用同步。

层次调用规范

• 禁止反向调用
• ODS 只能被 DWD 调用。
• DWD 可以被 DWS 和 ADS 调用。
• DWS 只能被 ADS 调用。
• 数据应用可以调用 DWD、DWS、ADS，但建议优先考虑使用汇总度高的数据。
• ODS->DWD->DWS>ADS
• ODS->DWD->ADS 纵向分域

纵向分域

主题域通常是联系较为紧密的数据主题的集合，方便寻找和使用数据。

基本原则

• 高内聚、低耦合。
• 数量不能太多。建议不超过十个。
• 必须保持稳定。既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或扩展新的数据域。
• 需要结合团队和业务的实际情况，比如业务是否稳定、团队成员建模水平等。
• 适度的抽象。太低不好适应变化，太高不易于理解使用。

分类

• 数据/业务主题域：依据业务流程划分，实现相对容易。

• 分析主题域：面向分析场景，实现较难，对业务理解、抽象能力等要求高。

划分依据

• 按照业务或业务过程划分：比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题。

• 根据需求方划分：比如需求方为财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题。

• 按照功能或应用划分：比如微信中的朋友圈数据域、群聊数据域等，而朋友圈数据域可能就会有用户动态信息主题、广告主题等。

• 按照部门划分：比如可能会有运营域、技术域等，运营域中可能会有工资支出分析、活动宣传效果分析等主题。

基本原则

• 高内聚和低耦合

• 核心模型与扩展模型分离

• 公共处理逻辑下沉及单一

• 成本与性能平衡

• 数据可回滚

• 一致性

• 命名清晰、可理解

附加字段

• 维表：创建时间、更新时间
• 事实表：ETL 日期、更新时间 其它要求

其他要求

• 表、字段的备注信息，必须言简意赅，在描述清楚的前提下尽量简洁。
• 字段类型的约束：比如字符串用 String，数值用 Int，年月日都用 String 比如 yyyyMMdd 等

1.2 ETL设计规范

抽取加载策略设计文档

• 节点名称，与目标表一致
• 负责人
• 源表、目标表
• 抽取方式、加载策略
• 增量新增数据的判断条件
• 是否支持重复执行

ETL 映射设计文档

• 节点名称，与目标表一致
• 所在层级、所属 Job
• Job 中的位置、上游节点名称
• 负责人
• 参数列表
• 源表、目标表
• 字段映射转换关系
• 是否支持重复执行

调度设计文档

• 顶层调度有几个？
• 顶层 Job 调度时机
• 顶层调度参数列表
• 每个 Job 内的任务调度顺序编排
• 调度是否支持重复执行
• 调度是否支持并行

1.3 命名规范

共有规范

• 采用蛇形命名法，即采用一个下划线分隔词根
• 优先使用词根中已有关键字（数仓标准配置中的词根管理），定期 Review 新增命名的不合理性
• 禁止采用非标准的缩写
• 命名一律采用小写，只能以字母开头
• 命名不宜过长

专有规范

• 表

  • 分层-分域-分词根-分时间周期
  • 正式表，所在层级名称+数据域+表描述+时间周期或加载策略，如增量、快照、拉链/小时、日、周、月、季、年
  • 中间表,对应正式表+mid+阿拉伯数字
  • 临时表，z+创建者姓名检查+表名

• 视图

  • 参照表命名规范+_v

• 字段

  • 优先从词根中取，多次出现的要增加到词根库

• 任务

  • 与目标表名相同

• 指标

  • 原子指标：业务修饰词 + 词根
  • 衍生指标：原子指标+时间周期（可选）
  • 派生指标：一个原子指标＋多个修饰词（可选）＋时间周期

1.4 指标体系建设

指标层级划分方式

按分析主题

• 一级分类
• 二级分类

按业务过程

• 一级分类
• 二级分类
• 三级分类

指标定义

内容

• 所属分类
• 指标类别
• 名称
• 描述
• 口径/算法
• 计量单位
• 适用维度
• ...

原则

• 唯一性
• 可扩展
• 易理解

类别

• 原子指标（某一业务事件行为下的度量，不可再拆分的指标）例如：订单金额
• 衍生指标（对原子指标进行四则运算）
• 派生指标（统计周期+统计粒度+业务限定+原子/衍生指标）例如：最近一天+新创建的+订单个数（阿里大数据之路对于派生指标的定义：派生指标=原子指标+时间周期修饰词+其它修饰词。唯一归属于某一个原子指标，继承该原子指标的数据域。）

说明

• 网上对于指标分类说法不统一，大家知道咋回事儿就行了。
• 搜了一下阿里的大数据之路，没有衍生指标的概念。
• 说法一：衍生指标=派生指标。那么用我上边派生指标的定义即可。
• 说法二：衍生指标是对原子指标进行四则运算得到的。
• 那么衍生指标就是原子指标增加减少几个修饰词或者时间周期扩大缩小后得到的。所以感觉衍生指标有点鸡肋搞不好就变成原子/派生指标了。

指标管理流程

• 指标新增申请
• 初审：明确指标口径，检查指标库是否包含
• 二审：审核指标定义需要的各项元素是否准确完备
• 入指标库

1.5 词根库

定义

把可能会多次用到的短语，集中命名，保证全局范围内的命名含义一致性。

内容

• 所属分类
• 名称
• 英文简称
• 数据类型
• 备注

分类

• 普通词根：描述事物的最小单元体，如：交易-trade。
• 专有词根：具备约定成俗或行业专属的描述体，如：美元-USD。

公共字段

• 公共字段=词根组合+其它关键词
• 公共字段放入词根库不太严谨，但字段命名时候可以直接取用，降低了命名不一致的风险，所以工具化不太完善的公司推荐这样使用。

二、流程规范

2.1 需求提交流程

提出需求

• 需求提出人：以文档的形式提出需求（写清楚需求内容、交付物、期望交付日期），发给数仓 Leader。

沟通需求

• 数仓 Leader 将需求分配给相关人承接，同时协商好实际交付日期。
• 如果需求提出人的交付日期与数仓 Leader 的交付日期不一致，双方需要进一步协商一致。

开发交付

• 需求承接人，需按照协商一致的交付日期，按期交付。

2.2 模型设计流程

数据调研、业务调研、需求调研

数据建模

• 总体思路
  • 根据已有的分层分域，分治、各个击破。
• 多种方式结合使用
  • 确定业务过程->声明粒度->确定维度->确定事实
  • 业务建模->逻辑建模->物理建模
  • 构建总线矩阵
  • 构建指标体系

评审

• 除了模型设计，还需要拉上必要的开发、业务、分析师、产品经理、数仓运维等。

上线、迭代、完善

2.3 ETL开发流程

需求理解

数据探查

程序开发

• 命名规范
  • Job 命名规范：J_层次名_内容描述。
  • 节点命名规范：跟目标表一致。
  • 参数命名规范：统一命名，禁止私自创造。
• 代码编写原则
  • 代码清晰、整齐，具有一定的可观赏性。
  • 代码编写要充分考虑执行速度最优原则。
  • 代码行整体层次分明、结构化强。
  • 代码中应有必要的注释以增强代码的可读性。
  • 规范要求非强制性地约束代码开发人员的代码编写行为。在实际应用中，只要不违反常规要求，允许存在可理解的偏差。
• 代码开发规范
  • 脚本是否有备注、复杂计算逻辑是否有注释。
  • 任务是否支持多次重跑而输出不变，不能有 insert into 语句。
  • 分区表是否使用分区键过滤并且有有效裁剪。
  • 外连接的过滤条件是否使用正确，例如在左连接的 where 语句存在右表的过滤条件。
  • 关联小表，是否使用/*+ map join * /。
  • 不允许引用别的计算任务临时表。
  • 原则上不允许存在一个任务更新多个目标表。
  • 是否存在笛卡尔积。
  • 禁止在代码里面使用 drop、create、rename 等 DDL 语句。
  • 使用动态分区时，有没有检查分区键值为 NULL 的情况。
  • 对于重要的任务 DQC 质量监控规则是否配置，严禁裸奔。
  • 代码中有没有进行适当的规避数据倾斜语句。
• 日志输出规范
  • 每个任务节点，都需要输出成功/失败标志，如果失败最好输出错误信息。
  • 每个 Job 也要输出成功/失败标志，如果失败必须输出失败任务节点名称。

流程依赖

配置调度

2.4 前端开发规范

• 接口规范
• 代码部署规范

2.5 上线流程

申请

• 上线时间

• 上线功能范围

• 对其它模块、上下游依赖的影响

• 上线支持团队清单

• 上线详细操作步骤

• 测试报告

• 回滚方案

评审

• 代码 Review

• 上下游影响分析

上线

• 上线支持团队就绪
• 严格按照上线操作步骤执行
• 失败回滚

三、质量管控规范

3.1 源端管控

• 源端变动，必须提前通知数仓侧。
• 有条件的话，使用工具监控源端重点内容的变动。

3.2 数仓管理

• 对已有规范没有贯彻的给予警告、处罚：建模规范、开发规范、上线规范
• 使用工具加强数据质量监控，发现问题及时通知、告警。
• 建立数据质量解决机制，责任到人。
• 定期复盘
  • 重要常见问题入告警规则
  • 源端数据质量问题，协调源端解决
  • 存储模型、ETL开发、上线流程等引起的问题，需要制定合适的解决方案

3.3 应用管控

• 统一指标定义
• 统一指标口径
• 统一外部数据输出归口

四、安全规范

4.1 网络安全

• 内外网隔离，外网环境访问内网需要登录 VPN
• 核心数据存储、功能模块，只开放给特定的少部分人。

4.2 账号安全

• 每个人分配独立的账号，赋予合理的权限，禁止相互借用。
• 数据库、大数据组件开通多个角色账号。比如只读、部分表读写、管理员等。当然还可以按实际需求细分。Hive、ODPS 的话也是可以实现单人单号的。
• 服务器登录。也是单人单号
• 公司内部应用账号。单人单号。

4.3 数据安全

• 至少做到表级别的权限控制，实在不行就分库。
• ODS 层不对外开放，只对 ODS-DWD 层相关部分开发人员可见。
• 特别敏感数据，如用户年龄、号码、身份证好、地址等，应该放到专门的数据库里，数仓主库只存放用户 ID 和其它必须字段。例如年龄应该脱敏成年龄区间或开发特定的 UDF 转化函数。