数仓建模—数据仓库初识

数据仓库之父Bill Inmon在1991年出版的"Building the Data Warehouse"一书中所提出的定义被广泛接受

数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

这是一个偏向学术的定义，却非常准确的界定了数据仓库与其他数据库系统的本质区别，我们也可以认为数据仓库是一种分析数据库，用于存储和处理数据，以便对数据进行分析。

数据仓库的本质就是从面向业务过程的数据组织管理方式向面向分析的数据组织管理方式的转变，面向业务过程的组织管理方式最常见的就是各种各样的业务系统，例如ERP、CRM 等

数据仓库的两个主要功能：存储分析数据和处理分析数据，当然你也可以认为是一种那就是数据管理能力。

数据仓库是一种体系结构，而不是某一种技术，就像我们常说的Hive 也只是数仓的一种工具而已，可以是它，也可以是其他技术，技术一直在变化，而一种设计思想或者是架构设计是很长一段时间都不会变化的，例如数仓的分层设计，变化的只是层的划分界限或者是层的名称什么的，但是分层的思想是一直没有变化的。

数据仓库最为核心的内容主要有两部分

第一部分建模
第二部分查询

建模是我们组织管理数据的方式，查询是数仓对外提供服务的能力，所以你可以看到建模是一种思想，查询服务是一种具体的实现，所以建模是底层思想、底层建筑、查询是对外提供服务，所以它一直在变化，数仓的查询能力是我们实现建模思想的手段也是我们对外提供服务的手段。

需要注意的是，数据仓库只是我们做数据服务的一个环节，最终的目的是做数据服务，用于支持管理决策，所以在我们的整个数据平台上，我们还提供了数据服务功能，也就是对外的数据接口和adhoc

数据仓库需要提供快速和高性能的查询能力，以支持复杂的分析和报表需求。为了实现这一点，数据仓库采用各种技术和策略，例如索引、分区、数据压缩、并行处理等，来优化查询性能和减少响应时间。

面向分析的存储系统

也就是说数仓是存数据的，企业的各种数据往里面塞(集成)，主要目的是为了有效分析数据，后续会基于它产出供分析挖掘的数据，或者数据应用需要的数据，如企业的分析性报告和各类报表，为企业的决策提供支持。

这就决定了它和传统的数据库是不一样的，因为我们对它的诉求是不一样的，例如我们关注它能不能存储各种各样的数据或者有没有这个能力能存储企业的全部数据，能不能对外提供分析决策的能力。

操作型数据库

主要面向应用，用于业务支撑，支持对实际业务的处理，也可以叫业务型数据库。可以理解为通常意义上的数据库（后端开发同学口中的经常提到的就是这种）。

要真正理解数据仓库的概念，需要与数据库的系统的对比来看。

数据库是作为“所有处理的单一数据源”出现和定义的。

数据库的出现有两个驱动因素，第一是70年代以前大量应用程序和主文件的分散存放导致一片混乱和大量冗余数据。第二是直接存取存储设备的出现使得按记录寻址成为可能。基于DBMS的在线事务处理为商业发展开辟全新的视野。

数据库系统的设计目标是事务处理。数据库系统是为记录更新和事务处理而设计，数据的访问的特点是基于主键，大量原子，隔离的小事务，并发和可恢复是关键属性，最大事务吞吐量是关键指标，因此数据库的设计都反映了这些需求。

数据仓库的设计目标是决策支持。历史的，摘要的，聚合的数据比原始的记录重要的多。查询负载主要集中在即席查询和包含连接，聚合等操作的复杂查询。

相对于数据库系统来说，查询吞吐量和响应时间比事务处理吞吐量重要的多。数据仓库和数据库系统的区别，一言蔽之：OLAP和OLTP的区别。数据库支持是OLTP，数据仓库支持的是OLAP

对 OLTP 和OLAP 的区别还可以有一个维度，就是及时性需求。OLTP对事务的及时性需求较高，而OLAP 则不然。

分析型数据库

主要面向数据分析，侧重决策支持，作为公司的单独数据存储，负责利用历史数据对公司各主题域进行统计分析。

由于分析型数据库中的操作都是查询，因此也就不需要严格满足关系型数据库一些设计规范，这样的情况下再将它归为数据库不太合适，也容易不引起混淆，所以称之为数据仓库。

数仓建模

数据仓库采用特定的数据模型来组织和表示数据。常用的数据建模技术包括维度建模和星型/雪花模型。维度建模将数据组织成以事实表（包含业务度量）和维度表（包含描述性属性）为中心的结构，使得数据分析和查询变得更加直观和高效。

数仓的特点

数据仓库主要用来进行决策分析的,所以数据仓库是有它自己的特点的。

数据仓库是面向主题的

与传统的数据库不一样，数据仓库是⾯面向主题的，那什么是主题呢？

首先主题是一个较高乘次的概念，是较高层次上对企业信息系统中的数据进行综合归类并进行分析的对象集合。在逻辑意义上，它是对企业中某一个宏观分析领域所涉及的分析对象。(就是⽤户用数据仓库进行决策所关心的重点的⽅方⾯面，⼀个主题通常与多个操作信息型系统有关，⽽操作型数据库的数据组织⾯向事务处理理任务，各个任务之间是相互隔离的)

要很好地理解主题这个概念我们还是要和操作型数据系统进行对比，我们的操作型数据系统更多的是面向应用或者是功能的

面向应用例如汽车产品、人寿产品、
面向功能例如登陆注册、加入购物车、下单、浏览搜索等

如果我们是按照应用来划分的，那我们如果有多个应用，那我们的用户表、购物车等表就会有多个，站在整个企业的角度来说，这就是数据孤岛。

但是我们的数据仓库里面的主题指的是例如顾客主题、保险主题、消费主题、索赔主题、产品主题，其实我们可以看到这是两个不同方向的划分层次，数仓的主题就是对某个分析领域的概念总结，是一个高屋建瓴式的方向领导，一个数仓可以有一个主题或者多个主题。面向主题的数据组织方式，就是在较高层次上对被分析对象有一个完整、一致的描述，能刻画各个分析对象所涉及到的各项数据及数据之间的关系。

数据仓库是集成的

集成的原因就是我们的操作型数据都是面向应用的，也就是非集成的，数据仓库的数据是从原来的分散的数据库数据(mysql等关系型数据库)抽取出来的，然后进行集成，不集成的数据是没有意义的，数据孤岛依然存在，但是抽取到数仓的这一步也就是ODS 环节，只是具备了集成的条件，但是还没有集成。

操作型数据库与DSS(决策⽀支持系统)分析型数据库差别甚⼤大。

第⼀，数据仓库的每一个主题所对应的源数据在所有的各个分散的数据库中，有许多重复和不一样的地⽅方，且来源于不不同的联机系统的数据都和不同的应⽤用逻辑捆绑在⼀起;
第二，数据仓库中的综合数据不能从原来有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一处理，这⼀步是数据仓库建设中最关键、最复杂的一步，所要完成的⼯作有:
1. 要统计源数据中所有矛盾之处，如字段的同名异议、异名同义、单位不统一，字段长度不统一等。
2. 进⾏数据的综合和计算。数据仓库中的数据综合工作可以在原有数据库抽取数据时生成，但许多是在数据仓库内部⽣成的，即进入数据仓库以后进行综合⽣成的

数据仓库作为一个中心化的存储系统，用于集成来自多个不同数据源的数据。这些数据源可以包括企业内部的操作型数据库、数据湖、日志文件、外部数据提供商等。通过将这些数据源整合到一个数据仓库中，企业可以消除数据孤岛，并在一个地方对数据进行统一管理和查询。

多数据源抽取/集成

这只是集成的第一步，就是将相关的数据都抽取过来，存放在数仓里，这个技术实现有很多，例如Sqoop、DataX等

数据规范化处理

在将数据加载到数据仓库之前(其实规范化本身就是在数据仓库里操作的)，通常需要进行数据清洗和转换操作。这包括数据质量检查、数据规范化、缺失值处理、数据类型转换等。清洗和转换的目的是确保数据的一致性、准确性和完整性，使其适合分析和决策制定。

包括字段的命名、单位、数据格式等需要统一，只有这样集成才是有意义的

例如性别的表示到底是使用0|1 数字还是 m|f 字母都是不太重要的，重要的是性别这个属性它们在数仓里面的表示是需要统一的。

数据仓库的数据是随着时间的变化而变化的

数据仓库的数据是随着时间的变化而变化的的言外之意是反映历史变化

数据仓库中的数据不可更新是针对应用来说的，也就是说，数据仓库的用户进行分析处理理是不进行数据更更新操作的。但并不是说，在从数据集成输⼊入数据仓库开始到最后被删除的整个生命周期中，所有的数据仓库数据都是永远不变的。

数据仓库的数据是随着时间变化而变化的，这是数据仓库的特征之一。这一特征主要有以下三个表现:

数据仓库随着时间变化不断增加新的数据内容。数据仓库系统必须不断捕捉OLTP数据库中变化的数据，追加到数据仓库当中去，也就是要不断的⽣成OLTP数据库的快照，经统一集成增加到数据仓库中去;但对于确实不在变化的数据库快照，如果捕捉到新的变化数据，则只生成一个新的数据库快照增加进去，⽽不会对原有的数据库快照进⾏行行修改。
数据库随着时间变化不断删去旧的数据内容。数据仓库内的数据也有存储期限，一旦过了了这一期限，过期数据就要被删除。只是数据库内的数据时限要远远的⻓于操作型环境中的数据时限。在操作型环境中⼀般只保存有60到90天的数据，而在数据仓库中则要需要保存较⻓时限的数据(例例如:5~10 年年)，以适应DSS进行趋势分析的要求。
数据仓库中包含有⼤量的综合数据，这些综合数据中很多跟时间有关，如数据经常按照时间段进行综合，或隔⼀定的时间片进⾏抽样等等。这些数据要随着时间的变化不断地进⾏重新综合。因此数据仓库的数据特征都包含时间项，以标明数据的历史时期。

其实说白了就是一些列的操作型数据库的快照

数据仓库的数据是不可修改的(相对稳定的)

数据仓库的数据主要提供企业决策分析之⽤，所涉及的数据操作主要是数据查询，⼀般情况下并不进行修改操作。

数据仓库的数据反映的是⼀一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据，而不是联机处理理的数据。

数据库中进行联机处理理的书库进过集成输入到数据仓库中，一旦数据仓库存放的数据已经超过数据仓库的数据存储期限，这些数据将从当前的数据仓库中删去。

因为数据仓库只进行数据查询操作，所以数据仓库当中的系统要⽐数据库中的系统要简单的多。数据库管理系统中许多技术难点，如完整性保护、并发控制等等，在数据仓库的管理理中几乎可以省去。

但是由于数据仓库的查询数据量往很大，所以就对数据查询提出了更高的要求，要求采用各种复杂的索引技术;同时数据仓库⾯面向的是商业企业的⾼层管理层，他们会对数据查询的界⾯面友好性和数据表示提出更高的要求;

用于支持决策的

这其实说明了为什么要建设数据仓库，前面是数据仓库的特点，这里是建设数据仓库的目的

大数据仓库的特点

基于大数据的高扩展

高扩展主要依赖我们底层的大数据组件，例如我们的Hadoop,从而达到我们的存储能力和计算能力的扩展

基于大数据的高安全

数据安全不丢失，这主要是依赖着大数据的存储技术，例如我们的HDFS

基于大数据的高效率

spark hive 等大数据框架提供了更加高效的数据分析能力

离线+实时的架构提高数据的实时性

随着实时计算技术的发展，我们在数据仓库的架构的基础上，引入了事实计算，从而弥补了传统架构在实时计算方面的性能不足，下面就是我们的传统数仓的架构

对比数据库

其实这两个除了都是用sql 查询之外，基本上就没有其他相似点

数据库是面向事务的(OLTP)，而数据仓库是面向主题的(OLAP)
数据库存在在线交易数据的，数据仓库存储历史数据的
数据库设计应该避免冗余，而数据仓库设计是有意引入冗余的
数据库设计是为捕获数据而设计的，数据仓库是为分析数据而射进的
用户和系统的面向性：OLTP是面向客户的，用于办事员、客户和信息技术专业人员的事务和查询处理。OLAP是面向市场的，用于知识工人（包括经理、主管和分析人员）的数据分析。
数据内容：OLTP 系统管理的是当前数据，通常这种数据太琐碎，很难用于决策。OLAP 系统管理的则是大量的历史数据，提供汇总和聚集机制，并在不同的粒度层上存储和管理信息，这些特点使得数据更容易用于有根据的决策。
访问模式：OLTP系统主要由短的原子事务组成，这种系统需要并发控制和恢复机制。然而，对 OLAP 系统的访问大部分是只读操作（由于大部分数据仓库存放历史数据，而不是最新数据），尽管许多访问可能是复杂的查询。
文件系统：hive 分布式文件系统数据库本地文件系统
数据规模上 hive 没有瓶颈

数据库数仓分离开的原因

分离的主要原因是有助于提高两个系统的性能。操作数据库是为已知的任务和负载设计的，如使用的主键索引，检索特定的记录，优化“定制的”查询。而数据仓库的查询通常是复杂的，涉及大量数据汇总级的计算，可能需要特殊的基于多维视图的数据组织、存取方法和实现方法。在操作数据库上处理 OLAP 查询，可能会大大降低操作任务的性能。
操作数据库支持多事务的并发处理，需要并发控制和恢复机制（例如，加锁和记日志），以确保一致性和事务的鲁棒性。通常，OLAP 查询只需要对汇总和聚集数据记录进行只读访问。如果将并发控制和恢复机制用于这种 OLAP 操作，就会危害并行事务的运行，从而大大降低 OLTP 系统的吞吐量。
数据仓库与操作数据库分离是由于这两种系统中数据的结构、内容和用法都不相同。决策支持需要历史数据，而操作数据库一般不维护历史数据。在这种情况下，操作数据库中的数据尽管很丰富，但对于决策是远非完整的。决策支持需要整合来自异构源的数据（例如，聚集和汇总），产生高质量的、纯净的和集成的数据。操作数据库只维护详细的原始数据（如事务），这些数据在进行分析之前需要整理。由于两种系统提供大不相同的功能，需要不同类型的数据，因此需要维护分离的数据库。

OLAP 与 OLTP

我们经常提到的OLAP 是 On-Line Analytical Processing（联机分析处理）的缩写。广义的 OLAP 泛指数据查询分析，像报表、即席查询、多维分析都属于 OLAP 的范畴。OLTP 和 OLAP 最大区别在于前者会产生数据，而后者只利用前者生产的数据进行数据分析为企业经营提供决策支持。

OLAP是更广泛的商业智能类别的一部分，它还包括关系数据库、报告编写和数据挖掘。OLAP的典型应用包括用于销售的业务报告、市场营销、管理报告、业务流程管理(BPM)、预算和预测、财务报告等领域。

业务类系统主要供基层人员使用，进行一线业务操作，通常被称为OLTP（On-Line Transaction Processing，联机事务处理）。
数据分析的目标则是探索并挖掘数据价值，作为企业高层进行决策的参考，通常被称为OLAP（On-Line Analytical Processing，联机分析处理）。
从功能角度来看，OLTP负责基本业务的正常运转，而业务数据积累时所产生的价值信息则被OLAP不断呈现，企业高层通过参考这些信息会不断调整经营方针，也会促进基础业务的不断优化，这是OLTP与OLAP最根本的区别（其他OLTP与OLAP的差别各位可以自行网上搜索，这里不再啰嗦）

OLAP

OLAP的工具使用户能够从多个角度交互地分析多维数据。OLAP由三种基本的分析操作组成:整合(roll-up)、钻取（drill-down）和切片（slicing 和dicing）。整合涉及到可以在一个或多个维度中累积和计算的数据的聚合。相比之下，钻取是一种允许用户浏览细节的技术。切片是一种分析功能，用户可以从中提取OLAP多维数据集的特定数据集，并从不同的视角查看切片。

多维分析 – MDA

多维分析(Multidimensional Analysis)是是一种数据分析过程，将数据分为两类：数据维和度量。在分析型系统中，用户可以通过拖拽维度（Dimension）来汇总度量（Measure）以方便使用者可以从不同角度观察数据。如果从报表的角度来看，多维分析类似于自助报表，业务人员基于一个事先准备的结果集进行动态报表查询，可以进行切片、钻取、旋转（行列变换）等操作。狭义上，BI、OLAP 和多维分析经常被视为同一类，其实是特指实现了多维分析的工具和产品。

数据立方体 – cube

在数据仓库兴起之时，Jim Gray等人将数据立方（DataCube）的概念应用于描述时变（time-varying）的业务数据。这种方法在业务表现以及实现的性能的强大优势，迅速成为了数据仓库技术中最重要的一环。

cube 也叫数据立方体，名字源自数据可以有任意数量的维度。但cube并不是严格数学意义上的 “立方体”，可以有超过三个以上的维度。我们可以将这个概念理解成是一个数据集，在多维分析中使用者需要基于一个结果集进行拖拽分析，这个结果集就是 cube 了，多维分析针对 cube 进行查询、切片、钻取等操作。

在数据仓库系统中，cube通常指的是一个多维的数据阵列，也可以理解为一个更高层次的业务模型抽象。传统的数据分析大多是基于关系型数据库的。关系型数据库使用SQL语句进行操作，但SQL在多维度操作和分析方面的能力相对较弱。所以cube有自己独特的查询语言MDX，它的表达式比较丰富，并具有强大的多维处理能力，所以以cube为核心的分析系统成为了数据分析主要的选项。通过采用cube，OLAP分析系统可以轻松地得以构建。

维度

维(Dimension)：人们观察事物的视角，如时间、地理位置、年龄和性别等，是单一角度概念。
维的层次(Lever of Dimension)：表示维度概念基础上进一步的细分，如时间可以细分为年、季度、月三个层次。
维成员(Member of Dimension)：表示维不可再细分的原子取值，如时间维的成员可以是2019年1月10日。
度量(Measure)：表示在这个维成员上的取值。

操作

下探(Drill down)

维度是有层次的，下探表示进入维度的下一层，将汇总数据拆分到下一层所在细节数据信息，如下图从第二季度下探到看4、5、6月的明细数据。

上钻(Drill up)

下探的反向操作，回到更高汇聚层的汇总数据。

切片(Slice)

切片可以理解成把立体按某一个维度进行切分，就可以看两维数据，如图中按电子产品切分，看到的是时间和地理位置关系的二维数据。

切块(Dice)

相对于切片是按一个点切分，切块就是按一个范围(区间)来做切分。

旋转(Pivot)

维的行列位置交换，换一个视角分析数据。

OLAP分类

OLAP按存储器的数据存储格式分为ROLAP、MOLAP和HOLAP。

MOLAP（Multi-dimensional OLAP）

以多维数组（Multi-dimensional Array）存储模型的OLAP，是OLAP发源最初的形态，某些方面也等同于OLAP。
它的特点是数据需要预计算（pre-computaion），然后把预计算之后的结果（cube）存在多维数组里。

优点

cube包含所有维度的聚合结果，所以查询速度非常快。
计算结果数据占用的磁盘空间相对关系型数据库更小

缺点

空间和时间开销大。update cube的时间跟计算维度（degree）相关，随着维度增加计算时间大幅增加，此外预计算还会造成数据库占用急剧膨胀。
查询灵活度比较低。需要提前设计维度模型，查询分析的内容仅限于这些指定维度，增加维度需要重新计算。

ROLAP（Relational OLAP）

基于关系模型存放数据，一般要求事实表（fact table）和维度表（dimensition table）按一定关系设计，它不需要预计算，使用标准SQL就可以根据需要即时查询不同维度数据。

优点

扩展性强，适用于维度数量多的模型，MOLAP对于维度多的模型预计算慢，空间占用大
更适合处理non-aggregate事实，例如文本描述
基于row数据更容易做权限管理

缺点

因为是即时计算，查询响应时间一般比预计算的MOLAP长。

HOLAP

业界还没有一致的定义，它是MOLAP和ROLAP类型的混合运用，细节的数据以ROLAP的形式存放，更加方便灵活，而高度聚合的数据以MOLAP的形式展现，更适合于高效的分析处理。公司使用HOLAP的目的是根据不同场景来利用不同OLAP的特性。

产品

MOLAP 产品

有 Cognos Powerplay, Oracle Database OLAP Option, MicroStrategy, Microsoft Analysis Services, Essbase, TM1, Jedox ,icCube和kylin等。

ROLAP产品

有Vertica、Amazon Redshift、Google Dremel、Hulu Nesto、Presto、Druid、Impala、Greenplum、HAWQ和Doris等。

当前OLAP的发展状态

在国内，不论传统公司还是互联网公司，都开始利用OLAP技术分析挖掘大数据的价值，国内除BAT等大厂会自研OLAP产品外，其他中小互联网公司普遍拥抱开源，会使用Kylin、Presto、impala、Druid和Greenplum等开源技术来实现OLAP分析查询业务。
在调研了市面上主流的开源OLAP引擎后发现，目前还没有一个系统能够满足各种场景的查询需求。其本质原因是，没有一个系统能同时在数据量、性能、和灵活性三个方面做到完美，每个系统在设计时都需要在这三者间做出取舍。

灵活性

预计算系统（Druid/Kylin等）则在入库时对数据进行预聚合，进一步牺牲灵活性换取性能，以实现对超大数据集的秒级响应。
缺点：不太灵活
MPP和搜索引擎系统无法满足超大数据集下的性能要求，因此很自然地会考虑预计算系统。而Druid主要面向的是实时Timeseries数据，我们虽然也有类似的场景，但主流的分析还是面向数仓中按天生产的结构化表，因此Kylin的MOLAP Cube方案是最适合作为大数据量时候的引擎。