数仓分层
按照数据流入流出过程,数仓架构可分为:源数据,数据仓库,数据应用
数据仓库的数据来源于不同的源数据,并提供多样的数据应用,数据自下而上流入数据仓库后向上层开放应用,而数据仓库只是中间集成化数据管理的一个平台;
源数据:此层数据无需任何更改,直接沿用外围系统数据结构和数据,不对外开放;为临时存储层,是接口数据的临时存储区域,为后一步的数据处理做准备;
数据仓库:也称细节层,DW层的数据应该是一致的,准确地,干净的数据,即对源系统数据清洗后的数据;
数据应用:前端直接读取的数据源,根据报表,专题分析需求而计算生成的数据;
数据仓库从各个数据源获取数据及在数据仓库内的转换和流动都可以认为是ETL,(抽取Extra,转换Transfer,装载Load)的过程,ETL是数据仓库的流水线,也可以认为是数据仓库的血液,它维系着数据仓库中数据的新陈代谢,数据仓库日常大部分工作都是保持ETL的正常和稳定;
那么数仓分层的真正原因:
1.用空间换时间:通过大量的预处理来提升应用系统的用户体验(效率),因此数据仓库存在大量的数据冗余,如果不分层,源系统业务规则发生变化将影响整个数据清洗过程,增加极大工作量;
2.通过数仓分层简化数据清洗过程:将一个步骤分为多个步骤去完成,相当于把一个复杂的工作拆分为多个简单的工作,将一个大黑盒变成白盒,每层的处理逻辑相对简单和容易理解,这样不仅可以保证每个步骤的正确性,当数据发生错误的时候,我们只需要局部调整某个步骤即可;
主要数仓结构
1.数据集市架构
数据集市是按主题域组织的数据集合,用于支持部门级的决策,有两种类型的数据集市 独立数据集市和从属数据集市;
1.独立数据集市
独立数据集市集中于部门所关心的单一主题域,数据以部门为基础部署,无需考虑企业级别的信息共享与集成;例如:制造部门,人力资源部门各自有自己的数据集市;
优点:因为一个部门业务相对于整个企业要简单,数据量也小很多,所以部门的独立数据集市会有周期短,见效快的特点;
缺点:
.从业务角度看,当部门的分析需求扩展,或者需要分析跨部门或跨主题域的数据时,独立数据市场会显得力不从心;
.当数据存在歧义,比如同一个产品,在A与B部门定义不同时,将无法在部门间进行信息比较;
.每个部门使用不同的技术,建立不同的ETL过程,处理不同的事务系统,而在多个数据集市之间还会存在数据的交叉与重叠,甚至会与数据不一致的情况;
2.从属数据集市
从属数据集市的数据来源于数据仓库,数据仓库将数据经过整合,重构,汇总后传递给从属数据集市(数据内容从数据仓库中得到而并不直接来自外部数据源的数据集市);
建立数据集市的好处:
.性能:当数据仓库的查询性能出现问题,可以考虑建几个从属数据集市,将查询从数据仓库移出到数据集市;
.安全:每个部门可以完全控制他们自己的数据;
.数据一致:因为每个数据集市的数据来源都是同一数据仓库,有效消除了数据不一致的情况;
2.Inmon企业工厂架构
企业级数据仓库:该架构的核心组件,正如Inmon数据仓库所定义的,企业级数据仓库是一个细节数据的集成资源库,其中的数据以最低级别粒度被捕获,存储在满足三范式的关系型数据库;
部门级数据集市:是面向主题数据的部门级视图,数据从企业级数据仓库直接获取;数据在进入部门数据集市时可能进行聚合,数据集市是使用多维模型设计,用于数据分析;重要的一点,所有的报表工具,BI工具等都是从数据集市查询数据,而不是之间访问企业级数据仓库;
3.Kimball数据仓库架构
对比Inmon架构可以看出,两种架构主要区别在于核心数据仓库的建立设计和建立;
Kimball的数据仓库包含高粒度的企业数据,使用多维模型设计,这也意味着 数据仓库由星型模式的维度表和事实表构成;分析系统或报表工具可以直接访多维数据库中的数据;
在此架构中的数据集市与Inmon架构的不同,这里的数据集市是一个逻辑概念,只是多维数据仓库中的主题域划分,并没有自己的物理储存,也可以说是虚拟的数据集市;
4.混合型数据仓库架构
混合型数据仓库:指在一个数据仓库环境中,联合使用Inmon与Kimball两种架构;
从架构图可以看到,这种架构将Inmon方法中的数据集市替换成一个多维数据仓库,而数据集市则是多维数据仓库上的逻辑视图;
架构优点:既可以利用规范化设计消除数据冗余,保证数据的粒度足够细,又可以利用多维结构更灵活的在企业级实现报表分析;
数据仓库元数据管理
元数据(Meta date),主要记录数据仓库中模型的定义,各层级间的映射关系,监控数据仓库的数据状态及ETL的任务运行状态;一般会通过元数据资料库(Metadata Repository)来统一的存储和管理元数据,其主要目的是使数据仓库的设计,部署,操作和管理达成协同和一致;
元数据是数据仓库管理系统的重要组成部分,元数据管理是企业级数据仓库中的关键组件,贯穿数据仓库构建的整个过程,直接影响数据仓库的构建,使用和维护;
.构建数据仓库的主要步骤之一是ETL,这时元数据将发挥重要的作用,它定义了源数据系统到数据仓库的映射,数据转换规则,数据仓库的逻辑结构,数据更新规则,数据导入历史记录及装载周期等相关内容,数据抽取和转换的专家正及数据仓库管理员正是通过元数据高效的构建数据仓库;
.用户在使用数据仓库时,通过元数据访问数据,明确数据项的定义及定制报表;
.数据仓库的规模及其复杂性离不开正确的元数据管理,包括增加和移除外部数据源,改变数据清洗方法,控制出错的查询及数据备份等;
.元数据可分为技术元数据和业务元数据: 技术元数据为开发和管理数据仓库的IT人员使用,它描述了与数据仓库开发,管理和维护相关的数据,包括数据源信息,数据转换描述,数据仓库模型,数据清洗与更新规则,数据映射与访问权限;而业务元数据为管理层和业务分析人员服务,从业务角度描述数据,包括商务术语,数据仓库有什么数据,数据的位置和数据可用性等,帮助业务人员更好的理解数据仓库中有哪些数据可用以及如何使用;
由此可见,元数据不仅定义了数据仓库中数据的模式,来源,抽取和转换规则等 ,而且是整个数据仓库运行的基础,元数据把数据仓库中各个松散的组件联系起来,组成了一个有机的整体;
数仓常见术语解析
数仓名词解释
1.实体
.实体是指依附的主体,就是我们分析的一个对象,比如我们分析商品销售情况,如华为手机近半年的销量,那华为手机就是一个实体;分析用户的活跃度,那用户就是一个实体,实体也可以不是现实中真实存在的,例如虚拟的业务对象,活动,会员都可以看作一个实体;
.实体的存在是为了业务分析,作为分析的一个筛选的维度,拥有描述自己的属性,本身具有可分析价值;
2.维度
.维度就是看待问题的角度,分析业务数据,从什么角度分析,就建立什么样的维度;所以维度就是对数据进行分析时所用的一个量,比如分析产品销售情况,可以按商品类别进行分析,这就构成一个维度,把所有商品类别集合在一起就构成了维度表;
.3度量
.度量是业务流程节点上的一个数值,比如销量,价格,成本等;
.事实表中的度量可分为三类:完全可加,半可加,不可加
.1.完全可加的度量是最灵活,最有用的,比如销量,销售额等,可以进行任意维度汇总;
.2.半可加的度量可以对某些维度进行汇总,但不能对所有维度进行汇总,差额是常见的半可加度量,它除了时间维度外,可以跨所有维度进行加法操作;
.3.还有一种是完全不可加的,例如:比率,对于这种不可加度量,一种最好的办法就是尽可能存储非可加度量的完全可加分量,并在计算出最终的非可加事实前,将这些分量汇总到最终的结果集;
.4.粒度
.粒度就是业务流程中对度量的单位,比如商品是按件记录度量还是按批记录;
.在数仓建设中,我们说这是用户粒度的事实表,那么表中每行数据都是一个用户,无重复用户;例如还有销售粒度的表,那么表中每行记录都是一条销售记录;
.选择合适的粒度级别是数据仓库建设好坏的关键,在设计数据粒度时,通常需重点考虑以下因素:
1.要接受的分析类型,可接受的数据最低粒度和能存储的数据量;
2.粒度的层次定义越高,就不能在该仓库进行更细致的分析;
3.如果存储资源有限,那只能采取较高粒度划分;
4.数据粒度划分策略一定要保证:数据的粒度确实能够满足用户的决策分析需要,这是数据粒度划分策略中最重要的一个准则;
.5.口径
口径即取数逻辑(如何取数的),比如要取得是10岁以下儿童中男孩的平均身高,这就是统计的口径;
.6.指标
指标是口径的衡量值,也就是最后的结果,比如最近7天的订单量,一个促销活动的购买转化率等,一个指标具体到计算实施,主要有以下几部分组成:
.指标加工逻辑,如count,avg,sum等
.维度,如按部门,地域统计,相当于group by
.业务限定/修饰词,比如以不同渠道来算对应指标,微信支付退款率,支付宝支付退款率,相当于sql中的where;
除此之外指标本身还可以衍生,派生出更多的指标,基于这些特点,可以将指标分类:
.原子指标:基本业务事实,没有业务限定,没有维度;比如订单表中的订单量,订单总额都算原子指标;
业务更关心的指标,是有实际业务含义的,可以直接取数的指标,比如店铺近一天的订单支付金额就是派生指标,会被直接在产品上展示给商家看;
但是这个指标却不能直接从数仓的统一中间层取数,(因为没有现成的事实字段,数仓一般都是大宽表),需要有一个桥梁连接数仓中间层和业务方的指标需求,于是有了派生指标
.派生指标:维度+修饰词+原子指标,店铺近一天销售额,其中店铺是维度,近一天是时间类型修饰词,支付金额是原子指标;
维度:观察各项指标的角度;
修饰词:维度的一个或某些值,比如维度性别下,男和女就是2种修饰词;
.衍生指标:比如某一个促销活动的转化率就是衍生指标,因为需要促销投放人数和促销订单数指标进行计算得出;(需要预先计算的其他指标转化得出的指标)
.7.标签
.标签是人为设定的根据业务场景需求,对目标对象运用一定的算法得到的高度精炼的特征标识,可见标签是经过人为再加个后的结果,如网红,白富美,萝莉;对于有歧义的标签,我们内部可以进行标签区分,比如苹果,我们可以定义苹果为水果,苹果手机才指手机;
.8.自然键
.由现实中已存在的键组成,它在业务中是唯一的,并具有一定的业务含义,比如商品ID,员工ID;从数仓角度看,来源于业务系统的标识符就是自然键,比如业务库中员工的编号;
.9.持久键
.保持永久性不会发生变化,有时也被叫做超自然持久键,例如身份证号;
.自然键和持久键区别:例如某员工离职后重新入职,那么他的员工编号就是自然键,发生了变化,但是他的持久键身份证号是不会变的
.10.代理键
.就是不具有业务含义的键,代理键有许多其他的称呼:无意义键,整数键,非自然键,人工键,合成键等;
.代理键就是简单的以按照顺序序列产生的整数表示,产品行的第一行代理键为1,下一行为2,依次进行;代理键的作用仅仅是连接维度表与事实表
.11.退化维度
.退化维度,就是那些看起来像是事实表的一个维度关键字,但事实上并没有其对应的维度表,就是维度属性存储到事实表中,这种存储到事实表的维度称为退化维度,与其他存储在维度表中的维度一样,退化维度也可以用来进行事实表的过滤查询,实现聚合操作等;
.那么如何定义退化维度呢,比如订单ID,这种量级很大的维度,没必要用一张维度表来存储,而我们进行数据查询或者数据过滤的时候又很重要,所以这种就冗余在事实表里,这种就叫退化维度,如citycode这种我们也会冗余在事实表里,但是他有对应的维度表,所以他不是退化维度;
.12.下钻
.这是在数据分析中常见的概念,下钻可以理解为增加维的层次,从而可以由粗粒度到细粒度来观察数据,比如对产品销售情况分析时,可以沿着时间线从年到月再到日维度等;
.13.上卷
.知道了下钻,上卷就容易理解了,它俩是 相逆的操作,上卷可以理解为删掉某些维的某些层,由细粒度到粗粒度观察数据的操作或沿着维度进一步向上聚合汇总数据;
.14.数据集市
.数据集市(Data Mart),也叫数据市场,数据集市就是满足特定部门或者用户的需求,按照多维方式进行存储,包括定义维度,需要计算的指标,维度的层次等;生成面向决策分析需求的数据集,本质就是从数据仓库抽出的一个小合集;
数仓名词之间的关系
1.实体表,事实表,维度表之间的关系
.在Kimball维度建模中有维度和事实,在Inmon范式建模有实体与关系,如果分开两种建模方式看这些概念比较容易理解,但目前也有很多混合建模方式,两种建模结合起来看容易记得混乱,尤其是事实表与实体表
.1维度表:维度表可以看成是用户用来分析一个事实的窗口,它里边的数据应该是对事实的各个方面的描述,比如时间维度表,地域维度表,维度表是事实表的一个分析角度;
.2.事实表:事实表就是通过各种维度及指标组合来确定一个事实,比如通过时间维度,地域维度,指标值可以去确定某时某地的一些指标值怎么样的事实,事实表的每条数据都是几条维度表的数据与指标值交会得到的;
.3.实体表:实体表就是一个实际对象的表,实体表放的数据一定是一条条客观存在的事物数据,比如各种商品,它是客观存在的,所以可以将其设计成一个实体表;实体表只描述各种事物,并不存在具体的事实,所以可以称实体表是无事实的事实表;(无事实即无确定的可度量数据,没得指标可以算,我理解实体表中数据是唯一的)
举个栗子:比如商场有苹果手机,华为,小米等手机,这些数据可以组成一个手机实体表,但是表中没有可度量的数据,某一天,华为卖了20台,小米卖了10台,这些销售数据属于事实,组成一个事实表,这样就可以使用日期维度表与地域维度表对这个事实表进行各种维度分析;
2.指标与标签的区别
.概念不同
指标是用来定义,评价和描述特定事物的一种标准或方式,比如:新增用户数,累计用户数,用户活跃率等是衡量用户发展情况的指标;
标签是人为设定的,根据业务场景需求,对目标对象运用一定的算法得到高度精炼的特征标识,可见标签是经过人为再加工后的结果,如网红,白富美,萝莉;
.构成不同
指标名称是对事物质与量两方面特点的命名;指标取值是指标在具体时间,地域,条件下的数量表现,如人的体重,指标名称是体重,指标的取值就是120斤;
标签名称通常都是形容词+名词的结构,标签一般是不可量化的,通常是孤立的,除了基础类标签,通过一定算法加工出来的标签一般都没有单位和量纲,如将超过200斤的称为大胖子;
.分类不同
.对指标的分类:
.按照指标计算逻辑,可以将指标分为原子指标,派生指标,衍生指标三类;
.按照对事件描述内容的不同,分为过程性指标和结果性指标;
.对标签的分类
.对照标签的变化性分为静态标签和动态标签;
.按照标签的指代和评估指标不同,可分为定性标签和定量标签;
指标:最擅长的应用是监测,分析,评价和建模;
标签:最擅长的应用是标注,刻画,分类和特征提取;
对结果的标注也是一种标签,所以在自然语言处理和机器学习相关的算法应用场景下, 标签对监督式学习有重要价值,只是单纯的指标难以做到的,而指标在任务分配,绩效管理等领域的作用也是标签无法做到的;
3.维度和指标的区别与联系
.维度就是数据的观察角度,即从哪个角度取分析问题,看待问题;
.指标是在维度的基础上去衡算这个结果的值;
.维度一般是一个离散的值,比如时间维度上每一个独立的日期或者地域,因此统计时,可以把相同维度的记录聚合在一起,应用聚合函数做累加,均值,最大最小等计算;
.自然键和代理键在数仓的使用区别
.一般数仓中说维度表的唯一主键应该是代理键而不应该是自然键,有时建模人员不愿意放弃使用自然键,因为他们希望用操作型代码查询事实表,而不希望与维度表做连接操作;但实际上,应该避免使用包含业务含义的多维键,因为不论我们做出任何假设最终都可能变得无效,因为我们控制不了业务库的变动;
.所以数据仓库中维度表与事实表的每个连接应该基于无实际含义的整数代理键,避免使用自然键作为维度表的主键;
.数据集市和数据仓库的关系
.数据集市是企业级数据仓库的一个子集,它主要面向部门级业务,并且只面向某个特定的主题,为了解决灵活性和性能之间的矛盾,数据集市就是数据仓库体系结构中增加的一种小型的部门或工作组级别的数据仓库,数据集市存储为特定用户事先计算好的数据,从而满足用户对性能的需求,数据集市可以一定程度上缓解访问数据仓库的瓶颈;
.数据集市和数据仓库的主要区别:数据仓库是企业级的,能为整个企业各个部门的运行提供决策支持手段,而数据集市则是一种微型的数据仓库,它通常有更少的数据,更少的主题域,以及更少的历史数据,因此是部门级的,一般只能为某个局部范围内的管理人员服务,因此也称为部门级数据仓库;
离线数仓建设核心
数据仓库的核心是展现层和提供优质的服务,ETL及其规范,分层等所作的一切都是为了展现一个更清晰易用的展现层;
1.数仓分层
数仓分层原则:
1.便于数据分析,要屏蔽底层复杂业务,简单完整,集成的将数据暴露给分析层;
2.底层业务变动对模型冲击最小化,业务系统变化影响削弱在基础数据层,结合自上而下的建设方法削弱需求变动对模型的影响;
3.高内聚松耦合,即主题之内或各个完整意义的系统内数据的高内聚,主体之间或各个完整意义的系统间数据的松耦合;
4.构建仓库基础数据层,使底层业务数据整合工作与上层应用开发工作相隔离,为仓库大规模开发奠定基础 仓库层次更加清晰,对外暴露数据更加统一;
一般采取如下分层结构:
1.数据源层:ODS
ODS层,最接近数据源中数据的一层,为了考虑以后可能要追溯数据的问题,因此对这一层就不建议做过多的数据清洗工作,原封不动接入原始数据即可;至于数据的去噪,去重,异常值处理等过程可以放在后边的DWD层来做;
2.数据仓库层:DW(Data Warehouse)
数据仓库层是数据仓库的核心层,在这里,从ODS层获得的数据按照主题建设各种数据模型;
DW层又细分为DWD层,DWM层和DWS层
1).数据明细层:DWD
该层一般保持和ODS层一样的数据粒度,并且提供一定的数据质量保证,DWD层要做的就是将数据清理,整合,规范化,脏数据,垃圾数据,规范不一致的,状态定义不一致的,命名不规范的数据都会被处理;
同时,为提高数据明细层的易用性,该层会采取一些维度退化的手法,将维度退化至事实表中,减少事实表与维度表的关联;
另外,该层也会做一部分的数据聚合,将相同主题数据汇集到一张表中,提高数据的可用性;
2).数据中间层:DWM
该层会在DWD层数据基础上,数据做轻度聚合操作,生成一系列的中间表,提升公共指标的复用性,减少重复加工;
直观说就是,对通用核心维度进行聚合操作,算出相应的统计指标;
在实际计算中,如果直接从DWD或ODS计算出宽表的统计指标,会存在计算量太大并且维度太少的问题,因此一般做法是,在DWM层计算出多个小的中间表,然后再拼成一张DWS的宽表,由于宽和窄的界限不易界定,也可以去掉DWM这层,只留DWS层,将所有数据放在DWS即可;
3)数据服务层:DWS
DWS层为公共汇总层,会进行轻度汇总,粒度比明细数据稍粗,基于DWD层的基础数据,整合汇总某一主题域的服务数据,一般是宽表,DWS层应覆盖80%的应用场景,又称数据集市或宽表;
按照业务划分,如主题域流量,订单,用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等;
一般来讲,该层的数据表会相对较少,一张表涵盖比较多的业务内容,由于其字段较多,因此一般也称该层的表为宽表;
3.数据应用层:APP(ADS)
在这里,主要是提供给数据产品和数据分析使用的数据,一般会存在ES,PostgreSql、Redis等系统供线上系统使用,也可能存在Hive或者Durid中供数据分析和数据挖掘使用;比如我们的报表数据,一般就放在这里;
4.维表层:DIM
如果维表过多,也可针对维表单独设计一层,维表主要包含两部分数据:
高基数维度数据:一般是用户资料表,商品资料表类似的资料表.数据量可能是千万或者上亿级别;
低基数维度数据:一般是配置表,比如枚举值的中文含义,或者日期维表,数据量可能是个位数或者几千几万;
2.数仓建模方法
数仓建模在哪层建设呢,以维度建模为例,建模是在数据源层的下一层进行建设,在分层架构中,就是在DW层进行数仓建模,所以DW层是数仓建模的核心;
那,数仓建模究竟如何建,数仓建模方法有很多种,每一个建模都代表哲学上的一个观点,代表了归纳,概况世界的一种方法,常见的有范式建模法,维度建模法,实体建模法等,方法的本质是从不同的角度看待业务中的问题;
1.范式建模法
范式建模法,范式建模法是我们在构建数据模型中常用的一个方法,该方法主要由Inmon所提倡,主要解决关系型数据库中的数据存储,利用的一种技术层面上的方法,目前,我们在关系型数据库中的建模方法,大部分采用的 是三范式建模法;
范式是符合某一种级别的关系模式的集合,构造数据库必须遵守一定的规则,而在关系型数据库中这种规则就是范式,这一过程也被称为规范化,目前关系型数据库中有六种范式:第一范式(1NF),第二范式(2NF),第三范式(3NF),Boyce-Code范式(BCNF),第四范式(4NF)和第五范式(5NF);
在数据仓库的模型设计中,一般采用第三范式,一个符合第三范式的关系必须具有以下三个条件:
.每个属性值唯一,不具有多意性;
.每个非主属性必须依赖于整个主键,而非主键的一部分;
.每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归到其他关系中去;
范式建模
根据Inmon的观点,数据仓库模型的建设方法和业务系统的企业数据模型类似,在业务系统中,企业的数据模型决定了数据的来源,而企业数据模型也分为两个层次,即主题域模型和逻辑模型,同样,主题域模型可以看成是业务模型的概念模型,而逻辑模型则是域模型在关系型数据库上的实例化;
2.维度建模法
维度模型是数据仓库领域另一位大师Ralph Kimall所倡导,他的"数据仓库工具箱"是数据仓库工程领域最流行的数仓建模经典;维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能;
典型的代表是我们熟知的星型模型,以及在一些特殊场景下适用的雪花模型;
维度建模中重要的概念就是事实表和维度表;其最简单的描述就是,按照事实表,维度表来构建数据仓库,数据集市;
3.实体建模法
实体建模法并不是数据仓库建模中一个常见的方法,它来源于哲学的一个流派,从哲学的意义上说,客观的世界是可以细分的,客观世界可以由一个个实体,实体与实体间的关系构成,那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体间的关系,以及针对这些关系的说明就是我们数据建模要做的工作;
虽然实体法粗看有些抽象,但我们可以将一个业务过程划分为3个部分,实体,事件,说明,如下图所示:
实体建模:如上图,我们描述一个简单的事实,小明开车去上学;以这个业务事实为例,我们可以把小明,学校看成是一个实体,上学我们可以抽象为一个具体的事件,而开车去可以看成事件的一个说明;
3.维度建模详解
目前大多公司都用的建模方法为维度建模,维度建模是专门应用于分析型数据库,数据仓库,数据集市建模的方法,数据集市可以理解为是一种小型数据仓库;
在建模前,先了解维度建模中表的类型及维度建模的模式
1.维度建模中表的类型
维度建模分为两种表:事实表和维度表
1.事实表:必然存在的一些数据,像采集日志文件,订单表,都可以作为事实表;
特征:是一堆主键的集合,每个主键对应维表中的一条记录,客观存在的,根据主题确定出需要使用的数据;
2.维度表:维度就是所分析的数据的一个量,维度表就是以合适的角度来创建的表,分析问题的一个角度:时间,地域,用户等角度
1.事实表
发生在现实世界中的操作型事件,其所产生的可度量数值,存储在事实表中,从最低的粒度级别来看,事实表行对应一个度量事件,反之亦然;
事实表表示对分析主题的度量,比如一次购买行为我们就可以理解为是一个事实;
如图中的订单表就是一个事实表,可以理解为它就是在现实中发生的一次操作型事件,我们每完成一个订单,就会在订单中增加一条记录,事实表的特征:表里没有存放实际的内容,它是一堆主键的集合,这些ID分别对应到维度表中的一条记录,事实表包含了与各维度表关联的外键,可与维度表关联;事实表的度量通常是数值类型,且记录会不断增加,表数据规模迅速增长;
明细表(宽表):
事实表的数据,有些属性共同组成一个字段(糅合在一起),比如年月日时分秒构成了时间,当需要某一属性进行分组统计时需要截取拼接操作,效率不高,为了方便分析,可以将事实表的一个字段切割提取出多个属性构成新的字段,因为字段变多了,所以称为宽表,原来的表称为窄表; 又因为宽表的信息更加清晰明细,所以也可以称为明细表;
事实表种类:
事实表可分为以下6类:1.事务事实表,2.周期快照事实表,3.累计快照事实表,4.无事实的事实表,5.聚集事实表,6.合并事实表
这几种表的概念如下:
.事务事实表:表中一行对应时间或空间上某点的度量事件,就是一行数据中必须有度量字段,什么是度量,就是指标,比如说销售金额,销售数量等这些可加的或者半可加的就是度量值,另一点就是事务事实表都包含一个与维度表关联的外键,并且度量值和事物粒度保持一致;
.周期快照事实表:即每行都带有时间值的字段,代表周期,通常时间值都是标准周期,如某一天,某周,某月等,粒度是周期,而不是个体的事务,也就是说周期快照事实表中数据可以是多个事实,但它们都属于某个周期内;
.累计快照事实表:周期快照事实表是单个周期内的数据,而累计快照事实表是由多个周期数据组成,每行汇总了过程开始到结束之间的度量,每行数据相当于管道或工作流,有事件的起点,过程,终点,并且每个关键步骤都包含日期字段,如订单数据,累计快照事实表一行就是一个订单,当订单产生时插入一行,订单发生变化时,这行就被修改;
.无事实的事实表:以上讨论的事实表度量是数字化的,当然实际应用中绝大多数都是数字化的度量,但是也可能会有少量没有数字化的值,但是还很有价值的字段,无事实的事实表就是为这种数据准备的,利用这种事实表可以分析发生了什么;
.聚集事实表:聚集就是对原子粒度的数据进行简单的聚合操作,目的就是为了提高查询性能,如我们需求是查询全国所有门店的总销售额,我们原子粒度的事实表中每行事实每个分店每个商品的销售额,聚集事实表就可以先聚合每个分店的总销售额,这样汇总所有门店的销售额时计算的数据量就会小很多;
.合并事实表:这种事实表遵循一个原则,就是相同粒度,数据可以来自多个过程,但只要它们属于相同粒度,就可以合并为一个事实表,这类事实表特别适合经常需要共同分析的多过程度量;
维度表:
每个维度表都包含单一的主键列,维度表的主键可以作为与之关联的任何事实表的外键,维度表行的描述环境应与事实表完全对应,维度表通常比较宽,是扁平型非规范表,包含大量低粒度的文本属性;
维度表示你要对数据进行分析时所用的一个量,例如要分析产品销售情况,你可以选择按类别进行分析,或按区域进行分析,每个类别就构成一个维度,维度表一般都有一个唯一的主键,然后在表中存放了详细的数据信息;
总体上,在数据仓库中不需要严格遵守规范化设计原则,因为数据仓库的主导功能就是面向分析,以查询为主,不涉及数据的更新操作,事实表的设计是以能够正确记录历史信息为准则,维度表的设计是以能够以合适的角度来聚合主题内容为准则;
维度表结构
维度表谨记一条原则,包含单一主键列,但有时因业务复杂,也可能出现联合主键,但要尽量避免,如无法避免,也要尽量确保是单一的,如果维表的主键不是单一,和事实表关联时会出现数据发散,导致最终结果出现错误;
维度表通常比较宽,包含大量低粒度的文本属性;
跨表钻取
每个查询的行头包含相同一致性属性时,将不同的查询结果进行融合,排序等(意思是union之类的?)
钻取:上钻:向着更高维度汇总数据;下钻:向着更低维度查看更详细数据;
退化维度
退化维度就是将维度退回到事实表中,因为有时维度除了主键没有其他内容,虽然也是合法维度键,但是一般都会退回到事实表,减少关联次数,提高查询性能;
多层次维度
多数维度包含不止一个自然层次,如日期维度可以从天到月周年的层次,所以有些情况下同一维度存在不同层次;
维度表空值属性
当给定维度行没有全部填充时,或者当存在属性没有被应用到所有维度行时,将产生空值维度属性,上述两种情况,推荐采用描述性字符串代替空值,如使用unknown,不可用 替换空值;
日历日期维度
在日期维度表中,主键的设置不要使用顺序生成的ID来表示,可以使用更有意义的数据,比如将年月日拼接起来,即YYYYMMDD,或者更加详细的精度;
标签：数据仓库,建模,集市,维度,数据,事实 From： https://www.cnblogs.com/19951009Z/p/16620894.html