OneData

1.什么是 onedata

面对爆炸式增长的数据，如何建设高效的数据模型和体系，对这些数据进行有序和有结构地分类组织和存储，避免重复建设和数据不一致性，保证数据的规范性，一直是大数据系统建设不断追求的方向。OneData 即是阿里巴巴内部进行数据整合及管理的方法体系和工具。阿里巴巴的大数据工程师在这一体系下，构建统一、规范、可共享的全域数据体系，避免数据的冗余和重复建设，规避数据烟囱和不一致性，充分发挥阿里巴巴在大数据海量、多样性方面的独特优势。借助这一统一化数据整合及管理的方法体系，我们构建了阿里巴巴的数据公共层，并可以帮助相似的大数据项目快速落地实现。

2.指导思想

阿里巴巴集团数据公共层设计理念遵循维度建模思想，可参考 StarSchema-The Complete Reference 和 The Data Warehouse Toolkit-The Definitive Guide to Dimensional Modeling。数据模型的维度设计主要以维度建模理论为基础，基于维度数据模型总线架构，构建一致性的维度和事实。其核心的实施指导方针如下：

⚫ 首先，要进行充分的业务调研和需求分析。

⚫ 其次，进行数据总体架构设计，主要是根据数据域对数据进行划分；按照维度建模理论，构建总线矩阵，抽象出业务过程和维度。

⚫ 再次，对报表需求进行抽象整理出相关指标体系，使用 One Data 工具完成指标规范定义和模型设计。

⚫ 最后，是代码研发和运维。其实施流程主要分为：数据调研、架构设计、规范定义和模型设计。

3.业务调研

业务调研：需要确认要规划进数仓的业务领域，以及各业务领域包含的功能模块，以阿里的业务为例，可规划如下矩阵

需求调研：了解需求方关系哪些指标？需要哪些维度、度量？数据是否沉淀到汇总层等。

可以想象一下，在没有考虑分析师、业务运营人员的数据需求的情况下，根据业务调研建设的数据仓库无疑等于闭门造车。了解了业务系统的业务后并不代表就可以进行实施了，此刻要做的就是收集数据使用者的需求，可以去找分析师、业务运营人员了解他们有什么数据诉求，此时更多的就是报表需求。

需求调研的途径有两种:一是根据与分析师、业务运营人员的沟通(邮件、IM)获知需求；二是对报表系统中现有的报表进行研究分析。通过需求调研分析后，就清楚数据要做成什么样的。很多时候，都是由具体的数据需求驱动数据仓库团队去了解业务系统的业务数据，这两者并没有严格的先后顺序。

举例：分析师需要了解大淘宝(淘宝、天猫、天猫国际)一级类目的成交金额。当获知这个需求后，我们要分析根据什么(维度)汇总，以及汇总什么(度量)，这里类目是维度，金额是度量；明细数据和汇总数据应该怎样设计?这是一个公用的报表吗?是需要沉淀到汇总表里面，还是在报表工具中进行汇总?

4.架构设计

4.1 数据域的划分

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合，一般数据域和应用系统(功能模块)有联系，可以考虑将同一个功能模块系统的业务过程划分到一个数据域。业务过程可以概括为一个个不可拆分的行为事件，如下单、支付、退款。为保障整个体系的生命力，数据域需要抽象提炼，并且长期维护和更新，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或者扩展新的数据域。如表所示是功能模块/业务线的业务动作(部分示例)：

根据业务过程进行归纳，可以抽象出如下数据域：

4.2 构建总线矩阵

在进行充分的业务调研和需求调研后，就要构建总线矩阵了，需要做两件事情：

1.明确每个数据域下有哪些业务过程。

2.业务过程与哪些维度相关，并通过总线矩阵定义每个数据域下的业务过程和维度。

如下表是供应链管理业务过程示例：

4.3 规范定义

规范定义主要定义指标体系，包括原子指标、修饰词、时间周期和派生指标。

4.4 模型设计

模型设计主要包括维度及属性的规范定义，维表、明细事实表和汇总事实表的模型设计。

4.5 架构总结

One Data 的实施过程是一个高度迭代和动态的过程，一般采用螺旋式实施方法。在总体架构设计完成之后，开始根据数据域进行迭代式模型设计和评审。在架构设计、规范定义和模型设计等模型实施过程中，都会引入评审机制，以确保模型实施过程的正确性。

5.指标体系搭建

5.1 指标体系核心结构

具体模块说明：

1.数据域：是指一个或多个业务过程或者维度的集合。

2.原子指标：基于某一业务过程下的度量。例如：搜索+次数=访问次数 PV

3.派生指标=时间修饰+其他修饰词+原子指标；属性是用来刻画某个实体对象维度的数据形态；事实叫做度量，如访问次数。

4.修饰：指针对原子指标的业务场景限定抽象。例如：最近 N 天。

5.2 指标体系中的数据规范

5.3 指标体系的基本原则

5.3.1 组成体系之间的关系

1.原子指标、修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域。

2.派生指标由原子指标、时间周期修饰词、若干其他修饰词组合得到。派生指标可以选择多个修饰词，修饰词之间的关系为‘或’或者‘且’的关系，具体由具体的派生指标语义决定。

3.派生指标唯一归属一个原子指标，继承原子指标的数据域、与修饰词的数据域无关。一般而言：事务型指标和存量型指标只会唯一定位到一个业务过程，如果遇到同时有两个行为发生、需要多个修饰、生成一个派生指标的话，选择时间靠后的行为创建原子指标，另一个时间靠前的行为创建为修饰词。

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

5.3.2 命名约定

命名所用术语：尽量使用英文简写，其次是英文，当指标英文名太长时，可考虑用汉语拼音首字母命名。如中国质造，用 zgzc。在 OneData 工具中，维护了常用的名词术语，以用来进行命名。

(1)业务过程：英文名——用英文的缩写或者英文或者中文拼音简写；中文名——具体的业务过程中文即可。

(2)原子指标：英文名：动作+度量；中文名：动作+度量；原子指标必须挂靠在某个业务过程下。

(3)修饰词：只有时间周期才会有英文名，且长度为 2 位，加上“_”为三位，例如_1d。其他修饰词无英文名。阿里常用的时间周期修饰词列表如下:

(4)派生指标

英文名：原子指标英文名+时间周期修饰词（=3 位，例如，_1d）+序号（=4 位，例如，_001）。

中文名：时间周期修饰词+[其他修饰词]+原子指标。

在 One Data 工具中，英文名与中文名都会由 One Data 工具自动生成。

举例如下：

注意：派生指标为了控制英文名称过长，在英文名的理解和规范上做了取舍，所有修饰词的含义都纳入了序号中。序号是根据原子指标+派生指标自增的。

5.3.3 操作细则

派生指标的分类：

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

⚫ 事务型指标：是指对业务活动进行衡量的指标。例如，新发商品数，重发商品数，新增注册会员数，订单支付金额，这类指标 需维护原子指标及修饰词，在此基础上创建派生指标。

⚫ 存量型指标：是指对实体对象(如商品、会员)，某些状态的统计。例如，商品总数，注册会员总数，这类指标维护原子指标及修饰词，在此基础上创建派生指标，对应的时间周期一般为“历史截止到当前某个时间”。

⚫ 复合型指标：是在事务性指标和存量型指标基础上复合而成的，例如，浏览UV-下单买家数转化率，有些需要创建新原子指标，有些则可以在事务性或存量型原子指标基础上、增加修饰词得到派生指标。

举个例子

复合型指标的规则：

1.比率型：需创建原子指标。例如，CTR，浏览 UV-下单买家数转化率，满意率等。

举例：“最近 1 天店铺首页 CTR”，原子指标为“CTR”，时间周期为“最近 1天”，修饰类型为“页面类型”，修饰词为“店铺首页”。

2.比例型：创建原子指标。例如，百分比、占比。举例:“最近 1 天无线支付金额占比”，原子指标为“支付金额占比”，修饰类型为“终端类型”，修饰词为“无线。

3.变化量型：不创建原子指标，增加修饰词，在此基础上创建派生指标。举例：“最近 1 天订单支付金额上 1 天变化量”，原子指标为“订单支付金额”，时间周期为“最近 1 天”，修饰类型为“统计方法”，修饰词为“上 1 天变化量”。

变化率型：创建原子指标。举例:“最近 7 天海外买家支付金额上 7 天变化率”，原子指标为”支付金额变化率”，修饰类型为“买家地域”，修饰词为“海外买家”。

4.统计型（均值、分位数等）：不创建原子指标，增加修饰词，在此基础上创建派生指标；在修饰类型“统计方法”下增加修饰词：人均、日均、行业平均、商品平均、90 分位数、70 分位数等。举例：自然月日均 UV，原子指标为 UV，修饰词为“统计方法”，修饰词为“日均”。

5.排名型：i.创建原子指标，一般为 top_xxx_xxx，有时会同时选择 rank 和top_xxx_xxx 组合使用。ii.创建派生指标时选择对应的修饰如下：统计方法（例如：降序，升序）；排名名次（例如：TOP10）；排名范围（例如：行业、省份、一级来源等）；根据什么排序(例如:搜索次数，浏览 PV)。示例如下：

6.对象集合型：i. 创建原子指标，一般为 xxx 串； ii.创建派生指标时选择对应的修饰如下：统计方法（例如：降序，升序）；排名名次（例如：TOP10）；排名范围（例如：行业，区域)。示例如下：

7.上下层级派生指标同时存在时：如最近 1 天定位次数，最近 1 天 PC 端定位次数，建议使用前者，把 PC 端作为维度属性存放在物理表中体现。

8.父子关系原子指标存在时：当父子关系原子指标存在时，派生指标使用子原子指标创建派生指标。如 PV，IPV(商品详情页 PV)，当我们统计商品详情页 PV 时，优先选择子原子指标。

5.4 维度属性的基本规则

1.命名约定：维度和维度属性，尽量使用英文简写，其次是英文，当指标英文名太长时，可考虑用汉语拼音首字母命名。如中国质造，用 zgzc。在 OneData 工具中，维护了常用的名词术语，以用来进行命名。

2.维度的归属：维度必须归属于某个数据域。

3.在创建维度时，必须清楚维度的主键是什么：如会员维度的主键是会员 ID，商品维度的主键是商品 ID。从源系统引入的属性，如果没有重复，则尽量遵从源系统命名，如果有重复则与业务方沟通选择合理的命名以方便业务使用。

4.维度属性：在维度下创建维度属性分为两类，一是直接从源系统引入，二是在源系统基础上、根据应用需求的数据挖掘出的属性特征作为维度的属性。

5.关于行为维度和杂项维度：杂项维度一般指将事实表中的指示符、状态、分类、属性、标签等字段单独创建维表。比如交易订单、物流订单均可以称为杂项维度。行为维度是基于历史事实构建的维度，如会员最后一次登录时间，最后一次浏览的网页，这个可作为会员的维度属性，不建议单独创建维度。

6.维度的拆解

a. 如果维度不由事实决定两者的关系，如商品属于某个类目，建议通过父子关系拆解成两个维度。

b. 如果两个维度是由事实的发生才建立关系，则必须拆解成多个维度，如交易表中的商品和买家。

c. 杂项维度需新建一个维度，行为维度建议放在主体对象维度中。

d. 角色维度如会员在交易中即扮演买家的角色又扮演卖家的角色，这两种角色的会有较多不一样的维度属性，如果会员这个维度会在多个事实中存在买家和卖家的角色，则可创建买家和卖家维度，并作为会员维度的子维度。

7.维度属性的层级关系：商品归属于类目，所以商品的父维度是类目，类目的子维度是商品。OneData 不支持商品维度中添加类目的 ID，但可通过 OneData 工具中父子层级关系的管理来解决。

8.OneData 中为了操作的便利性，没有把维度层级的父子关系、维度角色的父子关系以及核心和自定义的父子关系进行区分,两者均可通过 OneData 的维度关系管理建立维度的父子关系。

a.维度层级关系:商品归属于类目，所以商品的父维度是类目，类目的子维度是商品。

b.角色关系:如会员可作为卖家、也可作为买家，这两种角色就会有其自己相关的维度属性，我们建议创建买家和卖家维度并作为子维度挂在会员维度下核心和自定义。

9.多值维度：如果是行为累计的串类维度，如车辆运行轨迹中的 GPS 点列表，需要对轨迹做详细分析时建议在用户到达杂项维度创建 GPS 轨迹列表维度属性。如果是由于维度在事实中扮演的多个角色造成的多值维度建议按照第三点中的角色维度处理。

6.模型设计

6.1 数据分层

1.数仓为什么要分层？

(1)用空间换时间，通过大量的预处理来提升应用系统的用户体验（效率），因此数据仓库会存在大量冗余的数据；不分层的话，如果源业务系统的业务规则发生变化将会影响整个数据清洗过程，工作量巨大。

(2)通过数据分层管理可以简化数据清洗的过程，因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成了一个白盒，每一层的处理逻辑都相对简单和容易理解，这样我们比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个步骤即可。

一个好的分层架构，有以下好处：

(1)清晰数据结构：每一个数据分层都有对应的作用域，在使用数据的时候能更方便的定位和理解。

(2)数据血缘追踪：提供给业务人员或下游系统的数据服务时都是目标数据，目标数据的数据来源一般都来自于多张表数据。若出现目标数据异常时，清晰的血缘关系可以快速定位问题所在。而且，血缘管理也是元数据管理重要的一部分。

(3)减少重复开发：数据的逐层加工原则，下层包含了上层数据加工所需要的全量数据，这样的加工方式避免了每个数据开发人员都重新从源系统抽取数据进行加工。

(4)数据关系条理化：源系统间存在复杂的数据关系，比如客户信息同时存在于核心系统、信贷系统、理财系统、资金系统，取数时该如何决策呢？数据仓库会对相同主题的数据进行统一建模，把复杂的数据关系梳理成条理清晰的数据模型，使用时就可避免上述问题了。

(5)屏蔽原始数据的影响：数据的逐层加工原则，上层的数据都由下一层的数据加工获取，不允许跳级取数。而原始数据位于数仓的最底层，离应用层数据还有多层的数据加工，所以加工应用层数据的过程中就会把原始数据的变更消除掉，保持应用层的稳定性。

业界对数仓分层的看法大同小异，大体上认为分为接入层、中间层和应用层三层，不过对中间层的理解有些差异。

阿里巴巴的数据团队对模型层次做如下划分：

特别说明：数据公共层（CDM，Common Dimenions Model）：存放明细事实数据、维表数据及公共指标汇总数据。其中，明细事实数据、维表数据一般根据ODS 层数据加工生成。公共指标汇总数据一般根据维表数据和明细事实数据加工生成。

CDM 层又细分为维度层（DIM）、明细数据层（DWD）和汇总数据层（DWS），采用维度模型方法作为理论基础，可以定义维度模型主键与事实模型中外键关系，减少数据冗余，也提高明细数据表的易用性。在汇总数据层同样可以关联复用统计粒度中的维度，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。

6.1.1 接入层(ods)

数据引入层（ODS，Operational Data Store，又称数据基础层）：将原始数据几乎无处理地存放在数据仓库系统中，结构上与源系统基本保持一致，是数据仓库的数据准备区。

业务数据一般是采用 dataX 或者 sqoop 等以固定频率同步到数仓中构建 ODS层；如果是日志数据则通过 flume 或者 Kafka 等同步到数仓中。接入层一般不会对源数据做任何处理、清洗，便于之后回溯。

6.1.2 通用维度层(dim)

维度层（DIM，Dimension）：以维度作为建模驱动，基于每个维度的业务含义，通过添加维度属性、关联维度等定义计算逻辑，完成属性定义的过程并建立一致的数据分析维表。为了避免在维度模型中冗余关联维度的属性，基于雪花模型构建维度表。

6.1.3 明细层(dwd)

明细数据层（DWD，Data Warehouse Detail）：以业务过程作为建模驱动，基于每个具体的业务过程特点，构建最细粒度的明细事实表。可以结合企业的数据使用特点，将明细事实表的某些重要属性字段做适当冗余，也即宽表化处理。理论上明细层数据是对 ods 层数据进行清洗加工，提高 ods 层数据的可用性，对于 dwd 层数据是否同层引用的观点需要权衡：

一般情况下 dwd 层不建议同层引用，这样做可以减少明细层任务之间的依赖，减少节点深度。但是在某些场景下，ods 层到 dwd 层数据加工逻辑复杂，计算开销大，这时可以权衡考虑适当复用 dwd 表来构建新的 dwd 表。

6.1.4 汇总层(dws)

汇总数据层（DWS，Data Warehouse Summary）：以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求，构建公共粒度的汇总指标表。以宽表化手段物理化模型，构建命名规范、口径一致的统计指标，为上层提供公共指标，建立汇总宽表、明细事实表。

这一层依赖我们的指标体系，将 dwd 层的数据按照各个维度进行聚合计算。

当我们有一些跨业务域的聚合统计需求时，放到这一层。

6.1.5 应用层(app)

数据应用层（ADS，Application Data Store）：存放数据产品个性化的统计指标数据，根据 CDM 层与 ODS 层加工生成。

这一层主要针对汇总层，进行相关指标的组合，生成报表。在这里，主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis 等系统中供线上系统使用，也可能会存在 Hive 或者 Druid、Doris 中供数据分析和数据挖掘使用。比如我们经常说的报表数据，一般就放在这里。

6.2 维度设计

维度建模中，将度量称为事实，维度用于分析事实所需要的多样环境。维度的作用一般是查询、分类汇总以及排序。

通过报表的约束条件，以及之前数据调研和业务方的沟通，我们可以获得维度。维度通过主键与事实表进行关联，维度表的主键分为代理键和自然键两种；

代理键不具有业务含义，一般用于处理缓慢变化维度，自然键则具有业务含义。

6.2.1 维度设计基本方法

1.选择或者新建一个维度，通过之前总线矩阵的构建掌握了目前数仓架构中的维度。

2.确定主维表。此处主维表一般是 ODS 表，直接与业务系统同步。

3.确定相关维表。数仓是业务源系统的数据整合，不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理，我们可以确认哪些表和主维表存在关联关系，并选择其中的某些表用于生成维度属性。

4.确定维度属性。本步骤分为两阶段，第一阶段是从主维表中选择维度属性或生成新的维度属性；第二阶段是从相关维表中选择维度属性或生成新的维度属性。

6.2.2 规范化和反规范化

当具有多层次的维度属性，按照第三范式进行规范化后形成一系列维度表，而非单一维度表，这种建模称为雪花模式。

将维度的属性层次合并到单个维度中的操作称为反规范化。

6.2.3 一致性维度和交叉探查

我们存在很多需求是对于不同数据域的业务过程或同一数据域的不同业务过程合并在一起观察。例如：对于日志数据域统计商品维度的近一天 PV 和 UV；

对于交易数据域统计商品维度近一天的 GMV。

这种将不同数据域的商品事实合并在一起进行数据探查，称为交叉探查。

数仓能进行交叉探查的前提是，不同数据域要具有一致性维度。

6.2.4 维度整合

由于数仓的数据源来源于不同的应用系统，应用系统之间相互独立，因此对同一信息的描述、存储都可能具有差异。而这些具有差异的数据进入数仓后需要整合在一起：

⚫ 命名规范的统一。表名、字段名等统一。

⚫ 字段类型的统一。相同和相似字段的字段类型统一。

⚫ 公共代码以及代码值的统一。

⚫ 业务含义相同的表的统一。主要依据高内聚、低耦合的理念，将业务关系大，源系统影响差异小的表进行整合。表级别的整合主要有两种形式：

⚫ 垂直整合，即不同来源表包含相同的数据集，只是存储的信息不同，可以整合到同一个维度模型中。

⚫ 水平整合，即不同来源表包含不同的数据集，这些子集之间无交叉或存在部分交叉，如果有交叉则去重；如果无交叉，考虑不同子集的自然键是否冲突，不冲突则可以将各子集自然键作为整合后的自然键，或者将各自然键加工成一个超自然键

6.3 事实表设计

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

6.3.1 事实类型

作为度量业务过程的事实，有可加性、半可加性和不可加性三种类型：

⚫ 可加性事实指可以按照与事实表关联的任意维度进行汇总。

⚫ 半可加事实只能按照特定维度汇总，不能对所有维度汇总。

⚫ 不可加性事实完全不具备可加性，比如比例事实。对于不可加性事实可考虑分解为可加的组件来实现聚合。

6.3.2 事实表类型

最常见的事实表有三种类型：事务事实表、周期快照事实表和累积快照事实表。

事务事实表用来描述业务过程，表示对应时空上某点的度量事件，保存的是最原子的数据，也称为原子事实表。在实际使用中，一般作为明细层使用，例如下单明细、支付明细等。

周期快照事实表的一行，以具有规律性的时间间隔记录事实。如每日库存快照表、每日用户余额快照表。

累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点，当过程随着生命周期不断变化时，记录也会随着过程的变化而被修改。以事务事实表中提到的订单例子为例，可以做一个和订单相关的，涉及订单下单、推单、抢单、支付等各个环节的一张订单全生命周期快照表。

此外，还有一种无事实的事实表，单纯只记录某一动作发生，其事件的量化是非数字的，比较典型的例子是访问点击日志。

6.3.3 事实表设计原则

⚫ 尽可能包含所有与业务过程相关的事实。

⚫ 只选择与业务过程相关的事实。

⚫ 分解不可加性事实为可加的组件。

⚫ 在选择维度和事实之前必须先声明粒度。

⚫ 在同一个事实表中不能有多种不同粒度的事实。

⚫ 事实的单位要保持一致。

⚫ 对事实的 null 值要处理，建议用 0 填充。

⚫ 使用退化维度提高事实表的易用性。

6.3.4 事实表设计方法

主要步骤包括：选择业务过程及确认事实表类型；声明粒度；确定维度；确定事实；冗余维度。

第一步:选择业务过程及确定事实表类型。

在明确了业务需求以后，接下来需要进行详细的需求分析，对业务的整个生命周期进行分析，明确关键的业务步骤，从而选择与需求有关的业务过程。

以淘宝的正向订单流转为例，如图所示。

业务过程通常使用行为动词表示业务执行的活动。比如图中的淘宝订单流转的业务过程有四个:创建订单、买家付款、卖家发货、买家确认收货。在明确了流程所包含的业务过程后，需要根据具体的业务需求来选择与维度建模有关的业务过程。比如是选择买家付款这个业务过程，还是选择创建订单和买家付款这两个业务过程，具体根据业务情况来确定。

在选择了业务过程以后，相应的事实表类型也随之确定了。比如选择买家付款这个业务过程，那么事实表应为只包含买家付款这一个业务过程的单事务事实表;如果选择的是所有四个业务过程，并且需要分析各个业务过程之间的时间间隔，那么所建立的事实表应为包含了所有四个业务过程的累积快照事实表。

第二步:声明粒度。

粒度的声明是事实表建模非常重要的一步,意味着精确定义事实表的每一行所表示的业务含义,粒度传递的是与事实表度量有关的细节层次。明确的粒度能确保对事实表中行的意思的理解不会产生混淆，保证所有的事实按照同样的细节层次记录。

应该尽量选择最细级别的原子粒度，以确保事实表的应用具有最大的灵活性。同时对于订单过程而言粒度可以被定义为最细的订单级别。比如在淘宝订单中有父子订单的概念，即一个子订单对应一种商品，如果拍下了多种商品，则每种商品对应一个子订单;这些子订单一同结算的话，则会生成一个父订单。那么在这个例子中，事实表的粒度应该选择为子订单级别。

第三步:确定维度。

完成粒度声明以后，也就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了，应该选择能够描述清楚业务过程所处的环境的维度信息。比如在淘宝订单付款事务事实表中，粒度为子订单，相关的维度有买家、卖家、商品、收货人信息、业务类型、订单时间等维度。

第四步:确定事实。

事实可以通过回答“过程的度量是什么”来确定。应该选择与业务过程有关的所有事实，且事实的粒度要与所声明的事实表的粒度一致。事实有可加性、半可加性、非可加性三种类型，需要将不可加性事实分解为可加的组件。

比如在淘宝订单付款事务事实表中,同粒度的事实有子订单分摊的支付金额、邮费、优惠金额等。

第五步:冗余维度。

在传统的维度建模的星形模型中,对维度的处理是需要单独存放在专门的维表中的，通过事实表的外键获取维度。这样做的目的是为了减少事实表的维度冗余，从而减少存储消耗。而在大数据的事实表模型设计中,考虑更多的是提高下游用户的使用效率降低数据获取的复杂性减少关联的表数量。所以通常事实表中会冗

余方便下游用户使用的常用维度，以实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等操作。

比如在淘宝订单付款事务事实表中,通常会冗余大量的常用维度字段，以及商品类目、卖家店铺等维度信息。