数据仓库指北

2022-12-17 15:26:35 浏览数 (3)

文章开头介绍下,这篇文章的第一部分Q&A环节,主要来源于日常工作沉淀,于是决定抽空写篇原创博文来做技术分享

原创推文链接:https://mp.weixin.qq.com/s/LiCZz1GHhH4CsBIl5VdZjA

通过大纲对本文内容进行概览,你能通过文章学到什么: 1. 数据仓库的基础必备问题 2. 数据仓库的几种数据表 3. 数据仓库分层设计及各层作用 4. 数据仓库几种数据模型 5. 维度建模

一、 灵魂十二问

Q1:大数据的数据来源?

埋点上报数据:如页面浏览、点击、评论等,主要体现在埋点事件的设计,区分出公共字段和业务埋点事件参数,埋点事件的设计好坏程度直接会影响数据仓库流量域的建设,埋点数据时常可以用来分析用户行为 业务数据库数据:如订单、商品等业务过程的数据,主要体现在业务的数据库中 日志数据:如上报的性能日志等,主要体现在服务器日志文件中,通过采集解析的方式拉取

Q2:数据集市?

数据集市可以理解为是一个微型的数据仓库,具有更少的主题域,服务对象更小,可以是部门级别,而数据仓库则是服务于企业级别。数据仓库可以统一规划数据,避免数据孤岛。

Q3:为什么做数据分层设计?

大数据处理时,作为数据开发者,我们总会进行各种表关联或者表依赖,如果没有很好地规划表依赖,则会造成我们的数据表关系混乱复杂,不方便我们看清数据的整体生命周期及数据流向,甚至出现循环依赖的数据体系,于是数据分层就很有必要,可以直观看清数据流向,建造更加良好的数据体系。

Q4:数据分层的好处?

  • 1、清晰数据结构:每一个数据分层都有它的作用域和职责,在使用表的时候能更方便地定位和理解
  • 2、减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算
  • 3、统一数据口径:通过数据分层,提供统一的数据出口,统一对外输出的数据口径
  • 4、复杂问题简单化:将一个复杂的任务分解成多个步骤来完成,每一层解决特定的问题

Q5:数据仓库起到什么作用?

数据仓库,简称DW,是各源系统数据及日志数据的汇总落地处,为企业决策做制定过程,为产品业务改进做支撑,控制成本和提高产品质量,而数据仓库也不是数据的最终目的地,而是为数据最终目的地做准备,比如清洗、转义、分类、重组、合并、拆分、统计,数据要体现出价值,最终目的地则是为各类大数据应用系统服务,常用的有BI报表系统、用户画像、推荐系统、风控系统。

Q6:OLAP和OLTP的区别?

OLAP(On-Line Analytical Processing),即联机分析处理,主要应用在数据仓库,主要使用对象是决策者,对响应速度要求不高,强调多维分析能力,保留历史数据,数据大小一般是TB或PB级别。 OLTP(On-Line Transaction Processing),即联机事务处理,主要应用在数据库,主要使用对象是开发人员,对实时性要求高,保留数据最新状态,数据大小一般是GB级别。

Q7:什么是维度?

维就可以相当于角度,简单理解,按什么维度看数据就是你想从什么角度分析数据。

Q8:SCD缓慢变化维?

指的是数据仓库维度表中,那些随着时间会缓慢发生变化的维度,但是变化又不明显,即维度值变化不频繁的维度。 比如:员工表中,员工的岗位和工作地点 在特殊场景分析时就可以看成是缓慢变化维,因为存在升职和调岗行为。 分析下岗位为什么我说可以看成缓慢变化维,即入职那会是数仓开发工程师,几年后升职为数仓负责人;再分析下工作地点为什么我说可以看成缓慢变化维,即入职那会是在上海,几年后调岗到北京。

Q9:历史拉链表

是一种既能反应数据的历史变更状态,又能更大程度的节省数据存储的一种数据模型表。常用于表内属性状态经常会变更,比如订单表中的同个订单在每天都会有不同的订单状态(例如:今天下单创建,明天开始搬运,后天才更新订单完成),这是hive里比较常见的处理SCD缓慢变化维场景的一种技术。(PS:由于篇幅问题,这次不在这里详述,下次有空我再安排一篇文章细讲缓慢变化维和拉链表设计实现)

Q10:什么是次留用户,7日留存?

次留用户指的是统计当天的用户仍是昨天的那个用户,7日留存用户指的就是统计当天活跃的用户是在7天前同样活跃的用户。

Q11:上卷和下钻?

钻相对于维来说的话,就是可以改变维的层次,变换分析的粒度。向上钻取就是上卷,向下钻取就是下钻。

比如:把业务的内购流水按照时间维度进行向上聚集汇总数据,从而计算出天内购流水和月内购流水;把业务的内购流水沿着时间维向下细探到每个用户产生的明细流水数据,这就叫做下钻。

Q12:自然键和代理键?

搞清楚一个问题,在数据层面,键一般是用来唯一标识一个实体的所有属性。 自然键一般是已经存在的数据,字段本身含有一定的业务意义,例如:身份证号 代理键一般是无实际业务意义的数据,只具有主键作用,例如:自增ID 在ETL过程中,数据仓库中商品维表中的商品ID可能是自然键,而可以生成一个唯一标识的键作为代理键,而在前台业务系统中,商品ID倒是作为代理键来着。 使用代理键的优点: ①能够对集成多个操作型系统的数据进行整合时起到缓冲作用,因为不同业务系统的同主题下可能会出现唯一标识重复,就需要有一个代理键来进行整合唯一标识; ②代理键是整型的,减少了事实表中记录的长度,同样的IO可以读取更多的事实表记录,整型字段做外键关联效率也高,提升性能; ③使用代理键可用来处理缓慢变化维的情况,例如拉链表。 使用代理键的缺点:是使用代理键会增加ETL的复杂性,开发和维护成本高。

二、数据仓库的层级划分规范

表命名通用规范:层级前缀_主题域_表内容_周期_增量/全量表

DWD层:该层的粒度一般保持和ods层一样,不过有时为了数据开发时易用性,会退化一些维度进入事实表,减少事实表和维表的关联提高性能。通常是解析ods层日志数据或者对ods层业务数据进行维度建模,提升数据质量和规范化数据,做一些数据清洗的工作,比如去噪或去异常值。 DWB层:主要作用有2种:①对dwd层的数据按照维度进行收敛,做明细数据轻度聚合,出现一些业务统计原子指标。②把各个业务相关的可归为同主题的dwd表关联一起组成宽表获取更丰富的字段信息,使用宽表模型,做明细数据横向整合。 DWS层:在这层的数据表会比较少,根据业务线划分生成字段较多的宽表,比如充值统计、活跃统计,一般是多天累计的分区表,出现一些比如近30天的充值次数啊等指标。这层重点在于提高数据易用性,起数据开发优化作用。

三、数据仓库的一些数据表种类

1. 宽表

顾名思义是字段比较多的数据库大表,通常是把同个业务主题域的相关维度、指标、属性都关联放在同一张表,由于把不同内容都放在一张表这本身就已经破坏了表的设计范式,所以宽表会造成大量数据冗余,但查询性能和效率就会提高和便捷,相当于以空间换时间,宽表设计场景可在数据挖掘模型训练前的数据准备,减少表关联取数数量

2. 窄表

严格按照数据设计三范式,尽量减少数据冗余,缺点是修改一个数据可能要经常切换修改与之关联的表对应数据

3. 维度表

维度表是存放着维度属性的集合,维度数据固定或者变化缓慢,且数据量不大,把维度看成是分析数据的角度,就是按什么角度来分析数据

4. 事实表

事实表是数据仓库结构中的中央表,按维度表分析事实的详细数据,事实表中每行记录代表着一个业务过程事件,每行记录一般包含着:具备可累计的度量值 与维表关联的外键。 事实表有三类:

  • 事务型事实表事务一旦被提交,事实表数据被插入了,数据就不再变更,采用增量同步策略,即以每个事务或事件为单位。比如:订单支付事实表,一笔订单支付记录作为事实表里的一条数据,类似于日志流水记录。
  • 周期性快照事实表不会保留全部数据,仅保留固定时间周期内数据,比如:每月的账户余额,即账户余额每天都在变化,但我更关心的是我每月最后的账单余额。
  • 累积型快照事实表主要用于跟踪业务事实的变化,采用新增更新同步策略,比如:数据仓库中可能需要累积或者存储订单从下订单开始,到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单整个生命周期的进展情况。

四、几种常见数据模型

1. 星型模型

是数据集市维度建模中的推荐方法,星型模型以事实表为中心,所有的维度表都直接连接在事实表上,像星星一样,按维度进行汇总,所以执行效率会比较高些。即由一张事实表和多张维度表组成,事实表里包括各维度表的各个主键ID,以及其它没有放进维度表的内容,维度表里存储对应维度的详细信息。星型模型的领域主要适用于数据集市,它的最大作用其实是为了解决数据仓库建模中的性能问题(join少则shuffle就少,性能就越好)

2. 雪花模型

在星型模型中,维度表包括了该维度的所有信息,因为没有分层,所以维度表里面可能会有冗余出现,雪花模型正是为了减少维度表的冗余,雪花模型的维度表是可以拥有连接其他维度表的,雪花模型在星型模型的基础上,把维度表中的一些字段进行进一步的拆分出维度表,减少冗余,使其更有层次。不过雪花模型的性能相比于星型模型低,但相对较灵活些。

3. 星座模型

星型模型的扩展,只不过星座模型是可以基于多张事实表的,可共享维度信息。可以看作是多个事实表版本的星型模型,它的一个特点是多张事实表共用模型中的维度表,适用于比星型模型和雪花模型更复杂的场合。数据仓库大多是这类模型,即数据集市建模采用星型模型,然后各数据集市组成一个完整的数据仓库则演变成星座模型。

总结

星型模型适合用于指标分析,比较关注事实表里的内容; 雪花模型适合用于维度分析,相比于星型模型来设计的话,基于维度分析的场景数据冗余浪费情况较好。

五、数据仓库建模

维度建模

维度建模四步走如下 (PS:按流程走,四步是从上往下,环环相扣的)

1、选择业务过程 此过程是基于业务需求以及日后的易扩展性考虑的,即开始数仓建模时按业务区分选择数据。

2、声明粒度 存在一对一关系的就是相同粒度,粒度可以理解为层级,比如一个公司有多个部门,一个部门有多个员工,而这里面的不同部门就是相同粒度,不同员工也是相同粒度。维度建模时在同一事实表中必须具有相同的粒度,不同粒度最好建立不同的事实表,从业务获取数据时最好是从最细粒度开始,即原子粒度。 3、确认维度 维度就是分析数据的角度,是数仓的“灵魂”,数仓工具箱告诉我们牢牢掌握事实表的粒度,就可以区分出维度,维度表必须保证不出现重复数据,即维度唯一。 4、确认事实 事实表是用来度量的,基本是一些计数值,维度建模核心原则之一是同一事实表中的所有度量都必须具备相同的粒度,才能确保不出现重复计算度量的问题。

范式建模

主要应用于数据库设计,通过三范式对表进行设计,避免数据冗余。

关系建模

严格遵守三范式对表进行设计,避免数据冗余和保持数据一致性,关系建模和维度建模在表关系依赖方面基本相似,维度建模一般只依赖一层表关系,关系建模就会层层表依赖,关系表比较多,关系复杂些。

0 人点赞