作为一个数据人，是不是经常被各种名词围绕，是不是对其中很多概念认知模糊。有些词虽然只有一字之差，但是它们意思完全不同，今天我们就来了解下数仓建设及数据分析时常见的一些概念含义及它们之间的关系。
建议大家收藏此文，以后遇到不熟悉的概念可以在本篇文章中查找下
本文结构如下图所示：
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. 下钻
这是在数据分析中常见的概念，下钻可以理解成增加维的层次，从而可以由粗粒度到细粒度来观察数据，比如对产品销售情况分析时，可以沿着时间维从年到月到日更细粒度的观察数据。从年的维度可以下钻到月的维度、日的维度等。
13. 上卷
知道了下钻，上卷就容易理解了，它俩是相逆的操作，所以上卷可以理解为删掉维的某些层，由细粒度到粗粒度观察数据的操作或沿着维的层次向上聚合汇总数据。
1. 实体表，事实表，维度表之间的关系
在Kimball维度建模中有维度与事实，在Inmon范式建模中有实体与关系，如果我们分开两种建模方式看这些概念比较容易理解。但是目前也出现了不少混合建模方式，两种建模方式结合起来看，这些概念是不是容易记忆混乱，尤其事实表和实体表，它们之间到底有怎样区别与联系，先看下它们各自概念：
维度表：维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，地域维度表，维度表是事实表的一个分析角度。
事实表：事实表其实就是通过各种维度和一些指标值的组合来确定一个事实的，比如通过时间维度，地域组织维度，指标值可以去确定在某时某地的一些指标值怎么样的事实。事实表的每一条数据都是几条维度表的数据和指标值交汇而得到的。
实体表：实体表就是一个实际对象的表，实体表放的数据一定是一条条客观存在的事物数据，比如说各种商品，它就是客观存在的，所以可以将其设计一个实体表。实时表只描述各个事物，并不存在具体的事实，所以也有人称实体表是无事实的事实表。
举个例子：比如说手机商场中有苹果手机，华为手机等各品牌各型号的手机，这些数据可以组成一个手机实体表，但是表中没有可度量的数据。某天苹果手机卖了15台，华为手机卖了20台，这些手机销售数据属于事实，组成一个事实表。这样就可以使用日期维度表和地域维度表对这个事实表进行各种维度分析。
2. 指标与标签的区别 概念不同
指标是用来定义、评价和描述特定事物的一种标准或方式。比如：新增用户数、累计用户数、用户活跃率等是衡量用户发展情况的指标；
标签是人为设定的、根据业务场景需求，对目标对象运用一定的算法得到的高度精炼的特征标识。可见标签是经过人为再加工后的结果，如网红、白富美、萝莉。
构成不同指标名称是对事物质与量两方面特点的命名；指标取值是指标在具体时间、地域、条件下的数量表现，如人的体重，指标名称是体重，指标的取值就是120斤；
标签名称通常都是形容词或形容词+名词的结构，标签一般是不可量化的，通常是孤立的，除了基础类标签，通过一定算法加工出来的标签一般都没有单位和量纲。如将超过200斤的称为大胖子。
分类不同对指标的分类：
按照指标计算逻辑，可以将指标分为原子指标、派生指标、衍生指标三种类型；
按照对事件描述内容的不同，分为过程性指标和结果性指标；
对标签的分类：
按照标签的变化性分为静态标签和动态标签；
按照标签的指代和评估指标的不同，可分为定性标签和定量标签；
指标最擅长的应用是监测、分析、评价和建模。标签最擅长的应用是标注、刻画、分类和特征提取。特别需要指出的是，由于对结果的标注也是一种标签，所以在自然语言处理和机器学习相关的算法应用场景下，标签对于监督式学习有重要价值，只是单纯的指标难以做到的。而指标在任务分配、绩效管理等领域的作用，也是标签无法做到的。
3. 维度和指标区别与联系
维度就是数据的观察角度，即从哪个角度去分析问题，看待问题。
指标就是从维度的基础上去衡算这个结果的值。
维度一般是一个离散的值，比如时间或地域维度上每一个独立的日期或地区。因此统计时，可以把维度相同记录的聚合在一起，应用聚合函数做累加、均值、最大值、最小值等聚合计算。
指标就是被聚合的通计算，即聚合运算的结果，一般是一个连续的值。
4. 自然键与代理键在数仓的使用区别
数仓工具箱中说维度表的唯一主键应该是代理键而不应该是自然键。有时建模人员不愿意放弃使用自然键，因为他们希望与操作型代码查询事实表，而不希望与维度表做连接操作。然而，应该避免使用包含业务含义的多维键，因为不管我们做出任何假设最终都可能变得无效，因为我们控制不了业务库的变动。