数仓:事实表设计方法,原则和三种类型选择

面经总结(大数据开发相关) 整理收集一些面试遇到的简单问题 阅读详情

在这里插入图片描述
关注公众号,回复关键字 【资料】,获取【10万字大数据框架面试知识点】与【大数据开发的命令手册】

事实表设计方法

事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设计。其包含与该业务过程有关的维度引用(外键)以及该业务过程的度量。
一般设计会遵循以下四个步骤:

1. 选择业务过程及确定事实表类型

通常情况下,一个业务过程对应一张事实表。

2. 声明粒度

精确定义每张事实表的每行数据表示什么,按照业务尽可能选择最细粒度,以此来应各种细节程度的需求。

3. 确定维度

确定与每张事实表相关的维度有哪些? 维度的丰富程度就决定了模型能够支持的指标丰富程度。

4. 确定事实

每个业务过程的度量值(通常是可累加的数字类型的值,例如:次数、个数、件数、金额等)。细分如下:

(1)可加事实

可加事实是指可以按照与事实表相关的所有维度进行累加,例如事务型事实表中的事实。

(2)半可加事实

半可加事实是指只能按照与事实表相关的一部分维度进行累加,例如周期型快照事实表中的事实。比如库存,库存事实可以按照仓库或者商品维度进行累加,但是不能按照时间维度进行累加,因为将每天的库存累加是不科学的。

(3)不可加事实

不可加事实是指完全不具备可加性,例如比率型事实。不可加事实通常需要转化为可加事实,例如比率可转化为分子和分母。

开发指标过程中,指标定义总结以下公式(仅供参考)

指标 = 维度 + 度量 + (条件)

其中度量:基于事实表中可以进行统计的数据属性,如: 金额, 次数等。

映射到SQL就是

select 度量 from table where 条件 group by 维度

事实表设计原则

  1. 尽可能包含所有与业务过程相关的事实
  2. 只选择与业务过程相关的事实
  3. 分解不可加性事实为可加的组件
  4. 在选择维度和事实之前必须先声明粒度
  5. 在同一个事实表中不能有多种不同粒度的事实
  6. 事实的单位要保持一致
  7. 对事实的 null 值要处理
  8. 使用退化维度提高事实表的易用性
什么是维度退化?

维度退化的维度表可以被剔除,从而简化维度数据仓库的模式。因为简单的模式比复杂的更容易理解,也有更好的查询性能。
当一个维度没有数据仓库需要的任何数据时就可以退化此维度。需要把维度退化的相关数据迁移到事实表中,然后删除退化的维度。
维度属性也可以存储到事实表中,这种存储到事实表中的维度列被称为“维度退化”。与其他存储在维表中的维度一样 , 维度退化也可以用来进行事实表的过滤查询、实现聚合操作等。

比如说订单id,这种量级很大的维度,没必要用一张维度表来进行存储,而我们进行数据查询或者数据过滤的时候又非常需要,所以这种就冗余在事实表里面,这种就叫退化维度,citycode这种我们也会冗余在事实表里面,但是它有对应的维度表,所以它不是退化维度。

三种类型

事务型事实表

是什么

事务事实表用来记录各业务过程,跟踪时间上某点的度量事件,它保存的是各业务过程的原子操作事件,即最细粒度。

场景

事务型事实表可用于分析与各业务过程相关的各项统计指标,由于其保存了最细粒度的记录,可以提供最大限度的灵活性,可以支持无法预期的各种细节层次的统计需求。

不适合干什么

(1)存量型指标不适合

比如说商品库存,账户余额… 对于这种存在进进出出(加或减操作)不适合。
一张存储商品的进货的原子操作事件,一张存储商品出库的原子操作事件。如果要统计当日的库存又多少,这就需要对进货表和出库表进行操作,需要一正一反地区分对库存的影响。所以在写代码或者sql过程还是执行效率都会打折扣。

(2)多事务关联统计不适合

比如在订单中,建立了下单事务事实表和支付事务事实表,现在指标统计某个时间内用户下单到支付的时间间隔的平均值,这就需要这两个表的Join操作,然而,订单在大型公司属于达标,大表 Join 大表 你可想而知。

周期型快照事实表

周期快照事实表以具有规律性的、可预见的时间间隔来记录事实,一般周期可以是每天、每周、每月、每年等。主要用于分析一些存量型或者状态型指标

场景

存量型:例如对于商品库存、账户余额这些存量型指标,业务系统中通常就会计算并保存最新结果,所以定期同步一份全量数据到数据仓库,构建周期型快照事实表,就能轻松应对此类统计需求。

状态型:例如对于空气温度、行驶速度这些状态型指标,由于它们的值往往是连续的,我们无法捕获其变动的原子事务操作,所以无法使用事务型事实表统计此类需求。而只能定期对其进行采样,构建周期型快照事实表。

累积型快照事实表

用来描述过程开始和结束之间的关键步骤事件,覆盖过程的整个生命周期,通常具有多个时间字段来记录关键时间点,当过程随着生命周期不断变化时,记录也会随着过程的变化而被修改。

场景

如交易流程中的下单、支付、发货、确认收货业务过程。会具体记录下单时间,支付时间,发货时间,收获时间。如果统计某个时间内用户下单到支付的时间间隔的平均值。这样就轻松搞定。

对比

-事务型事实表周期型事实表累积型快照事实表
时间离散事务时间每天、每周、每月、每年等多个时间字段来记录关键时间点
粒度每行代表实体的一个事务每行代表某时间周期的一个实体每行代表一个实体的生命周期
数据加载方式insertinsertinsert/update
一篇文章搞懂数据仓库:三种事实表(设计原则,设计方法、对比) 粒度是一个订单一行数据,创建订单时间,付款时间,发货时间,收货时间,分别作为一个字段,便于计算不同业务过程的时间间隔。事实表作为数据仓库维度建模的核心,紧紧围绕着业务过程来设 计,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度 和与业务过程有关的度量。订单支付金额和订单票数,两个事实的粒度为 “订单级”,属于上一层订单级数据,与 “票级” 事实表的粒度不一致,且不能进行汇总;如,订单金额、订单优惠金额、订单运费这 3 个事实,应该采用统一的计量单位,统一为元或者分,以方便使用; 阅读详情

相关推荐

精选Flink面试题

精选Flink面试题

lbg20211023的博客 992

什么是退化维度?

退化维度的维度表可以被剔除,从而简化维度数据仓库的模式。因为简单的模式比复杂的更容易理解,也有更好的查询性能。 当一个维度没有数据仓库需要的任何数据时就可以退化此维度。需要把退化维度的相关数据迁移到事实表中,然后删除退化的维度。 维度属性也可以存储到事实表中,这种存储到事实表中的维度列被称为“退化维度”。与其他存储在维表中的维度一样 ,退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。那...

a6822342的博客 2万+

数仓理论及建模方法

1. 数仓概述 数据仓库: 数据仓库是一个面向主题的、集成的、非易失的、随时间变化的数据集合。重要用于组织积累的历史数据,并且使用分析方法(OLAP、数据分析)进行分析整理,进而辅助决策,为管理者、企业系统提供数据支持,构建商业智能。 面向主题:为数据分析提供服务,根据主题将原始数据集合在一起。 集成的:原始数据来源于不同的数据源,要整合成最终数据,需要经过 ETL(抽取、清洗、转换)的过程。 非易失:保存的数据是一系列历史快照,不允许被修改,只允许通过工具进行查询、分析。 时变性:数仓会定期接收、集成新的

weixin_47243236的博客 1万+

大数据知识点总结笔记 -- 应用篇

周末两天,继续整理了近些年从事大数据工作经验以及调优,本次主要针对一些Hive应用层面。 一、事实表分类 1. 事务型事实表 事务型事实表,一般指随着业务发生不断产生的数据。特点是一旦发生不会再变化。 一般比如,交易流水,操作日志,出库入库记录等等。 典型案例--交易流水表: 2. 周期型事实表 周期型事实表,一般指随着业务发生不断产生的数据。 与事务型不同的是,数据会随着业务周期性的推进而变化。 比如订单,其中订单状态会周期性变化。再比如,请假、贷款申请,随着批复状态在周期性变化。 .

zhanggf的博客 1286

数仓维度设计模型、事实表、维度表、指标、宽表,常见的三种维度建模设计——星型模型、雪花模型、星座模型

在很多时候维度空间内的事实表不止一个,而一个维表也可能被多个事实表用到。在业务发展后期,绝大部分维度建模都采用的是星座模式。

qq_40585384的博客 1万+

【数仓】数仓建模理论及步骤,ER建模,维度建模,星形模型,雪花模型,数据分层

数据仓库是一个面向主题、集成的、非易失的且随时间变化的数据集合。它主要用于组织、积累历史数据,并使用分析方法(如OLAP、数据分析)进行分析整理,以辅助决策,为管理者、企业系统提供数据支持、构建商业智能。 数据仓库的特点包括面向主题性、集成性、非易失性和时变性。 数仓建模的目标是在性能、成本、效率和数据质量之间找到最佳平衡点

不积跬步无以至千里,不积小流无以成江海。一个喜欢学习分享的程序员 6218

数仓设计_数仓中的三种事实表

事实表有三种类型 :

迎难而上 901

数据仓库—维度建模—事实表设计

顾客单次购买行为的体现是一张购物小票,但是事务事实表应该选择最原子粒度的事件,所以小票的子项(在业务上的动作即为收银员每次扫描的商品条码)应该是超市零售事务事实表的粒度。这里的粒度主要指库存的周期,商品的粒度很容易确定(注意这里是 SKU 级别)。选择库存的周期需要考虑到数据量膨胀情况。考虑如下例子,某个超市有 万个商品(即SKU), 其有 100 家连锁店,那么每天对其库存拍照将有 100_10000=100 万行记录,那么一年将有 365_1000000=3.65亿条记录。

2401_84052244的博客 4799

数仓进阶:详解维度建模之事实表

这类聚集汇总数据,被叫作。状态有变化,每天的分区存储昨天的全量数据和当天的增量数据合并的结果,对于数据量在可控范围内的情况可以采用如下 保存策略: 如果存储空间和成本可接受,完整存储,确保能够追溯到历史每天数据状态 存储空间有限,考虑移动历史快照数据到冷盘,需要使用的时候可恢复 数据历史状态数据无太大价值,可以考虑部分删除,比如近保留每月最后一天的快照数据。相对于明细事实表,聚合事实表通常是在明细事实表的基础上,按照一定的粒度粗细进行的汇总、聚合操作,它的粒度较明细数据粒度粗,同时伴随着细节信息的丢失;

m0_69632475的博客 1026

数仓建模—事实表和维度表设计规范

事实表和维度表设计规范 前面我们介绍了数仓建模—数仓开发规范,我们也介绍了事实表和维度表你可以参考数仓建模—事实表和数仓建模—维度表,但是我们的数仓设计其实很大一部分就是在设计维度表和事实表,所以我们这里就单独再看一下事实表和维度的设计规范和原则。 事实表设计规范 存储规范 明细层的表的类型为事实表,存储方式为按天分区。 事务型事实表一般永久保存。周期快照型事实表根据业务需求设置生命周期管理。您可依据3个月内的最大需要访问的跨度设置保留策略,具体计算方式如下: 当3个月内的最大访问跨度小于或等于4天时,建

6万+

数仓(六):数据建模之维度建模: 事实表&维度表设计

维度设计基本方法 1、设计步骤: 1)第一步:选择维度或新建维度。 作为维度建模的核心,在企业级数据仓库中必须保证维度的唯一性。以淘宝商品维度为例,有且只允许有一个维度定义。 2)第二步:确定主维表。 此处的主维表一般是 ODS 表,直接与业务系统同步。以淘宝商品维度为例,s_auction_ auctions是与前台商品中心系统同步的商品表,此表即是主维表。 3)第三步:确定相关维表。 数据仓库是业务源系统的数据整合,不同业务系统或者同一业务系统中的表之间存在关联性。根据对业务的梳理,确定哪些表和主维

. 8929

数仓建模—维度建模之事实表

顾客单次购买行为的体现是一张购物小票,但是事务事实表应该选择最原子粒度的事件,所以小票的子项(在业务上的动作即为收银员每次扫描的商品条码)应该是超市零售事务事实表的粒度。这里的粒度主要指库存的周期,商品的粒度很容易确定(注意这里是 SKU 级别)。选择库存的周期需要考虑到数据量膨胀情况。考虑如下例子,某个超市有 万个商品(即SKU), 其有 100 家连锁店,那么每天对其库存拍照将有 10010000=100 万行记录,那么一年将有 3651000000=3.65亿条记录。

2401_84052244的博客 3227

数仓建模—事实表

事实表 在ER模型中抽象出了有实体、关系、属性三种类别,在现实世界中,每一个操作型事件,基本都是发生在实体之间的,伴随着这种操作事件的发生,会产生可度量的值,而这个过程就产生了一个事实表,存储了每一个可度量的事件,所以事实表本质上是反映一个个事件的,例如下单事件,度量就是下单的金额,事实表的特点就是增长迅速,且主要以数值进行记录 在构建数据仓库总线矩阵完成后,可着手事实表和维度表的设计。 数仓总线矩阵里每个业务过程都会生成至少一张事实表(识别业务过程的本质就是识别要构建的事实表),因为有可能一个原子事件涉及

6万+

数仓事实表设计

事实表设计 数仓里面的事实表具体分为两大类: 明细事实表 聚合事实表 明细事实表 (dwd) 明细事实表: 事实表有粒度大小之分,基于数据仓库层次架构,明细事实表一般存在于dwd层,该层事实表设计 不进行聚合、汇总操作,仅做数据规范化、数据降维动作,同时数据保持业务事务粒度,确保数据信息 无丢失。 数据降维: (利用数据冗余来达到降维的目的,提高任务的执行效率) 为了提升模型易用性,将常规维度表中的常用的属性数据冗余到相应的事实表中,从而在使用的时候 避免维表关联的方式,

雾岛与鲸的博客 2313

数仓之事实表设计

事实表基础 特性 事实表是数据仓库维度建模的核心,与业务紧密相连,通过获取描述业务过程的度量来表达业务过程,包含了引用的维度和与过程有关的度量。 相对维表来说,通常事实表比维表细长得多,数据行的增加速度也比维表快。 维度属性也可以存储到事实表中,作为“退化维度”。退化维度可以作为事实表的过滤条件,实现聚合操作。主要是为了方便操作和使用,比如物联网数据中轨道电路的状态字段,调整和分路,这两个状态通常用来聚合和过滤。 事实表有三种类型:事务事实表、周期快照事实表、累积快照事

石榴姐yyds 1659

VSAN数据救援实战:当26个虚拟机突然不可访问时我们做了什么?

本文深度复盘了一次由运维操作失误引发的VMware vSAN存储危机,导致26个虚拟机数据不可访问的实战救援过程。文章详细剖析了vSAN脑裂状态的诊断方法,分享了在官方支持受限时,如何结合社区智慧与自主分析,通过精准的底层命令干预和状态推理,最终成功恢复全部数据的破局思路与操作细节,为vSAN数据救援提供了宝贵经验。

weixin_35749786的博客 239
上一篇: 数仓:用户行为类指标一网打尽
下一篇: 重回大学:CPU 核数 进程 线程 串行 并发 并行 同步 异步 你分清楚了吗?
大数据左右手
博客等级 码龄9年 475粉丝 116原创
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付:10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值