5. 电商数据仓库系统
电商数据仓库系统数据仓库概述数据仓库建模概述维度建模理论之事实表维度建模理论之维度表维度建模理论之维度表数据仓库环境准备数仓开发之ODS层数仓开发之DIM层数仓开发之DWD层数仓开发之DWS层数仓开发之ADS层报表数据导出数据仓库工作流调度数据仓库概述数据仓库建模概述维度建模理论之事实表维度建模理论之维度表维度建模理论之维度表数据仓库环境准备数仓开发之ODS层数仓开发之DIM层数仓开发之DWD层数
5. 电商数据仓库系统
1 数据仓库概述
数据仓库 : 为数据分析而设计的企业级数据管理系统
数据仓库可集中、整合多个信息源的大量数据，借助数据仓库的分析能力，企业可从数据中获得宝贵的信息进而改进决策
数据仓库核心架构 :
2 数据仓库建模概述
2.1 数据仓库建模的意义
数据模型 : 数据组织和存储方法，强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后，数据才能得到高性能、低成本、高效率、高质量的使用
- 高性能：快速查询所需要的数据
- 低成本：减少重复计算，实现计算结果的复用，降低计算成本
- 高效率：良改善用户使用数据的体验，提高使用数据的效率
- 高质量：改善数据统计口径的混乱，减少计算错误的可能性
2.2 数据仓库建模方法论
2.2.1 ER模型
建模方法 : 从全企业的高度，用实体关系（Entity Relationship，ER）模型来描述企业业务，并用规范化的方式表示出来，在范式理论上符合 3NF
2.2.1.1 实体关系模型
实体关系模型将复杂的数据抽象 :
- 实体 : 一个对象，如 : 学生、班级
- 关系 : 两个实体之间的关系，如 : 学生和班级之间的从属关系
2.2.1.2 数据库规范化
数据库规范化 : 使用一系列范式设计数据库（关系型数据库）的过程，其目的 : 减少数据冗余，增强数据的一致性
关系型数据库的范式 :
- 第一范式（1NF）
- 第二范式（2NF）
- 第三范式（3NF）
- 巴斯-科德范式（BCNF）
- 第四范式(4NF）
- 第五范式（5NF）
遵循的范式级别越高 ，数据冗余性就越低
2.2.1.3 三范式
2.2.1.3.1 函数依赖
完全函数依赖：
设 X，Y 是关系 R 的两个属性集合，X’ 是 X 的真子集，存在 X—> Y，但对每一个 X’ 都有 X’ !—> Y，则称 Y 完全函数依赖于 X 。
记做：
人类语言：
如 : 通过(学号，课程) 推出分数，但是单独用学号不能推出分数，所以 分数 完全依赖于(学号，课程)
即：通过 AB 能得出 C，但是 AB 单独得不出 C，所以 C 完全依赖于AB
部分函数依赖 :
假如 Y 函数依赖于 X，但同时Y 并不完全函数依赖于X，就称 Y 部分函数依赖于 X，记做：
人类语言：如 : 通过(学号，课程) 推出姓名，但可以直接通过学号推出姓名，所以：姓名 部分依赖于(学号，课程)
即：通过 AB 能得出 C，，通过 A 也能得出 C，或通过 B 也能得出 C，所以 C 部分依赖于 AB
传递函数依赖 :
传递函数依赖：设 X，Y，Z 是关系 R 中互不相同的属性集合，存在 X—> Y(Y !—> X), Y —> Z，所以 Z 传递函数依赖于 X , 记做：
人类语言：学号推出系名，系名推出系主任，但是系主任推不出学号，系主任主要依赖于系名 , 所以系主任 传递依赖于 学号
通过 A 得到 B，通过 B 得到 C，但是 C 得不到 A，所以 C 传递依赖于 A
2.2.1.3.2 第一范式
1NF 核心原则：属性不可切割
上表格设计 : 不符合第一范式，商品列中的数据不是原子数据项，是可以分割的，所以要修改，让表格符合第一范式的要求
修改结果 :
1NF 是所有关系型数据库的最基本要求，在关系型数据库管理系统（RDBMS），如 : SQL Server，Oracle，MySQL中创建数据表的时，如果数据表的设计不符合最基本的要求，那么操作一定是不能成功的。所以 , 只要在 RDBMS 中已经存在的数据表，就一定符合 1NF
2.2.1.3.3 第二范式
2NF 核心原则：不能存在部分函数依赖
表格明显存在，部分依赖。如 : 表的主键是（学号，课名 ) ，分数确实完全依赖于(学号，课名），但是姓名并不完全依赖于(学号，课名）
去除部分函数依赖 , 符合第二范式 :
2.2.1.3.4 第三范式
3NF核心原则：不能存在传递函数依赖
表中，存在传递函数依赖：学号->系名->系主任，但系主任推不出学号
拆分 :
构建的模型 :
建模方法的出发点是整合数据，目的 : 将整个企业的数据进行组合和合并，并进行规范处理，减少数据冗余性，保证数据的一致性。但该模型不适合直接用于分析统计
2.2.2 维度模型
维度模型 : 将复杂的业务通过事实和维度 进行呈现
事实 : 业务过程
维度 : 业务过程发生时所处的环境
业务过程概括为一个个不可拆分的行为事件，如 : 电商交易中的下单，取消订单，付款，退单等，都是业务过程
维度模型 :
以中心的 SalesOrder 为事实表，保存的是下单这个业务过程的所有记录
位于周围每张表都是维度表，包括Date（日期），Customer（顾客），Product（产品），Location（地区）
这些维度表组成了每个订单发生时所处的环境，如 : 何人、何时、在何地下单了何种产品
维度建模 : 以数据分析作为出发点，为数据分析服务，所以关注重点是用户如何更快的完成需求分析 和 如何实现较好的大规模复杂查询的响应性能
3 维度建模理论之事实表
3.1 事实表概述
事实表 : 数据仓库维度建模的核心，紧紧围绕着业务过程来设计。其包含与该业务过程有关的维度引用（维度表外键）和 该业务过程的度量（可累加的数字类型字段）
事实表特点 : 比较 “细长”，即列较少，但行较多，且行的增速快
事实表的类型：
- 事务事实表
- 周期快照事实表
- 累积快照事实表
3.2 事务型事实表
事务事实表 : 记录各业务过程，保存了各业务过程的原子操作事件 ( 最细粒度的操作事件 )
粒度 : 事实表中一行数据所表达的业务细节程度
事务型事实表 : 分析与各业务过程相关的各项统计指标，由于保存最细粒度的记录，可以提供最大限度的灵活性，可以统计各种细节层次的需求
3.2.1 设计流程
设计事务事实表步骤：
- 选择业务过程
- 声明粒度
- 确认维度
- 确认事实
3.2.1.1 选择业务过程
业务过程概括 : 一个个不可拆分的行为事件，如 : 电商交易中的下单，取消订单，付款，退单等，都是业务过程
通常情况下，一个业务过程对应一张事务型事实表
3.2.1.2 声明粒度
业务过程确定后，需要为每个业务过程声明粒度
精确定义每张事务型事实表的每行数据表示什么，选择最细粒度，适应各种细节程度的需求
粒度声明 , 如 : 订单事实表中一行数据表示一个订单中的一个商品项
3.2.1.3 确定维度
确定维度 : 确定与每张事务型事实表相关的维度有哪些
确定维度时选择与业务过程相关的环境信息。因为维度的丰富程度就决定了维度模型能够支持的指标丰富程度
3.2.1.4 确定事实
事实 : 每个业务过程的度量值（可累加的数字类型的值，如：次数、个数、件数、金额）
上述四个步骤，事务型事实表就基本设计完成
- 选择业务过程可以确定有哪些事务型事实表
- 确定每张事务型事实表的每行数据是什么
- 确定每张事务型事实表的维度外键
- 确定每张事务型事实表的度量值字段
3.2.2 不足
事务型事实表 : 保存所有业务过程的最细粒度的操作事件，理论上可以支撑与各业务过程相关的各种统计粒度的需求
某些特定类型的需求 :
- 存量型指标
- 多事务关联统计
逻辑可能会比较复杂，或效率会比较低下
存量型指标
如 : 商品库存，账户余额
例子 : 电商中的虚拟货币为
虚拟货币业务包含的业务过程主要包括 :
- 获取货币
- 使用货币
两个业务过程各自对应一张事务型事实表，一张存储所有的获取货币的原子操作事件，另一张存储所有使用货币的原子操作事件
假定需求 : 要求统计截至当日的各用户虚拟货币余额
由于获取货币和使用货币均会影响到余额，所以对两张事务型事实表进行聚合，且区分两者对余额的影响（加或减），另外需要对两张表的全表数据聚合才能得到统计结果
以上从逻辑上还是效率上考虑，这都不是一个好的方案
多事务关联统计
如 : 统计最近30天，用户下单到支付的时间间隔的平均值。
统计思路 : 找到下单事务事实表和支付事务事实表，过滤出最近30天的记录，然后按照订单 id 对两张事实表进行关联，之后用支付时间减去下单时间，然后再求平均值
逻辑上虽然不复杂，但是效率较低，下单事务事实表和支付事务事实表均为大表，大表 join 大表的操作要尽量避免
上述两种场景下事务型事实表的表现并不理想
所以下面两种类型的事实表弥补事务型事实表的不足
3.3 周期型快照事实表
周期快照事实表 : 具有规律性的、可预见的时间间隔来记录事实，分析一些存量型（如 : 商品库存，账户余额）或 状态型（空气温度，行驶速度）指标
商品库存、账户余额这些存量型指标 : 业务系统中通常就会计算并保存最新结果，所以定期同步一份全量数据到数据仓库，构建周期型快照事实表，来解决此类统计需求，而无需再对事务型事实表中大量的历史记录进行聚合
空气温度、行驶速度这些状态型指标 : 由于它们的值往往是连续的，所以无法捕获变动的原子事务操作，所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样，构建周期型快照事实表
3.3.1 设计流程
3.3.1.1 确定粒度
周期型快照事实表的粒度 : 由采样周期和维度描述，所以确定采样周期和维度后 , 就确定粒度
采样周期一般选择每日
维度可根据统计指标决定，如 : 指标为统计每个仓库中每种商品的库存，就可确定维度为仓库和商品
确定完采样周期和维度后，就可确定该表粒度 : 每日 - 仓库 - 商品
3.3.1.2 确认事实
事实也可根据统计指标决定，如 : 指标为统计每个仓库中每种商品的库存，则事实 : 商品库存
3.3.2 事实类型
事实类型 : 度量值的类型，而非事实表的类型
事实（度量值）分三类 :
- 可加事实
- 半可加事实
- 不可加事实
3.3.2.1 可加事实
可加事实 : 可以按照与事实表相关的所有维度进行累加，如 : 事务型事实表中的事实
3.3.2.2 半可加事实
半可加事实 : 只能按照与事实表相关的一部分维度进行累加，如 : 周期型快照事实表中的事实
例子 : 各仓库中各商品的库存每天快照事实表
该张表中的库存事实可以按照 : 仓库或 商品维度进行累加，但不能按照时间维度进行累加，因为将每天的库存累加起来是没有意义的
3.3.2.3 不可加事实
不可加事实 : 完全不具备可加性，如 : 比率型事实
不可加事实通常需要转化为可加事实，如 : 比率 转化为分子和分母
3.4 累积型快照事实表
累计快照事实表 : 基于一个业务流程中的多个关键业务过程联合处理而构建的事实表，如 : 交易流程中的下单、支付、发货、确认收货业务过程
累积型快照事实表 : 具有多个日期字段，每个日期对应业务流程中的一个关键业务过程（里程碑）
| 订单id | 用户id | 下单日期 | 支付日期 | 发货日期 | 确认收货日期 | 订单金额 | 支付金额 |
|---|---|---|---|---|---|---|---|
| 1001 | 1234 | 2020-06-14 | 2020-06-15 | 2020-06-16 | 2020-06-17 | 1000 | 1000 |
累积型快照事实表主要用于 : 分析业务过程（里程碑）之间的时间间隔等需求。如 : 用户下单到支付的平均时间间隔，使用累积型快照事实表进行统计，就能避免两个事务事实表的关联操作，让其简单高效
3.4.1 设计流程
累积型快照事实表的设计流程与事务型事实表类似
采用以下四个步骤 :
- 选择业务过程
- 声明粒度
- 确认维度
- 确认事实
3.4.1.1 选择业务过程
选择一个业务流程中需要关联分析的多个关键业务过程，多个业务过程对应一张累积型快照事实表
3.4.1.2 声明粒度
精确定义每行数据表示的是什么，尽量选择最小粒度
3.4.1.3 确认维度
选择与各业务过程相关的维度，注意 : 每各业务过程都需要一个日期维度
3.4.1.4 确认事实
选择各业务过程的度量值
4 维度建模理论之维度表
维度表是维度建模的基础和灵魂
事实表紧紧围绕业务过程进行设计，而维度表则围绕业务过程所处的环境进行设计
维度表主要包含一个主键和各种维度字段 ( 维度属性 )
4.1 维度表设计步骤
4.1.1 确定维度（表）
在设计事实表时，就确定了与每个事实表相关的维度，理论上每个相关维度均需对应一张维度表
可能存在多个事实表与同一个维度都相关的情况，为了保证维度的唯一性，只创建一张维度表
当某些维度表的维度属性很少，如 : 只有一个名称，就可不创建该维度表，而把该表的维度属性直接增加到相关的事实表中 ( 维度退化 )
4.1.2 确定主维表和相关维表
主维表和相关维表均指业务系统中与某维度相关的表
如 : 业务系统中与商品相关的表有 sku_info，spu_info，base_trademark，base_category3，base_category2，base_category1 等
其中 sku_info 为 商品维度的主维表，其余表为商品维度的相关维表
维度表的粒度通常与主维表相同
4.1.3 确定维度属性 ( 确定维度表字段 )
维度属性主要来自于业务系统中与该维度对应的主维表和相关维表
维度属性可直接从主维表或相关维表中选择，也可进一步加工得到。
确定维度属性时，遵循要求：
1. 尽可能生成丰富的维度属性
维度属性是后续做分析统计时的查询约束条件、分组字段的基本来源，是数据易用性的关键
维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度
2. 尽量不使用编码
使用明确的文字说明，一般编码和文字共存
3. 尽量沉淀出通用的维度属性
有些维度属性的获取需要进行比较复杂的逻辑处理，如 : 需要通过多个字段拼接得到。为避免每次使用时的重复处理，可将这些维度属性沉淀到维度表中
4.2 维度设计要点
4.2.1 规范化与反规范化
规范化 : 使用一系列范式设计数据库的过程，目的 : 减少数据冗余，增强数据的一致性。通常情况下，规范化之后，一张表的字段会拆分到多张表
反规范化 : 将多张表的数据冗余到一张表，目的 : 减少 join 操作，提高查询性能
设计维度表时 :
- 雪花模型 : 对其进行规范化
- 星型模型 : 对其进行反规范化
4.2.1.1 星型模型
雪花模型与星型的区别主要在于维度表是否进行规范化
4.2.1.2 雪花模型
雪花模型，比较靠近 3NF，但是无法完全遵守。因为遵循 3NF 的性能成本太高
数据仓库系统的目的 : 用于数据分析和统计，所以是否方便用户进行统计分析决定了模型的优劣。
采用雪花模型 : 用户在统计分析的过程中需要大量的关联操作，使用复杂度高，同时查询性能很差
采用星型模型 : 方便、易用且性能好。所以出于易用性和性能的考虑，维度表一般是很不规范化
4.2.2 维度变化
维度属性通常不是静态的，而是会随时间变化的，数据仓库的一个重要特点就是反映历史的变化，所以如何保存维度的历史状态是维度设计的重要工作之一
保存维度数据的历史状态，两种做法 :
- 全量快照表
- 拉链表
4.2.2.1 全量快照表
离线数据仓库的计算周期通常为每天一次，所以可以每天保存一份全量的维度数据
-
优点 : 简单而有效，开发和维护成本低，且方便理解和使用
-
缺点 : 浪费存储空间，尤其是当数据的变化比例比较低时
4.2.2.2 拉链表
拉链表的意义 : 能够更加高效的保存维度信息的历史状态
拉链表 : 记录每条信息的生命周期 , 一旦一条记录的生命周期结束，就重新开始一条新的记录，并把当前日期放入生效开始日期
如果当前信息至今有效，在生效结束日期中填入一个极大值（如 9999-12-31 ）
拉链表适合于：数据会发生变化，但变化频率并不高的约 ( 缓慢变化维 ）
如：用户信息会发生变化，但是每天变化的比例不高
如果数据量有一定规模，按照每日全量的方式保存效率很低。如：1亿用户 * 365天，每天一份用户信息。(每日全量效率低)
生效开始时间 <= 某个时间 & 生效结束时间 >= 某个日期, 能够得到某个时间点的数据全量切片
拉链表数据 :
例子 : 获取 2019-01-01 历史切片
select *
from user_info
where
start_date <= '2019-01-01' and end_date >= '2019-01-01'
例子 : 获取 2019-01-02 的历史切片 :
select
*
from
order_info
where
start_date <= '2019-01-02' and end_date >= '2019-01-02'
4.2.3 多值维度
多值维度 : 事实表中一条记录对应某个维度表中多条记录
如 : 下单事实表中的一条记录为一个订单，一个订单可能包含多个商品，对应商品维度表中多条数据
两种方案解决 :
-
降低事实表的粒度，如 : 将订单事实表的粒度由一个订单降低为一个订单中的一个商品项
-
在事实表中采用多字段保存多个维度值，每个字段保存一个维度 id。只适用于多值维度个数固定的情况
一般采用 降低事实表的粒度解决多值维度问题
4.2.4 多值属性
多值属性 : 维表中的某个属性同时有多个值，如 : 商品维度的平台属性和销售属性，每个商品均有多个属性值
两种方案 :
-
将多值属性放到一个字段，该字段内容为
key1:value1，key2:value2的形式，如 : 一个手机商品的平台属性值为 “ 品牌:华为，系统:鸿蒙，CPU:麒麟990 ” -
将多值属性放到多个字段，每个字段对应一个属性。只适用于多值属性个数固定的情况
5 数据仓库设计
5.1 数据仓库分层规划
数仓体系，需要良好的数据分层结构
合理的分层，能够使数据体系更加清晰，使复杂问题得以简化
数据仓库分层规划 :
5.2 数据仓库构建流程
构建数据仓库的完整流程 :
5.2.1 数据调研
数据调研重点工作 :
- 业务调研
- 需求分析
这两项工作做的是否充分，直接影响着数据仓库的质量。
业务调研
业务调研的主要目标是熟悉业务流程、熟悉业务数据
熟悉业务流程要求做到，明确每个业务的具体流程，需要将该业务所包含的每个业务过程一一列举出来
熟悉业务数据要求做到，将数据（埋点日志 & 业务数据表）与业务过程对应起来，明确每个业务过程会对哪些表的数据产生影响，以及产生什么影响。产生的影响，需要具体到，是新增一条数据，还是修改一条数据，并且需要明确新增的内容或 修改的逻辑
例子 : 业务电商中的交易
交易业务涉及到的业务过程 : 买家下单、买家支付、卖家发货，买家收货
具体流程 :
需求分析
需求指标 , 如 : 最近一天各省份手机品类订单总额
分析需求时，需要明确需求所需的业务过程及维度，如 : 该需求所需的业务过程就是买家下单，所需的维度 : 日期，省份，商品品类
总结
做完业务分析和需求分析后，要保证每个需求都能找到相应的业务过程及维度。若现有数据无法满足需求，就和业务方进行沟通，如 : 某个页面需要新增某个行为的埋点
5.2.2 明确数据域
数据仓库模型设计除横向的分层外，还需要根据业务情况进行纵向划分数据域
划分数据域的意义 : 便于数据的管理和应用
一般根据业务过程或部门进行划分，该处根据业务过程进行划分 , 一个业务过程只能属于一个数据域
所有业务过程及数据域划分详情 :
| 数据域 | 业务过程 |
|---|---|
| 交易域 | 加购、下单、取消订单、支付成功、退单、退款成功 |
| 流量域 | 页面浏览、启动应用、动作、曝光、错误 |
| 用户域 | 注册、登录 |
| 互动域 | 收藏、评价 |
| 工具域 | 优惠券领取、优惠券使用（下单）、优惠券使用（支付） |
5.2.3 构建业务总线矩阵
业务总线矩阵中包含 :
- 维度模型所需的所有事实（业务过程）以及维度
- 各业务过程与各维度的关系
矩阵的行 : 一个个业务过程
矩阵的列 : 一个个的维度
行列的交点 : 业务过程与维度的关系
业务总线矩阵 :
一个业务过程对应维度模型中一张事务型事实表，一个维度则对应维度模型中的一张维度表
构建业务总线矩阵的过程就是设计维度模型的过程
总线矩阵中通常只包含事务型事实表，另外两种类型的事实表需单独设计
按照事务型事实表的设计流程 :
- 选择业务过程
- 声明粒度
- 确认维度
- 确认事实
最终的业务总线矩阵 :
| 数据域 | 业务过程 | 粒度 | 维度 | 度量 | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 时间 | 用户 | 商品 | 地区 | 活动(具体规则) | 优惠券 | 支付方式 | 退单类型 | 退单原因类型 | 渠道 | 设备 | ||||
| 交易域 | 加购物车 | 一次加购物车的操作 | √ | √ | √ | 商品件数 | ||||||||
| 下单 | 一个订单中一个商品项 | √ | √ | √ | √ | √ | √ | 下单件数/下单原始金额/下单最终金额/活动优惠金额/优惠券优惠金额 | ||||||
| 取消订单 | 一次取消订单操作 | √ | √ | √ | √ | √ | √ | 下单件数/下单原始金额/下单最终金额/活动优惠金额/优惠券优惠金额 | ||||||
| 支付成功 | 一个订单中的一个商品项的支付成功操作 | √ | √ | √ | √ | √ | √ | √ | 支付件数/支付原始金额/支付最终金额/活动优惠金额/优惠券优惠金额 | |||||
| 退单 | 一次退单操作 | √ | √ | √ | √ | √ | √ | 退单件数/退单金额 | ||||||
| 退款成功 | 一次退款成功操作 | √ | √ | √ | √ | √ | 退款件数/退款金额 | |||||||
| 流量域 | 页面浏览 | 一次页面浏览记录 | √ | √ | √ | √ | √ | 浏览时长 | ||||||
| 动作 | 一次动作记录 | √ | √ | √ | √ | √ | √ | √ | 无事实(次数1) | |||||
| 曝光 | 一次曝光记录 | √ | √ | √ | √ | √ | √ | √ | 无事实(次数1) | |||||
| 启动应用 | 一次启动记录 | √ | √ | √ | √ | √ | 无事实(次数1) | |||||||
| 错误 | 一次错误记录 | √ | √ | √ | √ | 无事实(次数1) | ||||||||
| 用户域 | 注册 | 一次注册操作 | √ | √ | 无事实(次数1) | |||||||||
| 登录 | 一次登录操作 | √ | √ | √ | √ | √ | 无事实(次数1) | |||||||
| 工具域 | 领取优惠券 | 一次优惠券领取操作 | √ | √ | √ | 无事实(次数1) | ||||||||
| 使用优惠券(下单) | 一次优惠券使用(下单)操作 | √ | √ | √ | 无事实(次数1) | |||||||||
| 使用优惠券(支付) | 一次优惠券使用(支付)操作 | √ | √ | √ | 无事实(次数1) | |||||||||
| 互动域 | 收藏商品 | 一次收藏商品操作 | √ | √ | √ | 无事实(次数1) | ||||||||
| 评价 | 一次取消收藏商品操作 | √ | √ | √ | 无事实(次数1) |
5.2.4 明确统计指标
明确统计指标的工作 : 深入分析需求，构建指标体系
构建指标体系的主要意义 : 指标定义标准化
所有指标的定义，都必须遵循同一套标准，这样能有效的避免指标定义存在歧义，如 : 指标定义重复
5.2.4.1 指标体系相关概念
- 原子指标
- 派生指标
- 衍生指标
5.2.4.1.1 原子指标
原子指标基于某一业务过程的度量值，是业务定义中不可再拆解的指标
原子指标的核心功能 : 对指标的聚合逻辑进行了定义
原子指标三要素 :
- 业务过程
- 度量值
- 聚合逻辑
例子 : 订单总额就是一个典型的原子指标
- 业务过程 : 用户下单
- 度量值 : 订单金额
- 聚合逻辑 : sum() 求和
原子指标只是用来辅助定义指标一个概念，通常不会对应实际统计需求
5.2.4.1.2 派生指标
派生指标基于原子指标
与原子指标的关系 :
与原子指标不同，派生指标通常会对应实际的统计需求
5.2.4.1.3 衍生指标
衍生指标 : 在一个或多个派生指标的基础上，通过各种逻辑运算复合而成的
如 : 比率、比例等类型的指标。衍生指标也会对应实际的统计需求。
5.2.4.2 指标体系对于数仓建模的意义
很多统计需求，都可以使用原子指标、派生指标、衍生指标这套标准去定义
这些统计需求都直接或 间接 对应一个或 多个派生指标
当统计需求足够多时，必然会出现部分统计需求对应的派生指标相同的情况。该情况就可以将这些公共的派生指标保存下来，目的 : 减少重复计算，提高数据的复用性
这些公共的派生指标统一保存在数据仓库的 DWS 层。因此 DWS 层设计，就可以根据现有的统计需求整理出的派生指标
5.2.4.3 指标体系
最近1/7/30日各渠道访客数 :
从业务过程为页面浏览、统计周期为最近1/7/30日、统计粒度为会话的任一派生指标计算而来。统计时需要用到会话所属的渠道属性，和设备ID属性。
最近1/7/30日各渠道会话平均停留时长 :
该指标可以由最近1 / 7 / 30日的各会话停留总时长计算而来，计算是需要用到会话所属的渠道属性
最近1/7/30日各渠道会话平均浏览页面数 :
由最近1/7/30日的各会话浏览页面数计算而来，计算时需要用到会话所属的渠道属性
最近1/7/30日各渠道总会话数 :
可由统计周期为最近1/7/30日，业务过程为页面浏览，统计粒度为会话 的任一派生指标计算而来。统计时需要用到会话所属的渠道属性。
最近1/7/30日各渠道跳出率 :
可由最近1/7/30日各会话浏览页面数统计而来。统计时需用到会话所属的渠道属性。
最近1/7/30日页面浏览路径分析(各跳转次数) :
流失用户数 :
回流用户数 :
用户新增留存率 :
最近1/7/30日新注册用户数 :
最近1/7/30日活跃用户数 :
漏斗分析 :
最近1/7/30日新增下单用户数 :
最近1/7/30日新增支付用户数 :
最近 1 / 7 / 30 日各年龄段下单人数 :
可由各用户末次下单时间计算而来，计算时需要使用用户维度的年龄属性
最近7/30日各品牌复购率 :
可由最近30日各用户购买各商品次数统计而来，统计时需要使用商品维度的品牌属性
最近1/7/30日各品牌商品订单数 :
可由最近30日各用户购买各商品次数统计而来，统计时需要使用商品维度的品牌属性
最近1/7/30日各品牌商品订单人数 :
可由最近30日各用户购买各商品次数统计而来，统计时需要使用商品维度的品牌属性
5.2.4.4 派生指标
| 原子指标 | 统计周期 | 业务限定 | 统计粒度 | ||
|---|---|---|---|---|---|
| 业务过程 | 度量值 | 聚合逻辑 | |||
| 页面浏览 | * | * | 最近1/7/30日 | 会话 | |
| during_time | sum() | 最近1/7/30日 | 会话 | ||
| 1 | count() | 最近1/7/30日 | 会话 | ||
| * | * | 最近1/7/30日 | 会话 | ||
| 1 | count() | 最近1/7/30日 | 会话 | ||
| 1 | count() | 最近1/7/30日 | 访客-页面 | ||
| 1 | count() | 最近1/7/31日 | 访客-页面 | ||
| 用户登录 | date_id | max() | 历史至今 | 用户 | |
| date_id | max() | 历史至今 | 用户 | ||
| date_id | max() | 历史至今 | 用户 | ||
| date_id | max() | 历史至今 | 用户 | ||
| 加购 | 1 | count() | 最近1/7/30日 | 用户 | |
| 下单 | 订单金额 | sum() | 最近1/7/30日 | 用户 | |
| order_id | count(distinct()) | 最近1/7/30日 | 用户 | ||
| order_id | count(distinct) | 最近1/7/30日 | 用户 | ||
| order_id | count(distinct) | 最近1/7/30日 | 用户 | ||
| date_id | min() | 历史至今 | 用户 | ||
| date_id | max() | 历史至今 | 用户 | ||
| 1 | count() | 最近30日 | 用户-商品 | ||
| 1 | count() | 最近1/7/30日 | 用户-商品 | ||
| 1 | count() | 最近1/7/30日 | 用户-商品 | ||
| 1 | count() | 最近1/7/30日 | 用户-商品 | ||
| 1 | count() | 最近1/7/30日 | 用户-商品 | ||
| order_id | count(distinct) | 最近1/7/30日 | 省份 | ||
| 订单金额 | sum() | 最近1/7/30日 | 省份 | ||
| 订单原始金额 | sum() | 最近30日 | 订单使用优惠券(coupon_id不为null) & 优惠券发布日期在最近30日内 | 优惠券 | |
| 优惠券优惠金额 | sum() | 最近30日 | 订单使用优惠券(coupon_id不为null) & 优惠券发布日期在最近30日内 | 优惠券 | |
| 订单原始金额 | sum() | 最近30日 | 订单参与活动(activity_id不为null) & 活动的发布日期在最近30日内 | 活动 | |
| 活动优惠金额 | sum() | 最近30日 | 订单参与活动(activity_id不为null) & 活动的发布日期在最近30日内 | 活动 | |
| 退单 | 1 | count() | 最近1/7/30日 | 用户-商品 | |
| 1 | count() | 最近1/7/30日 | 用户-商品 | ||
| 1 | count() | 最近1/7/30日 | 用户-商品 | ||
| 1 | count() | 最近1/7/30日 | 用户-商品 | ||
| 1 | count() | 最近1/7/30日 | 用户 | ||
| 1 | count() | 最近1/7/30日 | 用户 | ||
| 支付 | date_id | min() | 历史至今 | 用户 | |
| order_id | count(distinct()) | 最近1/7/30日 | 用户 |
5.2.5 维度模型设计
- 事实表存储在 DWD 层
- 维度表存储在 DIM 层
5.2.6 汇总模型设计
汇总表与派生指标的对应关系 : 一张汇总表通常包含业务过程相同、统计周期相同、统计粒度相同的多个派生指标
永洪科技，致力于打造全球领先的数据技术厂商，具备从数据应用方案咨询、BI、AIGC智能分析、数字孪生、数据资产、数据治理、数据实施的端到端大数据价值服务能力。
更多推荐
1
0- 0
已为社区贡献2条内容
所有评论(0)