名词术语	解释
数据域	指面向业务分析，将业务过程或者维度进行抽象的集合。其中，业务过程可以概括为一个个不可拆分的行为事件，在业务过程之下，可以定义指标；维度是指度量的环境，如买家下单事件，买家是维度。为保障整个体系的生命力，数据域是需要抽象提炼，并且长期维护和更新的，但不轻易变动。在划分数据域时，既能涵盖当前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中和扩展新的数据域。
业务过程	指企业的业务活动事件，如下单、支付、退款都是业务过程。请注意，业务过程是一个不可拆分的行为事件，通俗地讲，业务过程就是企业活动中的事件。
时间周期	用来明确数据统计的时间范围或者时间节点，如最近30天、自然周、截至当日等。
修饰类型	是对修饰词的一种抽象划分。修饰类型从属于某个业务域，如日志域的访问终端类型涵盖无线端、PC端等修饰词。
修饰词	指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于一种修饰类型，如在日志域的访问终端类型下，有修饰词PC端、无线端等。
度量 / 原子指标	原子指标和度量含义相同，基于某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。
维度	维度是度量的环境，用来反映业务的一类属性，这类属性的集合构成一个维度，也可以称为实体对象。维度属于一个数据域，如地理维度(其中包括国家、地区、省以及城市等级别的内容)、时间维度(其中包括年、季、月、周、日等级别的内容)。
维度属性	维度属性隶属于一个维度，如地理维度里面的国家名称、国家 ID、省份名称等都属于维度属性。
派生指标	派生指标 = 一个原子指标 + 多个修饰词(可选) + 时间周期。可以理解为对原子指标业务统计范围的圈定。派生指标唯一归属一个原子指标，继承原子指标的数据域，与修饰词的数据域无关。如原子指标：支付金额，最近 1 天海外买家支付金额则为派生指标(最近 1 天为时间周期，海外为修饰词，买家作为维度，而不作为修饰词)。派生指标可以分为三类：事务型指标、存量型指标和复合型指标事务型指标：是指对业务活动进行衡量的指标。例如：订单支付金额、新发商品数等，这类指标需维护原子指标及修饰词，在此基础上创建派生指标。存量型指标：是指对实体对象(如商品、会员)某些状态的统计。例如商品总数、注册会员总数，这类指标需维护原子指标及修饰词，再次基础上创建派生指标，对应的时间周期一般为“历史截至当前某个时间”。复合型指标：是在事务型指标和存量型指标的基础上复合而成的。例如浏览UV - 下单买家数转化率，有些需要创建新原子指标，有些则可以在事务型或存量型原子指标的基础上增加修饰词得到派生指标。

模型设计基本原则

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

1、高内聚和低耦合

一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储。

2、核心模型与扩展模型分离

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

3、公共处理逻辑下沉及单一

越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。

4、成本与性能平衡

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

5、数据可回滚

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

6、一致性

具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。

数仓构建流程

需求分析

在需求分析阶段，您需要沉淀出业务分析或报表中的指标，以及指标的定义和粒度。粒度可以作为维度的输入。建议您思考下列问题，对后续的数据建模将有巨大的帮助：

业务数据是根据什么（维度、粒度）汇总的，衡量标准是什么？例如，成交量是维度，订单数是成交量的度量。
明细数据层和汇总数据层应该如何设计？公共维度层该如何设计？是否有公共的指标？
数据是否需要冗余或沉淀到汇总数据层中？

举例：数据分析师需要了解A公司电商业务中厨具类目的成交金额。当获知这个需求后，您需要分析：根据什么（维度）汇总、汇总什么（度量）以及汇总的范围多大（粒度）。例如，类目是维度，金额是度量，范围是全表。此外，还需要思考明细数据和汇总数据应该如何设计、是否是公共层的报表及数据是否需要沉淀到汇总表中等因素。

需求调研的分析产出通常是记录原子与派生指标的文档。

分析业务过程

业务过程可以概括为一个个不可拆分的行为事件。用户的业务系统中，通过埋点或日常积累，通常已经获取了充足的业务数据。

这是一个非常典型的电商交易业务流程图。在该业务流程图中，有创建订单、买家付款、卖家发货、确认收货四个核心业务步骤。由于确认收货代表交易成功，我们重点分析确认收货（交易成功）步骤即可。

划分数据域

数据域是联系较为紧密的数据主题的集合，是业务对象高度概括的概念，目的是便于管理和应用数据。

数据域是指面向业务分析，将业务过程或者维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新。在划分数据域时，既能涵盖当前所有的业务需求，又能让新业务在进入时可以被包含进已有的数据域或扩展新的数据域。数据域的划分工作可以在业务调研之后进行，需要分析各个业务模块中有哪些业务活动。

数据域可以按照用户企业的部门划分，也可以按照业务过程或者业务板块中的功能模块进行划分。例如A公司电商营销业务板块可以划分为如下数据域，数据域中每一部分都是实际业务过程经过归纳抽象之后得出的。

数据域	业务过程
会员店铺域	注册、登录、装修、开店、关店
商品域	发布、上架、下架、重发
日志域	曝光、浏览、单击
交易域	下单、支付、发货、确认收货
服务域	商品收藏、拜访、培训、优惠券领用
采购域	商品采购、供应链管理

定义维度与构建总线矩阵

定义维度

在划分数据域、构建总线矩阵时，需要结合对业务过程的分析定义维度。以本教程中A电商公司的营销业务板块为例，在交易数据域中，我们重点考察确认收货（交易成功）的业务过程。

在确认收货的业务过程中，主要有商品和收货地点（本教程中，假设收货和购买是同一个地点）两个维度所依赖的业务角度。从商品维度我们可以定义出以下维度的属性：

商品ID（主键）
商品名称
商品交易价格
商品新旧程度： 1 全新 2 闲置 3 二手
商品类目ID
商品类目名称
品类ID
品类名称
买家ID
商品状态： 0 正常 1 删除 2 下架 3 从未上架
商品所在城市
商品所在省份

从地域维度，我们可以定义出以下维度的属性：

城市code
城市名称
省份code
省份名称

作为维度建模的核心，在企业级数据仓库中必须保证维度的唯一性。以A公司的商品维度为例，有且只允许有一种维度定义。例如，省份code这个维度，对于任何业务过程所传达的信息都是一致的。（维度设计后面细讲....）

构建总线矩阵

明确每个数据域下有哪些业务过程后，即可构建总线矩阵。您需要明确业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。如下所示是A公司电商板块交易功能的总线矩阵，我们定义了购买省份、购买城市、类目名称、类目ID、品牌名称、品牌ID、商品名称、商品ID、成交金额等维度。


数据域/过程		一致性维度
数据域/过程		购买省份	购买城市	类目ID	类目名称	品牌ID	品牌名称	商品ID	商品名称	成交金额
交易	下单	Y	Y	Y	Y	Y	Y	Y	Y	N
	支付	Y	Y	Y	Y	Y	Y	Y	Y	N
	发货	Y	Y	Y	Y	Y	Y	Y	Y	N
	确认收货	Y	Y	Y	Y	Y	Y	Y	Y	Y

其中，数据仓库总线架构的重要基石之一就是一致性维度。在针对不同数据域进行迭代构建或并行构建时，存在很多需求是对于不同数据域的业务过程或者同一数据域的不同业务过程合并在一起观察。比如对于日志数据域，统计了商品维度的最近一天的 PV 和 UV; 对于交易数据域，统计了商品维度的最近一天的下单 GMV。现在将不同数据域的商品的事实合并在一起进行数据探查，如计算转化率等，称为交叉探查。

如果不同数据域的计算过程使用的维度不一致，就会导致交叉探查存在问题。当存在重复的维度，但维度属性或维度属性的值不一致时，会导致交叉探查无法进行或交叉探查结果错误。接上个例子，假设对于日志数据域，统计使用的是商品维度 1;对于交易数据域，统计使用的是商品维度 2。商品维度 1 包含维度属性 BC 类型，而商品维度 2 无此属性，则无法在 BC 类型上进行交叉探查;商品维度 1 的商品上架时间这一维度属性时间格式是 yyyy-MM-dd HH:mm:ss，商品维度 2 的商品上架时间这一维度属性时间格式是 UNIX timestamp，进行交叉探查时如果需要根据商品上架时间做限制，则复杂性较高;商品维度 l 不包含阿里旅行的商品，商品维度 2 包含全部的淘系商品，交叉探查也无法进行。还有很多种形式的不一致，这里不再一一列举，但基本可以划分为维度格式和内容不一致两种类型。

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

共享维表。比如在阿里巴巴的数据仓库中，商品、卖家、买家、类目等维度有且只有一个。所以基于这些公共维度进行的交叉探查不会存在任何问题。
一致性上卷，其中一个维度的维度属性是另一个维度的维度属性的子集，且两个维度的公共维度属性结构和内容相同。比如在阿里巴巴的商品体系中，有商品维度和类目维度，其中类目维度的维度属性是商品维度的维度属性的子集，且有相同的维度属性和维度属性值。这样基于类目维度进行不同业务过程的交叉探查也不会存在任何问题。
交叉属性，两个维度具有部分相同的维度属性。比如在商品维度中具有类目属性，在卖家维度中具有主营类目属性，两个维度具有相同的类目属性，则可以在相同的类目属性上进行不同业务过程的交叉探查。

明确统计指标

指标定义注意事项

原子指标是明确的统计口径、计算逻辑： 原子指标=业务过程+度量。派生指标即常见的统计指标：派生指标=时间周期+修饰词+原子指标。原子指标的创建需要在业务过程定义后方才可创建。派生指标的创建一般需要在了解具体报表需求之后展开，在新建派生指标前必须新建好原子指标。注意事项如下：

原子指标、修饰类型及修饰词，直接归属在业务过程下，其中修饰词继承修饰类型的数据域。
派生指标可以选择多个修饰词，由具体的派生指标语义决定。例如，支付金额为原子指标，则客单价（支付金额除以买家数）为派生指标。
派生指标唯一归属一个原子指标，继承原子指标的数据域，与修饰词的数据域无关。

根据业务需求确定指标

本教程中，用户是电商营销部门的营销数据分析师。数据需求为最近一天厨具类目的商品在各省的销售总额、该类目Top10销售额商品名称、各省用户购买力分布（人均消费额）等，用于营销分析。

根据之前的分析，我们确认业务过程为：确认收货（交易成功），而度量为商品的销售金额。因此根据业务需求，我们可以定义出原子指标：商品成功交易金额。

派生指标为：

最近一天全省厨具类目各商品销售总额
最近一天全省厨具类目人均消费额（消费总额除以人数）

最近一天全省厨具类目各商品销售总额进行降序排序后取前10名的名称，即可得到该类目Top10销售额商品名称。

事实表设计原则

原则 1 :尽可能包含所有与业务过程相关的事实

事实表设计的目的是为了度量业务过程，所以分析哪些事实与业务过程有关是设计中非常重要的关注点。在事实表中应该尽量包含所有与业务过程相关的事实，即使存在冗余，但是因为事实通常为数字型，带来的存储开销也不会很大。

原则 2:只选择与业务过程相关的事实

在选择事实时，应该注意只选择与业务过程有关的事实。比如在订单的下单这个业务过程的事实表设计中，不应该存在支付金额这个表示支付业务过程的事实。

原则 3: 分解不可加性事实为可加的组件

对于不具备可加性条件的事实，需要分解为可加的组件。比如订单的优惠率，应该分解为订单原价金额与订单优惠金额两个事实存储在事实表中。

原则 4:在选择维度和事实之前必须先声明粒度

粒度的声明是事实表设计中不可忽视的重要一步，粒度用于确定事实表中一行所表示业务的细节层次，决定了维度模型的扩展性，在选择维度和事实之前必须先声明粒度，且每个维度和事实必须与所定义的粒度保持一致。在设计事实表的过程中，粒度定义得越细越好，建议从最低级别的原子粒度开始，因为原子粒度提供了最大限度的灵活性，可以支持无法预期的各种细节层次的用户需求。在事实表中，通常通过业务描述来表述粒度，但对于聚集性事实表的粒度描述，可采用维度或维度属性组合的方式。

原则 5: 在同一个事实表中不能有多种不同粒度的事实

事实表中的所有事实需要与表定义的粒度保持一致，在同一个事实表中不能有多种不同粒度的事实。

如表 11.1 所示为机票支付成功事务事实表，粒度为票一级的，而在实际业务中，一个订单可以同时支付多张票，如 ID 为 100901 的订单包含三张机票， ID 为 100902 的订单包含两张机票， ID 为 100903 的订单包含一张机票。在该事实表的设计中，票支付金额和票折扣金额两个事实与表定义的粒度一致，并且支持按表的任意维度汇总，可以添加进该事实表中。而订单支付金额和订单票数作为上一层粒度的订单级事实，与该票级事实表的粒度不一致，且不能进行汇总。比如订单 ID 为 100901 的订单支付金额为 3700 元，订单票数为 3 张，如果这两个度量在该表进行汇总计算总订单金额和总票数，则会造成重复计算的问题，所以不能作为该表的度量选入。

原则 6:事实的单位要保持一致

对于同一个事实表中事实的单位，应该保持一致。比如原订单金额、订单优惠金额、订单运费金额这三个事实，应该采用一致的计量单位，统一为元或分，以方便使用。

原则 7: 对事实的null值要处理

对于事实表中事实度量为 null 值的处理，因为在数据库中 null 值对常用数字型字段的 SQL 过滤条件都不生效，比如大于、小于、等于、大于或等于、小于或等于，建议用零值填充。

原则 8:使用退化维度提高事实表的易用性

在 Kimball 的维度建模中，通常按照星形模型的方式来设计，对于维度的获取采用的是通过事实表的外键关联专门的维表的方式，谨慎使用退化维度。而在大数据领域的事实表设计中，则大量采用退化维度的方式，在事实表中存储各种类型的常用维度信息。这样设计的目的主要是为了减少下游用户使用时关联多个表的操作，直接通过退化维度实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等。通过增加冗余存储的方式减少计算开销，提高使用效率。

事实表设计方法

对于维度模型设计采用四步设计方法: 选择业务过程、声明粒度、确定维度、确定事实。

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

订单流转的业务过程有四个:创建订单、买家付款、卖家发货、买家确认收货。在明确了流程所包含的业务过程后，需要根据具体的业务需求来选择与维度建模有关的业务过程。比如是选择买家付款这个业务过程，还是选择创建订单和买家付款这两个业务过程，具体根据业务情况来确定。

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

第二步：声明粒度

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

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

在下单交易时，有两种方式:一种是选定商品后直接购买，这样会产生一个交易订单;一种是将多种商品加入到购物车中，然后一起结算，此时对于每一种商品都会产生一个订单，同时对于同一个店铺会额外产生一个订单，即父订单;由于是在同一个店铺购买的，所以父订单会承载订单物流、店铺优惠等信息。而对于每一种商品产生的订单就称为子订单，子订单记录了父订单的订单号，并且有子订单标志。如果在同一个店铺只购买了1种商品，则会将父子订单进行合并，只保留一条订单记录。

第三步：确定维度

完成粒度声明以后，也就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了，应该选择能够描述清楚业务过程所处的环境的维度信息。比如在淘宝订单付款事务事实表中，粒度为子订单，确定维度包含: 买家、卖家、商品、商品类目、发货地区、收货地区、父订单维度以及杂项维度。由于订单的属性较多，比如订单的业务类型、是否无线交易、订单的 attributes 属性等，对于这些使用较多却又无法归属到上述买卖家或商品维度中的属性，则新建一个杂项维度进行存放。

第四步：确定事实

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

如在下单业务过程中，需要包含下单金额、下单数量、下单分摊金额;在支付业务过程中，包含支付金额、分摊邮费、折扣金额、红包金额、积分金额;在完结业务过程中包含确认收货金额等。由于粒度是子订单，所以对于一些父订单上的金额需要分摊到子订单上，比如父订单邮费、父订单折扣等。

第五步：冗余维度

在传统的维度建模的星形模型中，对维度的处理是需要单独存放在专门的维表中的，通过事实表的外键获取维度。这样做的目的是为了减少事实表的维度冗余，从而减少存储消耗。而在大数据的事实表模型设计中，考虑更多的是提高下游用户的使用效率，降低数据获取的复杂性，减少关联的表数量。所以通常事实表中会冗余方便下游用户使用的常用维度，以实现对事实表的过滤查询、控制聚合层次、排序数据以及定义主从关系等操作。

比如在淘宝订单付款事务事实表中，通常会冗余大量的常用维度字段，以及商品类目、卖家店铺等维度信息，提高对事实表进行过滤查询、统计聚合的效率。

多事务事实表

多事务事实表将不同的事实放到同一个事实表中，即同一个事实表包含不同的业务过程。多事务事实表在设计时有两种方法进行事实的处理 : 1、不同业务过程的事实使用不同的事实字段进行存放；2、不同业务过程的事实使用同一个事实字段进行存放，但增加一个业务过程标签。接下来将通过淘宝交易事务事实表和淘宝收藏商品事务事实表分别阐述其设计方法。

先放一个单事务事实表和多事务事实表的区别：

交易事务事实表(存在稀疏)

将多个业务过程放到同一个事实表中，将要面对的是如何处理多个事实。淘宝交易事务事实表中包含了下单、支付和成功完结三个业务过程，则需要包含下单度量、支付度量和成功完结度量信息，这里的解决方案是针对每个度量都使用一个字段进行保存，即不同的事实使用不同的字段进行存放;如果不是当前业务过程的度量，则采取零值处理方式。比如在下单业务过程中，对于支付度量和成功完结度量全部置为 0，其他业务过程类似处理。

同一个事实表中包含了多个业务过程，在表中如何进行标记呢?淘宝交易事务事实表采取了这样的解决方案，即针对每个业务过程打一个标签，标记当天是否是这个业务过程，比如针对下单，则打一个是否当天下单的标签;针对支付，打一个是否当天支付的标签；针对成功完结，打一个是否当天成功完结的标签，标签之间互不相干。

收藏商品事务事实表(存在多条记录)

收藏和加购物车是淘宝购物过程中比较常见的两个行为，当用户遇到喜欢的商品或者店铺时可以选择收藏，然后下次继续浏览购买。这里以收藏事务事实表阐述多事务事实表在处理不同业务过程时使用同一个字段保存事实的设计方式。

收藏业务较为简单，商品和店铺的收藏业务相似，这里仅以收藏商品为例进行阐述。用户可以直接收藏一个商品，也可以删除所收藏的商品，所以在这个过程中包含了两个业务过程 : 收藏商品和删除商品。因此收藏商品事务事实表的第一步就是选择收藏商品和删除商品两个业务过程。业务过程确定后，接下来就是确定粒度。无论是收藏商品还是删除所收藏的商品，都是用户对商品的一个操作，因此这里确定为用户加上商品的粒度。

确定好业务过程和粒度后，接下来是确定维度和事实。由于粒度是用户加上商品，所以维度主要是用户维度和商品维度。为了使事实表信息更丰富，冗余了商品类目维度和商品所属卖家维度，收藏商品和删除商品业务过程所属的维度是一致的。

收藏商品和删除商品是两个不同的业务过程，但是确定了相同的粒度和维度，所以考虑、设计多事务事实表，将这两个业务过程放到同一个事实表中，只是在不同业务过程的事实上进行区分。在前面的“淘宝交易事务事实表 ”中是使用不同字段存放不同业务过程的事实，这里的解决方案是使用同一个字段存放不同业务过程的事实，使用标签字段区分不同业务过程，比如收藏事务事实表使用一个“收藏事件类型”字段来区分是收藏商品还是删除商品。收藏商品和删除商品的事实主要是商品价格，不过收藏事务事实表更多的是无事实的事实表，一般用于统计收藏或者删除的次数。

多事务事实表选择

上面介绍了两种多事务事实表的设计方式，在实际应用中需要根据业务过程进行选择。由于是多事务事实表，因此在事实表中包含多个业务过程 :

当不同业务过程的度量比较相似、差异不大时，可以采用第二种多事务事实表的设计方式，使用同一个字段来表示度量数据。但这种方式存在一个问题一一在同一个周期内会存在多条记录。
当不同业务过程的度量差异较大时，可以选择第一种多事务事实表的设计方式，将不同业务过程的度量使用不同字段冗余到表中，非当前业务过程则置零表示。这种方式所存在的问题是度量字段零值较多。

事实表分类

事实表有三种类型：

1、事务事实表：事务型事实表用来记录各业务过程，它保存的是各业务过程的原子操作事件，即最细粒度的操作事件，粒度是指事实表中一行数据所表达的业务细节程度。事务型事实表可用于分析与各业务过程相关的各项统计指标，由于其保存了最细粒度的记录，可以提供最大限度的灵活性，可以支持无法预期的各种细节层次的统计需求。一个业务过程对应一张事务型事实表。

不足：

存量型指标：比如电商中的虚拟货币或者商品库存，增长或者存入商品可能对应一个事实表，减少或者寄出商品对应一个事实表，如果需要计算存量，那么可能需要进行大表join，效率慢。

多事务关联统计：比如现在需要统计最近30天，用户下单到支付的时间间隔的平均值，统计思路应该从下单事务事实表和支付事务事实表找到最近30天的记录，然后根据订单id进行大表join，同样是效率慢。

2、周期快照表：周期快照事实表以具有规律性的、可预见的时间间隔来记录事实，主要用于分析一些存量型（例如商品库存、账户余额）或者状态型（平均驾驶速度、平均温度）指标。对于存量型指标，业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，避免从历史记录中进行聚合。对于状态型指标，由于它们的值往往是连续的，无法捕获其变动的原子事务操作，所以无法使用事务型事实表统计此类需求，而只能定期对其进行采样，构建周期型快照事实表。

3、累积快照表：累积快照事实表是基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如交易流程中的下单、支付、发货、确认收货业务过程。通常具有多个日期字段，每个日期对应业务流程中的一个关键过程。累积型快照事实表重要用于分析业务过程之间的时间间隔等需求，例如用户下单到支付的平均时间间隔，就能避免两个事务型事实表的关联操作。

数据仓库分层

ODS 操作数据层

既然数据都是从数据库(MySQL)中获取，那如果直接作为数据仓库的数据源不行吗？

1、业务数据库的数据存储位行式存储，而数据仓库要求列数存储（行式数据转换为列式数据）

2、业务数据库中存储的数据不是海量数据，有可能只是近几年的数据，但是数据仓库要求更多历史数据时，可能不满足要求（数据量不够）

3、数据库不是为了数据仓库服务的（数据仓库在对接数据库时，会对数据库的性能造成影响，从而影响业务正常运行）

所以，需要设计一个自己的数据源，ods层就是数据仓库的数据源

ODS层的基本工作

同步：结构化数据增量或者全量同步ODS层中
结构化：非结构化（日志）结构化处理并存储到ODS层中
累积历史、清洗：根据数据业务需求及稽核和审计要求保存历史数据、清洗数据

其中尽可能不变

1、存储方式不要变

2、数据格式不要变

3、压缩格式不要变

可以变

1、融合异构数据

2、汇总不同时间的数据

DWD 明细粒度层

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

明细粒度事实层（DWD）通常分为三种：事务事实表、周期快照事实表和累积快照事实表。

事务事实表用来描述业务过程，跟踪空间或时间上某点的度量事件，保存的是最原子的数据，也称为原子事实表。
周期快照事实表以具有规律性的、可预见的时间间隔记录事实。
累积快照事实表用来表述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点。当累积快照事实表随着生命周期不断变化时，记录也会随着过程的变化而被修改。

通常，一个明细粒度事实表仅和一个维度关联。
尽可能包含所有与业务过程相关的事实。
只选择与业务过程相关的事实。
分解不可加性事实为可加的组件。
在选择维度和事实之前必须先声明粒度。
在同一个事实表中不能有多种不同粒度的事实。
事实的单位要保持一致。
谨慎处理Null值。
使用退化维度提高事实表的易用性。

明细粒度事实表整体设计流程如下图所示。

在一致性度量中已定义好了交易业务过程及其度量。明细事实表注意针对业务过程进行模型设计。明细事实表的设计可以分为四个步骤：选择业务过程、确定粒度、选择维度、确定事实（度量）。粒度主要是在维度未展开的情况下记录业务活动的语义描述。在您建设明细事实表时，需要选择基于现有的表进行明细层数据的开发，清楚所建表记录存储的是什么粒度的数据。存储方式可以变为列式存储。

DWS 公共汇总粒度层

公共汇总粒度事实层DWS（Data Warehouse Summary）以分析的主题对象作为建模驱动，基于上层的应用和产品的指标需求构建公共粒度的汇总指标事实表。公共汇总层的一个表至少会对应一个派生指标。

聚集是指针对原始明细粒度的数据进行汇总。DWS公共汇总层是面向分析对象的主题聚集建模。在本教程中，最终的分析目标为：最近一天某个类目（例如：厨具）商品在各省的销售总额、该类目Top10销售额商品名称、各省用户购买力分布。因此，我们可以以最终交易成功的商品、类目、买家等角度对最近一天的数据进行汇总。数据聚集的注意事项如下：

聚集是不跨越事实的。聚集是针对原始星形模型进行的汇总。为获取和查询与原始模型一致的结果，聚集的维度和度量必须与原始模型保持一致，因此聚集是不跨越事实的。
聚集会带来查询性能的提升，但聚集也会增加ETL维护的难度。当子类目对应的一级类目发生变更时，先前存在的、已经被汇总到聚集表中的数据需要被重新调整。

此外，进行DWS层设计时还需遵循以下原则：

数据公用性：需考虑汇总的聚集是否可以提供给第三方使用。您可以思考，基于某个维度的聚集是否经常用于数据分析中。如果答案是肯定的，就有必要把明细数据经过汇总沉淀到聚集表中。
不跨数据域：数据域是在较高层次上对数据进行分类聚集的抽象。数据域通常以业务过程进行分类，如交易统一划到交易域下，商品的新增、修改放到商品域下。
区分统计周期：在表的命名上要能说明数据的统计周期，如_1d 表示最近1天， td 表示截至当天，nd 表示最近N天。

DIM 公共维度层

公共维度汇总层DIM（Dimension）基于维度建模理念，建立整个企业的一致性维度。

公共维度汇总层（DIM）主要由维度表（维表）构成。维度是逻辑概念，是衡量和观察业务的角度。维表是根据维度及其属性将数据平台上构建的物理化的表，采用宽表设计的原则。因此，公共维度汇总层（DIM）首先需要定义维度。

完成维度定义后，您可以对维度进行补充，进而生成维表。维表的设计需要注意：

建议维表单表信息不超过1000万条。
维表与其他表进行Join时，建议您使用Map Join。
避免过于频繁的更新维表的数据。

ADS 数据应用层

存放数据产品个性化的统计指标数据，根据DW层与ODS层加工生成。ADS层数据优先使用DW层数据，当公共层没有数据时，需评估是否需要创建公共层数据，当不需要创建公用的公共层时，方可直接使用ODS层数据。

参考：

书籍：阿里大数据之路

数据仓库的分层和各层级用途_云原生大数据计算服务 MaxCompute(MaxCompute)-阿里云帮助中心

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/运维做开发/article/detail/962930