跳至主要內容

【万字长文】数仓构建理论

PowerData大约 38 分钟数据中台

本文由 PowerData 满一贡献
姓名：苏奕嘉
花名：满一
微信：fl_manyi
年龄：95 后
工作经验：3-5 年
工作内容：架构, 数开, 后端, 方案
自我介绍：ApacheDoris Contributor & SelectDB 生态研发工程师，使用 Doris 请 Call 我~

对本文感兴趣或有任何疑问，可直接添加作者微信交流。

一、概述

1.1 目的与范围

数据模型用于有效组织企业的数据资产，其设计工作应当在一定的规范约束下进行，这是建设高质量数据模型的前提条件。因此本文档用于定义 PowerData 数据中台数据模型设计实施的规范要求。

1.2 使用对象

l 数据架构师

l 数据开发者

l 数据应用人员

l 企业数据管理者

1.3 术语介绍

1、数据仓库：数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策 (Decision Making Support)。

2、数据模型：以数学的方式对现实事物的一种抽象表达，数据（Data）是描述事物的符号记录，模型（Model）是现实世界的抽象。数据模型按不同的应用层次分成三种类型，分别是概念数据模型、逻辑数据模型、物理数据模型。

二、公共规范

2.1 设计理念

企业数据的管理和组织，技术上需要满足业务对数据访问、计算、存储、质量上的技术要求，在业务上需要满足企业便捷使用数据的诉求。数据中台数据模型设计方法是阿里 OneData 体系的核心组成部分。它在维度建模思想基础上，针对大数据存储计算平台的特点，充分考虑新时代大数据应用特点，以阿里巴巴数据中台体系建设的实践经验为依托，建立一套模型设计规范与准则。在维度建模理论基础下，如何建设标准统一、质量可靠、性能优异、成本可控的数据体系是 OneData 体系追求的目标。

数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。

数据模型的事实表设计在维度模型事实表的基础上，结合数据使用场景的具体实践，进行一定扩展，采用宽表设计方法。所谓宽表：为了提升访问便利性和访问性能，在维度模型的事实表基础上，将部分常用维度退化（冗余）到事实表，或者将一些可枚举型的维度和度量，采用多指标、多字段方式实现在事实表中。

在指标定义中，采取组件化的形式，进行指标标准化定义，先规范定义，后生产，全生命周期控制，保障数据口径统一，减少重复建设，强调数据复用和共享。

2.2 基本原则

1、高内聚和低耦合：一个逻辑和物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚和低耦合原则。主要从数据业务特性、访问特性、计算特性等方面来考虑：将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储，针对计算依赖的数据产出时间是否相近，计算是否能同时产出等原则确定组合在一起还是拆分。

2、核心模型与扩展模型分离：建立核心模型与扩展模型体系，核心模型包括的字段支持常用核心的业务，扩展模型包括的字段支持个性化或是少量应用的需要，必要时让核心模型与扩展模型做关联，不能让扩展字段过度侵入核心模型，破坏了核心模型的架构简洁性与可维护性。

3、公共处理逻辑下沉及单一：越是底层公用的处理逻辑更应该在数据调度依赖的底层进行封装与实现，不要让公共的处理逻辑暴露给应用层实现，不要让公共逻辑在多处同时存在。公共处理逻辑下沉及单一，既有利于数据复用，也有利于变更修改。

**4、成本与性能平衡：**适当的数据冗余换取查询和刷新性能，但是不宜过度冗余与数据复制。

**5、数据可回滚：**数据计算处理逻辑不变，在不同时间多次运行数据结果确定不变。

**6、数据一致性：**相同的字段在不同表字段命名和定义相同。

7、命名清晰可理解：表命名规范需清晰、一致，易于下游理解和使用。

2.3 分层架构

OneData 体系中，数据划分为三层：

  • ODS（Operational Data Store）：原始操作层，主要完成业务系统、日志等结构化和半结构化数据引入到数据中台，保留业务系统原始数据，包括增量明细和全量明细。

  • CDM（Common Data Model）：通用数据模型，主要完成公共数据加工与整合，建立一致性的维度，构建可复用面向分析和统计的明细事实表以及汇总公共粒度的指标。

  • ADS（Application Data Service）：应用层数据，提供直接面向业务应用的数据。为方便实现数据应用、数据消费的诉求，进行数据形式的组装，进行面向应用逻辑的数据加工处理。

其中在 CDM 层，由以下几部分组成：

  • DIM（Dimension），公共维度层，基于维度建模理念思想，建立企业的一致性维度。

  • DWD（Data Warehouse Detail），明细粒度事实层，以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细层事实表，结合企业的数据使用特点，将明细事实表的某些重要维度属性字段做适当冗余，也就是宽表化处理。

  • DWS（Data Warehouse Summary），公共汇总粒度事实层：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标事实表，以宽表化手段物理化模型。

2.4 层次调用

应用层优先调用公共层数据，已经存在中间层数据，不允许应用层从 ODS 层重复加工数据。一方面，CDM 研发人员应该积极了解应用层数据的建设需求，将公用的数据沉淀到公共层，为其他团队提供数据服务；另一方面，应用层团队也需积极配合 CDM 层团队进行持续的数据公共建设的改造和迁移。必须避免出现过度的 ODS 层引用和不合理的数据复制和子集合冗余。

CDM 层任务的深度不宜过大（建议不超过 10 层）。原则上一个计算刷新任务只允许一个输出表。如果多个任务刷新输出一个表（不同任务插入不同的分区），需要建立一个虚拟任务，依赖多个刷新任务，通常情况下游应该依赖此虚拟任务。

CDM 汇总层优先调用 CDM 明细层。可累加类指标计算，CDM 汇总层尽量优先调用已经产出的粗粒度汇总层，避免大量汇总都直接从海量的明细数据层计算。

CDM 明细层累计快照事实表优先调用 CDM 事务型事实表，保持数据一致性产出。避免应用层过度引用和依赖 CDM 层明细数据，有针对性建设好 CDM 公共汇总

2.5 数据类型

为保证 ODS 层数据和源业务系统的兼容性，ODS 层统一采用 String 类型，ODS 层之上的 CDM 和 ADS 数据类型基于系统的数据类型转换，转换规则如下：

l MySQL 的转换规则如下：

MySQL 数据类型中台数据类型
TINYINT/SMALLINT/ MEDIUMINT/ INTEGER / BIGINTBigint
FLOAT / DOUBLE / DECIMALDouble
LONGTEXT /TEXT/VARCHAR/ CHARString
DATE/ DATETIMEString(YYYY-MM-DD HI24:MM:SS)

l Oracle 的转换规则如下：

Oracle 数据类型DataQ 数据类型
NumberID 转换为 bigint，根据实际数据，如果是浮点数则使用 double，默认使用 bigint。
VARCHAR2/VARCHARString
DATEString
CLOBString

CDM 数据公共层如果是引用 ODS 层数据，默认使用 ODS 层字段数据类型，衍生加工数据字段按以下标准执行：

  • 金额类及其它小数点数据：double

  • 字符类数据：string 或 string

  • ID 类和整形数值：bigint

  • 时间类型数据：string(如果有特殊的格式强制要求，可以选择性使用 datetime)

  • 状态：string

2.6 公共字段

数据统计日期分区字段

  • 按天分区：ds(YYYYMMDD)

  • 按小时分区：hh(00-23)

  • 按分钟：mi (00-59)

is_{业务}：表示布尔型数据字段。“Y”,“N” 表示，不允许出现空值域。

原则上不需要冗余分区字段

2.7 数据冗余

一个表做宽表冗余维度属性时，应该遵循以下几个建议准则：

  • 冗余字段与表中其它字段高频率同时访问。

  • 冗余字段的引入不应造成其本身的刷新完成时间过多后延。

  • 公共层的数据不允许字段重复率大于 60% 的相同粒度数据表冗余，可以选择原表基础上拓宽或者下游应用通过 JOIN 方式实现。

从一个集合中冗余一部分记录作为另外一张表存在时，可以优先考虑子分区方式，但是多级子分区不超过 5 级，只有以下情况才考虑冗余：

  • 子类型表有较多（大于 10 个）字段父类型表并不存在。

  • 子集合的过滤条件被多次（大于 5 次）应用。

2.8 数据拆分

数据水平和垂直拆分基本上按访问热度分布和数据表的 “非空或者 0 值” 数据值在行列二维空间上分布情况进行划分。

  • 在物理上划分核心模型和扩展模型，将其字段进行垂直划分。

  • 将访问相关度较高的列放在一个表存储，将访问相关度较低的字段分开存储。

  • 将经常用到的 WHERE 条件按记录行进行水平切分或者冗余，水平切分可以考虑二级分区方法，避免多作的数据复制与冗余。

  • 将表中出现大量空值和零值的统计汇总表，依据其空值和零值分布状况可做适当的水平和垂直切分，可以有效的减少存储和减少下游的扫描数据量。

2.9 空值处理原则

  • 汇总类指标的空值：空值处理，填充为零，当前数据中台基于列存储的压缩技术不会由于填充大量空值导致存储成本上升。

  • 维度属性值为空：在汇总到对应维度上时，参照不上的统计事实记录行，填充 - 911（未知），在对应维表有一条 - 911（未知）的记录。

三、规范定义

指以维度建模作为理论基础，构建总线矩阵，划分和定义数据域、业务过程、维度、度量／原子指标、业务限定、时间周期、统计粒度、派生指标。

规范定义实例如下：

3.1 名词术语

名词解释
数据域面向业务分析，将业务过程或者维度进行抽象的集合。其中，业务过程可以概括为一个个不可拆分的行为事件，在业务过程之下，可以定义指标；维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼、并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响的被包含进已有的数据域和扩展新的数据域。
业务过程业务过程是指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意业务过程是一个不可拆分的行为事件，通俗讲业务过程就是企业活动中的事件。
时间周期用来明确数据统计的时间范围或者时间点，如最近 30 天、自然周、截至当日等。
度量／原子指标原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。
业务限定指除了统计维度以外指标的业务场景限定抽象，是对业务中圈选的统计范围的定义。如日志域的访问终端类型为无线端等。
维度维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度（其中包括国家、地区、省以及城市等级别的内容）、时间维度（其中包括年、季、月、周、日等级别的内容）。
维度属性维度属性隶属于一个维度，如地理维度里面的国家名称、国家 ID、省份名称等都属于维度属性。
派生指标派生指标 = 原子指标 + 业务限定 + 时间周期 + 统计粒度。可以理解为对原子指标业务统计范围的圈定，并选定某些维度或维度组合作为统计粒度。如原子指标: 支付金额，最近 1 天海外买家支付金额则为派生指标 (最近 1 天为时间周期，海外为业务限定，买家作为统计粒度)。

3.2 指标体系

3.2.1 基本原则

1、组成体系之间的关系

  • 派生指标由原子指标、业务限定、时间周期、统计粒度组合得到。

  • 原子指标、业务限定，直接归属在业务过程下。

  • 派生指标唯一归属一个原子指标，继承原子指标的数据域。

  • 原子指标有确定的英文字段名、数据类型和算法说明。派生指标要继承原子指标的英文名、数据类型和算法要求。

2、命名约定

Ø 命名所用术语

指标命名：使用英文简写，其次是英文，当指标英文名太长时，考虑用汉语拼音首字母命名，如中国质造，用 zgzz。

Ø 业务过程

英文名：用英文的缩写或者英文、中文拼音简写

中文名：具体的业务过程中文描述即可

关于存量指标（见下文定义）对应的业务过程约定：实体对象英文名 +‘_stock’。如在线会员数，一星会员数等，其对应的业务过程为 mbr_stock。在线商品数，其对应的业务过程为 item_stock。

Ø 原子指标

英文名：业务动作 + 度量

中文名：业务动作 + 度量

原子指标必须挂靠在某个业务过程下。

Ø 时间周期

时间周期英文名长度为 2 位，加上 “_” 共三位，如_1d。

常用的时间周期修饰词如下：

中文名英文名中文名英文名
最近 1 天1d自然月cm
最近 3 天3d自然季度cq
最近 7 天1w截至当日td
最近 14 天2w年初截至当日sd
最近 30 天1m0 点截至当前tt
最近 60 天2m财年fy
最近 90 天3m最近 1 小时1h
最近 180 天6m准实时f1w
180 天以前bh未来 7 天f4w
自然周cw未来 4 周f42

Ø 业务限定

英文名：尽量使用英文缩写，尽量是没有下划线的字母组合，最多有一个下划线，长度尽量控制在 5 个字符以内。

中文名：可以描述较为完整业务的中文名称。

Ø 派生指标

英文名：原子指标英文名 + 时间周期（=3 位，例如，_1d）+ 业务限定英文名（以_开头带上业务限定英文名，例如，_pcvst）。

中文名：统计粒度 + 时间周期 + 业务限定 + 原子指标。

为控制派生指标英文名称过长，因此在定义业务限定英文名时，尽量精简明了。

3.2.2 操作细则

一、派生指标的种类

派生指标可以分为三类：事务型指标、存量型指标和复合型指标。按照其特性不同，有些必须新建原子指标，有些可以在其他类型原子指标基础上增加业务限定形成派生指标。

Ø 事务型指标

是指对业务活动进行衡量的指标。

例如，新发商品数，重发商品数，新增注册会员数，订单支付金额，这类指标需维护原子指标及业务限定，在此基础上根据指定的统计粒度创建派生指标。

Ø 存量型指标

是指对实体对象 (如商品、会员) 某些状态的统计，它最典型的特点是它的总量不是一个统计时间范围内的增量，而是历史累计到统计时间点的全量。

例如，当前商品总数，当前会员总数，这类指标维护原子指标及修饰词，在此基础上创建派生指标，对应的时间周期为 “历史截止到当前”。

Ø 比较衍生型指标

是在事务性指标和存量型指标基础上进一步衍生而成的，例如，店铺最近 1

天无线端支付金额按行业降序排名、本月成交额与去年同期同比变化率等。

l 比较衍生型指标的规则

Ø 排名型

在已有的派生指标上衍生创建。

其定义方式为：派生指标 + 排名范围（例如：行业、省份、一级类目等）+ 排名方式（例如：升序排名 ark，降序排名 drk）。举例：“店铺最近 1 天无线端支付金额按行业降序排名”，派生指标为店铺最近 1 天无线端支付金额，排名范围为行业，排名方式为降序排名。

Ø 排名对象集合型

对象集合型主要是数据产品和应用需要展现数据时，将一些对象以 KV 对的方式存储在一个字段中，方便前端展现。

其定义方式为：派生指标 + 排名范围（例如：行业、省份、一级类目等）+ 排名方式（例如：升序排名 ark，降序排名 drk）+topN + 对象名 + s（s 代表指标为字符串）。

Ø 变化量型

变化量型指标分为同比变化量、环比变化量和滑动窗口变化量三种类型。

指标定义方式为：派生指标 + 变化量类型（=3 位，第 1 位为比较周期窗口 {y 年 / m 月 / d 日}，滑动窗口比没有这部分；第 2 位为比较方法 {s 同比 / r 环比 / w 滑

动窗口比}；第 3 位 “a” 表示比较内容为变化量）

常用的变化量类型列表如下：

中文名英文名指标案例
年同比变化量ysa本月成交额与去年同期同比变化量（pay_amt_1m_ysa）
月同比变化量msa当天成交额与上月同期同比变化量（pay_amt_1d_msa）
年环比变化量yra本财年成交额与上财年成交额环比变化量（pay_amt_fy_yra）
季环比变化量qra本季度成交额与上季度成交额环比变化量（pay_amt_cq_qra）
月环比变化量mra本月成交额与上月成交额环比变化量（pay_amt_1m_mra）
日环比变化量dra今日成交额与昨日成交额环比变化量（pay_amt_1d_mra）
滑动窗口比变化量wa最近 7 天成交额与昨日统计的最近 7 天成交额变化量 （pay_amt_1w_wa） 最近 30 天成交额与昨日统计的最近 30 天成交额变化量（pay_amt_1m_wa）

Ø 变化率型

变化率型指标分为同比变化率、环比变化率和滑动窗口变化率三种类型。

指标定义方式为：派生指标 + 变化率类型（=3 位，第 1 位为比较周期窗口 {y 年 / m 月 / d 日}，滑动窗口比没有这部分；第 2 位为比较方法{s 同比 / r 环比 / w 滑动窗口比}；第 3 位“r” 表示比较内容为变化率）

常用的变化率类型列表如下：

中文名英文名指标案例
年同比变化率ysr本月成交额与去年同期同比变化率（pay_amt_1m_ysr）
月同比变化率msr当天成交额与上月同期同比变化率（pay_amt_1d_msr）
年环比变化率yrr本财年成交额与上财年成交额环比变化率（pay_amt_fy_yrr）
季环比变化率qrr本季度成交额与上季度成交额环比变化率（pay_amt_cq_qrr）
月环比变化率mrr本月成交额与上月成交额环比变化率（pay_amt_1m_mrr）
日环比变化率drr今日成交额与昨日成交额环比变化率（pay_amt_1d_mrr）
滑动窗口比变化率wr最近 7 天成交额与昨日统计的最近 7 天成交额变化率 （pay_amt_1w_wr） 最近 30 天成交额与昨日统计的最近 30 天成交额变化率 （pay_amt_1m_wr）

Ø 比例型

比例型指标定义方式为：派生指标 + rb（rationby）+ 占比组，用于例如：“卖家最近 1 天销售金额行业占比”，派生指标为卖家最近 1 天销售金额，占比组为行业，可定义为 pay_amt_1d_rb_industry。

后续可以做一个指标管理系统，用来管理业务指标和数据指标的关联关系。

具体每个指标的明细查询：

四、ODS 层设计规范

4.1 同步策略

4.1.1 小数据量表

1、抽取处理策略

数据库直连方式全量抽取，每日全量一个分区。数据量大时可以做增量合并的方式进行抽取。

2、存储策略

全量表：按天全量存储，生命周期根据业务需要可设置长周期（如 366 天或永久保存）。

4.1.2 大数据量表

4.1.2.1 维表

1、抽取处理策略

数据库直连方式通过业务时间戳抽取增量数据到增量表，再从增量表 merge 入全量表。

有些表的数据量随业务的发展越来越大，如果按周期全量同步的方式会影响处理效率。在这种情况下，选择改为每次只同步新变更的增量数据，然后与上一同步周期获得的全量数据进行合并，从而获得最新版本的全量数据。

具体使用的方式可用全外连接（full outer join）+ 数据全量覆盖重新加载（insert overwrite）的方式，即如日调度，则将当天增量数据和前一天全量数据做全外连接，重新加载为最新的全量数据。

2、存储策略

增量表：可设置长周期（如 366 天或永久保存）；

全量表：根据业务需求及存储资源考虑设置较长周期（如 183 天或 366 天或 732 天，若需要永久保存则要使用历史拉链处理）。

4.1.2.2 日志型事务表

1、抽取处理策略

原始日志增量抽取到增量表。按天增量存储。因为日志数据表现为只会有新增不会有修改的情况，因此不需要保存全量表。

2、存储策略

增量表：可设置长周期（如建议永久保存）；

4.1.2.3 非流水型事务表

1、抽取处理策略

从源数据库通过时间戳抽取增量数据到增量表，再从增量表 merge 入最近 N 天（例如最近 200 天）全量表。

具体使用的方式可用全外连接（full outer join）+ 数据全量覆盖重新加载（insert overwrite）的方式，即如日调度，则将当天增量数据和前一天全量数据做全外连接，重新加载为最新的全量数据。

需要注意选择当天增量数据和前一天全量数据都需要限制最近 N 天创建的限制条件。

以下以淘宝订单为例，描述抽取与处理策略：

2、存储策略

增量表：可设置长周期（如永久保存）。

最近 N 天全量表：根据业务需求及存储资源保留合适周期（如生命周期设置为 7 天或 33 天，若要对全量表快照保留长周期并做极限存储需要仔细评估计算与存储代价）。

3、历史数据处理

若需要进一步对所有的历史数据做存储，而不仅仅是最 N 天的全量。可在上述方案基础上，平衡历史可回滚、存储数据量、更新性能等方面，参考下面这样一套三级存储 / 更新方案：

其中：OLD 表存储最近 N 天之前的数据，这部分数据不再使用 delta 增量数据更新。使用创建日期作为分区，生命周期保存永久。

OLD_UPDATE 表用于更新 N 天之前的记录 merge 至该表。表使用最新分区，只需保存一个很短的生命周期（例如 3 天）。

4.2 命名规范

4.2.1 表命名规范

l 日增量数据：{project_name}.s_{instance 缩写}_ {schema 缩写}_{源系统表名}_delta

例：dp_ods. s_ebsdb_ont_oe_order_lines_all_delta

l 日全量数据：{project_name}.s_{instance 缩写}_ {schema 缩写}_

例：dp_ods. s_ebsdb_ont_oe_order_lines_all

l 按分钟 / 小时的增量表：{project_name}.s_{instance 缩写}_ {schema 缩写}{源系统表名}_

例：dp_ods. s_ebsdb_ont_oe_order_lines_all_delta_hh

l 按分钟 / 小时的全量表：{project_name}.s_{instance 缩写}_ {schema 缩写}{源系统表名}

例：dp_ods. s_ebsdb_ont_oe_order_lines_all_hh

4.2.2 字段命名规范

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

l 字段名与平台关键字冲突时处理规则：加一个 “_col” 后缀，即：源字段名_col

4.2.3 同步任务命名规范

l 任务名跟表命名保持一致

4.3 数据存储及生命周期管理规范

数据表类型存储方式最长存储保留策略
ODS 流水型全量表按日分区n 不可再生情况下永久保存
ODS 镜像型全量表按日分区n 不可再生情况下永久保存
ODS 增量表按日分区n 有对应的全量表最多保留最近 14 天分区数据。n 无全量表的增量数据永久保留
ODS ETL 过程临时表按日分区n 最多保留最近 7 天分区
DBSync 非去重数据按日分区n 由应用通过中间层作保留历史处理，默认 ODS 层不保留历史。（待定）

4.4 数据质量规范

数据质量规则：

  • 每个 ODS 全量表必须配置唯一性字段标识

  • 每个 ODS 全量表必须做分区空数据监控

  • 建议对重要表的重要枚举类型字段做枚举值变化、及枚举值分布监控

  • 建议对 ODS 表设置数据量及数据记录数做上周同比无变化监控，用于监控源系统下线或者已迁移

  • 只对有监控要求的表才创建数据质量管控层

  • 每个 ODS 层全表都必须要有注释，由数据质量团队推动前台业务系统执行此规范

五、CDM 层设计规范

5.1 CDM 明细层事实表设计规范

5.1.1 公共准则

DWD 模型设计可以允许视图，但是该视图仅对其来源做简单的清洗和过滤，不做 JOIN 和 group by。

5.1.2 数据域和业务过程

英文名缩写数据域全称缩写业务过程举例
Operateopt运营salessales销售
Customercut客户handlehde客户办理
Human resourceshur人力usersusers人员资料

5.1.3 表命名规范

{project_name}.dwd_{数据板块缩写 / pub}{数据域缩写}[{自定义表命名标签缩写}]。

  • pub 表示数据包括多个板块的数据，

  • 刷新周期标识: d / 天，w / 周，m / 月，r / 实时（准实时），单分区增量全量标识（i 表示增量，f 表示全量）。

  • ODS 视图的和 ODS 的结构保持一致 ()，命名规范同 dwd 层规范，后缀带_v

例如：

  • tbcdm.dwd_tb_trd_ordcrt_trip_di（淘宝航旅机票订单下单事实表，日刷新增量）

  • tbcdm.dwd_tb_itm_item_df（淘宝商品快照事实表，日刷新全量）

  • tbcdm.dwd_tb_trd_ordcrt_ri(淘宝交易下单准实时表，实时新增量)

5.1.4 字段命名规范

字段命名原则上遵循词根法，相同的字段含义在不同表中字段命名必须相同。

5.1.5 数据存储及生命周期管理规范

数据表类型存储方式最长存储保留策略
明细层按日分区事务型事实表一般永久保留周期性快照事实表根据业务需求设置生命周期管理或者极限存储策略

5.2 CDM 汇总层事实表设计规范

5.2.1 命名规范

{project_name}.dws_{数据板块缩写 / pub}{数据域缩写}[{自定义表命名标签缩写}]。

统计实际周期范围缩写，缺省情况下，离线计算应该包括最近一天（_1d）, 最近 N 天（_nd）和历史截至当天 (_td) 三个表，如果出现_nd 的表字段过多，需要拆分之时，只允许以一个统计周期单元作为原子拆分，也就是说一个统计周期拆分一个表，比如最近 7 天 (_1w) 拆分一个表；不允许拆分出来的一个表存储多个统计周期的。

如果是多维分析，数据粒度缩写用 cube，在表的 comment 中描述哪几个维度。例如：

  • tbcdm.dws_tb_trd_byr_subpay_1d (淘宝买家粒度交易分阶段付款一日汇总事实表)

  • tbcdm.dws_tb_trd_byr_subpay_td（淘宝买家分阶段付款截至当日汇总表）

  • tbcdm.dws_tb_trd_byr_cod_nd (淘宝买家粒度货到付款交易汇总事实表)

  • tbcdm.dws_tb_itm_slr_td (淘宝卖家粒度商品截至当日存量汇总表)

5.2.2 数据存储及生命周期管理规范

数据表类型存储方式最长存储保留策略
汇总指标层按日分区存储默认保留 13 个月（暂定），可以选择保留月初数据，以及特定日期数据，需要更长保留周期，走申请通道。

5.3 DIM 维表设计规范

5.3.1 表命名规范

dim_{数据板块缩写 / pub}_{维度定义缩写}_EXT。

5.3.2 字段命名规范

字段命名遵循词根缩写。

5.3.3 维度种类划分

维度表达的是用于描述和分析业务过程的具体方面，企业的数据模型是由业务过程 + 维度组成，在上一章节定义了业务过程后，业务过程被一系列的维度描述，未来数据的指标将会被统计到各个维度，维度定义和管理的好坏，对后续数据质量、数据重复建设的管理至关重要。如图所示进行维度定义，关键信息填写建议：

  • 维度英文名：维度英文名直接使用维度的下划线 + 英文缩写组合。

  • 维度名称：使用维度的名称，切忌在后面添加 “表” 字，这是一个抽象的业务对象定义，不是表，比如商品、用户、类目。

同时我们提供了几种类型的维度定义：普通维度、普通维度（层级），枚举维度、虚拟维度。

5.3.3.1 普通维度

普通维度是我们常见的一般维度，需要填写主键及其它一下信息，填写规范建议：

  • 主键英文名：xx_id，xx 是维度的英文名称部分

  • 主键名称：xxID，xx 是维度的中文名称部分

  • 主键计算逻辑：尽可能的简化 SQL 表达主键，比较简单情况是来源于某张源表，复杂一些情况可能需要两个表 join，可能需要去重操作。特别注意如果是从遗留系统里面迁移过来，如果存在一些排序逻辑，是不需要表达，因为我们这里只是利用主键对维度的数据范围进行定义，多个表且可能有重复情况可以使用 UNION ALL+DISTINCT 方式表达。同时注意 SQL 表达主键的需要使用 SELECT xx as key 语法，k 表达的是 key（主键）

维度的主从关系表达，有些维度在设计时，需要将维度进行层级划分，而有些维度表在组织上又有父子关系。比如，在我们实际业务中，会员是一个最大的企业级维度，但是可能其它一些子业务或者 BU 他们也有会员，例如航旅会员，他们在会员集合范围是企业级会员维度的子集，同时他们又具有一些自有的维度信息，可以把航旅会员定义为会员的子维度。它的好处是，可以共享父维度的维度属性信息，节省开发资源和存储计算资源，同时可以让我们的维度信息定义标准化，消除一些重复定义，最后，还会让我们具有相似的维度信息是结构化组织，便于用户查找和使用。

5.3.3.2 普通维度（层级）

在一些父子结构的数据，如部门的组织关系、多级树形结构归类，在数据仓库中需要将其加工为扁平结构的维度模型，方便用户在数据计算和分析时进行任意层级的汇总和查询。

基于本身的父子结构关键信息建议维表后，会存在多级维度结构数据。之所以为生产出多个分级类目维度是因为后续的粒度必须是由维度属性组成，否则如果统计是按二级、三级类目统计，那么二级、三级类目必须独立定义为一个维度。

5.3.3.3 枚举维度

枚举维度主要是用于一些用户定义的归类数据进行定义，一方面它可以进行数据内容格式的标准化，一方面可以方便用户快速录入。

Code：部分建议使用英文的代码标识，最好使用能够让你能理解的有业务含义的代码，value 值表达的是实际的中文业务含义。

5.3.3.4 虚拟维度

虚拟维度是用于表达退化到事实表中的维度信息，如果此维度的值域范围是不可枚举，类如 cookieid，且需要作为统计指标的粒度，因此我们有必要对维度进行定义，但是实际底层物理实现并不会物理化一张维度表。如果在事实逻辑表中的维度值域范围是可枚举的，规范建议优先选择为枚举维度定义，这样更有利于建维度的值域范围标准化。

六、ADS 层设计规范

表命名规范：

ads_{数据板块缩写}_ [_业务应用缩写]{_数据粒度}[自定义标签缩写]。

刷新周期标识：

d / 天，w / 周，m / 月，r / 实时（准实时）

字段名规则：

  • 字段命名可以遵循 dwd\dws 层规则

  • 个性化指标及字段按照词根命名

七、模型建设规范

7.1 业务过程

业务过程是指企业发生的主要业务事件或者流程，比如会员注册、网站点击、下单、支付等等。业务过程的梳理主要是业务调研，特别是在业务流程梳理阶段可以发现企业重要业务过程，完成第一轮的业务过程初稿整理，同时在数据应用调研时再次对业务过程进行第二轮确认，将需要分析的业务过程重点分析，将当前不在需求范围内的业务过程暂缓进入详细设计。

业务过程按其业务类型可以划分为以下几种类型，业务类型定义时的规范体系可以遵循如下建议：

业务过程类型特点名称英文名
事务型在一个时间点内发生的业务动作，比如浏览、点击、下单建议贴近业务理解的动宾结构或者动词结构命名，比如浏览网页、浏览、创建订单以下划线分割的动宾结构英文缩写，如: exp_pg、exp、crt_ord
混合事务型基于数据应用的需要多个事务动作组合抽象为一个业务过程，比如互动行为包括点赞、评论、转发。建议贴近业务理解的动宾结构或者动词结构命名，但是注意命名建立事务动作型的区分度，比如互动以下划线分割的动宾结构英文缩写，如: iac
业务流程型基于数据应用的需要由多个事务组成的一个业务流程，其与混合事务型典型的区别是之间存在流程关系多个事务型业务过程建议贴近业务理解的流程名称，比如下单支付以下划线分割的流程名称缩写，比如：crt_pay
存量状况型基于数据应用描述当前业务发展的状况，当前已经到什么状态了，比如当前注册会员数，当前在线商品数；核心关键是某个时间对当前一个状态的描述建议以当前存量对象的名称快照命名，比如商品快照、会员快照存量对象的英文缩写_sp 方式命名，比如 itm_sp、mbr_sp

在定义过程中，需要注意以下原则：

  • 原子化：注意业务流程与业务过程的区别，通常一个业务流程有多个原子化的业务过程组成，业务过程尽量进行业务级别原子化抽象，比如一个交易是由下单、支付、退款、确认收货等多个组成，因此不建议将交易构建为一个业务过程。一个技巧，当我们抽象了一个业务过程后，我们需要 review 以下是否有更细一层的业务组成，如果有继续细化，同时判断细化的业务过程是否是业务分析需要的

  • 互斥性：不要让两个不同的业务过程描述同一个业务，能尽可能有效避免指标定义重复

  • 利用原子化组合能力：混合事务型和业务流程型应对引用原子化的事务型组合而成。这样推行后，内在的关系能让指标更结构化呈现，比如用户分析交易下单时，可以同步关联分析下单 - 支付指标

7.2 原子指标

原子指标是对有一个业务过程进行统计的度量，用户需要输入以下核心信息：

1、主要来源字段：对于计算逻辑没有影响，主要用来引导计算逻辑是什么字段衍生

2、英文名：建议：{业务过程英文名}{其它说明英文缩写} 方式进行命名，比如 crt_ord_qty，名称：建议：中文名称，{业务过程中文名称}

3、统计周期，主要是用于全量型事实表，在统计指标时进行时间周期范围的限定，比如我们要统计最近 7 天新发商品数，在没有构建新发商品的增量型事实逻辑表情况下，我们从商品维度逻辑表（全量）进行统计，因此我们指标的逻辑必须限定商品维度逻辑表的 “创建时间” 字段在最近 7 天内

4、计算逻辑是一个 SQL 表达式，可以引用逻辑表的字段

除了普通的简单统计类指标，还有一类较为复杂的，一个指标是由多个原子指标经过表达式计算产生，典型的比率型指标，是有两个指标进行运算获取，比如支付客单价，是支付金额除以支付客户数。

7.3 业务限定

业务限定是在构建派生指标具体化过程中对原子指标特定的说明修饰，这些限定通常是一个逻辑表达式去限定指标的统计数据范围。业务限定也需要进行一定的公用性抽象，让业务限定能尽可能的复用能极大的改善数据标准一致性问题，也能大大提升研发效率。

主要输入信息：

  • 英文名：尽量使用英文缩写，尽量是没有下划线的字母组合，最多有一个下划线。长度尽量控制在 5 个字符以内

  • 名称：可以较为完整的业务的中文名称

  • 描述: 对业务描述算法文字描述

  • 计算逻辑：类 SQL 的计算逻辑表达式

7.4 派生指标

派生指标是用户在业务需求中真正需要的指标，一个派生指标由：一个原子指标、一个时间周期、一个业务限定、一个粒度组合而成，在用户操作层面只要按产品界面提示构建即可。派生指标的配置相对比较简单，提供了批量化生产，切忌批量大量生成无业务需求的指标，每个指标都需要耗费资源。

写在最后

数据中台整体架构设计：（面向未来）

我们是由一群数据从业人员，因为热爱凝聚在一起，以开源精神为基础，组成的 PowerData 数据之力社区。

可关注下方公众号后点击 “加入我们”，与 PowerData 一起成长