数据仓库之维度建模介绍-- 未写完,待更新

举报
米兰的小铁匠 发表于 2021/01/07 23:51:42 2021/01/07
【摘要】        数据仓库是一个面向主题的、集成的、非易失的、反应历史变化的数据集合,用于支持管理决策。数据仓库的首要目的是数据集成、将多个分散的、异构的数据源整合到一起,便于后续分析。       数据仓库第一个特征是面向主题的,对于零售商而言,主题域可以是顾客、产品、库存、销售、销售商等,对于生产商而言,主题域可以是产品、订单、销售商、材料单、原材料等。不同类型的公司,其主题是不同的。   ...

       数据仓库是一个面向主题的、集成的、非易失的、反应历史变化的数据集合,用于支持管理决策。数据仓库的首要目的是数据集成、将多个分散的、异构的数据源整合到一起,便于后续分析。

       数据仓库第一个特征是面向主题的,对于零售商而言,主题域可以是顾客、产品、库存、销售、销售商等,对于生产商而言,主题域可以是产品、订单、销售商、材料单、原材料等。不同类型的公司,其主题是不同的。
       数据仓库第二个特征是集成的,其数据可以是从多个不同的数据源传送过来,数据进入数据仓库中后,进行转换汇总等。数据进入数据仓库后,源数据通常会有一些不一致,如不一致的格式,集成后要消除一些不一致性,为用户提供一个统一的数据视图,一致性处理包括命名习惯、关键字结构、度量单位等。
       数据仓库第三个特征是非易失的,数据仓库的数据在装载是是以静态快照的方式进行的,后续发生变化后,一个新的快照记录就会写入数据仓库,数据仓库会保存数据的历史变化。新的数据一般加入仓库而不是取代,数据仓库不断吸收新的数据,并与原来的数据进行增量式集成。
       数据仓库的第四个特征是随时间变化,即数仓中的每个数据只是在某个时间是准确的。数据仓库中的数据时间期限要远远长于操作型系统中的数据时间期限。操作型数据仓库含有当前值的数据,这些数据的准确性在访问时是有效的,同样当前值的数据能被更新,而数据仓库中的数据仅仅是一系列某个时刻生成的快照。

       一个经典的数据仓库数据模型通常划分为3层,操作数据层ODS、中间数据层 dw层、应用数据层ADS。
       操作数据层ODS存储了用于分析当前和集成后的运营数据,它的结构与数据来源一般都与数据仓库相同,ODS提供源数据系统中抽取并清洗了的数据,在该层中会同步并结构化数据,保留历史数据并清洗数据。

        DW层又细分为DWD明细数据层和高粒度(粒度的概念会在下文中讲解)汇总DWS汇总数据层以及低粒度汇总DMB层,
        DWD是业务层和数据仓库的隔离层,为DW层提供来源明细数据,提供业务系统细节数据的长期沉淀,为未来分析类需求的扩展提供历史数据支撑 。数据模型与ODS层一致,不做清洗转换处理,为支持数据重跑可额外增加数据业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge处理。其为最细粒度的明细层事实表。
        DWB保存低粒度汇总加工数据,根据DWD明细数据进行转换,如维度转代理键、身份证清洗、会员注册来源清晰、字段合并、空值处理、脏数据处理、IP清晰转换、账号余额清洗、资金来源清洗等;DWS保存高粒度汇总数据,根据DWB层数据按各个维度ID进行高粒度汇总聚合,如按交易来源,交易类型进行合。                     ADS层存放数据产品的统计指标数据,根据DW和ODS层数据加工生成,可以直接用于BI报表展示。

       三层分层建模的好处
       减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。
       清晰数据结构:每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地定位和理解。
       数据血缘追踪:简单来讲可以这样理解,我们最终给业务诚信的是一能直接使用的张业务表,但是它的来源有很多,如果有一张来源表出问题了,我们希望能够快速准确地定位到问题,并清楚它的危害范围。
       把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。
       同时可以清洗脏数据并屏蔽业务影响,不必改一次业务就需要重新接入数据。

       维度建模(dimensionality modeling) DM 是数据仓库工程中最经典的建模方式,其经典的代表是星形模型,星型模型时,冗余的多对一属性会被移动到单独的维度表中,维度表被标准化为第三范式,星型模型由一个事实表和一组维度表组成,维度表之间没有关联,以事实表为核心,维度表围绕核心呈星型分布。

数据仓库维度建模星型.jpg

       在一些场景下会使用雪花模型,每个维度模型都由一个带有组合主关键字的表和一系列较小的表组成,前者称为事实表,后者称为维表,每一个维表有一个主关键字,它对应着事实表中的组合关键字中的一项,维表可以向外连接关联多个子维表。雪花模型的事实表在中央,周围是规范的维表。

数据仓库维度建模雪花.jpg

       星型和雪花模型都是单事实表对应多维表的方式,但在很多情况下维度空间内的事实表不止一个,而一个维表也可能被多个事实表用到即共享维度信息。很多时候维度建模都采用的是星座模式。星座模型的事实表在中央,周围是规范和非规范的维表。星座模式使用了非规范化的星型模型和规范化的雪花模型的混合体。

数据仓库维度建模星座.jpg

       星型、雪花、星座模型关系如下:雪花模式是将星型模式的维表进一步划分,使各维表均满足规范化设计。而星座模式则是允许星形模式中出现多个事实表。

数据仓库维度建模关系.jpg


事实表的技术基础

        发生在现实世界的操作型事件,其产生的可度量的数据值,存储在事实表中,事实表行对应一个度量事件。除数字度量外,事实表包含外键,用于与之关联的维度,也可以包含可选的退化的维度键和日期等。

       事实表中的数字度量可分为可加、半可加 、不可加事实,下文中会结合业务讲述该三类度量。一致性事实是如果某些度量出现在不同的事实表中,针对该事实的计数定义是相同的。

       事务事实表的一行对应空间或时间上的某点的度量事件,事务事实表可以稠密或稀疏,仅当存在度量时才会建立行。度量数字事实必须与事务粒度保持一致。对于单事务事实表,一个业务过程建立一个事实表,反应一个业务过程的事实,多事务事实表,在同一个事实表中反应多个业务过程。多个业务过程是否放在一个事实表中,要分析不同的业务过程之间的相似性和业务源系统。如零售交易中的下单、支付、成功完结三个业务过程存在相似性,属于订单处理的一环,可以放在同一个事务事实表中。事务事实表可以很好的跟踪一个事件,并对其进行度量分析。


周期性快照事实表
       快照事实表在确定的时间间隔内对实体的度量进行抽样,可以通过确认事实表的快照粒度和采样的状态度量来创建快照事实表。


累计快照事实表

       累计快照事实表的行汇总了发生在过程开始和结束之间的度量事件,管道和工作流过程具有定义的开始点、标准的中间过程、定义的结束点。累计快照中的一行,订单系统中对应一个具体的订单,当订单产生是插入一行,当管道过程发生时,累计事实表行被访问并修改。除了日期外键和每个关键过程关联外,累计事实表中包含其他维度和可退化的维度的外键。



三种事实表的对比

 

事务事实

周期快照

累计快照

时间

离散事务时间点

有规律可预测间隔产生快照

以时间跨度不确定的不断变化的工作流

日期维度

事务日期

快照日期

业务流程涉及的多个日期

粒度

每个是事务一行

每行代表一个时间周期的实体

每行代表一个实体的生命周期

事实

事务事实

累计事实

业务过程事实和时间间隔的事实

事实表加载

插入

插入

插入与更新

事实表更新

不更新

不更新

变更时更新

 

无事实事实表
       无事实事实表是不含事实或度量的事实表,其可以用来支持业务过程的度量。可以用其分析发生了什么。其主要有两种,一种是事件类,记录事件的发生。第二种是条件、范围、资格类的。记录维度与维度多对多之间的关系。

聚集型事实表

        聚集型事实表通过汇总明细粒度数据来获得改进查询性能的效果,将使用频繁的公用数据聚集成公共汇总层,聚集表的维度和度量需要和查询明细的粒度数据一致。确认聚集维度后通过一致性上钻获取聚集事实表。

合并事实表将来自多过程的事实横向钻取,以相同粒度一致性维度合并放在一个单一的事实表中。  

维度表技术基础
       每个维度表都包含单一的主键列,维度表的主键可以作为与之关联的任何事实表的外键。

       多层次维度包含不止一个自然层次,例如日历日期维度,它可以从天到周到月到年的层次进行划分,位置密集型维度可以包含多个地理层次。
       日历日期维度是连接到实际事实表使能够按照日期、月份、财务周期和日历上的特殊日期进行导航。
        杂项维度是事务型商业工程产生的一系列混杂的、低粒度的标识和指示器。单独的将不同的维度合并到一起的杂项维度。
       管理桥接表·

       支架维度包含对其他维度的引用,被引用的辅助维度称为支架维度,外支架是联结到其他维度表的维度表。并不是完全标准化的星型模型。
退化维度
       退化维度没有自己的属性,但要将其放入事实表中来对这一现状进行建模,但没有关联的维度表,退化维度常用于交易和累计快照事实表中。


维度层面上的操作有向上、向下、横向、旋转等

       向上钻取就是去掉分组列,获取汇总数据。比如把四维销售数据(所在地、时间、类型、分店维)上卷到(所在地、时间、类型维)三维销售维度。
       向下钻取意味着给我更多的详情,是向上钻取的逆操作,从事实表中请求更为精细和更细粒度的数据,即增一个维度属性创建一个分组列。通过维度引入执行下钻,比如把三维销售数据(所在地、时间、类型维)下钻到(所在地、时间、类型、分店维)四维销售数据。
       横向钻取是相同的粒度链接两个或多个事实表的过程。也可称为跨表钻取。
       旋转指能旋转行列数据,换一个视角看相同的数据,例如将所在地作为x轴,时间作为y轴,显示销售收入,可以旋转为时间作为x轴,所在地作为y轴的操作。

       开发一个数据仓库主要有两种方法学,Inmon的企业信息工厂(CIF)和Kimball的业务维度生命周期,kimball业务维度生命周期如下图。本文主要介绍Kimball的业务维度生命周期中的维度建模阶段。

kimball业务流程.PNG



一个维度模型的创建可以通过两个阶段实现,第一个阶段是创建高层维度模型,第二个阶段通过识别模型的维度属性向模型中添加细节。

        本文以零售和库存业务为例。

        第一个阶段的设计可以划分为以下几个步骤。如图


维度建模步骤.PNG


1. 选择业务过程
     该活动的结果创建一个数据仓库总线矩阵。
     我们需要采用数据仓库总线架构来构建一种架构化、增量式的数据仓库。
     总线矩阵采用组织的业务过程为矩阵行,重要的是业务过程,使用公共维度来表示矩阵的列,列有助于创建核心维度表。                                                               零售业务中的交易流程,数据要能够分析被销售的产品,在那个日期、那个商店、那个渠道、何种促销环境下被销售。



2. 确认粒度
       粒度决定事实表中记录什么,即事实表中每一行表达的层次细节。比如客户销售事务上的每个产品扫描到一行、仓库中每种材料库存水平的每日快照采用一行表示、医生开具的票据的列表内容项采用一行表示。针对不同事实表粒度,要建立不同的事实表,但同一事实表中不要混用多种不同的粒度。粒度是指数据仓库的数据单位中保存数据的细化或综合程度的级别。细化程度越高,粒度级就越小;相反,细化程度越低,粒度级就越大。粒度影响存放在数据仓库 中的数据量的大小,同时影响数据仓库所能回答的查询类型。在数据仓库中的数据量大小与查询的详细程度之间要作出权衡。

粒度 细节.PNG

       原子粒度数据具有强大的多维性,事实度量越详细,越能获得更确定的事实表。也可以通过汇总粒度来表示对原子数据的聚集,选择了较高级别的维度,就限制了获取更细节维度的可能,无法实现用户下钻细节的需求。

3. 选择维度
        选好业务过程并确定好粒度后,就可以确认维度了,维度设置了对事实表的事实提问的上下文。简单上线文信息在以往使用字典、目录、系统监视器等管理的。复杂上下文信息描述的是和简单上下文信息相同的数据,但是从一个不同的侧面描述。外部上下文信息是那些公司以外的随时间变化的信息方面起重要作用的信息。在零售业务中,日期、门店、产品、促销、渠道、支付方式都可以作为其维度信息。


4. 选择事实
       事实表的粒度决定哪些事实在维度模型中可以使用。事实表包含与其描述过程中有关的所有事实。零售中的事实可以包括销售数量、单价、折扣、价格等事实。完全可加事实如销售数量、销售、成本额、利润。不可加事实如利润率、单价等。半可加事实库存、余额等。


零售事实.PNG



第二个阶段确定维度模型的所有维度属性

       此阶段涉及添加一些属性,他们是在业务需求分析阶段,由用户指出的在分析所选的业务流程中所必须用到的属性,维度模型的有用性维度表中的属性的范围和性质决定。

       选择数据仓库的持续时间,持续时间测定事实表回溯多长时间。
       跟踪缓慢变化的维度,数据仓库的一个重要特征是反映历史变化,如何处理维度的变化时维度设计的重要工作,维度的属性不是静态的,它是随着时间流逝发缓慢的变化,与事实表的快速增长相比,维度变化相对缓慢。缓慢维度变化主要有三种类型,类型一、重写纬度值,用修改的维度属性覆盖旧值。类型二、插入新的维度行,使得在同一个维度记录中可以同时访问该属性的新旧两个值。类型三、添加新的维度列,创建一个新的维度记录。



维度变化.PNG

维度建模的优缺点

优点:


        数据冗余相对小,结构清晰,便于做数据分析,维度建模是可预测的标准框架,允许数据库系统和最终用户查询工具在数据方面生成强大的假设条件,星型连接模型可以忍受不可预知的用户行为变化,切换使用不同的维度查询很方便。
缺点:
       与ER建模相比,维度建模反范式,浪费存储,不易扩展,构建前需要大量数据预处理,业务发生变化时,需要重新进行维度定义,维度变化对数据更新量大,预处理过程中,会导致数据的大量冗余,同时使用成本相对较高,查询时需要关联多张表。单纯的依靠维度建模,不能保证数据来源的一致性和准确性。



数仓与数据湖的区别

      很多时候,数据仓库和数据湖被认为是等同的,二者用到的大数据组件技术栈也很相似,但二者代表企业要打成的不同目标。

数据湖

数据仓库

能够处理所有类型的数据,结构化数据、半结构化数据、非结构化数据,数据类型依赖于数据源系统的原始数据类型

只能对结构化数据进行处理,而且schema信息必须事先定义

数据湖包含更多相关信息,能够为企业挖掘新的运营需求

数据仓库通常用来存储和维护长期数据,数据可以被按需访问

拥有足够强的算力用于处理和分析所有类型的数据,分析后的数据会被存储起来供使用

处理结构化数据,将他们转化为多维数据,或者报表,以满足后续报表和数据分析需求。

 

 


后记

     流批一体、湖仓一体大势所趋,体验数据湖请来华为云EI-数据湖探索 DLI。

参考:

     数据仓库工具箱

     数据库系统设计、实现与管理

    





 



      

    

  



【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。