维度表
事实表
明细事实表
事务事实表
周期快照事实表
累计快照事实表
汇总事实表
lyw个人感觉部分周期快照事实表也属于汇总事实表
指标体系解析
派生指标 = 一个原子指标+多个修饰词(可选)+时间周期
派生指标唯一归属一个原子指标，继承原子指标的数据域， 与修饰词的数据域无关
例如：
原子指标: 支付金额
派生指标: 最近1天海外买家支付金额则
"最近 1 天"为时间周期
"海外"为修饰词
"买家"作为维度 而不作为修饰词
买家在表中通过 uid 等字段存放，作为维度字段
派生指标的种类
事务型指标
e.g., 用户uid 在 timestamp 时刻 消费了3RMB
存量型指标
e.g., 商品数量
复合型指标 是在事务型指标和存量型指标的基础上复合而成的
e.g., 浏览UV-下单买家数转化率
维度是度量的环境
对于电商来说可以有样例：
维度： 买家 卖家 商品 时间等
度量： 金额
关于 「维度」 和 「维度属性」
维度：商品
维度属性：商品id 商品名称 类目id 类目名称 行业id 行业名称
区分数值型属性和事实
数值型宇段是作为事实还是维度属性，可以参考字段的一般用途。
如果通常用于查询约束条件或分组统计，则是作为维度属性;
如果通常 用于参与度量的计算， 则是作为事实。
维度整合
垂直整合
不同的来源表包含相同的数据集（维度、主键），只是存储的信息（属性）不同
样例
淘宝会员在源系统中有会员基础信息表、 会员扩展信息表、淘宝会员等级信息表、天猫会员等级信息表等
这些表包含相同的用户（会员）范围，且都属于会员相关信息表，依据维度设计方法，尽量整合至会员维度模型中，丰富其维度属性。
一句话解释：通过 join/group 合并多个表的字段制作成宽表（增加字段），且因为多个表的主键范围一致，最终所有字段的覆盖率都较高
水平整合
不同的来源表包含不同的数据集，不同子集之间无交叉，也可以存在部分交叉。
样例
移动端用户访问记录 UNOIN ALL
web端用户访问记录 UNOIN ALL
pc 端用户访问记录 UNOIN ALL
一句话解释：通过 union 合并多个表
特殊维度
多值属性
举例来说商品维度下的商品SKU
方案1： 商品id [sku1, sku2, …, sku_n]
维度主键不变，将多值属性放在维度的一个属性字段中，可以压缩为属性、json等
使用复杂的「数据结构」
方案2： 卖家id 主营类目1_id 主营类目2_id 主营类目3_id
维度主键不变，将多值属性放在维度的 多个属性字段中
此处业务限制了主营类目的个数只有top3 所以刚好可以使用3字段来表示多值属性
新增字段「横向扩展」
方案3：比如商品 SKU 维表，对于每个商品，有多少 SKU，就有多少记录，主键是(商品_ID, SKU_ID)
维度主键发生变化，一个维度值存放多条记录。
新增记录数「纵向扩展」
事实表基础
度量的可加性
可加性
可加事实指的是该度量可以按照和事实表关联的任一维度进行汇总。
例如消费金额
半可加性
该度量在某些维度下不可进行汇总，或者说汇总起来没有意义
例如库存这个度量，只能按地点、商品累加，不能在时间维度上累加
最好处理成可加性事实度量
不可加性
该度量在所有与该事实表关联的维度下都不可进行汇总
通常来说比率型事实不可加，偶尔有例外： 华北地区占全国的销量占比 + 华东地区占全国的销量占比
最好处理成可加性事实度量
稀疏表/稠密表
稀疏表：当天只有发生了操作才会有记录
稠密表：当天没有操作也会有记录，便于下游使用
事务事实表是稀疏的，只有当天发生的业务过程，事实表才会记录该业务过程的事实
周期快照事实表是稠密的，无论当天是否有业务过程发生，都会记录一行，比如针对卖家的历史至今的下单和支付金额，无论当天卖家是否有下单支付事实，都会给该卖家记录一行
事务事实表
事实表记录了特定事件的数字化的度量，一般由 度量（数字值） 和 指向维度表的外键 组成
维度是度量的环境，如用户、日期、产品、地理位置等描述信息
事实可以是登录、登出、进入房间、退出房间、下单、支付
单事务事实表
多事务事实表
当不同业务过程的度量差异较大时，不同业务过程的事实使用不同的事实字段进行存放
淘宝交易事务事实表中同时包含了下单、支付和成功完结三个业务过程，这三个业务过程都是子订单粒度，比较适合放到同一个事实表中。
子订单ID 下单度量 支付度量 成功完结度量 下单时间 支付时间 成功完结时间 买家ID 卖家ID 商品ID
样例，下单、支付、发货、确认收获会获得4条记录
pt/ds 子订单id 用户id 下单日期 支付日期 发货日期 确认收货日期 订单金额 支付金额 ...
20200615 1001 1234 2020-06-14 null null null 1000 null
pt/ds 子订单id 用户id 下单日期 支付日期 发货日期 确认收货日期 订单金额 支付金额 ...
20200616 1001 1234 2020-06-14 2020-06-15 null null 1000 1000
pt/ds 子订单id 用户id 下单日期 支付日期 发货日期 确认收货日期 订单金额 支付金额 ...
20200617 1001 1234 2020-06-14 2020-06-15 2020-06-16 null 1000 1000
pt/ds 子订单id 用户id 下单日期 支付日期 发货日期 确认收货日期 订单金额 支付金额 ...
20200618 1001 1234 2020-06-14 2020-06-15 2020-06-16 2020-06-17 1000 1000
当不同业务过程的度量比较相似、差异不大时，使用同一个字段来表示度量数据，额外补充一个字段标记业务过程
例如收藏商品、取消收藏商品，两个业务过程描述字段相似所以存在一张事实表中，额外补充一个字段”动作类型“用于标记是收藏还是删除
周期快照事实表
可以从事务事实表中聚合获得
例如CC直播的td历史表，截止今日的用户观看时长、消费金额
可以周期性从软件数据库中定期同步过来
比如用户等级、淘宝卖家星级等
累计快照事实表
累积快照事实表适用于具有较明确起止时间的短生命周期的实体， 比如交易订单、物流订单等，对于实体的每一个实例，都会经历从诞生到消亡等一系列步骤。
对于商品、用户等具有长生命周期的实体， 一般采用周期快照事实表更合适。
不同于多事务事实表，对于上述淘宝交易的业务过程，累积快照事实表随着子订单1001下单、支付、发货、确认收货的进展只保留并更新一条记录：
pt/ds 子订单id 用户id 下单日期 支付日期 发货日期 确认收货日期 订单金额 支付金额 …
20200618 1001 1234 2020-06-14 2020-06-15 2020-06-16 2020-06-17 1000 1000
无事实事实表
登录、登出日志文章来源：https://www.toymoban.com/news/detail-607402.html
聚集型事实表
例如CC直播数据仓库中的混合维度每天快照事实表 dw.dwm_usr_view_1d，维度是 (每天,用户id,主播id,房间id,频道id,品类id…)
对应 dwm,dws 汇总事实表/公共汇总层文章来源地址https://www.toymoban.com/news/detail-607402.html
到了这里，关于《大数据之路》的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
