数仓中指标-标签,维度-度量,自然键-代理键,数据集市等各名词解析及关系

简介: 这是在数据分析中常见的概念,下钻可以理解成增加维的层次,从而可以由粗粒度到细粒度来观察数据,比如对产品销售情况分析时,可以沿着时间维从年到月到日更细粒度的观察数据。从年的维度可以下钻到月的维度、日的维度等。

作为一个数据人,是不是经常被各种名词围绕,是不是对其中很多概念认知模糊。有些词虽然只有一字之差,但是它们意思完全不同,今天我们就来了解下数仓建设及数据分析时常见的一些概念含义及它们之间的关系。


本文结构如下图所示:


77efb1f65105433ab8ce81453ce32a14.png


一、数仓中常见概念解析


1. 实体


实体是指依附的主体,就是我们分析的一个对象,比如我们分析商品的销售情况,如华为手机近半年的销售量是多少,那华为手机就是一个实体;我们分析用户的活跃度,用户就是一个实体。当然实体也可以现实中不存在的,比如虚拟的业务对象,活动,会员等都可看做一个实体。


实体的存在是为了业务分析,作为分析的一个筛选的维度,拥有描述自己的属性,本身具有可分析的价值。


2. 维度


维度就是看待问题的角度,分析业务数据,从什么角度分析,就建立什么样的维度。所以维度就是要对数据进行分析时所用的一个量,比如你要分析产品销售情况,你可以选择按商品类别来进行分析,这就构成一个维度,把所有商品类别集合在一起,就构成了维度表。


3. 度量


度量是业务流程节点上的一个数值。比如销量,价格,成本等等。


事实表中的度量可分为三类:完全可加,半可加,不可加。


1.完全可加的度量是最灵活,最有用的,比如说销量,销售额等,可进行任意维度汇总;


2.半可加的度量可以对某些维度汇总,但不能对所有维度汇总,差额是常见的半可加度量,它除了时间维度外,可以跨所有维度进行加法操作;


3.还有一种是完全不可加的,例如:比率。对于这类非可加度量,一种好的方法是,尽可能存储非可加度量的完全可加分量,并在计算出最终的非可加事实前,将这些分量汇总到最终的结果集中。


4. 粒度


粒度就是业务流程中对度量的单位,比如商品是按件记录度量,还是按批记录度量。


在数仓建设中,我们说这是用户粒度的事实表,那么表中每行数据都是一个用户,无重复用户;例如还有销售粒度的表,那么表中每行都是一条销售记录。


选择合适的粒度级别是数据仓库建设好坏的重要关键内容,在设计数据粒度时,通常需重点考虑以下因素:


1.要接受的分析类型、可接受的数据最低粒度和能存储的数据量;


2.粒度的层次定义越高,就越不能在该仓库中进行更细致的分析;


3.如果存储资源有一定的限制,就只能采用较高的数据粒度划分;


4.数据粒度划分策略一定要保证:数据的粒度确实能够满足用户的决策分析需要,这是数据粒度划分策略中最重要的一个准则。


5. 口径


口径就是取数逻辑(如何取数的),比如要取的数是10岁以下儿童中男孩的平均身高,这就是统计的口径。


6. 指标


指标是口径的衡量值,也就是最后的结果。比如最近七天的订单量,一个促销活动的购买转化率等。


一个指标具体到计算实施,主要有以下几部分组成:


  • 指标加工逻辑,比如count ,sum, avg


  • 维度,比如按部门、地域进行指标统计,对应sql中的group by


  • 业务限定/修饰词,比如以不同的支付渠道来算对应的指标,微信支付的订单退款率,支付宝支付的订单退款率 。对应sql中的where。


除此之外,指标本身还可以衍生、派生出更多的指标,基于这些特点,可以将指标进行分类:


  • 原子指标:基本业务事实,没有业务限定、没有维度。比如订单表中的订单量、订单总金额都算原子指标;


业务方更关心的指标,是有实际业务含义,可以直接取数据的指标。比如店铺近1天订单支付金额就是一个派生指标,会被直接在产品上展示给商家看。

但是这个指标却不能直接从数仓的统一中间层里取数(因为没有现成的事实字段,数仓提供的一般都是大宽表)。需要有一个桥梁连接数仓中间层和业务方的指标需求,于是便有了派生指标


  • 派生指标:维度+修饰词+原子指标。店铺近1天订单支付金额中店铺是维度,近1天是一个时间类型的修饰词,支付金额是一个原子指标;


维度:观察各项指标的角度;

修饰词:维度的一个或某些值,比如维度性别下,男和女就是2种修饰词。


  • 衍生指标:比如某一个促销活动的转化率就是衍生指标,因为需要促销投放人数指标和促销订单数指标进行计算得出。


7. 标签


标签是人为设定的、根据业务场景需求,对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果,如网红、白富美、萝莉。对于有歧义的标签,我们内部可进行标签区分,比如:苹果,我们可以定义苹果指的是水果,苹果手机才指的是手机。


8. 自然键


由现实中已经存在的属性组成的键,它在业务概念中是唯一的,并具有一定的业务含义,比如商品ID,员工ID。


以数仓角度看,来自于业务系统的标识符就是自然键,比如业务库中员工的编号。


9. 持久键


保持永久性不会发生变化。有时也被叫做超自然持久键。比如身份证号属于持久键。


自然键和持久键区别:举个例子就明白了,比如说公司员工离职之后又重新入职,他的自然键也就是员工编号发生了变化,但是他的持久键身份证号是不变的。


10. 代理键


就是不具有业务含义的键。代理键有许多其他的称呼:无意义键、整数键、非自然键、人工键、合成键等。


代理键就是简单的以按照顺序序列生产的整数表示。产品行的第1行代理键为1,则下一行的代理键为2,如此进行。代理键的作用仅仅是连接维度表和事实表。


11. 退化维度


退化维度,就是那些看起来像是事实表的一个维度关键字,但实际上并没有对应的维度表,就是维度属性存储到事实表中,这种存储到事实表中的维度列被称为退化维度。与其他存储在维表中的维度一样,退化维度也可以用来进行事实表的过滤查询、实现聚合操作等。


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


12. 缓慢变化维


维度建模的数据仓库中,有一个概念叫Slowly Changing Dimensions,中文一般翻译成“缓慢变化维”,经常被简写为SCD。缓慢变化维的提出是因为在现实世界中,维度的属性并不是静态的,它会随着时间的流逝发生缓慢的变化。这种随时间发生变化的维度我们一般称之为缓慢变化维,并且把处理维度表的历史变化信息的问题称为处理缓慢变化维的问题,有时也简称为处理SCD的问题。


处理缓慢变化维的方法通常分为三种方式:


  • 第一种方式是直接覆盖原值。这样处理,最容易实现,但是没有保留历史数据,无法分析历史变化信息。第一种方式通常简称为“TYPE 1”。


  • 第二种方式是添加维度行。这样处理,需要代理键的支持。实现方式是当有维度属性发生变化时,生成一条新的维度记录,主键是新分配的代理键,通过自然键可以和原维度记录保持关联。第二种方式通常简称为“TYPE 2”。


  • 第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列,来记录该属性变化前的值,而本属性字段使用TYPE 1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值,缺点是只保留了最后一次变化信息。第三种方式通常简称为“TYPE 3”。


在实际建模中,我们可以联合使用三种方式,也可以对一个维度表中的不同属性使用不同的方式,这些,都需要根据实际情况来决定,但目的都是一样的,就是能够支持方便的分析历史变化情况。


13. 微型维度


维度建模中,有一种维度叫minidimension,中文一般翻译成“微型维度”。微型维度的提出主要是为了解决快变超大维度。


以客户维度举例来说,如果维度表中有数百万行记录或者还要多,而且这些记录中的字段又经常变化,这样的维度表一般称之为快变超大维度。对于快变超大维度,设计人员一般不会使用TYPE 2的缓慢变化维处理方法,因为大家都不愿意向本来就有几百万行的维度表中添加更多的行。


这时,有一项技术可以解决这个问题。解决的方法是,将分析频率比较高或者变化频率比较大的字段提取出来,建立一个单独的维度表。这个单独的维度表就是微型维度表。


微型维度表有自己的关键字,这个关键字和原客户维度表的关键字一起进入事实表。有时为了分析的方便,可以把微型维度的关键字的最新值作为外关键字进入客户维度表。这时一定要注意,这个外关键字必须做TYPE 1型处理。


14. 下钻


这是在数据分析中常见的概念,下钻可以理解成增加维的层次,从而可以由粗粒度到细粒度来观察数据,比如对产品销售情况分析时,可以沿着时间维从年到月到日更细粒度的观察数据。从年的维度可以下钻到月的维度、日的维度等。


15. 上卷


知道了下钻,上卷就容易理解了,它俩是相逆的操作,所以上卷可以理解为删掉维的某些层,由细粒度到粗粒度观察数据的操作或沿着维的层次向上聚合汇总数据。


16. 数据集市


数据集市可以理解为是一种"小型数据仓库",它只包含单个主题,且关注范围也非全局。数据集市可以分为两种:


  • 一种是独立数据集市,这类数据集市有自己的源数据库和ETL架构;


  • 另一种是非独立数据集市,这种数据集市没有自己的源系统,它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时,非独立数据集市就可以简单为用户提供一个数据仓库的子集。


二、数仓概念之间关系


1. 实体表,事实表,维度表之间的关系


在Kimball维度建模中有维度与事实,在Inmon范式建模中有实体与关系,如果我们分开两种建模方式看这些概念比较容易理解。但是目前也出现了不少混合建模方式,两种建模方式结合起来看,这些概念是不是容易记忆混乱,尤其事实表和实体表,它们之间到底有怎样区别与联系,先看下它们各自概念:


1.维度表:维度表可以看成是用户用来分析一个事实的窗口,它里面的数据应该是对事实的各个方面描述,比如时间维度表,地域维度表,维度表是事实表的一个分析角度。


2.事实表:事实表其实就是通过各种维度和一些指标值的组合来确定一个事实的,比如通过时间维度,地域组织维度,指标值可以去确定在某时某地的一些指标值怎么样的事实。事实表的每一条数据都是几条维度表的数据和指标值交汇而得到的。


3.实体表:实体表就是一个实际对象的表,实体表放的数据一定是一条条客观存在的事物数据,比如说各种商品,它就是客观存在的,所以可以将其设计一个实体表。实时表只描述各个事物,并不存在具体的事实,所以也有人称实体表是无事实的事实表。


举个例子:比如说手机商场中有苹果手机,华为手机等各品牌各型号的手机,这些数据可以组成一个手机实体表,但是表中没有可度量的数据。某天苹果手机卖了15台,华为手机卖了20台,这些手机销售数据属于事实,组成一个事实表。这样就可以使用日期维度表和地域维度表对这个事实表进行各种维度分析。


2. 指标与标签的区别


- 概念不同

指标是用来定义、评价和描述特定事物的一种标准或方式。比如:新增用户数、累计用户数、用户活跃率等是衡量用户发展情况的指标;


标签是人为设定的、根据业务场景需求,对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果,如网红、白富美、萝莉。


- 构成不同


指标名称是对事物质与量两方面特点的命名;指标取值是指标在具体时间、地域、条件下的数量表现,如人的体重,指标名称是体重,指标的取值就是120斤;


标签名称通常都是形容词或形容词+名词的结构,标签一般是不可量化的,通常是孤立的,除了基础类标签,通过一定算法加工出来的标签一般都没有单位和量纲。如将超过200斤的称为大胖子。


- 分类不同


对指标的分类:


按照指标计算逻辑,可以将指标分为原子指标、派生指标、衍生指标三种类型;


按照对事件描述内容的不同,分为过程性指标和结果性指标;


对标签的分类:


按照标签的变化性分为静态标签和动态标签;


按照标签的指代和评估指标的不同,可分为定性标签和定量标签;


指标最擅长的应用是监测、分析、评价和建模。

标签最擅长的应用是标注、刻画、分类和特征提取。

特别需要指出的是,由于对结果的标注也是一种标签,所以在自然语言处理和机器学习相关的算法应用场景下,标签对于监督式学习有重要价值,只是单纯的指标难以做到的。而指标在任务分配、绩效管理等领域的作用,也是标签无法做到的。


3. 维度和指标区别与联系


维度就是数据的观察角度,即从哪个角度去分析问题,看待问题。


指标就是从维度的基础上去衡算这个结果的值。


维度一般是一个离散的值,比如时间维度上每一个独立的日期或地域,因此统计时,可以把维度相同记录的聚合在一起,应用聚合函数做累加、均值、最大值、最小值等聚合计算。


指标就是被聚合的通计算,即聚合运算的结果,一般是一个连续的值。


4. 自然键与代理键在数仓的使用区别


数仓工具箱中说维度表的唯一主键应该是代理键而不应该是自然键。有时建模人员不愿意放弃使用自然键,因为他们希望与操作型代码查询事实表,而不希望与维度表做连接操作。然而,应该避免使用包含业务含义的多维键,因为不管我们做出任何假设最终都可能变得无效,因为我们控制不了业务库的变动。


所以数据仓库中维度表与事实表的每个连接应该基于无实际含义的整数代理键。避免使用自然键作为维度表的主键。


5. 数据集市与数据仓库的区别与联系


数据集市就是企业级数据仓库的一个子集,它主要面向部门级业务,并且只面向某个特定的主题。为了解决灵活性与性能之间的矛盾,数据集市就是数据仓库体系结构中增加的一种小型的部门或工作组级别的数据仓库。数据集市存储为特定用户预先计算好的数据,从而满足用户对性能的需求。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。

相关实践学习
数据库实验室挑战任务-初级任务
本场景介绍如何开通属于你的免费云数据库,在RDS-MySQL中完成对学生成绩的详情查询,执行指定类型SQL。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
2月前
|
Python
区域代理分红商城系统开发源码片段示例规则解析
level = Column(Integer, default=1) # 代理等级,例如:1代表普通用户,2代表初级代理,3代表高级代理等 parent_id = Column(Integer, ForeignKey('user.id')) # 上级代理ID 【更全面的开发源码搭建可V or TG我昵称】 parent = relationship("User", remote_side=[id]) # 上级代理对象
|
5月前
|
SQL Oracle 物联网
助力工业物联网,工业大数据之数仓维度层DWS层构建【十二】
助力工业物联网,工业大数据之数仓维度层DWS层构建【十二】
47 0
|
5月前
|
设计模式 XML JSON
二十三种设计模式全面解析-代理模式进阶篇:揭秘远程代理
二十三种设计模式全面解析-代理模式进阶篇:揭秘远程代理
|
12天前
|
XML JSON 关系型数据库
Pandas一键解析代理IP与代理IP池的维护
Pandas一键解析代理IP与代理IP池的维护
|
6月前
|
存储 传感器 数据可视化
3D目标检测数据集 KITTI(标签格式解析、3D框可视化、点云转图像、BEV鸟瞰图)
本文介绍在3D目标检测中,理解和使用KITTI 数据集,包括KITTI 的基本情况、下载数据集、标签格式解析、3D框可视化、点云转图像、画BEV鸟瞰图等,并配有实现代码。
467 0
|
2月前
|
存储 大数据 数据管理
数据仓库(09)数仓缓慢变化维度数据的处理
数据仓库的重要特点之一是反映历史变化,所以如何处理维度的变化是维度设计的重要工作之一。缓慢变化维的提出是因为在现实世界中,维度的属性并不是静态的,它会随着时间的流逝发生缓慢的变化,与数据增长较为快速的事实表相比,维度变化相对缓慢。阴齿这个就叫做缓慢变化维。
220 2
数据仓库(09)数仓缓慢变化维度数据的处理
|
3月前
|
域名解析 缓存 网络协议
|
3月前
|
存储 Prometheus 监控
性能监控之国产时序库TDengine TDinsight dashboard 指标解析
【2月更文挑战第1天】性能监控之国产时序库TDengine TDinsight dashboard 指标解析
267 1
性能监控之国产时序库TDengine TDinsight dashboard 指标解析
|
7月前
|
存储 数据挖掘 关系型数据库
数仓学习---6、数据仓库概述、 数据仓库建模概述、维度建模理论之事实表、维度建模理论之维度表
数仓学习---6、数据仓库概述、 数据仓库建模概述、维度建模理论之事实表、维度建模理论之维度表
|
3月前
|
XML Java 数据格式
Spring5源码(41)-tx:annotation-driven 标签解析过程
Spring5源码(41)-tx:annotation-driven 标签解析过程
218 0

推荐镜像

更多