精华内容
下载资源
问答
  • 统计各个主题对象的当天行为,服务于DWT 层的主题宽表,以及一些业务明细数据, 应对特殊需求(例如,购买行为,统计商品复购率) DWS层表设计原则 通过外键获取相关的度量值,整合多个dwd事实表度量值构成新表。 ...

    DWD层维度建模

    在这里插入图片描述

    DWD 层需构建维度模型,一般采用星型模型,呈现的状态一般为星座模型。

    维度建模一般按照以下四个步骤:

    选择业务过程→声明粒度→确认维度→确认事实

    DWD层事实表设计原则
    联系维度的外键+度量值

    DWS层建模

    在这里插入图片描述

    统计各个主题对象的当天行为,服务于DWT 层的主题宽表,以及一些业务明细数据,

    应对特殊需求(例如,购买行为,统计商品复购率)

    DWS层表设计原则
    通过外键获取相关的度量值,整合多个dwd事实表度量值构成新表。

    DWT层建模
    以分析的主题对象为建模驱动,基于上层的应用和产品的指标需求,构建主题对象的全

    量宽表。

    DWT层事实表设计原则
    维度关联的事实表度量值+开头、结尾+累积+累积一个时间段。

    比如下单

    开头:
    第一次下单时间

    第一次下单金额

    结尾:
    最后一次下单时间

    最后一次下单金额

    结尾+累积:
    累积下单金额

    累积下单次数

    结尾+累积一个时间段:
    最近一个月(30天)下单时间

    最近一周(7天)下单时间
    在这里插入图片描述
    总结
    事实表就是动作,如支付,下单,退款,架构

    维表就是名词,优惠券,活动,商品,用户

    数仓就是通过名词去组合动作描述一件事,某人某日某时某地在某处购买某物花了多少钱。

    展开全文
  • 目录 • 概述 •维度表设计 •代理键 •稳定维度 •缓慢渐变维 •拉链表详解 •事实表设计 •事实表设计 ... • 明细事实表 ... 数据仓库维度建模主要分为维度表设计事实表设计,下面分别...

    数据仓库之维度建模流程

    • 选定业务过程;

    • 声明粒度;

    • 确定维度;

    • 确定事实;

    1.确认业务过程

        选择建模的业务过程,比如园区中库存单元被租赁出去

     

    2.确认粒度

        保证维度粒度为最小粒度,保证以后的可扩展性,以及向下钻去的灵活性。特殊说明,除周期性快照表,其他类型的事实表的时间粒度都保持操作性系统中的时间,即明细到时分秒。

     

    3.确认维度

        也就是确认业务过程设计到的维度,维度主要用途是回答“what, when, where, how”等这样的问题。BI应用上,维度主要用来做筛选、分组、钻取。

        由于维度相对数据量较少,在hive中建立的维度表,不考虑使用分区。

    3.1 缓慢渐变维

        数据仓库需要追踪历史,因此部分维度需要采用缓慢渐变的方式,计划采用如下方式:

        在维度表上增加起始日期(begin_date)与结束日期(end_date),以及当前状态(current_status)

    3.2 维度一致性

        在确认最小粒度之后,维度表尽量一次建成以后,后续可重复使用,如此可以保证维度的一致性。

     

    4.确认事实

        确认需要衡量的事实,例如进出园区人数,次数;园区租赁金额等。

    •    事务型事实表:主要用来捕捉特定维度范围内,会经常发生的一系列基本无序的事件。

    •    周期型快照事实表:按照一定时间粒度(day/month),保存特定维度范围内的性能度量。例如,每日进出园区的人数。

    •    累积快照事实表:用来捕捉一系列有序的事件,在不同时间范阶段内性能度量。例如,CRM系统中有lead(潜在意向客户)->deal(签约中的客户) -> lease(发生租赁的客户),这样一系列的流程可以考虑使用累积快照事实表。

    展开全文
  • 一般常规的数据仓库层级结构可分为:ods、dw(可在细分为dwd...dw层:称为中间层,按主题建模(域->主题)的明细数据层,数据粒度与ods层一致。 dm层:称为数据集市层,集市层是按照业务主题、分主题构建出来的、面向特

    一般常规的数据仓库层级结构可分为:ods、dw(默认为汇总数据层,也可在细分为dwd(明细)与dw(汇总)两层)、dm共三层:

    ods层:称为接口层或近源数据层,表结构与源系统表结构高度相似,通常在ods层主要会做字段的筛选,枚举值转换,编码统一,异常&缺失数据处理等操作。

    dw层:称为中间层,按主题建模(域->主题)的明细数据层,数据粒度与ods层一致。

    dm层:称为数据集市层,集市层是按照业务主题、分主题构建出来的、面向特定部门或人员的数据集合。


    维度建模源于Kimball提出的总线式的自下而上(DM-DW)的数据仓库架构。

    特点:

    1.模型结构简单,星型模型为主;

    2.开发周期短,能够快速迭代;

    3.维护成本较高;


    范式建模源于Inmon提出的集线器的自上而下(EDW-DM)的数据仓库架构。

    特点:

    1.同一份数据只存放在一个地方,因此只能从一个地方获取,没有数据冗余,保证了数据一致性;

    2.解耦(系统级与业务级),方便维护;

    3.开发周期较长,开发成本较高;


    当下的数据仓库模型架构设计中,dw层通常会采用范式建模,并且可以根据实际情况允许存在一些冗余。dm层通常会采用维度建模,因为采用维度建模构建出来的数据模型更加符合普通人的认知、易于被普通人所理解,从而有利于数据的推广使用。




    展开全文
  • 比方在事实维度(或退化维度)中一个订单和明细号组合而成的ID,对应的就是事实表中的一条数据,这就是一对一的关系。比方说在产品维度中,一个产品维度成员可能对应着多个事实数据成员,这就是一对多的关系。说简单点...

    开篇介绍

    对于维度成员和事实数据直接的关系看到更多的可能还是一对一,一对多的关系。比方在事实维度(或退化维度)中一个订单和明细号组合而成的ID,对应的就是事实表中的一条数据,这就是一对一的关系。比方说在产品维度中,一个产品维度成员可能对应着多个事实数据成员,这就是一对多的关系。说简单点,就是事实表的外键引用了维度表的主键,形成了这种关系。

    下面的这个例子就是一种多对多的情况,通常情况下,如果维度和度量值组中间是多对多的关系,那么在它们之间就需要创建一个中间事实表。 这个中间事实表的主键在数据仓库中可以不需要设计,包括与左侧维度表和右侧事实表之间的主外键关联也不需要设计,直接在数据源视图中修改逻辑关联就可以了 (在我的脚本代码中为了方便都主动的加上了主外键关联)。

    如果要在 DimSalesReason 和 FactInternetSales 建立关联的话,那么就需要通过定义多对多关系来实现。

    DimSalesReason - 销售原因维度,即每笔订单都会对应一个或者多个销售原因,比如因为价格原因和产品推广原因客户购买了,或者就是单单价格原因客户购买了。

    类似于这种结构,我们一般可以这样来操作:

    1. 第一步:基于 DimSalesReason 维度表创建一个常规维度 Sales Reason。
    2. 第二步:基于 FactInternetSales 事实表创建一个事实维度 InternetSalesFact。
    3. 这样一来在定义维度用法时:
    4. 第三步:SalesReason 对度量值组 Internet Sales Reason (即FactInternetSalesReason) 将形成一种一对多的关系,常规用法。
    5. 第四步:InternetSalesFact 对度量值组 Internet Sales Reason (即FactInternetSalesReason) 将形成一种一对多的关系,常规用法。
    6. 第五步:InternetSalesFact 对度量值组 Internet Sales (即FactInternetSales)将形成一种一对多的关系,事实用法。注:广义上来讲,这里的一对多关系其实也包含了一对一的关系。
    7. 第六步,最后 Sales Reason 维度将借助于 度量值组 Internet Sales Reason 关系到事实维度 InternetSalesFact,并通过事实维度 InternetSalesFact 关联到度量值组 Internet Sales而形成一种多对多的关系。

    第一步

    首先还是先将 DimSalesReason 这个维度创建好。

    第二步

    添加一个事实维度,选择事实表 FactInternetSales。由于事实表并不存在类似于维度的 NameColumn 描述信息,并且这个事实表也非常的特殊,因为它是由 SalesOrderNumber 和 SalesOrderLineNumber 共同组成的主键列。由于相对而言 SalesOrderNumber 比 SalesOrderLineNumber 更有意义一些,这里选择 SalesOrderNumber 作为 Name Colum。

    不需要与其它的维度进行关联。

    不需要太多的属性,就留一个主 KEY 就可以了。

    下一步并将维度名称命名为InternetSalesFact, 把 Fact 写在最后表示它是一个事实维度。

    两个维度创建好了之后,保存并部署项目,同时修改 Cube 向 Cube 添加一个度量值组 - Fact Internet Sales Reason,这个维度只是一个中间维度。

    可以隐藏 Fact Internet Sales Reason Count 度量值,因为实际上没有特别大的意义,讲它的 Visible 属性设置为 False。

    一会将度量值组名称改为 - Internet Sales Reason。

    保存并部署,然后编辑多维数据集的维度用法, 添加 SalesReason 维度后在 SalesReason 与 Internet Sales Reason 之间默认出现一个 Sales Reason。

    第三步

    SalesReason 对度量值组 Internet Sales Reason (即FactInternetSalesReason) 将形成一种一对多的关系,常规用法。

    点击查看它们默认的关系,注意这里只是 SalesReason 维度和这个中间度量值组之间的关系,实际上 SalesReason 和 Internet Sales 之间是没有关联的。

    在维度用法中添加新的维度即事实维度 InternetSalesFact,将表现第四步和第五步的行为。

    第四步

    InternetSalesFact 对度量值组 Internet Sales Reason (即FactInternetSalesReason) 将形成一种一对多的关系,常规用法。

    第五步

    InternetSalesFact 对度量值组 Internet Sales (即FactInternetSales)将形成一种一对多的关系,事实用法。

    第六步

    最后 Sales Reason 维度将借助于 度量值组 Internet Sales Reason 关系到事实维度 InternetSalesFact,并通过事实维度 InternetSalesFact 关联到度量值组 Internet Sales而形成一种多对多的关系。

    可以看到 SalesReason 和 InternetSales 之间形成了多对多关系。

    保存并部署,浏览一下 Cube 中的数据。可以看到订单号为 SO43697 的这笔订单有两个销售原因 - Manufacturer 和 Quality,虽然两个销售原因对应的销售额都是 3578美元,但是这仍然是属于一笔订单,因此看到销售类别 Other 的 Internet Sales Amount 还是显示的是 3578 美元。

    数据库中的订单对应了两个销售原因,但它的销售额仍然是 3578.27 而不是 两个 SalesAmount的总和。

    参看与本文相关的文章如下

    SSAS 系列 - 多维数据集维度用法之一 引用维度 Referenced Dimension

    SSAS 系列 - 多维数据集维度用法之二 事实维度(退化维度 Degenerate Dimension)

    引起争论的结论

    虽然这篇文章讲到了多对多维度的实现,但是实际开发中尽量避免使用这种关联关系,因为多对多的关系处理在数据聚合上效率肯定比通常一对一,一对多的效率要低很多。同时由于在建立多对多关系的时候需要额外创建一个事实维度来实现这种多对多的关联,因此额外的事实维度需要被创建,在维度处理上变得更复杂,个人建议在设计的时候应该尽量避免这种关系的出现。

    PS

    感谢各位在本贴的留言,回复与讨论。上面的这个结论下的有点不严谨,个人观点,希望不会误导大家,不过大家可以充分讨论。关于这个多对多的设计能否在某些场景下避免的问题,我保留我的意见,这个问题待续。

    更多 BI 文章请参看 BI 系列随笔列表 (SSIS, SSRS, SSAS, MDX, SQL Server)    如果觉得这篇文章看了对您有帮助,请帮助推荐,以方便他人在 BIWORK 博客推荐栏中快速看到这些文章。

    展开全文
  • 今天大家分享下,在做业务预测时,需要使用到天气方面的数据,这些数据需要从一些网站中进行收集,这是我们就要用到爬虫,收集到一个完整的天气预报数据(用excel保存): 1、爬虫前准备: ① python 3.6已正常...
  • 首先sonar分析的质量数据维度明细在metric表中:图中很关键的数据:覆盖率,新增覆盖率;代码行覆盖率,代码行新增覆盖率覆盖率是字节码的比值,代码覆盖率是代码行层面的统计,所以一般代码行覆盖率一般>=...
  • 维度建模提倡针对某一主题,通过建设维度和事实来快速建设数据仓库。与维度建模相对应的自然是Inmon的范式建模。在上篇也提到范式建模非常适合应用于中间明细层的建设,那么在DW/DM层为什么选择使用维度建模呢?这是...
  • 公共维度模型层(CDM):存放明细事实数据、维表数据及公共指 标汇总数据 ,其中明细事实数据、维表数据一般根据 ODS 层数据加工生成 :公共指标汇总数据一般根据维表数据和明细事实数据加工生成。 CDM 层又细分为 ...
  • 依据自己负责的内容及SN的一些规范等,将这一阶段的模型工作进行一个思考总结。 一、仓库字段、表等命名的规范 数据仓库建设目的,当中重要的一个方面就是建立统一的全局视图;表、字段等的规范命名就是仓库全局...
  • 数仓之事实表和维度表(一)

    千次阅读 2018-12-27 16:47:53
    事实表: 事务事实表:(->明细事实表->聚合事实表) ...明细事实表(单事件事实表,流程事实表): 一般位于DWD层,该层事实表设计不进行聚合,汇总等动作,仅做数据规范化...
  • 在SN做仓库项目,根据自己负责的内容及SN的一些规范等,将这一阶段的模型工作进行一个思考总结。 一、仓库字段、表等命名的规范 数据仓库建设目的,其中重要的一个方面就是建立统一的全局视图;表、字段等的规范...
  • 电信互联网行业数据安全标准体系包括基础共性、关键技术、安全管理、重点领域四大类标准。基础共性标准包括术语定义、数据安全框架、数据分类分级,相关标准为各类标准提供基础性支撑。关键技术标准从数据采集、...
  • 维度建模之案例详解

    2020-10-12 21:13:03
    下面我们分别来学习维度表设计事实表设计: •维度表设计:代理键,稳定维度,缓慢渐变维,拉链表 •事实表设计:事实表设计,明细事实表,聚合事实表 •数据仓库之拉链表详解 1.维度表设计 1.1 代理键 ...
  • 随着公司业务不断发展,数据种类存储呈现爆发式增长,繁多的业务数据如何被各业务中心分析使用,如何有效组织管理大量业务数据,减少大数据平台相近逻辑重复计算、相近数据...明细区:采用维度建模方法,整合近源
  • 数据仓库面试

    2021-04-09 09:51:46
    1、数仓构建 1. 前期业务调研,如需求调研、数据...其中公共维度模型层包括明细数据层(DWD汇总数据层(DWS)。 公共维度模型层(CDM):存放明细事实数据、维表数据及公共指标汇总数据,其中明细事实数据、维...
  • 电商数据仓库理论

    2020-06-23 21:22:44
    电商数据仓库理论数据仓库分层为什么要分层数据集市与数据仓库概念数仓命名规范表命名脚本命名规范表字段类型数仓理论范式理论范式概念函数依赖三范式区分关系建模和维度建模关系建模维度建模维度表和事实表数据仓库...
  • 数据治理之模型实施

    2019-10-31 09:56:07
    实施工作流: 1)数据调研: ① 业务调研:确定数据仓库要包含所有的业务领域合适各业务各自...明细数据和汇总数据怎么设计? 2)架构设计: ① 数据域划分:对业务模块和维度进行高度抽象的集合 ② 构建总线矩...
  • 数据分层使的数据具有清晰的数据结构,便于进行数据血缘追踪,能够把复杂问题简单化,减少重复开发,屏蔽原始数据的异常业务的影响。每个企业或组织由于各自业务、规范、目标不尽相同,分层的策略可能会有一些区分...
  • 数据质量

    2020-12-03 00:05:43
    数据测试整体从一致性精确性两个点去做测试。 条数核对。与底层逻辑的数据量进行核对,数据条数保持一致 整体调查。查出每一个字段,看是否有字段全空,全0等单独列异常情况存在。 明细层事实数据着重测试。对于...
  • DW层:数据仓库层,一般用来存放明细数据,根据不同业务类型将ODS的数据进行关联融合,得到不同业务类型的明细表。明细表可以提供给前端报表直接查询明细使用,也可供后面的数据汇总使用。 DM层:数据集市层,根据...
  • 数据治理之模型设计

    2019-10-31 09:52:00
    2)公共维度层:存放明细事实数据、维表数据、公共指标汇总 ① 明细事实数据、维表数据从ODS层数据加工而来,公共指标汇总数据从细事实数据、维表数据加工而来 ② DWDDWS层主要的作用是组合相似数据,建立...
  • 数据仓库分层

    2019-11-24 00:26:22
    这种设计没有问题且简单明了,但是如果业务场景复杂,数据种类多,维度多,那么数据仓库的设计就尤为重要,结构清晰明了的数据仓库设计将方便对问题数据进行排查,数据仓库可分为:ODS(原始数据)、DWD(明细视图,...
  • 数据链路

    2020-07-15 09:07:20
    ODS层:ODS层属于操作数据层,是直接从业务系统采集过来的最原始的数据,包含了所有业务的变更过程,数据粒度也是最细的。 DWD层:是在ODS层基础上,...ADS层:个性化维度汇总层,对于不是特别通用的统计维度数据
  • 数据仓库——上篇

    2020-11-05 23:33:13
    文章目录一、数仓分层1.1 数仓的分层1.1.1 ODS(原始数据层)层1.1.2 DWD(数据明细层)层1.1.3 DWS(数据服务层)1.1.4 DWT(数据主题层)1.1.5 ADS(数据应用层)1.1.6 总结二、数仓理论2.1 范式、2.2 函数依赖2.3 常见的...
  • 对于刷卡消费类的数据分析,如果能够拿到所有人的信用卡消费数据(一...即数据分析本身是KPI驱动的,那么如果从最原始的数据明细入手,应该如何进行展开和数据维度的拓展? 对于有信用卡的人,我们收到的信用卡账...
  • 数据仓库解决什么问题 1、将各种数据源整合到一起统一数据中心,解决数据壁垒。 <仓库的集成性特点> 2、脏数据清洗,简化业务复杂结构数据。 3、规范表、字段名称,统一... DWD 明细数据层 DWS 汇总数据层

空空如也

空空如也

1 2 3 4 5 6
收藏数 114
精华内容 45
关键字:

明细数据和维度数据