08数仓
数仓
为什么要分层
清晰数据结构
每一个数据分层都有它的作用域，这样我们在使用表的时候能更方便地定位和理解。
方便数据血缘追踪
简单来说，我们最终给业务呈现的是一个能直接使用业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围
减少重复开发
规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算
把复杂问题简单化
将一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
屏蔽原始数据的异常
屏蔽业务的影响，不必改一次业务就需要重新接入数据
ETL
ETL的设计分三部分：数据抽取（Extract）、转换（Transform）、装载（Load）。在设计ETL的时候我们也是从这三部分出发。数据的抽取是从各个不同的数据源抽取到ODS(Operational Data Store，操作型数据存储)中。
数据的抽取（Extract）
这一部分需要在调研阶段做大量的工作，首先要搞清楚数据是从几个业务系统中来,各个业务系统的数据库服务器运行什么DBMS,是否存在手工数据，手工数据量有多大，是否存在非结构化的数据等等，当收集完这些信息之后才可以进行数据抽取的设计。
数据的清洗转换（Cleaning、Transform）
数据清洗的任务是过滤那些不符合要求的数据，将过滤的结果交给业务主管部门，确认是否过滤掉还是由业务单位修正之后再进行抽取。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。比如有效值检测（如是否是已有的邮政编 码？是否在有效值范围内？）、一致性检测（如邮政编码与城市代码是否一致？）、删除重复记录（如是否有同一个客户出现两次而相关的属性略有不同？）、检测 是否有复杂的业务规则和过程需要增强（如白金客户是否有相关的信用状态？）等等
数据转换的任务主要进行不一致的数据转换、数据粒度的转换。比如 不一致数据转换：这个过程是一个整合的过程，将不同业务系统的相同类型的数据统一，比如同一个供应商在结算系统的编码是XX0001,而在CRM中编码是YY0001，这样在抽取过来之后统一转换成一个编码。数据粒度的转换：业务系统一般存储非常明细的数据，而数据仓库中数据是用来分析的，不需要非常明细的数据。一般情况下，会将业务系统数据按照数据仓库粒度进行聚合。
数据装载
数据装载也叫提交。后台任务的终点就是准备好数据以方便查询。这一步骤中至关重要的是将数据物理地组织成简单、对称的框架模型，我们称之为维度模型，或者星 型模型。
数仓分层思想
数据分层每个企业根据自己的业务需求可以分成不同的层次，但是最基础的分层思想，理论上数据分为三个层，数据运营层、数据仓库层和数据服务层。基于这个基础分层之上添加新的层次，来满足不同的业务需求。
数据运营层(ODS)
Operate data store（操作数据-存储），是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的ETL之后，装入ODS层。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。例如：MySQL里面的一张表可以通过sqoop之间抽取到ODS层
ODS层是数据仓库准备区，为DWD层提供基础原始数据，可减少对业务系统的影响
建模原则：从业务系统增量抽取、保留时间由业务需求决定、可分表进行周期存储、数据不做清洗转换与业务系统数据模型保持一致、按主题逻辑划分
数据仓库层（DW）
Data warehouse（数据仓库）。在这里，从ODS层中获得的数据按照主题建立各种数据模型。例如以研究人的旅游消费为主题的数据集中，便可以结合航空公司的登机出行信息，以及银联系统的刷卡记录，进行结合分析，产生数据集。在这里，我们需要了解四个概念：维（dimension）、事实（Fact）、指标（Index）和粒度（ Granularity）。
DW数据分层，由下到上为 DWD,DWB,DWS
- DWD：data warehouse detail 细节数据层，是业务层与数据仓库的隔离层。为DW层提供来源明细数据，提供业务系统细节数据的长期沉淀，为未来分析类需求的扩展提供历史数据支撑，数据模型与ODS层一致，不做清洗转换处理、为支持数据重跑可额外增加数据业务日期字段、可按年月日进行分表、用增量ODS层数据和前一天DWD相关表进行merge处理
- DWB：data warehouse base 基础数据层，存储的是客观数据，一般用作中间层，可以认为是大量指标的数据层。根据DWD明细数据进行转换，如维度转代理键、身份证清洗、会员注册来源清晰、字段合并、空值处理、脏数据处理、IP清晰转换、账号余额清洗、资金来源清洗等
- DWS：data warehouse service 服务数据层，基于DWB上的基础数据，整合汇总成分析某一个主题域的服务数据，一般是宽表。根据DWB层数据按各个维度ID进行高粒度汇总聚合，如按交易来源，交易类型进行汇合
Data Market (数据集市)层
可以是一些宽表，是根据DW层数据按照各种维度或多种维度组合把需要查询的一些事实字段进行汇总统计并作为单独的列进行存储
数据服务层/应用层（ADS）
Application Data Service(应用数据服务)。该层主要是提供数据产品和数据分析使用的数据，一般会存放在ES、MySQL等系统中供线上系统使用，也可能会存在Hive或者Druid中供数据分析和数据挖掘使用。例如：我们经常说的报表数据，或者说那种大宽表，一般就放在这里。
建模方法
范式建模（E-R模型）
将事物抽象为“实体”、“属性”、“关系”来表示数 据关联和事物描述
ER模型是数据库设计的理论基础，当前几乎所有的OLTP系统 设计都采用ER模型建模的方式
但是 逐渐随着企业数据的高增长，复杂化，数仓全部使用ER模型建模 显得越来越不合时宜。因为其按部就班的步骤，三范式等，不适合现代化复杂，多变的业务组织。
E-R模型建模的步骤（满足3NF）如下：
- 抽象出主体 (教师，课程)
- 梳理主体之间的关系 （一个老师可以教多门课，一门课可以被多个老师教）
- 梳理主体的属性 （教师：教师名称，性别，学历等）
- 画出E-R关系图
维度建模
维度建模，是数据仓库大师Ralph Kimball提出的，是数据仓库工程领域最流行的数仓建模经典。
维度建模以分析决策的需求出发构建模型，构建的数据模型为分析需求服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。维度建模是面向分析的，为了提高查询性能可以增加数据冗余，反规范化的设计技术。
Ralph Kimball提出对数据仓库维度建模，并且将数据仓库中的表划分为事实表、维度表两种类型。
事实表
在ER模型中抽象出了有实体、关系、属性三种类别，在现实世界中，每一个操作型事件，基本都是发生在实体之间的，伴随着这种操作事件的发生，会产生可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。
事实表的设计时，一定要注意一个事实表只能有一个粒度，不能将不同粒度的事实建立在同一张事实表中
以电商行业为例：电商场景：一次购买事件，涉及主体包括客户、商品、商家，产生的可度量值 包括商品数量、金额、件数等
维度表
维度，顾名思义，业务过程的发生或分析角度。比如从颜色、尺寸的角度来比较手机的外观，从cpu、内存等较比比较手机性能维。
比如
- 商品维度：商品ID、商品名称、商品种类、单价、产地等
- 用户维度：用户ID、姓名、性别、年龄、常住地、职业、学历等
- 时间维度：日期ID、日期、周几、上/中/下旬、是否周末、是否假期等
维度分为：
（1）退化维度（DegenerateDimension）
在维度类型中，有一种重要的维度称作为退化维度，亦维度退化一说。这种维度指的是直接把一些简单的维度放在事实表中。退化维度是维度建模领域中的一个非常重要的概念，它对理解维度建模有着非常重要的作用，退化维度一般在分析中可以用来做分组使用。
（2）缓慢变化维（Slowly Changing Dimensions）
维度的属性并不是始终不变的，它会随着时间的流逝发生缓慢的变化，这种随时间发生变化的维度我们一般称之为缓慢变化维（SCD）。比如员工表中的部门维度，员工的所在部门有可能两年后调整一次。
维度建模模型分类
星型模型
星型模型主要是维表和事实表，以事实表为中心，所有维度直接关联在事实表上，呈星型分布。
雪花模型
雪花模型，在星型模型的基础上，维度表上又关联了其他维度表。雪花模型，维度表的涉及更加规范，一般符合3NF，有效降低数据冗余，维度表之间不会相互关联。这种模型维护成本高，性能方面也较差，所以一般不建议使用。尤其是基于hadoop体系构建数仓，减少join就是减少shuffle，性能差距会很大。
