数仓与数仓建模

目录

一、数据仓库

英文名称为Data Warehouse，可简写为[DW]或DWH。是为企业所有级别的决策制定过程，提供所有类型数据支持的战略[集合]。

其实这个说法其实是不严谨的，过于片面，两方面，一是这个概念说为企业提供，查了一下，其实企业是以盈利为目的的，有一个新闻，上海社区利用独居老人家的智能水表和开关门等数据来判断独居老人在家是否有危险，这个案例项目也会用到数仓，或者说是大数据的项目，但是这里的数仓并不是为企业的决策制定过程的。二是只分析数据是做不了决策的，加上从业人员的经验才可以做出更好的决策，最大化发挥出数据的价值。

数据库与数据仓库区别：一个是面向主题(也就是弄这个数仓目的是啥、要分析啥、目的是干啥用)，一个是面向业务(例如卖东西，反映到数据上就是增删改查)

图例
图例

二、数仓特点

1. 主题性：按设定主题进行划分整合
2. 集成性：抽取、清洗、转换对数据进行集成
3. 稳定性：查询和分析，而不修改
4. 动态性：反映历史变化

三、数仓建模

1. 什么是建模？

建模，就是建立模型，就是为了理解事物而对事物做出的一种抽象

2. 什么是数据模型？

数据模型是抽象描述现实世界的一种工具和方法，是通过抽象的实体及实体之间联系的形式，来表示现实世界中事务的相互关系的一种映射。(可以参照楼盘沙盘来理解模型，楼的模型其实就是通过对现实世界进行抽象得到的)

3. 为什么需要数据模型？
   数据仓库的发展大致经历了这样的三个过程：

   1. 简单报表阶段

   2. 数据集市阶段：这个阶段，主要是根据某个业务部门的需要，进行一定的数据采集，整理和展现，主题单一

   3. 数据仓库阶段：这个阶段，主要是按照一定的数据模型，对整个企业的数据进行采集，整理，并且能够按照各个业务部门的需要，提供跨部门的，完全一致的业务报表数据，能够通过数据仓库生成对对业务具有指导性的数据，同时，为领导决策提供全面的数据支持。多个主题，抽象性高，模型更强。

   4. 如何建设数据模型？(分几步，每一步都干啥)(这一步在实际实现操作中其实是很模糊的，基本都是依据经验进行，因为公司一般都是从小做起，一般不会上来就干数仓，通常先搞个数据集市然后根据业务需求一步一步扩展成数仓。除非是那种传统企业转型升级有必要进行这一步骤)

      • 业务建模：划分整个公司的业务，一般按照业务部门的划分，进行各个部分之间业务工作的界定，理清各业务部门之间的关系。深入了解各个业务部门内的具体业务流程并将其程序化。(也就是公司都有哪些业务，对这些业务进行组织关系业务关系等方面进行分解梳理程序化模型化)

      • 领域建模：抽取关键业务概念，并将之抽象化。将业务概念分组，按照业务主线聚合类似的分组概念。细化分组概念，理清分组概念内的业务流程并抽象化。理清分组概念之间的关联，形成完整的领域概念模型。(简单理解为对业务进行领域划分)

      • 逻辑建模：主要是将领域模型的概念实体以及实体之间的关系进行数据仓库层次的逻辑化。(也就是建立不同业务线之间的逻辑关系)

      • 物理建模：主要解决，逻辑模型针对不同关系型数据库的物理化以及性能等一些具体的技术问题。(也就是建立真实的数据仓库，并考虑技术性能)

四、建模方法(怎么干)

1. 范式建模(相对传统)

1. 什么是范式？
   范式是符合某一种级别的关系模式的集合。关系数据库中的关系必须满足一定的要求，满足不同程度要求的为不同范式。(也就是规则，按照不同规则建立模型就是所谓的范式理论建模)

2. 范式划分？

第一范式（1NF）

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值。(说人话就是不能一列放两个属性，如果有，就得分开，也就是拆的更细)

图例

第二范式（2NF）：是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。它要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。这个唯一属性列被称为主关键字或主键、主码。(就是每一列都要有主键可以唯一区分，也就是拆的更细)

图例

第三范式（3NF）：要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。
例如：存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在图3-2的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。
例如：

图例

此外还有巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式），一般说来，只需满足第三范式(3NF）就行了。
我们总结一下：范式越高，冗余越少，数据越规范，范式越高，越灵活，扩展性越强，使用成本越高。（说人话就是拆的太细也更规范，更灵活，但是也需要更多的人力物力）

3. 范式建模
   说完了范式，那范式建模是什么呢？
   就是将事物抽象为 实体（Entity）、属性、关系(Relationship)来表示数据关联和事物描述。
   这就要说到ER模型：

   
   图例
   

   ER模型是数据库设计的理论基础，Bill Inmon (比尔·恩门，被称为数据仓库之父，最早的数据仓库概念提出者) 提出使用ER模型构建数仓。
   对于ER模型，我们需要梳理清楚企业各个业务系统的实体，实体间的关系，实体的属性，它的实施周期长，而互联网行业是不断探索，不断迭代的过程，当你还没有梳理清楚的时候，业务就已经发生了改变，甚至当你的数仓还没建好的时候，有可能这个企业已经黄了。

所以就有了接下来讲的维度建模

2、维度建模

维度建模主要以分析决策的目的 (也就是你的目的是啥 你想干啥) 进行模型构建，构建的数据模型为分析需求提供服务，因此它重点解决用户如何更快速完成分析需求，同时还有较好的大规模复杂查询的响应性能。维度建模的核心部分为事实表和维度表。(事实：事情的真实情形，说人话也就是真实的事情(发生了什么事情))
维度建模不需要完整的梳理企业业务流程和数据，可以根据主题进行建模，容易快速实现，这也符合互联网行业的特点。

1)星型模型
星型模型：由一个事实表和一组维度表组成，每个维表都有一个维度作为主键，事实表居中，多个维表呈辐射状分布于四周，并与事实表连接，形成一个星型结构。(其实就是现实生活中的星星一样，中间一个基本点，周围发散很多点，对应模型，就是一个事实，很多维度)

这是一个星星
订单表例子
事实表

2)雪花模型
雪花模型：在星型模型的基础上，基于范式理论进一步层次化，将某些维表扩展成事实表，最终形成雪花状结构. (和星型的区别就是一个中心分化出的每个分支还可以再分，就是一对多，多对多)

这是雪花
订单表举例
事实表

星型模型还是雪花模型的主要区别在于维度表的拆分，对于雪花模型，维度表的设计更加规范。
对于星型模型，采用降维的操作，利用空间换时间的方式提高易用和分析效率.

3)星座模型
星座模型是基于多个事实表、共享维度表的，这也是很多数仓的常态。所以说星座不星座只跟你的数据和需求有关系，跟设计没有关系，不需要选择。 在实际场景中不会绝对选择某一种，是根据情况灵活组合的。但是整体来看，更倾向于维度更少的星型模型，尤其是hadoop体系，减少join就是减少shuffle。

星座模型
星座模型

范式建模：业务交易、服务于业务系统
优点：准3NF、节约存储、易扩展、结构清晰、前期投入大，但后期成本低
缺点：周期长，见效慢、构建繁琐、查询复杂、学习成本高、对业务理解和建模能力都要求很高

维度建模：分析、决策、服务于分析系统
优点：方便使用、适合进行OLAP操作、建模方法简单、迭代式建设见效快
缺点：反范式、浪费存储、不易扩展、维度补全会造成存储的浪费，维度变化对数据的更新量大、前期成本低，后期会逐渐升高。

针对两种建模方式的小总结：
通俗来说：一般来说，大一点的企业，大型集团，譬如能源、电信、金融、税务、以及政府，这些是可以用Inmon的，能够承受成本和进度的压力。毕竟Inmon架构确实极具科学性和规范性、严谨些。
然而，而对于中型、小型企业（这一块量更大），尤其是民营企业，在建设成本上承受能力要弱上不少，而且比较务实，更适合灵活多变的维度建模。

4、数仓分层

<u>http://wiki.iyunxiao.com/pages/viewpage.action?pageId=342559684</u>

五、两种建模方式的区别

在大部分的数据仓库设计中，一般是不怎么考虑是否满足第几范式的，特别是互联网场景下的数据建设就更少考虑数据仓库和范式之间的关系。

讲到这里，就可以知道，范式理论建模虽然模型建立非常精细化，也就是需要成本大，也正式因为这个原因，因此，实际中范式理论主要还是应用于数据库设计，而对于面向OLAP的数据仓库，更多使用的还是相对轻量化的维度建模。(这就像追一个姑娘，你要是十年磨一剑等到自己变优秀了再去追人家，可能人家孩子都能喊你叔叔了，所以还是先上手再说，后面慢慢优化，此处和我们公司的一个理念相通，那就是先造轮子再逐步造车子)

数据库的设计，可以理解是联机事务处理OLTP（On-Line Transaction Processing），主要是基本的、日常的事务处理，例如银行交易。直白点讲，就是各种增删改查，需要对数据进行操作。

而数据仓库，我们可以理解为是联机分析处理OLAP（On-Line Analytical Processing），主要是面向日常数据分析，它的数据主要是插入和查询，基本不涉及删除和修改操作。

范式，主要优化的是增删改的问题，比如数据冗余、更新异常、删除异常等。这些也正是数据库设计比较关注的点。而数据仓库对这方面的关注度则比较少。

数据仓库更关注的是使用是否方便，查询效率是否高。 另外，数据仓库不同层级的设计也会用到不同的建模方式，比如说接近业务数据的层次，会更倾向使用范式建模，接近数据分析的层次则会更倾向于维度建模。

六、数据仓库架构演变

(这些高大上的东西有时候虽然正式，但是非常不便于我们理解。通俗来说，这就像在很久以前的时候都是人工处理数据，后来慢慢有了计算机，也就开始用表格处理数据，同时对于软件系统的数据存储交互开发了数据库，说白了就是存数据的，然后数据库也出现了各种软件提升性能，但是对于不断增多的数据量，原先的数据库并不支持分析大量的数据 (那就要知道为啥要分析大量的数据，举例给地主干活，分为长工短工，不同的工资，不同的工作时间，不同的工作内容，这是不是和现在的你上班打卡算工资一样一样的。一个人还有数据要分析，那一个公司为很多人提供各种服务更要分析)，于是就有了数据仓库的概念，以及数据湖的概念)

首先，数据仓库是伴随着企业信息化发展起来的，在企业信息化的过程中，随着信息化工具的升级和新工具的应用，数据仓库技术也在不停的发展。

历史
数仓架构演变

1）第一阶段：以Hadoop为代表的离线数据处理基础设施。
如下图所示，Hadoop是以HDFS为核心存储，以MapReduce（简称MR）为基本计算模型的批量数据处理基础设施。
围绕HDFS和MR，产生了一系列的组件，不断完善整个大数据平台的数据处理能力。同时，随着大家对于批处理的性能要求越来越高，新的计算模型不断被提出，产生了Spark、Presto等计算引擎，MR模型也逐渐进化成DAG模型。

Hadoop架构

2）第二阶段：lambda架构。
随着数据处理能力和处理需求的不断变化，越来越多的用户发现，批处理模式无论如何提升性能，也无法满足一些实时性要求高的处理场景，流式计算引擎应运而生，例如Storm、Spark Streaming、Flink等。 然而，随着越来越多的应用上线，大家发现，其实批处理和流计算配合使用，才能满足大部分应用需求；而对于用户而言，其实他们并不关心底层的计算模型是什么，用户希望无论是批处理还是流计算，都能基于统一的数据模型来返回处理结果，于是Lambda架构被提出。
Lambda架构的核心理念是“流批一体”，整个数据流向自左向右流入平台。进入平台后一分为二，一部分走批处理模式，一部分走流式计算模式。无论哪种计算模式，最终的处理结果都通过服务层对应用提供，确保访问的一致性。

Lambda架构

3）第三阶段：Kappa架构。Lambda架构解决了应用读取数据的一致性问题，但是“流批分离”的处理链路增大了研发的复杂性。因此，有人就提出能不能用一套系统来解决所有问题。目前比较流行的做法就是基于流计算来做。流计算天然的分布式特征，注定了他的扩展性更好。通过加大流计算的并发性，加大流式数据的“时间窗口”，来统一批处理与流式处理两种计算模式。

Kappa架构

4）对比

两种架构对比

5)数据湖(data lake)
(数据湖与数仓一样，都是在技术应用思想发展过程中的一种进化形态)，对于一个典型的数据湖而言，它与大数据平台相同的地方在于它也具备处理超大规模数据所需的存储和计算能力，能提供多模式的数据处理能力；增强点在于数据湖提供了更为完善的数据管理能力，具体体现在：
1）更强大的数据接入能力。
数据接入能力体现在对于各类外部异构数据源的定义管理能力，以及对于外部数据源相关数据的抽取迁移能力，抽取迁移的数据包括外部数据源的元数据与实际存储的数据。
2）更强大的数据管理能力。
管理能力具体又可分为基本管理能力和扩展管理能力。基本管理能力包括对各类元数据的管理、数据访问控制、数据资产管理，是一个数据湖系统所必须的。
扩展管理能力包括任务管理、流程编排以及与数据质量、数据治理相关的能力。
数据湖特点：
1）“保真性”
2）“灵活性”
3）“可管理”
4）“可追溯”
5）丰富的计算引擎
6）多模态的存储引擎

数据湖模型
数据湖架构

数据湖为什么叫数据湖而不叫数据河或者数据海？有一个有意思的回答帮我们理解这个概念：
1）“河”强调的是流动性，“海纳百川”，河终究是要流入大海的，而企业级数据是需要长期沉淀的，因此叫“湖”比叫“河”要贴切；同时，湖水天然是分层的，满足不同的生态系统要求，这与企业建设统一数据中心，存放管理数据的需求是一致的，“热”数据在上层，方便应用随时使用；温数据、冷数据位于数据中心不同的存储介质中，达到数据存储容量与成本的平衡。
2）不叫“海”的原因在于，海是无边无界的，而“湖”是有边界的，这个边界就是企业/组织的业务边界；因此数据湖需要更多的数据管理和权限管理能力。
3）叫“湖”的另一个重要原因是数据湖是需要精细治理的，一个缺乏管控、缺乏治理的数据湖最终会退化为“数据沼泽”，从而使应用无法有效访问数据，使存于其中的数据失去价值。

七、收获

经过此次学习总结对数仓、数仓发展及建模理论有了一些系统的了解，同时也知道了在实际工作中应该如何建模，比如单业务线建模可以参照一下步骤：
业务线建模步骤：
1、梳理业务线的内部实体关系以及此业务线与其他业务线的关系，并使用流程图将关系程序化
2、针对分析目的确定分析的主题
3、确定数据源
4、确定数仓命名规范
5、根据业务需求及数仓分层划分事实表、维度表等
6、数据ETL
但这仍需要不断实践并优化，才能根据经验建立合适的数仓模型。
同时，也反思了在数仓融合过程中一些好的以及可以优化的地方，比如在融合时避免了烟囱式的开发，采用逐层实现的方案，但是根据原有设计实现并未能根据现有业务重新进行梳理并根据需求合理重构也是一点遗憾，在公司不断发展的过程中，业务和数据也会不断变化，数仓也会更加完善。
总的来说，数仓建模是理论与实践相结合的过程，需要理论的支撑的实践的经验才能在各种环境下面对不同需求建立合适的模型，正如理论的终点是哲学一样，不能太苛求某一种理论，适合的才是最好的。

问题总结：

1、什么样的数仓可以称为好数仓？
数据源的接入：数据时效性新、数据源完整、脏数据过滤良好、可支持多形式多平台的数据接入
业务的处理与分离：业务线分离清晰
数据的处理：数据质量高、处理耗时短、任务调度合理
权限管理：清晰、安全
2、范式建模与维度建模的各有什么优劣？
范式建模
优点：结构清晰、易扩展
缺点：周期长，见效慢、构建繁琐
维度建模
优点：周期短、见效快、相对易于建设
缺点：反范式、浪费存储、不易扩展
3、事实表与维度表的区别？
事实表就是你要关注的内容，维度表就是你观察该事务的角度，是从哪个角度去观察这个内容的。
4、事实表要考虑哪些？
(1)选择业务过程
(2)声明粒度
(3)确认维度
(4)确认事实
5、维度与度量怎么选？
维度提供围绕某一业务过程事件所涉及的“谁、什么、何处、何时、为什么、如何”等背景。
业务过程中能够表达真实事件的关键指标就是度量，根据事件数据含有的度量与业务所需度量进行选择
6、什么场景下建宽表?
宽表由于把不同的内容都放在同一张表存储，已经不符合三范式的模型设计规范，随之带来的坏处就是数据的大量冗余，好处就是查询性能的提高与便捷。
通常应用于画像、数据挖掘模型训练前的数据准备等需要提升数据计算效率的场景。