超全面数仓建设规范指南（干货建议收藏）

点击上方 "云祁的数据江湖"关注, 星标一起成长

大家好，我是云祁！某大厂资深数据老兵。

一个企业的数据仓库或者数据中台建设，往往都需要经历前期混沌摸索的阶段，踩过无数的坑之后，才会逐渐建设完善，形成适合自己的一套数仓体系和建设规范。

本文将结合我在头部数科公司与阿里淘系多年数仓建设经验，全面讲解数仓建设规范，从数据模型规范，到数仓公共规范，数仓各层规范，到最后事实表与维度表设计原则等！

1.1 目的与范围

模型是对现实事物的反映和抽象，能帮助我们更好地了解客观世界。

数据模型定义了数据之间关系和结构，使得我们可以有规律地获取想要的数据。并用于有效组织企业的数据资产，其设计工作应当在一定的规范约束下进行。

这是建设高质量数据模型的前提条件！

1.2 术语介绍

OneData：包括一整套数据规范定义标准、数据模型架构设计最佳实践和产品工具体系来保障数据资产标准化、规范化建设。

旨在面向各行各业大数据建设、管理及应用诉求，通过输出实战沉淀的大数据建设体系 OneModel、OneID、OneServic（产品、技术、方法论），一站式提供集数据引入、规范定义、数据建模、数据研发、数据萃取、数据资产管理和数据服务的全链路智能数据构建及管理服务，助力企业打造属于自己的标准统一、资产化、服务化和闭环自优化的智能数据体系。

二、公共规范

2.1 设计理念

企业数据的管理和组织，技术上需要满足业务对数据访问、计算、存储、质量上的技术要求，在业务上需要满足企业便捷使用数据的诉求。针对这样的诉求，业界沉淀了 OneData 体系。

数据中台数据模型设计方法是 OneData 体系的核心组成部分。它在维度建模思想基础上，针对大数据存储计算平台的特点，充分考虑新时代大数据应用特点，以数据中台体系建设的实践经验为依托，建立一套模型设计规范与准则。

在维度建模理论基础下，如何建设标准统一、质量可靠、性能优异、成本可控的数据体系是 OneData 体系追求的目标。

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

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

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

2.2 基本原则

高内聚和低耦合

一个逻辑和物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚和低耦合原则。

主要从数据业务特性、访问特性、计算特性等方面来考虑：将业务相近或者相关的数据、粒度相同数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储，针对计算依赖的数据产出时间是否相近，计算是否能同时产出等原则确定组合在一起还是拆分。

核心模型与扩展模型分离

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

公共处理逻辑下沉及单一

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

成本与性能平衡

适当的数据冗余换取查询和刷新性能，但是不宜过度冗余与数据复制。

数据可回滚

数据计算处理逻辑不变，在不同时间多次运行数据结果确定不变。

一致性

相同的字段在不同表字段命名和定义相同。

命名清晰可理解

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

2.3 分层架构

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

ODS（Operational Data Store）操作数据层

它相当于数据中台通用数据模型层的一个数据准备区，同时又承担着基础数据的记录以及历史变化，主要完成业务系统、日志等结构化和半结构化数据引入到数据中台。

保留业务系统原始数据，包括增量明细和全量明细。在结构上其与源系统的增量或者全量数据基本保持一致。

CDM（Common Data Model）通用数据模型

主要完成公共数据加工与整合，基于维度建模理念思想，建立一致性的维度，构建可复用面向分析和统计的明细事实表以及汇总公共粒度的指标。

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

DIM（Dimension）公共维度层

基于维度建模理念思想，建立企业的一致性维度。

DWD（Data Warehouse Detail）明细粒度事实层

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

DWS（Data Warehouse Summary）汇总粒度事实层

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

ADS（Application Data Service）应用层数据

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

2.4 层次调用

应用层优先调用公共层数据，已经存在中间层数据，不允许应用层跨过中间层从 ODS 层重复加工数据。

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

ODS 层数据不能被应用层任务引用，中间层不能有沉淀的 ODS 层数据，必须通过 CDM 层的视图访问。CDM 层视图必须使用调度程序进行封装，保持视图的可维护性与可管理性。

CDM 层任务的深度不宜过大（建议不超过10层）。

原则上一个计算刷新任务只允许一个输出表。

如果多个任务刷新输出一个表（不同任务插入不同的分区），需要建立一个虚拟任务，依赖多个刷新任务，通常情况下游应该依赖此虚拟任务。

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

CDM明细层累计快照事实表优先调用 CDM 事务型事实表，保持数据一致性产出。

避免应用层过度引用和依赖 CDM 层明细数据，有针对性建设好 CDM 公共汇总层。

2.5 数据类型

为保证 ODS 层数据和源业务系统的兼容性，数据类型基于源系统数据类型转换，转换规则如下：

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

• 金额类及其它小数点数据：decimal
• 字符类数据：varchar 或 string
• ID类和整型数值：bigint
• 时间类型数据：Datetime 或 Timestamp (如果有特殊的要求，可以使用 String)
• 状态：string

2.6 分区字段

数据统计日期分区字段：

• 按天分区：ds(YYYYMMDD)
• 按小时分区：hh(00-23)
• 按分钟：mi (00-59)

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

2.7 数据冗余

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

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

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

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

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

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

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

2.8 数据拆分

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

l在物理上划分核心模型和扩展模型，将其字段进行垂直划分；比如会员表，建议拆分为核心表和扩展表。核心表相对字段较少，刷新产出时间较早，优先使用。扩展表字段较多，且可以冗余核心表部分字段，刷新产出时间较晚，适合数据分析人员使用。

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

数据记录数较大的维度表，可以适当冗余一些子集合。将经常用到的 where 条件按记录行进行水平切分或者冗余；水平切分可以考虑二级分区手段，以减少下游扫描数据量，避免多余的数据复制与冗余。

比如商品表，可以根据当天是否有行为，产出一个有活跃行为的相关维表，以减少应用的数据扫描量。或可根据所属业务扫描数据范围大小的不同，进行适当子集合冗余。

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

2.9 空值处理

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

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

三、规范定义

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

规范定义如下：

3.1 名词术语

3.2 指标体系

基本原则

组成体系之间的关系

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

• 原子指标、业务限定，直接归属在业务过程下。
• 派生指标唯一归属一个原子指标，继承原子指标的数据域。
• 原子指标有确定的英文字段名、数据类型和算法说明；派生指标要继承原子指标的英文名、数据类型和算法要求。

命名约定

• 命名所用术语

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

• 业务过程

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

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

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

• 原子指标

英文名：动作+度量

中文名：动作+度量

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

• 时间周期

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

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

• 业务限定

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

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

• 派生指标

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

中文名：统计粒度+时间周期+业务限定+原子指标。为控制派生指标英文名称过长，因此在定义业务限定英文名时，尽量精简明了。

操作细则

派生指标的种类

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

• 事务型指标

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

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

• 存量型指标

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

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

• 比较衍生型指标

是在事务性指标和存量型指标基础上进一步衍生而成的。例如，店铺最近1天无线端支付金额按行业降序排名、本月成交额与去年同期同比变化率等。

比较衍生型指标的规则

• 排名型

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

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

• 排名对象集合型

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

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

• 变化量型

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

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

• 变化率型

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

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

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

• 比例型

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

四、ODS 模型设计规范

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

• ODS（Operational Data Store）：操作数据层。它相当于数据中台通用数据模型层的一个数据准备区，同时又承担着基础数据的记录以及历史变化，主要完成业务系统、日志等结构化和半结构化数据引入到数据中台。保留业务系统原始数据，包括增量明细和全量明细。在结构上其与源系统的增量或者全量数据基本保持一致。

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

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

其中 CDM 层又分为 DWD 明细层、DWS 轻度汇总层和 DIM 维度层。本文从设计思路、主要作用、面临挑战等方面对数仓 ODS 层进行了介绍和说明。

4.1 设计思路

数仓 ODS 层将业务数据几乎无处理地同步备份到数仓里，后续所有的数据计算都不会影响原来的业务系统。设计思路包括以下几个方面：

1. 实现数据的抽取和加载，确保数据的及时性和准确性。

2. 对数据进行初步的清洗和加工，例如去重、格式化、转换等，使其符合企业的业务需求和规范。

3. 将数据按照相关业务进行分类和组织，方便后续的数据整合和分析。

4. 根据业务需求和数据特点，设计合理的数据结构，包括表结构、索引、分区等，以满足数据查询和检索的高效性和灵活性。

5. 确保 ODS 层与其他层级之间的数据交互和数据转换的正确性和稳定性。

4.2 同步策略

4.3 小数据量表

• 抽取处理策略

数据库直连方式全量抽取。

• 存储策略

全量表：按天全量存储，生命周期一般设置为 367 天，如有特殊业务需要可调整生命周期。

4.4 大数据量表

维表

• 抽取处理策略

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

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

具体使用的方式可用主键去重（row_number）+ 数据全量覆盖重新加载（insert overwrite）的方式，即如日调度，则将当天增量数据和前一天全量数据合并后根据主键去重，重新加载为最新的全量数据。

• 存储策略

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

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

日志型事务表

• 抽取处理策略

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

• 存储策略

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

非流水型事务表

• 抽取处理策略

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

具体使用的方式可用全外连接（full outer join） + 数据全量覆盖重新加载（insert overwrite）的方式，即如日调度，则将当天增量数据和前一天全量数据做全外连接，重新加载为最新的全量数据。 需要注意选择当天增量数据和前一天全量数据都需要限制最近N天创建的限制条件。

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

• 存储策略

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

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

• 历史数据处理

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

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

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

五、维度表

维度是维度建模的基础和灵魂。

在维度建模中，将度量称为“事实”，将环境描述为“维度”，维度是用于分析事实所需要的多样环境。例如，在分析交易过程时，可以通过买家、卖家、商品和时间等维度描述交易发生的环境。

维度所包含的表示维度的列，称为维度属性。

维度属性是查询约束条件、分组和报表、标签生成的基本来源，是数据易用性的关键。

例如，在查询请求中，获取某类目的商品、正常状态的商品等，是通过约束商品类目属性和商品状态属性来实现的；统计淘宝不同商品类目的每日成交金额，是通过商品维度的类目属性进行分组的；我们在报表中看到的类目、 BC 类型（ 指天猫， 指集市）等，都是维度属性。所以维度的作用一般是查询约束、分类汇总以及排序等。

如何获取维度或维度属性？

如上面所提到的，一方面，可以在报表中获取；另一方面，可以在和业务人员的交谈中发现维度或维度属性。因为它们经常出现在查询或报表请求中的“按照”（ by ）语句内。例如，用户要“按照”月份和产品来查看销售情况，那么用来描述其业务的自然方法应该作为维度或维度属性包括在维度模型中。

维度使用主键标识其唯一性，主键也是确保与之相连的任何事实表之间存在引用完整性的基础。主键有两种：代理键 和 自然键，它们都是用于标识某维度的具体值。

但代理键是不具有业务含义的键， 一般用于处理缓慢变化维；自然键是具有业务含义的键。 比如商品，在 ETL 过程中，对于商品维表的每一行，可以生成一个唯一的代理键与之对应；商品本身的自然键可能是商品 ID 等。其实对于前台应用系统来说，商品ID 是代理键；而对于数据仓库系统来说，商品 ID 则属于自然键。

5.1 设计方法

维度的设计过程就是确定维度属性的过程，如何生成维度属性，以及所生成的维度属性的优劣，决定了维度使用的方便性，成为数据仓库易用性的关键。正如 Kimball 所说的，数据仓库的能力直接与维度属性的质量和深度成正比。

5.2 设计步骤

第一步：选择维度或者新建维度。 作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以商品维度为例，有且只允许有一个维度定义。

第二步：确定主维表。 主维度表一般是 ods 层表，直接与业务系统同步。以商品维度为例：s_auction_aunctions 是与前台商品中心系统同步的商品表，此表即为主维度表。

第三步：确定相关维度表。 数据仓库是业务源系统的数据整合，不同业务系统或者同一业务系统的表之间存在关联性。根据业务的梳理，确定哪些表和主维度表存在关联关系。并选择其中的某些表用于生产维度属性。以商品维度为例，根据对业务逻辑的梳理，可以得到商品与类目、SPU、买家、店铺等维度存在的关联关系。

第四步：确定维度属性。 主要包括两个阶段：第一个阶段是从主维度表中选择维度属性或者生成新的维度属性；第二阶段是从相关维度表中选择维度属性和生成新的维度属性。以商品维度为例，从主维度表和类目、SPU、卖家、店铺等相关维表中选择维度属性或生成新的维度属性。

确定维度属性的注意点：

1、尽可能生成丰富的维度属性

比如商品维度有近百个维度属性，为下游数据统计、分析、探查提供了良好的基础。

2、尽可能多地给出包括一些富有意义的文字性描述

属性不应该是编码，而应该是真正的文字。在维度建模中，一般是编码和文字同市存在，比如商品维度中的商品 ID 和商品标题、类目 ID 和类目名称等。ID 一般用于不同表之间的关联，而名称一般用于报表标签。

3、区分数值型属性和事实

数值型字段作为事实还是维度属性，可以参考字段的一般用途。如果通常用于查询约束条件或者分组统计，则是作为维度属性；如果通常参与度量的计算，则是作为事实。

比如商品价格，可以用于查询约束条件或者统计价格区间的商品数量，此时是作为维度属性使用的。也可以用于统计某类目下商品的平均价格，此时是作为事实使用的。

另外，如果数值型字段是离散值，则作为维度属性存在的可能性较大。如果数值型字段是连续值，则作为度量存在的可能性较大，但并不绝对，需要同时参考字段的具体用途。

4、尽量沉淀出通用的维度属性

有些维度属性获取需要进行比较复杂的逻辑处理，有些需要通过多表关联得到，或者通过单表的不同字段混合处理得到，或者通过对单表的某个字段进行解析得到。

此时，需要将尽可能多的通用的维度属性进行沉淀。一方面，可以提高下游使用的方便性，减少复杂度；另一方面，可以避免下游使用解析时由于各自逻辑不同而导致口径不一致。

例如，淘宝商品的 property 字段，使用 key:value 方式存储多个商品属性。商品品牌就存储在此字段中，而商品品牌是重要的分组统计和查询约束的条件，所以需要将品牌解析出来，作为品牌属性存在。

例如，商品是否在线，即在淘宝网站是否可以查看到此商品，是重要的查询约束的条件，但是无法直接获取，需要进行加工，加工逻辑是：商品状态为0和1且商品上架时间小于或等于当前时间，则是在线商品；否则是非在线商品。所以需要封装商品是否在线的逻辑作为一个单独的属性字段。

5.3 维度的层次结构

维度中的一些描述属性以层次方式或一对多的方式相互关联，可以被理解为包含连续主从关系的属性层次。

层次的最底层代表维度中描述最低级别的详细信息，最高层代表最高级别的概要信息。维度常常有很多个这样的嵌入式层次结构。比如淘宝商品维度，有卖家、类目、品牌等。商品属于类目，类目属于行业，其中类目的最低级别是叶子类目，叶子类目属于耳机类目，二级类目属于一级类目。

在属性的层次结构中进行钻取是数据钻取的方法之一。

上钻：从当前数据往上回归到上一层数据。例如：（某数据的分类下面分为品名）从品名列表收拢到分类列表。

下钻：从当前数据往下展开下一层数据。 例如：（某数据的分类下面分为品名）从分类列表展开到品名列表。

上钻、下钻统称钻取。

切片：展现同一层面的数据。如上述的产品。

转轴：这些属于查询、展现范畴。

案例：假如有一个交易订单，创建事实表。

现在统计2019年 “双11” 的下单 GMV，得到一行记录；沿着层次向下钻取，继续沿着层次向下钻取，添加行业，得到行业实例个数的记录数；继续沿着层次向下钻取，添加一级类目，得到一级类目实例个数的记录数。可以看到，通过向报表中添加连续的维度细节级别。实现在层次结构中进行钻取。

5.4 规范化和反规范化

当属性层次被实例化为一系列维度，而不是单一的维度时，被称为雪花模式。大多数联机事务处理系统（OLTP）的底层数据结构在设计时采用此种规范化技术，通过规范化处理将重复属性转至其自身所属的表中，删除冗余数据。

这种方法用在 OLTP 系统中可以有效避免数据冗余导致的不一致性。比如在 OLTP 系统中，存在商品表和类目表，且商品表中有冗余的类目表的属性字段，假设对其类目进行更新，则必须更新商品表和类目表，且由于商品和类目是一对多的关系，商品表可能每次需要更新几十万甚至上百万条记录，这是不合理的。

而对于联机分析处理系统（OLAP）来说，数据是稳定的，不存在 OLTP 系统中所存在的问题。

对于商品维度，如果采用雪花模型进行规范化处理，将表现为如下图所示形式：

将维度的属性层次合并到单个维度中的操作成为反规范化。分析系统的主要目的是用于数据分析和统计，如何更方便用户进行统计分析决定了分析系统的优劣。

采用雪花模式，用户统计分析的过程中需要大量关联操作，使用复杂度高，同时查询性能很差；而采用反规范化处理，则方便、易用且性能好。

对于商品维度，如果采用范规范化处理，将表现为如下图所示

如上所述，从用户角度上来看简化了模型，并且使用数据查询优化器的连接路径比完全规范化的模型简化许多。反规范化的维度仍包含与规范化模型同样的信息和关系，从分析角度来看，没有丢失任何信息，但复杂性降低了。

采用雪花模式，除了可以节约一部分存储外，对于OLAP系统来说没有其他效用。而现阶段存储的成本是非常低。出于易用性和性能的考虑，维表一般是很不规范化的。在实际应用中，几乎总是使用维表的空间来换取简明性和查询性能。

5.5 一致性维度和交叉探查

构建企业级数据仓库不可能一蹴而就，一般采用迭代式的构建过程。而单独构建存在的问题是形式独立型数据集市，导致严重的不一致性。Kimball 的数据仓库总线架构提供了一种分解企业级数据仓库规划任务的合理方法，通过 企业范围内一致性维度 和 事实 来构建总线架构。

数据仓库总线架构的重要基石之一就是一致性维度。

在针对不同数据域进行迭代构建或并行构建时，存在很多需求是对于不同数据域的业务过程或者同一数据域的不同业务过程合并在一起观察。

比如对于日志数据域，统计了商品维度的最近一天的 PV 和 UV；对于交易数据域，统计了商品维度的最近一天的下单 GMV。现在将不同数据域的商品的事实合并在一起进行数据探查，如计算转化率。成为 交叉探查。

如果不同数据域的计算过程使用的维度不一致，就会导致交叉探查存在问题。

当存在重复的维度，但维度属性或者维度属性的值不一致时，会导致交叉探查无法进行或交叉探查结果错误。接上个例子，假设对于日志数据域，统计使用的商品维度1；对于交易数据域，统计使用的商品维度2。

商品维度1包含维度属性BC类型，而商品维度2无此属性，则无法在BC类型上进行交叉探查；商品维度1的商品上架时间这一维度属性时间格式是 yyyy-MM-dd HH:mm:ss ，商品维度2的商品上架时间这一维度属性时间格式是UNIX timestamp，进行交叉探查时如果需要根据商品上架时间做限制，则复杂性较高；商品维度1不包含阿里旅行的商品，商品维度2包含全部淘系商品，交叉探查也无法进行。还有很多形式的不一致，在这里不再一一列举，基本上可以划分为维度格式和内容不一致两种类型。

上面对维度不一致性进行详细分析，下面总结维度一致性的几种表现形式：

1、共享维度表。比如在阿里巴巴的数据仓库中，商品、卖家、买家、类目等维度有且只有一个。所以基于这些公共维度进行的交叉探查不会存在任何问题。

2、一致性上卷，其中一个维度的维度属性是另一个维度的维度属性的子集，而两个维度的公共维度属性结构和内容相同。

比如在阿里的商品体系中，有商品维度和类目维度，其中类目维度的维度属性是商品维度的维度属性的子集，且有相同的维度属性和维度属性值。这样基于类目维度进行不同业务过程的交叉探查也不会存在任何问题。

3、交叉属性。两个维度具有部分相同的维度属性。比如在商品维度中具有类目属性，在卖家维度中具有主营类目属性，这两个维度具有相同的类目属性，则可以在相同类目属性是哪个进行不同业务过程交叉探查。

六、事实表

事实表 作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含了引用的维度和与业务过程有关的度量。

事实表中一条记录所表达的业务细节程度被称为粒度。

通常粒度可以通过两种方式来表述：一种是维度属性组合所表示的细节程度；一种是所表示的具体业务含义。

基于某个业务过程，需要创建事务事实表，需要填写的信息遵循如下规范建议：

1. 英文名：我们预设定了业务过程名作为命名的一部分，因此候选部分用户以下划线连接的英文缩写进一步表达逻辑模型的业务含义。
2. 名称：建议以相对完整的中文短语描述名称，主要包括业务主体、业务过程，比如淘宝交易下单业务事实表。

描述：详细描述数据范围，以及表达的业务含义，一条记录代表的数据业务描述。

6.1 设计方法

6.2 设计原则

事务事实表

事务事实表记录的事务层面的事实，保存的是最原子的数据，也称“原子事实表”。事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

事务事实表的日期维度记录的是事务发生的日期，它记录的事实是事务活动的内容。 用户可以通过事务事实表对事务行为进行特别详细的分析。

通过事务事实表，还可以建立聚集事实表，为用户提供高性能的分析。

● 设计案例

● 单事务&多事务表区别

周期快照事实表

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，时间间隔如每天、每月、每年等等。典型的例子如：销售日快照表、库存日快照表等。

周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实表之上建立的聚集表。 周期快照事实表的维度个数比事务事实表要少，但是记录的事实要比事务事实表多。

周期快照事实表的日期维度通常是记录时间段的终止日，记录的事实是这个时间段内一些聚集事实值。事实表的数据一旦插入即不能更改，其更新方式为增量更新。

累积快照事实表

累积快照事实表和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。但是它们之间也有着很大的不同，周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。

累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日期字段，用来记录整个生命周期中的关键时间点。

另外，它还会有一个用于指示最后更新日期的附加日期字段。由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。

6.3 各种事实表区别

6.4 聚集事实表

聚集事实表是有派生指标按统计粒度组织的一系列模型，相同粒度的派生指标组织在一个聚集事实表里，基于此逻辑表，用户可以访问所需要的指标。

设计过程

设计原则

设计案例