导读: 在Kimball维度建模中,通常将度量称为“事实”,将环境描述为“维度”,维度是用于分析事实所需要的多样环境。维度和维度属性是维度的两个核心概念,如何构建维度的属性是维度设计中需要关注的。 作为维度建模的核心,我们在企业级的数据仓库中必须保证维度的唯一性。以淘宝商品维度为例,我们有且只允许有一个维度定义。 第二步:确定主维度表。 二、第二部分 在Kimball维度建模中,通常将度量称为“事实”,将环境描述为“维度”,维度是用于分析事实所需要的多样环境。 02 快照维表 维度的基本概念中介绍了自然键和代理键的定义,在Kimball的维度建模中,必须使用代理键作为每个维度表的主键,用于处理缓慢变化维度。 但在阿里巴巴数据仓库建设的实践过程中,虽然我们使用的是Kimball的维度建模的理论,但实际并未使用代理键。我们是如何处理缓慢变化维度,如何记录变化历史的呢?为什么不使用代理键呢?
而维度建模解决了模式过分复杂的问题。 我们换一种方式来解释什么是维度建模。学过数据库的童鞋应该都知道星型模型,星型模型在数据仓库的设计中可以为是一种典型的维度模型。 0x02 基本概念 维度建模中有一些比较重要的概念,理解了这些概念,基本也就理解了什么是维度建模。 为了便于理解,我们先假设一个业务场景:聊天! 比如短信聊天、软件聊天这些聊天场景。 我们可以回过头再看一下事实表的特征,在维度表里没有存放实际的内容,他是一堆主键的集合,这些ID分别能对应到维度表中的一条记录。 2. 维度表 每个维度表都包含单一的主键列。 0x03 实践 下面我们将以聊天场景为例,详细讲一下维度建模的建模方式,并举例如果使用这个模型(这点还是很重要的)。 维度模型在很多开源的系统都中都有支持,比如Kylin,在建模的时候就是用的维度建模中的星型模型,当然在最新版本中也支持了雪花模型。
这篇文章的观点可谓惊人:维度数据建模已死! ,维度数据建模更是其数据分析和建模的核心理念。 感兴趣的同学可以读下《数据仓库工具箱:维度建模权威指南》和阿里巴巴的《大数据之路》,从这两本书可以了解到维度数据建模的理论和工程实践。 维度数据建模起源于数据仓库权威专家 Ralph Kimball,虽然很多人说维度数据建模有很多种优点,但是作者认为其核心的优点有三个:优化计算、按主题组织数据和优化存储。 这些优点在历史上推动了维度数据建模在数据仓库领域的发展,吸引了很多人,但是站在此时此刻(2022年),我们需要重新审视为什么维度数据建模会存在和它是如何从根本上满足我们的需求的。
建模方法论 今天我们主要介绍常见的建模方法,这也就是我们今天文章的名称——建模方法论 20年前兴起的数据仓库简单的可分为两大流派,Inmon方法和Kimball方法,分别由 Ralph Kimbal和Bill 区别的关键在于如何在数据仓库中建模、加载和存储数据的方式。而由此出发的不同架构影响到了数据仓库的建设成本和到适应用户不断变化的ETL逻辑的能力。 建模的目的 数仓的建模或者分层,其实都是为了更好的去组织、管理、维护数据,所以当你站在更高的维度去看的话,所有的划分都是为了更好的管理。
维度建模方法 一、前言 本人学习《数仓工具箱》的学习总结,纯学习分享,供大家参考。 ---- 二、经典数仓架构理论 围绕着维度建模,那就不得不了解,早期的数据仓库构架方法。 参考:深入对比数据仓库模式:Kimball vs Inmon 三、维度建模步骤 3.1、设计企业服务总线 需要调查业务过程以及业务过程所涉及的公共维度。 维度建模是紧贴业务的,所以必须以业务为根基进行建模,那么选择业务过程,顾名思义就是在整个业务流程中选取我们需要建模的业务,根据运营提供的需求及日后的易扩展性等进行选择业务。 当然一个维表里可以只对某几个属性变更采用类型2) 类型3:增加新列 案例:维度属性每次发生一次变更,我们通过新增一条记录的方式来保留历史数据,但其缺点也比较明显。 对于数据量比较大的维度表来说,采用类型2就有些笨拙了,特别是对于属性指标分组的分析场景下就不太适用新增行记录的方式了。
01 为什么要维度建模? 维度建模:维度建模是从分析的角度,将业务数据重新按照事实和维度的形式进行组合,用于度量某个业务过程 朴素维度建模方法 面向原系统维度建模方法 面向业务看流程维度建模方法 05 常用名词? ,可以进行聚合和计算,例如下单金额 06 维度建模四个步骤? 持久建:始终保持不变,不受业务变更影响 超自然建:一般在多个系统融合时的用的比较多,例如,原系统编码+原系统自然建拼接为超自然建或者联合主键 智能建:具有股东的预先可确定行,如 yyyyMMdd (2) 包括,单事务事实表、多事务事实表 (2)周期快照事实表:用于观察某个业务某个固定周期内的累计度量,最简单的一个按理为门店商品库存周期快照事实表 (3)累计快照事实表:用于定义过程开始,结束以及期间的可区分的里程碑
01 为什么要维度建模? 维度建模:维度建模是从分析的角度,将业务数据重新按照事实和维度的形式进行组合,用于度量某个业务过程 朴素维度建模方法 面向原系统维度建模方法 面向业务看流程维度建模方法 05 常用名词? ,可以进行聚合和计算,例如下单金额 06 维度建模四个步骤? 持久建:始终保持不变,不受业务变更影响 超自然建:一般在多个系统融合时的用的比较多,例如,原系统编码+原系统自然建拼接为超自然建或者联合主键 智能建:具有股东的预先可确定行,如 yyyyMMdd (2) 包括,单事务事实表、多事务事实表 (2)周期快照事实表:用于观察某个业务某个固定周期内的累计度量,最简单的一个按理为门店商品库存周期快照事实表 (3)累计快照事实表:用于定义过程开始,结束以及期间的可区分的里程碑
前言 维度表是维度建模的灵魂所在,在维度表设计中碰到的问题(比如维度变化、维度层次、维度一致性、维度整合和拆分等)都会直接关系到维度建模的好坏,因此良好的维表设计就显得至关重要,今天就让我们就一起来探究下关于维表设计的相关概念和一些技术 因此在维度建模中,这一现象称为缓慢变化的维度,简称 缓慢变化维(slowly changing dimension, SCD)。 因此维度设计人员只在必要情况下使用此方法,同时需要告知下游分析人员。 采用重写维度值方法的维度表和事实表变化如图: ? 采用重写维度值方法处理变化维示例 2. 那么维度建模如何处理这些层次结构呢? 在维度建模中,我们采用第一种来处理维度的层级问题,这样反规范化的处理牺牲了部分存储,但是给用户使用带来了便捷,也降低了学习使用成本。
维度建模以分析决策的需求为出发点构建模型,一般有较好的大规模复杂查询的响应性能,更直接面向业务,典型的代表是我们比较熟知的星形模型,以及在一些特殊场景下适用的雪花模型。 但Inmon和kimball关于关系建模和维度建模的争论其实也没什么值得探讨的,没有谁更好,在企业内,这两种建模方式往往同时存在,底层用关系建模合适一点,技术的优雅换来了数据的精简,往上维度建模更合适一些 ,靠数据的冗余带来了可用性,优势互补,都说关系建模不易,概念模型是个坎,其实维度建模也不易,维度的梳理和运营是艰巨的,否则就是烂摊子的活。 在数据建模上,很多人纠结于如何建模,用关系建模、维度建模亦或其它? 很多企业花了巨大的代价建设了一套数据模型,周期长达1-2年,几年后却推倒重来,问题的根子不在于当初的项目完成的情况如何,包括建模方式是否合理,而在于项目完成了成鸟兽散,缺乏持续的运营。
文章目录 前言 维度建模关键概念 度量和环境 事实和维度 事实表 维度表 星形架构和雪花架构 维度建模一般过程 1. 选取业务过程 2. 定义粒度 3. 确定维度 4. 维度建模关键概念 度量和环境 维度建模是支持对业务过程的分析,所以它是通过对业务过程度量进行建模来实现的。 那么,什么是度量呢? 度量和环境这两个概念构成了维度建模的基础。而所有维度建模也正是通过对度量和 及其上下文和环境的详细设计来实现的。 维度建模一般过程 维度建模一般采用具有顺序的 个步骤来进行设计,即选择业务过程、定义粒度、确定维度和确定事实。 维度建模的这 个步骤贯穿了维度建模的整个过程和环节,下面逐一介绍。 1. 因此,确保数据一致性的最佳办法是从企业和公司全局与整体角度,对于某一个业务过程建立单一的、一致的维度模型。 2.
维度建模理论之维度表一、维度表概述维度表是维度建模的基础和灵魂。前文提到,事实表紧紧围绕业务过程进行设计,而维度表则围绕业务过程所处的环境进行设计。 2、确定主维表和相关维表此处的主维表和相关维表均指业务系统中与某维度相关的表。 维度属性的丰富程度直接影响到数据模型能够支持的指标的丰富程度。(2)尽量不使用编码,而使用明确的文字说明,一般可以编码和文字共存。 2、维度变化维度属性通常不是静态的,而是会随时间变化的,数据仓库的一个重要特点就是反映历史的变化,所以如何保存维度的历史状态是维度设计的重要工作之一。 第一种:将多值属性放到一个字段,该字段内容为key1:value1,key2:value2的形式,例如一个手机商品的平台属性值为“品牌:华为,系统:鸿蒙,CPU:麒麟990”。
分类目录:商业智能《维度建模》总目录 本文是《维度建模》后续文章的基础。 《维度建模》系列文章将紧紧抓住业务需求这一要点,逐步深入探讨逻辑设计、物理设计以及采用有关技术和工具的决策等问题。 基于此背景,我们将探索维度建模核心概念并建立基本词汇表。 下一篇文章将总结针对维度建模的诸多错误理解,并解释为什么在处理DW/BI项目时,既需要从数据库管理员的角度,也需要从商业分析师的角度考虑问题。 数据仓库与商业智能的目标 在开始深入研究维度建模的细节前,关注数据仓库与商业智能的基本目标是非常有益的。
发展至今以维度建模和关系建模为主,而随着互联网的发展,数据从GB到PB的裱花,企业业务迭代更新亦是瞬息万变,对维度模型的偏爱渐渐有统一互联网数仓建模标准的趋势。 维度模型以实体与实体之间发生的事务/实为切入,而关系建模则以实体与实体之间的关系来组织数据。在当前的环境下,互联网更倾向于维度建模,而传统行业则较多沿用关系建模。 模型理念 维度建模 以事实表为核心,多个维度表作为手臂形成的星型模型,是维度建模的典型实现方式。 建模实现的对比 维度建模:从实际的需求出发进行数据建设,一般面向部门/业务形成独立的数据集市,这样的方式带来鲜明的特点,高效。 从建模风格上看,它采用了一种由第三范式方法与维度建模方法混合而成的方式,以二者的独特组合来满足企业需求。
2、维度建模是面向分析场景而生,针对分析场景构建数仓模型;重点关注快速、灵活的解决分析需求,同时能够提供大规模数据的快速响应性能。针对性强,主要应用于数据仓库构建和OLAP引擎低层数据模型。 2、声明粒度 粒度传递的是与事实表度量有关的细节级别。 精确定义某个事实表的每一行表示什么。 对事实表的粒度要达成共识。 3、确认维度 健壮的维度集合来粉饰事实表。 如果只是依靠单纯的维度建模,不能保证数据来源的一致性和准确性,而且在数据仓库的底层,不是特别适用于维度建模的方法。 1、维度建模是以某一个既定的事实为依据,既然是事实表,那么这块的业务如果不变动的情况下,事实表的粒度基本不会改变; 2、事实表和维度表解耦,维度表的变更事实表基本不会影响,结果表也只需要回刷一下数据流程即可 2、派生指标=维度+原子指标+修饰词。当维度,原子指标,修饰词都确定的时候就可以唯一确定一个派生指标,同时给出具体数值。
今天我们就来聊下这两种建模方式——范式建模和维度建模。 本文开始先简单理解两种建模的核心思想,然后根据一个具体的例子,分别使用这两种建模方式进行建模,大家便会一目了然! 城市ID 省 市 0310 河北 邯郸 0311 河北 石家庄 0312 河北 保定 0313 河北 张家口 ④ 用户等级维度表 用户等级ID 价值属性 1 重要价值用户 2 一般价值用户 3 一般发展用户 在限定的维度条件上,计算商品单价的总和,也就是 sum 度量值,即可得到我们想要的结果。 ---- 维度建模,就是依靠维度进行建模,但是如果维度设计的不合理,会不会带来问题呢? 所以,互联网公司更多场景下趋向于使用 Kimball 维度-事实的设计反而可以更快地完成任务。 四、两种建模混合场景 通过以上几个小节我们已经理解了范式建模与维度建模的思想以及它们之间的异同,优缺点。 利用维度建模方法建设数据集市。
2、各种数据建模方法:如维度建模、范式建模法、实体建模法。 3、辅助系统:调度系统、元数据系统、ETL系统、可视化系统这类辅助系统。 接下来具体来了解维度建模 一、什么是维度建模 维度模型是数据仓库领域大师Ralph Kimball 所倡导,他的《数据仓库工具箱》,是数据仓库工程领域最流行的数仓建模经典。 星型模型 二、维度建模的基本要素 维度建模中有一些比较重要的概念,理解了这些概念,基本也就理解了什么是维度建模。 1. 我们可以回过头再看一下事实表的特征,在事实表里没有存放实际的内容,他是一堆主键的集合,这些ID分别能对应到维度表中的一条记录。 2. 维度表 每个维度表都包含单一的主键列。 1、数据冗余小(因为很多具体的信息都存在相应的维度表中了,比如客户信息就只有一份) 2、结构清晰(表结构一目了然) 3、便于做OLAP分析(数据分析用起来会很方便) 4、增加使用成本,比如查询时要关联多张表
一、前言 四步过程维度建模由Kimball提出,可以做为业务梳理、数据梳理后进行多维数据模型设计的指导流程,但是不能作为数据仓库系统建设的指导流程。本文就相关流程及核心问题进行解读。 图1 数据仓库系统建设流程 三、四步维度建模 Kimball四步建模流程适合上述数据仓库系统建设流程中模型设计环节,重点解决数据粒度、维度设计和事实表设计问题。四步建模流程如下图所示: ? 3.1 如何标识维度 标识维度解决的是业务人员如何描述来自业务过程的数据,维度用来表示“谁、什么、何时、何处、为何、如何”的问题。
01 数仓建模综述 数据建模是数据开发工作中的核心与基石,好的模型体系好处很多: 降低成本:优秀的模型设计能够提升数据复用性,减少计算/存储资源浪费 提升开发效率:优秀的模型设计能够降低数据使用门槛,减少工作量 目前业界使用最多的模型是Ralph Kimball 在《数据仓库工具》中提出的维度建模模型,其中典型的代表如星型模型,雪花模型。 一个典型的维度建模一般需要经过如下几个步骤: 业务调研:调研需要建模的业务形态,划分基本的业务线/数据域 层次设计:定义数仓层级,保证各层级之间职责明确,划分清晰 规范设计:定义数仓中表/字段的命名规范 因此在数仓建模的时候应该考虑将两者维护在同一个数据仓库之下,减少重复开发。 功能模块 用户 视频 广告主 广告订单 跳转页 广告点击 ⭕️ ⭕️ ⭕️ ⭕️ ⭕️ 广告转化 ⭕️ ⭕️ ⭕️ ⭕️ ⭕️ 广告曝光 ⭕️ ⭕️ ⭕️ ⭕️ ❌ 2.
详细介绍维度建模的基本概念以及相关理论。 为了能更真切地理解什么是维度建模,我将模拟一个大家都十分熟悉的电商场景,运用前面讲到的理论进行建模。 一、什么是维度建模 维度模型是数据仓库领域大师Ralph Kimall所倡导,他的《数据仓库工具箱》,是数据仓库工程领域最流行的数仓建模经典。 维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能。 我们换一种方式来解释什么是维度建模。 那么什么是事实表、什么又是维度表吗,下面会专门来解释。 二、维度建模的基本要素 维度建模中有一些比较重要的概念,理解了这些概念,基本也就理解了什么是维度建模。 1. 我们可以回过头再看一下事实表的特征,在维度表里没有存放实际的内容,他是一堆主键的集合,这些ID分别能对应到维度表中的一条记录。 2. 维度表 每个维度表都包含单一的主键列。
事实表是维度建模的核心表和基本表。 它存储了业务过程中的各种度量和事实,而这些度量和事实正是下游数据使用人员所要关心和分析的对象。 事务事实表 事务事实表是维度建模事实表中最为常见、使用最为广泛的事实表。 事务事实表通常用于记录业务过程的事件,而且是原子粒度的事件。 理解概念的最佳途径无疑是实际的例子,因此下面将结合超市零售业务以及维度建模的四个环节来说明事务事实表。 (2)定义粒度 累计周期快照事实表的粒度一般很容易确定,就是业务的某个实体,这里即为保险理赔申请。 以学生在各门课程中的出席情况为例给出无事实的事实表的维度设计方案: ? 总结 在经典的维度建模事实表设计中,事实表将仅存储维度表外键、选定的度量以及退化维度等,例如我们前面提到的超市零售事务事实表。