1. 数据仓库的基础必备问题2. 数据仓库的几种数据表3. 数据仓库分层设计及各层作用4. 数据仓库几种数据模型5. 维度建模
一、 灵魂十二问
Q1：大数据的数据来源？
埋点上报数据业务数据库数据日志数据
Q2:数据集市？
数据集市可以理解为是一个微型的数据仓库，具有更少的主题域，服务对象更小，可以是部门级别，而数据仓库则是服务于企业级别。数据仓库可以统一规划数据，避免数据孤岛。
Q3：为什么做数据分层设计？
大数据处理时，作为数据开发者，我们总会进行各种表关联或者表依赖，如果没有很好地规划表依赖，则会造成我们的数据表关系混乱复杂，不方便我们看清数据的整体生命周期及数据流向，甚至出现循环依赖的数据体系，于是数据分层就很有必要，可以直观看清数据流向，建造更加良好的数据体系。
Q4：数据分层的好处？
1、清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位和理解
2、减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
3、统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径
4、复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题
Q5：数据仓库起到什么作用？
而数据仓库也不是数据的最终目的地，而是为数据最终目的地做准备，比如清洗、转义、分类、重组、合并、拆分、统计，数据要体现出价值，最终目的地则是为各类大数据应用系统服务，常用的有BI报表系统、用户画像、推荐系统、风控系统。
Q6：OLAP和OLTP的区别？
OLAP（On-Line Analytical Processing），即联机分析处理，主要应用在数据仓库OLTP（On-Line Transaction Processing），即联机事务处理，主要应用在数据库
Q7：什么是维度？
维就可以相当于角度，简单理解，按什么维度看数据就是你想从什么角度分析数据。
Q8：SCD缓慢变化维？
指的是数据仓库维度表中，那些随着时间会缓慢发生变化的维度，但是变化又不明显，即维度值变化不频繁的维度。比如：员工表中，员工的岗位和工作地点 在特殊场景分析时就可以看成是缓慢变化维，因为存在升职和调岗行为。分析下岗位为什么我说可以看成缓慢变化维，即入职那会是数仓开发工程师，几年后升职为数仓负责人；再分析下工作地点为什么我说可以看成缓慢变化维，即入职那会是在上海，几年后调岗到北京。
Q9：历史拉链表
是一种既能反应数据的历史变更状态，又能更大程度的节省数据存储的一种数据模型表
Q10：什么是次留用户,7日留存？
次留用户指的是统计当天的用户仍是昨天的那个用户，7日留存用户指的就是统计当天活跃的用户是在7天前同样活跃的用户。
Q11:上卷和下钻？
钻相对于维来说的话，就是可以改变维的层次，变换分析的粒度。向上钻取就是上卷，向下钻取就是下钻。
比如：把业务的内购流水按照时间维度进行向上聚集汇总数据，从而计算出天内购流水和月内购流水；把业务的内购流水沿着时间维向下细探到每个用户产生的明细流水数据，这就叫做下钻。
Q12:自然键和代理键？
搞清楚一个问题，在数据层面，键一般是用来唯一标识一个实体的所有属性。自然键一般是已经存在的数据，字段本身含有一定的业务意义，例如：身份证号代理键一般是无实际业务意义的数据，只具有主键作用，例如：自增ID在ETL过程中，数据仓库中商品维表中的商品ID可能是自然键，而可以生成一个唯一标识的键作为代理键，而在前台业务系统中，商品ID倒是作为代理键来着。使用代理键的优点：①能够对集成多个操作型系统的数据进行整合时起到缓冲作用，因为不同业务系统的同主题下可能会出现唯一标识重复，就需要有一个代理键来进行整合唯一标识；②代理键是整型的，减少了事实表中记录的长度，同样的IO可以读取更多的事实表记录，整型字段做外键关联效率也高，提升性能；③使用代理键可用来处理缓慢变化维的情况，例如拉链表。使用代理键的缺点：是使用代理键会增加ETL的复杂性，开发和维护成本高。
二、数据仓库的层级划分规范
表命名通用规范：层级前缀_主题域_表内容_周期_增量/全量表
DWD层DWB层DWS层
三、数据仓库的一些数据表种类
1. 宽表
顾名思义是字段比较多的数据库大表，通常是把同个业务主题域的相关维度、指标、属性都关联放在同一张表，由于把不同内容都放在一张表这本身就已经破坏了表的设计范式，所以宽表会造成大量数据冗余，但查询性能和效率就会提高和便捷，相当于以空间换时间，宽表设计场景可在数据挖掘模型训练前的数据准备，减少表关联取数数量
2. 窄表
严格按照数据设计三范式，尽量减少数据冗余，缺点是修改一个数据可能要经常切换修改与之关联的表对应数据
3. 维度表
维度表是存放着维度属性的集合，维度数据固定或者变化缓慢，且数据量不大，把维度看成是分析数据的角度，就是按什么角度来分析数据
4. 事实表
事实表是数据仓库结构中的中央表，按维度表分析事实的详细数据，事实表中每行记录代表着一个业务过程事件，每行记录一般包含着：具备可累计的度量值+与维表关联的外键。事实表有三类：
事务型事实表
周期性快照事实表
累积型快照事实表
四、几种常见数据模型
1. 星型模型
是数据集市维度建模中的推荐方法，星型模型以事实表为中心，所有的维度表都直接连接在事实表上，像星星一样，按维度进行汇总，所以执行效率会比较高些。即由一张事实表和多张维度表组成，事实表里包括各维度表的各个主键ID，以及其它没有放进维度表的内容，维度表里存储对应维度的详细信息。星型模型的领域主要适用于数据集市，它的最大作用其实是为了解决数据仓库建模中的性能问题（join少则shuffle就少，性能就越好）
2. 雪花模型
在星型模型中，维度表包括了该维度的所有信息，因为没有分层，所以维度表里面可能会有冗余出现，雪花模型正是为了减少维度表的冗余，雪花模型的维度表是可以拥有连接其他维度表的，雪花模型在星型模型的基础上，把维度表中的一些字段进行进一步的拆分出维度表，减少冗余，使其更有层次。不过雪花模型的性能相比于星型模型低，但相对较灵活些。
3. 星座模型
星型模型的扩展，只不过星座模型是可以基于多张事实表的，可共享维度信息。可以看作是多个事实表版本的星型模型，它的一个特点是多张事实表共用模型中的维度表，适用于比星型模型和雪花模型更复杂的场合。数据仓库大多是这类模型，即数据集市建模采用星型模型，然后各数据集市组成一个完整的数据仓库则演变成星座模型。
总结
星型模型适合用于指标分析，比较关注事实表里的内容；雪花模型适合用于维度分析，相比于星型模型来设计的话，基于维度分析的场景数据冗余浪费情况较好。
五、数据仓库建模
维度建模
维度建模四步走如下 (PS:按流程走，四步是从上往下，环环相扣的)
1、选择业务过程
2、声明粒度3、确认维度4、确认事实
范式建模
主要应用于数据库设计，通过三范式对表进行设计，避免数据冗余。
关系建模
严格遵守三范式对表进行设计，避免数据冗余和保持数据一致性，关系建模和维度建模在表关系依赖方面基本相似，维度建模一般只依赖一层表关系，关系建模就会层层表依赖，关系表比较多，关系复杂些。
暂无评论内容