数据仓库的特点
面向主题
理解主题的概念可以和数据库应用系统对比理解。
数据库应用是以业务流程来划分应用程序和数据库,比如ERP(Enterprise Resource Planning)包括:进销存系统、人力资源管理系统、财务管理系统、仓库管理系统等,进销存系统管理了进货、销售、存储等业务流程,人力资源系统管理了员工的信息、待遇等相关信息。
数据仓库是以数据分析需求来对数据进行组织划分若干主题,比如销售主题、员工主题、产品主题,主题是一个抽象的概念,可以理解为相关数据的分类、目录等,通过销售主题可以进行销售相关的分析,如年度销量排行、月度订单量统计等。
总之,主题是以分析需求为导向来组织数据,数据库应用系统是以业务流程为导向来组织数据,注意:主题中的数据是跨应用系统的。
数据集成
主题中的数据是跨应用系统的,也就是说数据是分散在各各应用系统,比如销售数据在进销存系统中有,财务系统中也有,为了进行销售分析需要将销售数据进行集成,集成在销售主题中,就可以从销售主题来进行数据分析。
非易失
数据库应用系统是根据业务需求进行数据处理和存储,而数据仓库是根据数据分析需求来进行数据存储,数据仓库中的数据用于查询和分析,为了保证数据分析的准确性和稳定性,数据仓库中的数据一般是很少更新的,会将历史快照保存下来。
时变
数据仓库中的数据存储的是历史数据,历史数据是随时间变化的,比如历年的销售数据都会存储到数据仓库中,即使数据仓库中的数据很少更新,但也不能保证没有变化,如下需求:
1)会不断添加新数据
每年的销售数据会逐渐添加到数据仓库。
2)删除过期数据
数据仓库中的数据会保存很长的时间(5–10年),但也有过期时间,到过期 时间会删除过期 数据。
3)对历史明细数据进行聚合
为了方便数据分析,根据分析需求会将比较细粒度的数据进行数据聚合存储,这也是时变的一种表现,比如:为了方便统计年度销售额会将销售记录按月进行统计,统计年度销售额时只需要针对月度销售结果进行统计即可。
6. 数据仓库分层
6.1 为什么要分层?
作为一名数据的规划者,我们肯定希望自己的数据能够有秩序地流转,数据的整个生命周期能够清晰明确被设计者和使用者感知到。直观来讲就是如图这般层次清晰、依赖关系直观。
但是,大多数情况下,我们完成的数据体系却是依赖复杂、层级混乱的。如下的右图,在不知不觉的情况下,我们可能会做出一套表依赖结构混乱,甚至出现循环依赖的数据体系。
因此,我们需要一套行之有效的数据组织和管理方法来让我们的数据体系更有序,这就是谈到的数据分层。数据分层并不能解决所有的数据问题,但是
,数据分层却可以给我们带来如下的好处:
1.清晰数据结构:每一个数据分层都有它的作用域和职责,在使用表的时候能更方便地定位和理解。
2.复杂问题简单化:将一个复杂的任务分解成多个步骤来完成,每一层解决特定的问题。
3.便于维护:当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤开始修复。
4.减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少重复开发的工作量。
5.高性能:数据仓库的构建将大大缩短获取信息的时间,数据仓库作为数据的集合,所有的信息都可以从数据仓库直接获取,尤其对于海量数据的关联查询和复杂查询,所以数据仓库分层有利于实现复杂的统计需求,提高数据统计的效率。
通常将数据模型分为三层:数据运营层( ODS )、数据仓库层(DW)和数据应用层(APP)。简单来讲,我们可以理解为:ODS层存放的是接入的原始数据,DW层是存放我们要重点设计的数据仓库中间层数据,APP是面向业务定制的应用数据。下面详细介绍这三层的设计。
6.2 分层方法
6.2.1 源数据层(ODS)
此层数据无任何更改,直接沿用外围系统数据结构和数据,不对外开放;为临时存储层,是接口数据的临时存储区域,为后一步的数据处理做准备。
6.2.2 数据仓库层(DW)
DW 层的数据应该是一致的、准确的、干净的数据,即对源系统数据进行了清洗(去除了杂质)后的数据。
此层可以细分为三层:
明细层DWD(Data Warehouse Detail):存储明细数据,此数据是最细粒度的事实数据。该层一般保持和ODS层一样的数据粒度,并且提供一定的数据质量保证。同时,为了提高数据明细层的易用性,该层会采用一些维度退化手法,将维度退化至事实表中,减少事实表和维表的关联。
中间层DWM(Data WareHouse Middle):存储中间数据,为数据统计需要创建的中间表数据,此数据一般是对多个维度的聚合数据,此层数据通常来源于DWD层的数据。
业务层DWS(Data WareHouse Service):存储宽表数据,此层数据是针对某个业务领域的聚合数据,应用层的数据通常来源与此层,为什么叫宽表,主要是为了应用层的需要在这一层将业务相关的所有数据统一汇集起来进行存储,方便业务层获取。此层数据通常来源与DWD和DWM层的数据。
天睿TERADATA 十大主题模型
概述
Teradata FS-LDM 是一个成熟产品
模型内支持:保险、银行、证券行业
十大主题:当事人、产品、协议、事件、资产、财务、机构、地域、营销、渠道。
银行的贷款资产可分为正常类、关注类、可疑类、次级类与损失类五类,其中后三类回收的可能性偏低,被银监会合并称为不良贷款。
在实际计算中,如果直接从DWD或者ODS计算出宽表的统计指标,会存在计算量太大并且维度太少的问题,因此一般的做法是,在DWM层先计算出多个小的中间表,然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定,也可以去掉DWM这一层,只留DWS层,将所有的数据在放在DWS亦可。
6.2.3 数据应用层(DA 或 APP)
前端应用直接读取的数据源;根据报表、专题分析的需求而计算生成的数据。
6.2.4 维表层(Dimension)
最后补充一个维表层,维表层主要包含两部分数据:
1.高基数维度数据:一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
2.低基数维度数据:一般是配置表,比如枚举值对应的中文含义,或者日期维表。数据量可能是个位数或者几千几万。
在这里插入图片描述
数据仓库与数据集市**
数据仓库是用于企业整体分析的数据集合,比如分为:销售主题、客户主题、产品主题等。数据集市是用于部门分析的数据集合,从范围上来讲它属于数据仓库的子集,比如:销售部门的数据集市只有销售主题。
为什么会有数据集市的概念?
通常从企业整体出发去建数据仓库比较困难,所涉及到的业务及分析需求比较多,所以提出数据集市的概念,可以先从某个部门开始建设数据仓库,这样效率就比较高。
业界把从企业整体出发建设数据仓库的过程叫自顶向下,把从数据集市开始建设数据仓库再逐渐完善整个数据仓库的过程叫自下向上。通常建议自下向上建设数据仓库,不过这个在业界也存在争议。
数据仓库和数据集市具有什么区别?
1、范围的区别
数据仓库是针对企业整体分析数据的集合。
数据集市是针对部门级别分析的数据集合。
2、数据粒度不同
数据仓库通常包括粒度较细的数据明细。
数据集市则会在数据仓库的基础上进行数据聚合,这些聚合后的数据就会直接用于部门业务分析。
有两种常见的数据保存的模型:
星型模型:将一个大的事实表,直接拆分成多个维度表,来保存和计算数据,
在工作中星型模型比较常见
优点:结构整体比较简单,表的数量比较少
缺点:每个表格都可能会存在一些冗余数据
雪花模型:将一张拆分后的维度表,再当成一个小的事实表,继续进行维度的
拆分
优点:每个表格都没有冗余的数据,表格的内容比较干净
缺点:整个结构就会比较复杂,表的数量也会很多
第三范式(3NF):
第一范式:每一个列都是不可再拆分的列
第二范式:每个表都是有主键的
第三范式:每一个表的其他的列,都是和主键有直接相关的关系
事务的几个特征:
原子性:每一个事务都是最小的功能模块
一致性:同时成功同时失败
隔离性:同时操作事务的时候,事务之间不会互相影响
持久性:通过事务操作的数据,是永久保存的
拉链表,缓慢变化维:(拉链表用在业务规模较大,有存在少量更新 ,同时业务又要保留更新记录,以及查看某个历史时间快照信息的场景)
拉链表就是一张普通的表格,这个表格会保存你每一次数据前后变更的状态。
1.以行的方式保存历史数据和变化状态
有开始时间和结束时间还有变更状态这三列,用来记录每一行数据前后变更的状态和顺序,这三列叫做缓慢变化维。
优点:可以保存所有的历史记录
缺点:表格的数据会特别的多
2.以列的方式保存最近的历史数据
会创建列的旧数据的备份列,会保存最近一次的变更的数据,和数据变更的时间
优点:可以保证表格的数据量不会很大
缺点:看不到详细的变化状态
缓慢变化维和拉链表:
拉链表长什么样?
拉链表除了有表格核心的列的信息之外,还有数据变更状态的开始时间、结束时间、状态码,
例如现在有一个新的数据进来,这个数据的开始时间是现在时间,结束时间是2999-12-31的最大值,状态码给个1,如果这个数据的状态发生了变更,那么这个时候要新增一个数据,除了数据的新内容之外,开始时间是现在时间,结束时间是2999-12-31的最大值,状态码给个1,上一个这个数据的历史信息,结束时间要变成新数据的开始时间,状态码变成0。
什么是缓慢变化维?
记录拉链表前后数据变更的列,就是缓慢变化维。
有哪几种不同的缓慢变化维?
有两种,拉链表是最常见的一种。
还有一种只记录最近的变量数据和状态,不会记录所有的变更状态。
核心列 变更列 变更时间
id name addr mobile old_addr old_mobile update_time
1 li gz 131xx sz 130xxx 2020-12-18
指标与维度
要进行维度分析需要先理解两个术语:指标和维度。
指标是衡量事务发展的标准,也叫度量,如价格,销量等;指标可以求和、求平均值等计算。
指标分为绝对数值和相对数值,绝对数值反映具体的大小和多少,如价格、销量、分数等;相对数值反映一定的程度,如及格率、购买率、涨幅等。
维度是事务的特征,如颜色、区域、时间等,可以根据不同的维度来对指标进行分析对比。比如根据区域维度来分析不同区域的产品销量,根据时间来分析每个月产品的销量,同一个产品销量指标从不同的维度分析会得出不同的结果。
维度表和事实表的区别?
事实表大部分都在数仓里面,事实表一张表有很多的列,举个例子,一个事实表里面可能有销售员信息、门店信息、地区信息、销售信息、产品信息、库存信息等等,里面就会有大量的冗余信息;
维度表就是根据某个具体的维度,进行表格的细分,例如一个维度表只会存放销售员信息,一个表格的列只和表格的主键直接相关。
缓慢变化维和拉链表:
拉链表长什么样?
拉链表除了有表格核心的列的信息之外,还有数据变更状态的开始时间、结束时间、状态码,
例如现在有一个新的数据进来,这个数据的开始时间是现在时间,结束时间是2999-12-31的最大值,状态码给个1,如果这个数据的状态发生了变更,那么这个时候要新增一个数据,除了数据的新内容之外,开始时间是现在时间,结束时间是2999-12-31的最大值,状态码给个1,上一个这个数据的历史信息,结束时间要变成新数据的开始时间,状态码变成0。
什么是缓慢变化维?
记录拉链表前后数据变更的列,就是缓慢变化维。
有哪几种不同的缓慢变化维?
有两种,拉链表是最常见的一种。
还有一种只记录最近的变量数据和状态,不会记录所有的变更状态。
核心列 变更列 变更时间
id name addr mobile old_addr old_mobile update_time
1 li gz 131xx sz 130xxx 2020-12-18
mapreduce的基本原理:
分成map和reduce两个部分,首先是在map端对需要计算的数据进行拆分,分配到不同的计算资源上,分别进行计算,然后在reduce端对计算好的数据进行整合
hive和rdbms的数据库区别?
hive是使用mr计算,使用yarn调度资源,使用mysql存储元数据,使用hdfs存储数据,对小文件不友好,适合大文件一般都是PB TB级别的文件,没有主键和其他的约束,只有一个位图的索引
分区表有没有建过?
静态分区和动态分区的区别是什么?
静态分区的分区值是自己设置的,动态分区的分区值是通过select查询出来的某个列的值,动态分区需要打开动态分区的开关和打开nostrict非严格模式的开关,效率比静态分区要低。
静态可以通过load data和insert overwrite的方式添加数据,动态只能通过insert overwrite添加。
分桶表有没有建过?
分桶表在工作中用来做什么? 加快表连接的速度
分区和分桶的区别?
分区是partitioned by,创建的是文件夹,分桶是clustered by,创建的是文件,分区是新字段,分桶是已存在的字段,分区是自己设置规则,分桶是根据哈希算法分配的,分区是在查询分区字段的时候加快查询的速度,分桶是表连接的时候加快查询速度。
表格的存储格式有哪些,常用的是哪个?
textfile sequencefile rcfile orc
常用的是orc,orc有懒加载的模式,以行为单位进行数据压缩的,压缩率很高,查询到效率也很高
外部表有没有使用过?外部表的创建语法?
create external table 表名(
列名 数据类型)
各种分隔符的设置
location ‘hdfs文件夹位置’;
为什么要使用外部表,外部表和内部表的区别是什么?
外部表一般都是存放比较大的文件和表格,例如日志信息表,埋点数据的表格,大的业务数据表,内容表一般就是存储计算之后的结果,存储业务指标的计算结果
外部表如果删除的话,只会删除元数据,不会删除文件夹和内容,内部表会全部删除掉
文件的压缩格式常用的是哪种?
none record block
常用的是block压缩
数据倾斜有没有遇到过,经常在什么地方遇到?
大小表的连接;计算的表格有大量空值;不合理的sql语句
数据倾斜的表现?
看日志中reduce的百分比经常会卡在99%的位置不动了,sql语句长时间无法运行结束
如果发生了数据倾斜怎么去优化?怎么去预防?
如果是大小表连接,可以对大表进行数据的拆分,也可以使用分桶的方法来优化,或者使用mapjoin的优化器;
大量空值的话,会使用字符串加随机值的方式去填充空值;
查看是否有统计distinct结果之类的语句
说一下mapjoin优化器的原理?
将小表的数据先放入到内存中,然后使用大表去匹配内存中的小表数据。
7.脚本上线之后你都有遇到过哪些问题?是怎么解决的?
第一个是脚本运行时间太长,可能是出现了数据倾斜;
第二个可能是会出现数据和预期不一致的情况,首先看是否是调度工具的问题,其次是逻辑的问题,然后是上游数据的问题。