数仓概念梳理

数仓概念梳理

数仓分层

常见分层思路、案例

案例1：互联网金融

ODL层 (Operational Data Layer)：操作数据层

​ 外部数据什么样，该层数据就是什么样（关系型数据库、JSON格式等)，部分关系型数据可以直接转IDL层

BDL层 (Base Data Layer)：基础数据层

​ ODL层经过简单格式化解析后存储到BDL层，常见于JSON日志格式的解析。

IDL层 (Interface Data Layer)：接口层，也称主题表，宽表

​ 由BDL层经过去重、去噪、字典翻译、空值转化，日期格式化、关联JOIN、维度分析等清洗后的数据，如：用户、产品、绑卡、订单、用户行为等明细数据。

ADL层 (Application Data Layer)：应用层 ，也称数据集市

​ 通常与需求对接，由IDL层基于某些维度的深度加工统计汇总等操作转化而来，涉及到多个主题以及tmp数据之间的关联JOIN后的结果。

DIC层 (Dictionary Data Layer)：字典层

​ 存储一些诸如省、市、县区域表、渠道列表、商品类目等等表数据，可以从数据源直接sqoop生成dic_xxx表，也可以通过odl层转化层dic_表。

TMP层 (Temporary Data Layer)：临时层

​ 存储一些中间计算结果

案例2：电商业务

ODS(Operation Data Store)：原始数据层

​ ODS层：原始数据层，存放原始数据，直接加载原始日志、数据，数据保持原貌不做处理。

DWD(data warehouse detail)：明细数据层

​ DWD层：对ODS层数据进行清洗（去除空值，脏数据，超过极限范围的数据）、维度退化、脱敏等

DWS(data warehouse service)：服务数据层

​ 以DWD为基础，按天进行轻度汇总。

DWT(data warehouse Topic)：数据主题层

​ 以DWS为基础，按主题进行汇总。

ADS(Application Data Store)：数据应用层

​ ADS层，为各种统计报表提供数据

分层的优点

1）把复杂问题简单化 将复杂的任务分解成多层来完成，每一层只处理简单的任务，方便定位问题。
2）减少重复开发 规范数据分层，通过的中间层数据，能够减少极大的重复计算，增加一次计算结果的复用性。
3）隔离原始数据 不论是数据的异常还是数据的敏感性，使真实数据与统计数据解耦开。

各数据维度概念

数据库

​ 本质上是一个二维关系存储系统，存储结构化数据，比如某学校的学生信息表、某年级的学生成绩表等。它因为使用简单，结构化程度高，极大的促进了互联网的发展。它包含操作性数据库和分析型数据库两类。

​ 由于操作型数据库写多查少、数据动态变化、存储时间要求不高等特点，它注定与分析型数据库不会是同一个数据库，分析型数据库写少查多、数据基本稳定、存储时间长。随着我们对分析数据的要求变高，我们希望看到更多维度的分析，传统的分析型数据库的支持就变得很难了，比如我们想看淘宝某店家的披萨在什么情况下最好销售，这时候需要披萨信息表、订单销售表、消费者信息表、中国天气表等多个表联同起来，才能分析出在什么天气、什么地理位置、什么口味、什么价格的时候最好售卖，因此数据仓库应运而生。

数据仓库

​ 本质上是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，是比数据库范围更大的库。所谓面向主题，它指的是数据仓库内的信息按照某个主题进行聚合，比如地区、成本、商品、收入、利润等等；所谓集成的，它指的是可以把不同数据库中的数据都汇聚在一起；所谓相对稳定的，它指的是数据仓库的数据不会像操作型数据库那样经常变化；所谓反映历史变化，它指的是数据仓库内的信息不只是反映企业当前情况，还可以记录分析从过去某一个时间点到现在的变化。

对于数据仓库的概念我们可以从两个层次予以理解：
首先，数据仓库用于支持决策，面向分析型数据处理，它不同于企业现有的操作型数据库;
其次，数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。
简单的理解，其实就是为了进行OLAP(联机事务处理on-line transaction processing)，把分布在各个散落独立的数据库孤岛整合在了一个数据结构里面，称之为数据仓库。

数据集市

​ 所谓数据集市，它是一个小型的数据仓库，只关注某一个主题，比如只关注成本，那么它就会只收录成本相关的数据，数据来源可以是自己的源数据库，也可以从数据仓库中获取某一主题的数据；它通常有更少的数据，更少的主题区域，以及更少的历史数据。

​ 数据集市它只包含单个主题，且关注范围也非全局。数据集市可以分为两种:
一种是独立数据集市，这类数据集市有自己的源数据库和ETL架构；
另一种是非独立数据集市，这种数据集市没有自己的源系统，它的数据来自数据仓库。当用户或者应用程序不需要/不必要/不允许用到整个数据仓库的数据时，非独立数据集市就可以简单为用户提供一个数据仓库的子集。

数据湖

​ 数据湖是一种数据存储理念，存储企业各种各样的原始数据的大型仓库，包括结构化、非结构、二进制图像、音频、视频等等。

​ 它是一个比数据仓库更大、对于数据也没有任何限制的大型仓库，里面的数据像湖水一样可以自然流动，数据可以供存储、处理、分析。在数据湖中，存储的数据没有经过任何的处理，是直接从源系统导入的数据，它包含结构化数据、非结构化数据、半结构化数据，范围非常广，也是数据仓库的数据来源。此外，它还用于机器学习、预测分析、信息追踪等场景，提供海量的数据供科学家们进行模型训练、在某个领域做推荐引擎。数据仓库和数据湖的区别可见下表所示。

数据湖还有以下特点：

​ 从源系统导入所有的数据，没有数据流失。
​ 数据存储时没有经过转换或只是简单的处理。
​ 数据转换和定义schema 用于满足分析需求。

数据中台

​ 本质上是服务于业务的数据分析系统，它从一出生开始就是为业务而生。数据仓库提供的是统计分析、单领域维度、被动分析、非实时分析，必然不能满足企业的多维度分析、主动分析、预测分析、实时分析、多元化分析等场景，因此数据中台应运而生。整个数据中台产品就是一个闭环的解决方案，不再是业务过程中的一环，它包含数据埋点、数据接入标准化、数据仓库抽象化、数据治理、数据服务五大模块，打通了人、物、场多个维度，更好的为前台去服务。此外在数据中台的建设中，企业组织文化也非常重要，它需要联动各个业务线去接入这套系统，标准化治理与管理，但在数据仓库的建设过程是不需要关注这一层次的。因此数据中台是数据仓库的又一次质的飞跃。

​ 数据中台整体技术架构上采用云计算架构模式，将数据资源、计算资源、存储资源充分云化，并通过多租户技术进行资源打包整合，并进行开放，为用户提供“一站式”数据服务。

​ 利用大数据技术，对海量数据进行统一采集、计算、存储，并使用统一的数据规范进行管理，将企业内部所有数据统一处理形成标准化数据，挖掘出对企业最有价值的数据，构建企业数据资产库，提供一致的、高可用大数据服务。

​ 数据中台不是一套软件，也不是一个信息系统，而是一系列数据组件的集合，企业基于自身的信息化建设基础、数据基础以及业务特点对数据中台的能力进行定义，基于能力定义利用数据组件搭建自己的数据中台。

数仓命名规范

APP应用层表名
前缀为APP_主题名（缩写）功能描述 。数据表名称必须以有特征含义的单词或缩写组成，中间可以用下划线分割
例如： APP_RPT DEALER_GOODS。表名称不能用双引号包含，表名长度不超过30个字符。

DW/DM维度表表名　　　　　
前缀为D_ 。数据表名称必须以有特征含义的单词或缩写组成，中间可以用下划线分割
例如：D_ACCOUNT、D_PUB_DATE。表名称不能用双引号包含，表名长度不超过30个字符。

元数据表名
前缀为M_应用名（缩写）_功能描述 。数据表名称必须以有特征含义的单词或缩写组成，中间可以用下划线分割
例如：M_ETL_TASK。表名称不能用双引号包含，表名长度不超过30个字符。

数仓理论

范式理论

范式概念

1）定义

范式可以理解为设计一张数据表的表结构，符合的标准级别。 规范和要求

2）优点

关系型数据库设计时，遵照一定的规范要求，目的在于降低数据的冗余性。

为什么要降低数据冗余性？

（1）十几年前，磁盘很贵，为了减少磁盘存储。

（2）以前没有分布式系统，都是单机，只能增加磁盘，磁盘个数也是有限的

（3）一次修改，需要修改多个表，很难保证数据一致性

3）缺点

范式的缺点是获取数据时，需要通过Join拼接出最后的数据。

4）分类

目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

函数依赖

1、完全函数依赖：

设X，Y是关系R的两个属性集合，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。
完全函数依赖与部分函数依赖：在关系模式R(U)中，如果X->Y，并且对于X的任何一个真子集XX，都有XX不决定Y，则称Y完全函数依赖于X，记作X-（F）Y。如果X->Y，但Y不完全函数依赖于X，则称Y部分函数依赖于X记作X（P）Y。

提示：如果Y对X部分函数依赖，X中的“部分”就可以确定对Y的关联，从数据依赖的观点来看，X中存在“冗余”属性。实际上，部分依赖与传递依赖是产生冗余和异常的两个重要原因。

2、部分函数依赖(平凡函数依赖)

平凡函数依赖与非平凡函数依赖：在关系模式R(U)中，对于U的子集X和Y，如果X——>Y，但是Y不是X的子集，则称X->Y是非平凡函数依赖，若Y是X的子集，则称X->Y是平凡函数依赖。

提示：对于任一关系模式，平凡函数依赖都是必然成立的。

3、传递函数依赖

在关系模式R(U)中，如果X->Y,Y->Z,且Y不决定X，Z不属于X,则称Z传递函数依赖于X，记作X->(T)Z。

提示：传递函数依赖定义中之所以要加上条件Y不决定X，是因为如果Y->X,则X<->Y,这实际上是Z直接依赖于X，也就是直接函数依赖，而不是传递函数依赖。

三范式区分

第一范式1NF

要求属性不可分，第一范式是设计数据库表的最低要求。如联系方式 ：电环：XXX；邮箱：ssssss@qq.com。这个就不符合1NF。实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。

第二范式2NF

要求在满足1NF基础上，每个非主属性完全函数依赖于候选键。不能存在“部分函数依赖”

第三范式3NF

要求在满足2NF基础上，关系模式R(U,F)中的所有非主属性对任何候选键都不存在传递依赖。则称关系R是属于第三范式的模式。

关系建模与维度建模

​ 数据管理一直在演进，从早期的电子表格、蛛网系统到架构式数据仓库。发展至今以维度建模和关系建模为主，而随着互联网的发展，数据从GB到PB的裱花，企业业务迭代更新亦是瞬息万变，对维度模型的偏爱渐渐有统一互联网数仓建模标准的趋势。数仓模型不分高下，都是一种观察现实的角度。维度模型以实体与实体之间发生的事务/实为切入，而关系建模则以实体与实体之间的关系来组织数据。在当前的环境下，互联网更倾向于维度建模，而传统行业则较多沿用关系建模。

对比	维度建模	关系建模
建设周期	短	长
优点	高效	灵活
实践方式	需求导向	抽象化企业数据
常用范围	数据集市	企业模型

​ 当今的数据处理大致可以分成两大类：联机事务处理OLTP（on-line transaction processing）、联机分析处理OLAP（On-Line Analytical Processing）。OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。二者的主要区别对比如下表所示。

对比属性	OLTP 联机事务处理	OLAP 联机分析处理
读特性	每次查询只返回少量记录	对大量记录进行汇总
写特性	随机、低延时写入用户的输入	批量导入
使用场景	用户，Java EE项目	内部分析师，为决策提供支持
数据表征	最新数据状态	随时间变化的历史状态
数据规模	GB	TB到PB

​ 关系模型

关系模型如图所示，严格遵循第三范式（3NF），从图中可以看出，较为松散、零碎，物理表数量多，而数据冗余程度低。由于数据分布于众多的表中，这些数据可以更为灵活地被应用，功能性较强。关系模型主要应用与OLTP系统中，为了保证数据的一致性以及避免冗余，所以大部分业务系统的表都是遵循第三范式的。

​ 维度模型示意图

维度模型如图所示，主要应用于OLAP系统中，通常以某一个事实表为中心进行表的组织，主要面向业务，特征是可能存在数据的冗余，但是能方便的得到数据。

关系模型虽然冗余少，但是在大规模数据，跨表分析统计查询过程中，会造成多表关联，这会大大降低执行效率。所以通常我们采用维度模型建模，把相关各种表整理成两种：事实表和维度表两种。

关系建模

关系建模，被称为“实体-关系”模型，以一种“标准化”的方式存在，强调数据之间非冗余，满足3NF。在建设过程中，将数据标准化到细节级数据，如用户主题下，会有用户与姓名、用户与年龄、用户与住址等。在传统行业中，成熟的关系建模有ls-ldm模型，面向金融行业形成10大主题。

维度建模

以事实表为核心，多个维度表作为手臂形成的星型模型，是维度建模的典型实现方式。

事实表，记录业务过程中发生的可度量事件，如订单中的消费金额，折扣金额或是库存数量等，在实际业务中事实表占据主要的存储，如订单表；而维度表，则是对业务过程度量有关的文本环境，描述“谁、什么、哪里、何时、如何、为什么”，常用的维度表有日期、产品、用户、地址等。一般维度表会冗余信息，有超过100个列的维度表，这样的不规范化带来数据组织上的简单。

维度建模的三种方式：

​ 数据仓库大多数时候是比较适合使用星型模型构建底层数据Hive表，通过大量的冗余来减少表查询的次数从而提升查询效率，星型模型对OLAP的分析引擎支持比较友好，这一点在Kylin中比较能体现。而雪花模型在关系型数据库中如MySQL，Oracle中非常常见，尤其像电商的数据库表。在数据仓库中雪花模型和星座模型的应用场景比较少，但也不是没有，所以在具体设计的时候，可以考虑是不是能结合两者的优点参与设计，以此达到设计的最优化目的。

1.星型模式

​ 星形模型中有一张事实表，以及零个或多个维度表，事实表与维度表通过主键外键相关联，维度表之间没有关联，当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。星形模型是最简单，也是最常用的模型。由于星形模型只有一张大表，因此它相比于其他模型更适合于大数据处理。其他模型可以通过一定的转换，变为星形模型。

2.雪花模式

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的维度表，形成一些局部的 " 层次 " 区域，这些被分解的表都连接到主维度表而不是事实表

3.星座模式

星座模型是由星型模型延伸而来，星型模型是基于一张事实表而星座模式是基于多张事实表，并且共享维度表信息，这种模型往往应用于数据关系比星型模型和雪花模型更复杂的场合。星座模型需要多个事实表共享维度表，因而可以视为星形模型的集合，故亦被称为星系模型

模型的选择

首先就是星座不星座这个只跟数据和需求有关系，跟设计没关系，不用选择。
星型还是雪花，取决于性能优先，还是灵活更优先。
目前实际企业开发中，不会绝对选择一种，根据情况灵活组合，甚至并存（一层维度和多层维度都保存）。但是整体来看，更倾向于维度更少的星型模型。尤其是Hadoop体系，减少Join就是减少Shuffle，性能差距很大。（关系型数据可以依靠强大的主键索引）

维度表和事实表

维度表

维度表：一般是对事实的描述信息。每一张维表对应现实世界中的一个对象或者概念。 例如：用户、商品、日期、地区等。
维表的特征：

​ 1.维表的范围很宽（具有多个属性、列比较多）

​ 2.跟事实表相比，行数相对较小：通常< 10万条

​ 3.内容相对固定：编码表

事实表

事实表中的每行数据代表一个业务事件（下单、支付、退款、评价等）。“事实”这个术语表示的是业务事件的度量值（可统计次数、个数、金额等），例如，订单事件中的下单金额。
每一个事实表的行包括：具有可加性的数值型的度量值、与维表相连接的外键、通常具有两个和两个以上的外键、外键之间表示维表之间多对多的关系。
事实表的特征：

1. 非常的大
   2.内容相对的窄：列数较少
   3.经常发生变化，每天会新增加很多。

1）事务型事实表

以每个事务或事件为单位，例如一个销售订单记录，一笔支付记录等，作为事实表里的一行数据。一旦事务被提交，事实表数据被插入，数据就不再进行更改，其更新方式为增量更新。

2）周期型快照事实表

周期型快照事实表中不会保留所有数据，只保留固定时间间隔的数据，例如每天或者每月的销售额，或每月的账户余额等。

3）累积型快照事实表

累计快照事实表用于跟踪业务事实的变化。例如，数据仓库中可能需要累积或者存储订单从下订单开始，到订单商品被打包、运输、和签收的各个业务阶段的时间点数据来跟踪订单声明周期的进展情况。当这个业务过程进行时，事实表的记录也要不断更新。

数据仓库建模

数仓分层根据各业务不同，分仓定义名称不同，各层功能部分也会有不同，这里举一个案例作为参考，提供一个思路，不代表数仓分层一定是这样的处理方式

ODS层

[ operation Data Store：原始数据层 ]

（1）保持数据原貌不做任何修改，起到备份数据的作用，也有公司称作贴源层
（2）数据多采用压缩方式，减少磁盘存储空间（例如：原始数据100G，可以压缩到10G左右）
（3）创建partition分区表，防止后续的全表扫描(一般按照dt日期分区)

DWD层

[ data warehouse detail：明细数据层 ]

DWD层需构建维度模型，一般采用星型模型，呈现的状态一般为星座模型。

维度建模一般按照以下四个步骤：
选择业务过程→声明粒度→确认维度→确认事实
（1）选择业务过程
在业务系统中，挑选我们感兴趣的业务线，例如下单业务，支付业务，退款业务，物流业务，一条业务线对应一张事实表。
（2）声明粒度
数据粒度指数据仓库的数据中保存数据的细化程度或综合程度的级别。
声明粒度意味着精确定义事实表中的一行数据表示什么，应该尽可能选择最小粒度，以此来应各种各样的需求。
典型的粒度声明如下：
订单中，每个商品项作为下单事实表中的一行，粒度为每次下单
每周的订单次数作为一行，粒度就是每周下单。
每月的订单次数作为一行，粒度就是每月下单
（3）确定维度
维度的主要作用是描述业务是事实，主要表示的是“谁，何处，何时”等信息。
（4）确定事实
此处的“事实”一词，指的是业务中的度量值，例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。

至此，数仓的维度建模已经完毕，DWS、DWT和ADS和维度建模已经没有关系了。

DWS层

统计各个主题对象的当天行为，服务于DWT层的主题宽表。

DWT层

[ data warehouse Topic：数据主题层 ]

以分析的主题对象为建模驱动，基于上层的应用和产品的指标需求，构建主题对象的全量宽表。

DWS和DWT都是建宽表，宽表都是按照主题去建。主题相当于观察问题的角度。对应着维度表。

ADS层

[ application Data Store：数据应用层 ]

中的度量值，例如订单金额、下单次数等。
在DWD层，以业务过程为建模驱动，基于每个具体业务过程的特点，构建最细粒度的明细层事实表。事实表可做适当的宽表化处理。