这一篇万字数仓文章，让我对数仓有了一个新的认知

随着数据量的不断增大，无论是在数据管理方面还是还是数据安全或者追踪血缘方面难度也在不断增大。因此，数仓的出现是当前必然的产物。经过多年的计算机应用和市场积累，许多商业企业已保存了大量原始数据和各种业务数据，这些数据真实地反映了商业企业主体和各种业务环境的经济动态。然而由于缺乏集中存储和管理，这些数据不能为本企业进行有效的统计、分析和评估提供帮助。也就是说，无法将这些数据转化成企业有用的信息。70年代出现并被广泛应用的关系型数据库技术为解决这一问题提供了强有力的工具。 从80年代中期开始，随着市场竞争的加剧，商业信息系统用户已经不满足于用计算机仅仅去管理日复一日的事务数据，他们更需要的是支持决策制定过程的信息。 80年代中后期，出现了数据仓库思想的萌芽，为数据仓库概念的最终提出和发展打下了基础。
90年代初期，W.H.Inmon在其里程碑式的著作《建立数据仓库》中提出了“数据仓库”的概念，数据仓库的研究和应用得到了广泛的关注。这对处于激烈竞争中的商业企业，有着非同小可的现实意义。
今天小编就火热的数仓来做一篇文章希望在复习的同时也能帮助到大家。由于水平有限，博客中难免会有一些错误，有纰漏之处恳请各位大佬不吝赐教！
小编博客主页：https://blog.csdn.net/Mr_Yang888
尽管当前水平可能不及各位大佬，但我还是希望自己能够做得更好。因为我相信，努力就会有希望。如果你的内在一直成长，那么你早晚会破土而出

码字不易，先赞再看，养成习惯~~~

1、数据仓库的概念

数据仓库概念创始人在《建立数据仓库》一书中对数据仓库的定义是：数据仓库（DataWarehouse）是一个面向主题的（SubjectOriented）、数据集成的（Integrated）、相对稳定(非易失)的（Non-Volatile）、反映历史变化(时变)（TimeVariant）的数据集合，用于支持管理决策(DecisionMakingSupport)。
数据仓库是决策支持系统（dss）的结构化数据环境，如下图，决策支持系统基于数据仓库进行联机分析处理(OLAP)。常用的技术有，HDFS、HBase、Hive、SparkSql等。

对以上数仓流流程简单总结如下：

1. 数据采集,将源数据采集到数据仓库
2. 基于数据仓库进行数据分析
3. 生成报表

2、OLTP和OLAP区别

OLTP（On-LineTransactionProcessing）即联机事务处理，也称为面向交易的处理过程，其基本特征是前台接收的用户数据可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果，是对用户操作快速响应的方式之一，比如ERP系统，CRM系统，互联网电商系统等，这类系统的特点是事务操作频繁，数据量小。
OLAP（On-LineAnalyticalProcessing）即联机分析处理，有时也称为决策支持系统（DSS），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。这类系统的特点是没有事务性操作，主要是查询操作，数据量大。
详细的区别如下：

3、数据仓库的特点

3.1、面向主题

理解主题的概念可以和数据库应用系统对比理解，数据库应用是以业务内容来划分应用程序和数据库，比如ERP（EnterpriseResourcePlanning）包括：进销存系统、人力资源管理系统、财务管理系统、仓库管理系统等，进销存系统管理了进货、销售、存储等业务流程，人力资源系统管理了员工的信息、待遇等相关信息；数据仓库是以数据分析需求来对数据进行组织划分若干主题，比如销售主题、员工主题、产品主题，主题是一个抽象的概念，可以理解为相关数据的分类、目录等，通过销售主题可以进行销售相关的分析，如年度销量排行、月度订单量统计等。总之，主题是以分析需求为导向来组织数据，数据库应用系统是以业务流程为导向来组织数据，注意：主题中的数据是跨应用系统的。

3.2、数据集成

主题中的数据是跨应用系统的，也就是说数据是分散在各各应用系统，比如销售数据在进销存系统中有，财务系统中也有，为了进行销售分析需要将销售数据进行集成，集成在销售主题中，就可以从销售主题来进行数据分析。

3.3、非易失

数据库应用系统是根据业务需求进行数据处理和存储，而数据仓库是根据数据分析需求来进行数据存储，数据仓库中的数据用于查询和分析，为了保证数据分析的准确性和稳定性，数据仓库中的数据一般是很少更新的。

3.4、时变

数据仓库中的数据存储的是历史数据，历史数据是随时间变化的，比如历年的销售数据都会存储到数据仓库中，即使数据仓库中的数据很少更新，但也不能保证没有变化，如下需求：
1）会不断添加新数据
每年的销售数据会逐渐添加到数据仓库。
2）删除过期数据
数据仓库中的数据会保存很长的时间（5–10年），但也有过期时间，到过期时间会删除过期数据。
3）对历史明细数据进行聚合
为了方便数据分析，根据分析需求会将比较细粒度的数据进行数据聚合存储，这也是时变的一种表现，比如：为了方便统计年度销售额会将销售记录按月进行统计，统计年度销售额时只需要针对月度销售结果进行统计即可。

4、数据仓库系统架构

4.1、系统结构图

数据仓库提供企业决策分析的数据环境，数据从哪里获取？数据如何存储到数据仓库？决策分析系统如何从数据仓库获取数据进行分析？我们可以把数据从获取、存储到数据仓库、数据分析的所有部分称为一个数据仓库系统，本节讲解数据仓库系统的工作流程和系统架构。
下图是数据仓库系统的结构图：

以下系统各部分的执行流程是：
1、确定分析所依赖的源数据。
2、通过ETL将源数据采集到数据仓库。
3、数据按照数据仓库提供的主题结构进行存储。
4、根据各部门的业务分析要求创建数据集市（数据仓库的子集）。
5、决策分析、报表等应用系统从数据仓库查询数据、分析数据。
6、用户通过应用系统查询分析结果、报表。

4.2、源数据

源数据是指用于分析的原始数据，这一步主要是根据分析需求确定源数据，这个数据分布在内部系统和外部分系统中，内部数据主要是企业ERP系统、外部数据是指企业外部分系统所产生的数据，通常是指行业数据。源数据最大的特点是格式不统一，如果要对源数据进行分析需要经过ETL对数据进行集中获取、过虑、转换等处理。

4.3、ETL

ETL（Extra,Transfer,Load）包括数据抽取、数据转换、数据装载三个过程。
1、抽取
数据抽取是从各各业务系统、外部系统等源数据处采集源数据。
2、转换
采集过来的源数据如果要存储到数据仓库需要按照一定的数据格式对源数据进行转换，常见的转换方式有数据类型转换、格式转换、缺失值补充、数据综合等。
3、装载
转换后的数据就可以存储到数据仓库中，这个过程要装载。数据装载通常是按一定的频率进行的，比如每天装载当天的订单数据、每星期装载客户信息等。

4.4、数据仓库与数据集市

数据仓库是用于企业整体分析的数据集合，比如分为：销售主题、客户主题、产品主题等。数据集市是用于部门分析的数据集合，从范围上来讲它属于数据仓库的子集，比如：销售部门的数据集市只有销售主题。

为什么会有数据集市的概念？
通常从企业整体出发去建数据仓库比较困难，所涉及到的业务及分析需求比较多，所以提出数据集市的概念，可以先从某个部门开始建设数据仓库，这样效率就比较高。

业界把从企业整体出发建设数据仓库的过程叫自顶向下，把从数据集市开始建设数据仓库再逐渐完善整个数据仓库的过程叫自下向上。通常建议自下向上建设数据仓库，不过这个在业界也存在争议。

数据仓库和数据集市具有什么区别？
1、范围的区别

• 数据仓库是针对企业整体分析数据的集合。
• 数据集市是针对部门级别分析的数据集合。
  2、数据粒度不同
• 数据仓库通常包括粒度较细的数据明细。
• 数据集市则会在数据仓库的基础上进行数据聚合，这些聚合后的数据就会直接用于部门业务分析。

4.5、应用系统

这里的应用系统是指使用数据仓库完成数据分析、数据查询、数据报表等功能的系统。应用系统需要从数据仓库中查询数据、分析数据，比如：OLAP系统、数据查询系统等。

4.6、用户

使用数据仓库系统的用户主要有数据分析人员、管理决策人员（公司高层）等。

5、维度分析

5.1、维度分析介绍

对数据进行分析通常采取维度分析，比如：用户提出分析课程访问量的指标，为了满足不同的分析需求可以从时间维度分析课程访问量，分析每天、每小时的课程访问量；也可以从课程维度来分析课程访问量，分析每个课程、每个课程分类的访问量。

5.2、指标与维度

要进行维度分析需要先理解两个术语：指标和维度。指标是衡量事务发展的标准，也叫度量，如价格，销量等；指标可以求和、求平均值等计算，指标分为绝对数值和相对数值，绝对数值反映具体的大小和多少，如价格、销量、分数等；相对数值反映一定的程度，如及格率、购买率、涨幅等。
维度是事务的特征，如颜色、区域、时间等，可以根据不同的维度来对指标进行分析对比。比如根据区域维度来分析不同区域的产品销量，根据时间来分析每个月产品的销量，同一个产品销量指标从不同的维度分析会得出不同的结果。维度分为定性和定量两种，定性维度就是字符类型的特征，比如区域维度包括全国各省份；定量维度就是数值类型的特征，如价格区间、销量区间等，如价格区间维度分为0–100、100-1000两个区间，可以按价格区间维度来对指标进行分析，说到这里，其实指标是可以转成维度的，所转成的维度就是定量维度。
用具体的指标数值,来度量不同的维度。x轴和y轴的关系。

5.3、关键指标

在进行维度分析前需要收集关键指标，关键指标就是运营管理者最关心的指标，比如市场总监提出的产品销量、新增客户等指标；财务经理提出的营业额、利润率等。

5.4、识别维度

在日常生活中，我们从不同的角度看待事务会有不同的体会，数据分析也如此，比如：一个在线教育的平台，作为运营方会关注按时间段分析课程的访问量，作为教育机构则关注单个课程的访问量，都是课程访问量指标根据不同的维度去分析得到结果不同，这就是维度分析。

比如：按时间分析课程访问量，时间维度是课程访问量的分析依据，时间维度和业务中的课程访问量是对应的，下表列出了课程访问量明细记录：

上表中显示了部分课程访问的记录，每条记录表示一次课程访问，记录内容包括：IP，访问时间、课程ID，根据上边的记录可以按时间统计每天所有课程的访问量，时间就是一个维度，如下是按时间维度分析的课程访问量：

时间维度（天）

维度是数据仓库建模的基础，维度是在分析时从多个方面来进行分析，根据上边的例子，将课程访问作为度量，识别的维度包括：课程、时间、机构、课程分类等，如下图：

将课程购买作为度量的维度包括：

5.5、分层与分级

通常在分析结果中首先看到的是一个总数，比如全年课程购买量，然后会详细去看每个季度、每个月的课程购买量，全年、季度、月这些属于时间维度的一个层次，年、季度、月是这个层次的三个级别，比如按地区分析课程购买量，全国、省、市、县属于地区维度的一个层次，层次中共有四个级别。

每个维度至少有一个层次且该层次至少有一个级别。下边将课程访问的各各维度定义层次和级别，如下：

时间维度：
个层次四个级别：年、月、天、小时
课程维度：
课程名称：只有一个级别，每门课程的名称
课程分类：两个级别，大类和小类
课程难度：只有三个级别，简单、一般、难
课程等级：只有三个级别，初、中、高
地区维度：
一个层次三个级别：省、市、县

5.6、下钻与上卷

维度中有不同的层次，每个层次可以有多个级别，这样就可以根据多个维护层次和级别进行分析，可以灵活获取高级别的汇总信息，获取低级别的明细信息，把获取高级别的汇总信息的过程叫上卷，把获取低级别的明细信息的过程叫下钻，比如：课程访问量分析，时间维度有四个级别，分别是年、月、天、小时，现在我们某个级别分析每天的课程访问量，比如按天分析课程访问量，此时我们可以按小时下钻分析，得出一天内每小时的课程访问量，也可以按月上卷，得到月度的课程访问量。
下钻维度：
天、小时
上卷维度：
年、月

6、数仓建模

6.1、概述

数据仓库建模的方法常用的有两种：三范式建模法、维度建模法，三范式建模法主要是应用于传统的企业级数据仓库，这类数据仓库通常使用关系型数据库实现，是由Inmon提出的，应用于自顶向下的数据仓库架构;维度数据模型就是基于维度分析来创建模型，是由Kimball提出，应用于自下向上的数据仓库架构。本课程采用维度建模的方法。

维度建模，简称DM（Dimensionalmodeling），数据仓库大师Kimball的观点：维度数据模型是一种趋向于支持最终用户对数据仓库进行查询的设计技术，是围绕性能和易理解性构建的。是面向最终用户的。也就是说，维度模型是按照用户看待或分析数据的角度来组织数据。
维度建模的两个核心概念：事实表和维度表。

6.2、事实表

6.2.1、概述

事实表记录了特定事件的数字化信息，一般由数值型数字和指向维度表的外键组成。事实表的设计依赖于业务系统。数据分析的实质就是基于事实表开展的计算操作。

一般要给事实表设计一个代理键作为每行记录的唯一标识，相当于主键。代理键一般由系统生成，和业务无关。

事实表中的数值信息类型
可加数值类型：
可加事实指的是该度量可以按照和事实表关联的任一维度进行汇总。比如商品的单价，可以按照品类维度、店铺维度汇总平均值和总价格等等。

半可加数值类型：
指的就是该度量在某些维度下不可进行汇总，或者说汇总起来没有意义，比如说余额，余额在时间维度下的汇总就没有意义。

记录静态数据（库存数据，金融账户余额）的所有度量针对于日期属性等维度天然具有非可加性，但是例如库存数据针对产品种类或者商店维度进行汇总，是可加的，所以这种数据就是半可加事实。

不可加数值类型：
指的是该度量在所有与该事实表关联的维度下都不可进行汇总，比如说比率型数据，对于这种数据，如果确实是有汇总的必要，可以将其分子分母分别存储，然后在最后汇总之后再进行除法操作，从而得到“汇总”后的比率型数据。对这类数值的计算通常是在OLAP应用中。

事实表中的空值
事实表中的外键不能存在空值，否则会违反参照完整性，关联的维度表必须用默认的代理键而不是空值表示未知的条件。

所有聚合函数，比如sum、count、min、max、avg等均可针对包含空值的字段进行度量计算，其中sum、count(字段名)、min、max、avg会忽略空值，而count(1)或count(*)在计数时会将空值包含在内。

6.2.2、分类

6.2.2.1、事务事实表

• Transaction fact table，事务事实表与周期快照事实表、累积快照事实表使用相同的维度，但 是它们在描述业务事实方面是有着非常大的差异的。
• 事务事实表记录的事务层面的事实，保存的是最原子的数据，也称“原子事实表”或“交易事实表”。 事务事实表中的数据在事务事件发生后产生，数据的粒度通常是每个事务一条记录。一旦事务被提 交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。
• 事务事实表的日期维度记录的是事务发生的日期，它记录的事实是事务活动的内容。用户可以 通过事务事实表对事务行为进行特别详细的分析。沟通中常说的事实表，大多指的是事务事实表。

6.2.2.2、周期快照事实表

• Periodicsnapshot fact table，周期快照事实表以具有规律性的、可预见的时间间隔来记录事实， 时间间隔如每天、每月、每年等等。典型的例子如销售日快照表、库存日快照表等。
• 周期快照事实表的粒度是每个时间段一条记录，通常比事务事实表的粒度要粗，是在事务事实 表之上建立的聚集表。比如说时间周期是1周，那么这个周期快照事实表的一条记录就是这一周的 对于某个度量的统计值。周期快照事实表的维度个数比事务事实表要少。
• 周期快照事实表的日期维度通常是记录时间段的终止日，记录的事实是这个时间段内一些聚集 事实值。事实表的数据一旦插入即不能更改，其更新方式为增量更新。

6.2.2.3、累积快照事实表

• Accumulatingsnapshot fact table，累积快照事实表和周期快照事实表有些相似之处，它们存储的都是事务数据的快照信息。但是它们之间也有着很大的不同，周期快照事实表记录的确定的周期的数据，而累积快照事实表记录的不确定的周期的数据。
• 累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日 期字段，用来记录整个生命周期中的关键时间点。例如订单累计快照事实表会有付款日期，发货日 期，收货日期等时间点。
• 事务事实表中一个完整的交易记录会有一系列不同状态的数据来记录整个交易过程；而累积快 照事实表只会有一条记录，数据会一直更新直到过程结束。
• 累积快照事实表代表的是完全覆盖一个事务或产品的生命周期的时间跨度，它通常具有多个日 期字段，用来记录整个生命周期中的关键时间点。另外，它还会有一个用于指示最后更新日期的附 加日期字段。
• 由于事实表中许多日期在首次加载时是不知道的，所以必须使用代理关键字来处理未定义的日 期，而且这类事实表在数据加载完后，是可以对它进行更新的，来补充随后知道的日期信息。
• 举例来说：订货日期、预定交货日期、实际发货日期、实际交货日期、数量、金额、运费。

6.2.2.4、无事实事实表

• 没有事实发生，表面看没有事实的事实表是没有意义的，但是无事实的事实表却有其他的用途： 讲述不同维度之间的对应关系，帮助业务模型落地到数据模型过程中，更好地梳理维度之间的对应关系，并且能更快获得关系数据。
• 最常见的例子就是维度与维度之间的关系表，或者说是多对多表的中间表。
• 表面上没有一个可分析的度量值，所以被称为“无事实”的事实表。但实际上这样的事实表中都 会隐藏着一个count的信息，因此它也可以作为一个事实表来进行统计。

6.2.2.5、总结

6.3、维度表

6.3.1、概述

• 维度是指观察数据的角度，一般是一个名词，比如对于销售金额这个事实，我们可以从销售时 间、销售产品、销售店铺、购买顾客等多个维度来观察分析。
• 维度表的记录数比事实表少，但是每条记录可能会包含很多字段。
• 维度表一般也需要设计一个代理键，映射业务数据中的主键。业务系统的主键可以是自然键（指 已经存在的属性组成的键，比如身份证），也可以是代理键。

6.3.1、分类

主要包含两大类数据：

1、高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或 者上亿级别。
2、低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表、地理维表等。数据量可能是个位数或者几千条几万条。
例如：
时间维度表
描述事件发生的时间，数据仓库就是一个随时间变化的数据集合，因此可能需要一个时间维度 表。年月日时分秒。
日期维度表
描述地理位置信息数据，国家、省市县镇村、邮编等。
产品维度表
描述产品属性。比如书的分类，有科技、教育、小说等分类属性。
人员维度表
描述人员相关信息，销售人员、市场人员、开发人员等。

7、渐变维（SCD）

7.1、什么是渐变维

维度可以根据变化剧烈程度主要分为无变化维度、缓慢变化维度和剧烈变化维度。例如一个人 的相关信息，身份证号、姓名和性别等信息数据属于不变的部分，政治面貌和婚姻状态属于缓慢变 化部分，而工作经历、工作单位和培训经历等在某种程度上属于急剧变化字段。
大多数维度表随时间的迁移是缓慢变化的。比如增加了新的产品，或者产品的ID号码修改了， 或者产品增加了一个新的属性，此时，维度表就会被修改或者增加新的记录行。这样，在设计维度 和使用维度的过程中，就要考虑到缓慢变化维度的处理。
缓慢渐变维，即维度中的属性可能会随着时间发生改变，比如包含用户住址Address的 DimCustomer维度，用户的住址可能会发生改变，进而影响业务统计精度，DimCustomer维度就 是缓慢渐变维（SCD）。
SCD有三种分类，我们这里以顾客表为例来进行说明：
假设在第一次从业务数据库中加载了一批数据到数据仓库中，当时业务数据库有这样的一条顾 客的信息。

顾客 BIWORK ，居住在北京，目前是一名 BI 的开发工程师。假设 BIWORK 因为北京空气 质量 PM2.5 等原因从北京搬到了三亚。那么这条信息在业务数据库中应该被更新了。

那么当下次从业务数据库中抽取这类信息的时候，数据仓库又应该如何处理呢？

我们假设在数据仓库中实现了与业务数据库之间的同步，数据仓库中也直接将词条数据修改更 新。后来我们创建报表做一些简单的数据统计分析，这时在数据仓库中所有对顾客 BIWORK 的销 售都指向了 BIWORK 新的所在地 - 城市三亚，但是实际上 BIWORK 在之前所有的购买都发生在 BIWORK 居住在北京的时候。

通过这个简单的例子，描述了因一些基本信息的更改可能会引起数据归纳和分析出现的问题。

7.2、SCD1（缓慢渐变类型1）

通过更新维度记录直接覆盖已存在的值。不维护记录的历史。一般用于修改错误的数据。
在数据仓库中，我们可以保持业务数据和数据仓库中的数据始终处于一致。可以在 Customer 维度中使用来自业务数据库中的 Business Key - CustomerID 来追踪业务数据的变化，一旦发生变 化那么就将旧的业务数据覆盖重写。
DW 中的记录根据业务数据库中的 CustomerID 获取了最新的 City 信息，直接更新到 DW 中。

7.3、SCD2（缓慢渐变类型2）

在源数据发生变化时，给维度记录建立一个新的“版本”记录，从而维护维度历史。SCD2不删除、 不修改已存在的数据。SCD2也叫拉链表。
当然在数据仓库中更多是对相对静态的历史数据进行数据的汇总和分析，因此会尽可能的维护 来自业务系统中的历史数据，使系统能够真正捕获到这种历史数据的变化。以上面的例子来说，可 能需要分析的结果是 BIWORK 在 2012年的时候购买额度整体平稳，但是从2013年开始购买额度 减少了，出现的原因可能与所在的城市有关系，在北京的门店可能比在三亚的门店相对要多一些。
像这种情况，就不能很简单在数据仓库中将 BIWORK 当前所在城市直接更新，通过起始时间 来标识，Valid To（封链时间）为 NULL 的标识当前数据，也可以用2999，3000，9999等等比较 大的年份。

7.3、SCD3（缓慢渐变类型3）

实际上SCD1 and 2 可以满足大多数需求了，但是仍然有其它的解决方案，比如说 SCD3。 SCD3希望只维护更少的历史记录。
比如说把要维护的历史字段新增一列，然后每次只更新 Current Column 和 Previous Column。这样，只保存了最近两次的历史记录。但是如果要维护的字段比较多，就比较麻烦，因 为要更多的 Current 和 Previous 字段。所以 SCD3 用的还是没有 SCD1 和 SCD2 那么普遍。 它只适用于数据的存储空间不足并且用户接受有限维度历史的情况。

8、常见模型

8.1、星型模型

是一种多维的数据关系。一个事实表为中心，多个维度表环绕周围。
一个星型模型中可以有一个或多个事实表，每个事实表可以引用任意数量的维度表。
星型模型将业务流程分为事实和维度。事实是对业务的度量，是定量的数据，比如价格、销售 数量、距离、速度、质量等。维度是对事实数据属性的描述，比如日期、产品、客户、地理位置等。

8.2、雪花模型

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，就像多 个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展，是对星型模型的维度表做进一 步规范化处理后形成的，这些被分解的表都连接到主维度表而不是事实表。

如何将维度表进行规范化处理呢？
即把低基数（重复比较多、辨识度比较低）的属性从维度表中移除并形成单独的表。基数指的 是一个字段中不同值的个数，比如主键列具有唯一值，所以具有最高的基数，而性别枚举值（日期、 地区等）这样的列的基数就很低。
规范化的影响
规范化的过程是将维度表中重复度比较高的字段组成一个新表，所以规范化不可避免增加了表 的数量，减少了数据的存储空间，提高了数据更新的效率。但是查询时就需要连接更多的表。
折中的方式
底层使用雪花模型，上层用表连接建立视图来模拟星型模型。这样既通过规范化节省了存储空 间，又降低了用户查询数据的复杂性。但是当外部查询条件不需要连接整个维度表时，该方法将会 带来性能损失。
总结，雪花模型中，一个维度被规范化成多个关联的表，星型模型中，每个维度由一个单一的 维度表所表示。

9、建模过程

1. 选择需要建模的业务流程
2. 确认事实
   用户正是通过对事实表的访问获取数据仓库中存储的数据的。
3. 声明维度模型的粒度
   在选择维度和事实前必须声明粒度，不同的事实可以有不同的粒度，建议同一事实中不要混用 多种不同的粒度。也可以修改粒度级别。
   细粒度：原始粒度（从业务流程直接获取的数据），建议从原始粒度数据开始设计数据模型， 满足对细节数据的查询需求。（ODS、DWD）。
   粗粒度：汇总粒度（在原始粒度的基础上进行汇总），对优化查询性能很重要。（DWM、DWS）。
4. 确认维度
   维度的粒度要和第二步保持一致。

10、数仓分层

10.1、为什么要进行数仓分层

作为一名数据的规划者，我们肯定希望自己的数据能够有秩序地流转，数据的整个生命周期能 够清晰明确被设计者和使用者感知到。直观来讲就是如图这般层次清晰、依赖关系直观。

但是，大多数情况下，我们完成的数据体系却是依赖复杂、层级混乱的。如下的右图，在 不知不觉的情况下，我们可能会做出一套表依赖结构混乱，甚至出现循环依赖的数据体系。

因此，我们需要一套行之有效的数据组织和管理方法来让我们的数据体系更有序，这就是谈到 的数据分层。数据分层并不能解决所有的数据问题，但是，数据分层却可以给我们带来如下的好处：

1. 清晰数据结构：每一个数据分层都有它的作用域和职责，在使用表的时候能更方便地定位 和理解
2. 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
3. 便于维护：当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始 修复。
4. 统一数据口径：通过数据分层，提供统一的数据出口，统一对外输出的数据口径
5. 复杂问题简单化：将一个复杂的任务分解成多个步骤来完成，每一层解决特定的问题

为了满足前面提到好处，通常将数据模型分为三层：数据运营层（ ODS ）、数据仓库层（DW） 和数据应用层（APP）。简单来讲，我们可以理解为：ODS层存放的是接入的原始数据，DW层是 存放我们要重点设计的数据仓库中间层数据，APP是面向业务定制的应用数据。下面详细介绍这三 层的设计。

10.2、分层方法

10.2.1、源数据层（ODS）

此层数据无任何更改，直接沿用外围系统数据结构和数据，不对外开放；为临时存储层，是接 口数据的临时存储区域，为后一步的数据处理做准备。

10.2.2、数据仓库层（DW）

DW 层的数据应该是一致的、准确的、干净的数据，即对源系统数据进行了清洗（去除了杂质） 后的数据。
此层可以细分为三层:

• 明细层DWD（Data Warehouse Detail）：存储明细数据，此数据是最细粒度的事实数据。 该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细 层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。
• 中间层DWM（Data WareHouse Middle）：存储中间数据，为数据统计需要创建的中间 表数据，此数据一般是对多个维度的聚合数据，此层数据通常来源于DWD层的数据。
• 业务层DWS（Data WareHouse Service）：存储宽表数据，此层数据是针对某个业务领 域的聚合数据，应用层的数据通常来源与此层，为什么叫宽表，主要是为了应用层的需要在这一层 将业务相关的所有数据统一汇集起来进行存储，方便业务层获取。此层数据通常来源与DWD和 DWM层的数据。

在实际计算中，如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维 度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS 的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放 在DWS亦可。

10.2.3、数据应用层（DA 或 APP）

前端应用直接读取的数据源；根据报表、专题分析的需求而计算生成的数据。

10.2.4、维表层（Dimension）

最后补充一个维表层，维表层主要包含两部分数据：

1. 高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者 上亿级别。
2. 低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。
   3.

11、数据仓库设计案例

这里我们以电商网站的数据仓库为例，针对用户访问日志这一部分数据进行举例说明。
在ODS层中，由于各端的开发团队不同或者各种其它问题，用户的访问日志被分成了好几张表 上报到了我们的ODS层。
为了方便大家的使用，我们在DWD层做了一张用户访问行为天表，在这里，我们将PC网页、 H5、小程序和原生APP访问日志汇聚到一张表里面，统一字段名，提升数据质量，这样就有了一张 可供大家方便使用的明细表了。
在DWM层，我们会从DWD层中选取业务关注的核心维度来做聚合操作，比如只保留人、商品、 设备和页面区域维度。类似的，我们这样做了很多个DWM的中间表。
然后在DWS层，我们将一个人在整个网站中的行为数据放到一张表中，这就是我们的宽表了， 有了这张表，就可以快速满足大部分的通用型业务需求了。
最后，在APP应用层，根据需求从DWS层的一张或者多张表取出数据拼接成一张应用表即可。

----------------------------------------------------------------------------------------------------------------------------------------------------
今天的文章就分享到这里，小编会在下一篇章对本文万字文章做一篇精简版的总结。期待你们的一键三连哦！！
我是DJ丶小哪吒。是一名互联网行业的工具人，不生产代码，我只做代码的搬运工。哈哈哈，我们下期见哦，Bye~

如果你的内在一直成长，那么你早晚会破土而出