往期推荐

大数据HBase图文简介-CSDN博客

数仓分层ODS、DWD、DWM、DWS、DIM、DM、ADS-CSDN博客

数仓常见名词解析和名词之间的关系-CSDN博客

目录

0. 前言

0.1 浅谈维度建模

0.2 数据分析模型

1. 何为数据仓库

1.1 为什么不直接用业务平台的数据而要建设数仓？

1.2 数据仓库特征

1.3 数据仓库和数据库区别

1.4 以银行业务为例 

2. 数仓架构

2.1 离线数仓架构

2.1.1 数据集市架构

2.1.1.2 独立数据集市

2.1.1.2 从属数据集市

2.1.2 Inmon企业信息工厂架构

2.1.3 Kimball数据仓库架构

2.1.4 混合型数据仓库架构

2.2 实时数仓架构 

2.2.1 Lambda架构

2.2.1.1 传统的Lambda实时开发

2.2.1.2 升级的Lambda实时开发

2.2.2 Kappa架构

Kappa和Lambda对比

2.2.3 数据湖出现原因：批流一体

2.2.3 湖仓一体—数据湖

---

0. 前言

1. 1991年，数据仓库之父 比尔·恩门 著书《Building the DataWarehouse》，要求构建数据仓库时，遵循范式建模，即从关系型数据库中提取的范式数据，仍按范式存储到数据仓库中，这样就导致数仓中有很多小表，查询的时候必然会有很多表的关联，极大地影响查询效率和性能。
2. 1994年，拉尔夫·金博尔 著书《The DataWarehouse Toolkit》，提出维度建模和数据集市的概念，维度建模是反范式建模，自下而上，然而这种方式仍有缺点：那就是每个业务平台的数据有各自的数据集市，集市之间数据隔离，存在数据不一致、重复的情况。
3. 1998-2001年，比尔·恩门派和金博尔派合并，比尔·恩门提出CIF架构：数仓分层，不同层采用不同的建模方式，同时解决了数据不一致和查询效率低的问题。

0.1 浅谈维度建模

维度建模主要面向分析场景，分为维度表和事实表，建模过程和关系型数据库的建表很像，下图中，商家ID、产品ID、时间ID就是不同的维度列，而订单额就是度量值，维度+度量值=事实表。每个维度列也有自己的维度表。

那么基于以上，有如下两种数据分析模型。

0.2 数据分析模型

对比

• 查询效率：雪花模型有很多小表，看起来更为范式化，但这导致查询时需要关联很多表，查询效率比星型模型低。
• 数据冗余：星型模型的表通常是宽表，伪范式，即表有很多字段，这导致星型模型存在较多的数据冗余。

1. 何为数据仓库

• 数据仓库（Data Warehouse）即是存储历史数据的仓库，简写为DW或DWH。
• 数据仓库的目的是构建面向分析的集成化数据环境（OLAP），为企业提供决策支持。
• 仓库的数据来自各个业务平台，业务平台中的数据形式多种多样，可能是 MySQL等关系数据库里的结构化数据，可能是Word、Excel 文档中的非结构化数据，还可能是 HTML、XML 等自描述的半结构化数据。这些业务数据经过一系列的ETL（抽取、转换、加载），最终以一种统一的格式装载进数据仓库。
• 数据仓库本身并不“生产”任何数据，也不需要“消费”任何的数据，数据来源于外部，并且开放给外部应用，这也是为什么叫“仓库”而不叫“工厂”的原因。

1.1 为什么不直接用业务平台的数据而要建设数仓？

实际在数仓出现之前，确实是这么做的，但是有很多数据分析的先驱者当时已经发现，简单的直接访问方式很难良好工作，原因如下：

• 由于安全或其他因素不能直接访问某些业务数据。

• 业务平台存储的是当前数据，存在于RDBMS，并且数据版本变更很频繁，而大数据需要的是历史数据，读多改少。

• 各个平台数据存储是隔离的，且数据格式不统一，难以建立、维护、汇总数据。

• 业务系统的表结构（OLTP）为事务处理性能而优化，有时并不适合查询与分析（OLAP）。

• 有时用户要看到的某些数据字段在数据库中并不存在，是后期聚合处理生成的。

• 业务平台是跑业务的，本身就占用了一定数据库读写资源，大数据分析再从每个表中频繁读取数据，影响业务平台的性能，不够专业。

1.2 数据仓库特征

• 面向主题：
  传统数据库中，最大的特点是面向应用进行数据的组织，各个业务系统可能是相互分离的。而数据仓库则是面向主题的。主题是一个抽象的概念，是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。
• 集成性：
  通过对分散、独立、异构的数据库数据进行ETL并汇总得到了数据仓库的数据，这样保证了数据仓库内的数据的一致性。 数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一与综合，这一步是数据仓库建设中最关键、最复杂的一步，需要完成的工作有：
  • 要统一源数据中所有矛盾之处，如字段的同名异义、异名同义、单位不统一、字长不一致等等。
  • 进行数据综合和计算。数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。
• 包含历史：数仓反应的是某段时间内的历史数据，这也是数仓和数据库的区别之一。
• 不可修改：数据进入数据仓库以后，一般情况下被较长时间保留。数据仓库中一般有大量的查询操作，但修改删除操作很少，只需定时加载更新即可。
• 时效性：数仓存储的是历史数据，按照时间顺序追加，有时间属性。数仓用户通过分析企业过去一段时间业务的经营状况，挖掘潜在价值。但是分析的结果只能反映过去某段时间的情况，随着业务变化时间改变，数仓中的数据就会失去价值，需要载入新数据。
• 面向全企业
• 数据快照式的数据获取
• 面向决策支持
• 明细的数据存储

1.3 数据仓库和数据库区别

数据库与数据仓库的区别实际讲的是 OLTP 与 OLAP 的区别

• 操作型处理，叫联机事务处理 OLTP，也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理，像MYSQL，Oracle等关系型数据库一般属于OLTP。
• 分析型处理，叫联机分析处理 OLAP，一般针对某些主题的历史数据进行分析，支持管理决策。

首先要明白，数据仓库的出现，并不是要取代数据库。数据库是面向事务的设计，数据仓库是面向主题设计的。数据库一般存储业务数据，数据仓库存储的一般是历史数据。

• 数据库设计是尽量避免冗余，一般针对某一业务应用进行设计，比如一张简单的User表，记录用户名、 密码等简单数据即可，符合业务应用，但是不符合分析。
• 数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计。 数据库是为捕获数据而设计，数据仓库是为分析数据而设计。

1.4 以银行业务为例 

• 数据库是事务系统的数据平台，客户在银行做的每笔交易都会写入数据库，被记录下来，可以简单地理解为用数据库记账。
• 数据仓库是分析系统的数据平台，它从事务系统获取数据，并做汇总、加工，为决策者提供决策的依据。比如，某银行某分行一个月发生多少交易，该分行当前存款余额是多少。如果存款又多，消费交易又多，那么该地区就有必要设立 ATM了。 显然，银行的交易量是巨大的，通常以百万甚至千万次来计算。
• 事务系统是实时的，这就要求时效性，客户存一笔钱需要几十秒是无法忍受的，这就要求数据库只能存储很短一段时间的数据。 而分析系统是事后的，它要提供关注时间段内所有的有效数据。这些数据是海量的，汇总计算起来也要慢一些，但是，只要能够提供有效的分析数据就达到目的了。
• 数据仓库，是在数据库已经大量存在的情况下，为了进一步挖掘数据资源、为了决策需要而产生的，它决不是所谓的“大型数据库”。

2. 数仓架构

数仓架构大致分为离线数仓架构和实时数仓架构，数仓架构可以简单理解为构成数仓的各层关系，如ODS、DWM、DWD、DWS，具体分层这里不赘述。 

2.1 离线数仓架构

任何事物都是随着时间的演进变得越来越完善，当然也是越来越复杂，数仓也不例外。

离线数仓架构包括数据集市架构、Inmon企业信息工厂架构、Kimball数据仓库架构、混合型数据仓库架构，接下来就详细说说这几种架构。

2.1.1 数据集市架构

数据集市架构重点在于集市二字，数据集市是按主题域组织的数据集合，用于支持部门级的决策。有两种类型的数据集市：独立数据集市 和 从属数据集市。

2.1.1.2 独立数据集市

独立数据集市集中于部门所关心的单一主题域，数据以部门为基础，例如制造部门、人力资源部门和其他部门都各自有他们自己的数据集市。

• 优点：因为一个部门的业务相对于整个企业要简单，数据量也小得多，所以部门的独立数据集市周期短、见效快。
• 缺点：独立数据集市各自为政。从业务角度看，当部门的分析需求扩展或者跨部门跨主题域分析时，独立数据市场会力不从心。 当数据存在歧义，比如同一个产品在A部门和B部门的定义不同，将无法在部门间进行信息比较。 每个部门使用不同的技术，建立不同的ETL的过程，处理不同的事务系统，而在多个独立的数据集市之间还会存在数据的交叉与重叠，甚至会有数据不一致的情况！

2.1.1.2 从属数据集市

从属数据集市的数据来源于数据仓库，即从属于数据仓库。

优点：

• 性能：当数据仓库的查询性能出现问题，可以考虑建立几个从属数据集市，将查询从数据仓库移出到数据集市。
• 安全：每个部门可以完全控制他们自己的数据。
• 数据一致：因为每个数据集市的数据来源都是同一个数据仓库，有效消除了数据不一致的情况。

2.1.2 Inmon企业信息工厂架构

• Inmon架构是范式建模
• 企业级数据仓库是企业级别的，正如Inmon数据仓库所定义的，企业级数据仓库是一个细节数据的集成资源库。其中的数据以最低粒度级别被捕获，存储在满足三范式设计的关系数据库中。
• 部门级数据集市是企业中部门级别的，是面向主题数据的部门级视图，数据从企业级数据仓库获取。数据在进入部门数据集市时可能进行聚合。数据集市使用多维模型设计，用于数据分析。重要的一点是，所有的报表工具、BI 工具或其他数据分析应用都应该从数据集市查询数据，而不是直接查询企业级数据仓库。

2.1.3 Kimball数据仓库架构

• 对比上一张图可以看到，Kimball与Inmon两种架构的主要区别在于数据仓库的设计和建立。 Kimball的数据仓库包含高粒度的企业数据，使用多维模型设计，是维度建模，这也意味着数据仓库由星型模式的维度表和事实表构成。分析系统或报表工具可以直接访问多维数据仓库里的数据。
• 在此架构中的数据集市也与Inmon中的不同。这里的数据集市是一个逻辑概念，只是多维数据仓库中的主题域划分，并没有自己的物理存储，也可以说是虚拟的数据集市。

2.1.4 混合型数据仓库架构

• 所谓的混合型结构，指的是在一个数据仓库环境中，联合使用Inmon和Kimball两种架构。
• 从架构图可以看到，这种架构将Inmon方法中的数据集市替换成了一个多维数据仓库，而数据集市则是多维数据仓库上的逻辑视图。
• 使用这种架构的好处是：既可以利用规范化设计消除数据冗余，保证数据的粒度足够细；又可以利用多维结构更灵活地在企业级实现报表和分析。

2.2 实时数仓架构 

在某些场景中，数据的价值随着时间的推移而逐渐减少。所以在传统大数据离线数仓的基础上，逐渐对 数据的实时性提出了更高的要求。

2.2.1 Lambda架构

2.2.1.1 传统的Lambda实时开发

2.2.1.2 升级的Lambda实时开发

• 问题：为什么Lambda架构要分成两条线计算？
• 假如整个系统只有一个批处理层，会导致用户必须等待很久才能获取计算结果，一般有时间延迟。电商数据分析部门只能查看前一天的统计分析结果，无法获取当前的结果，这对于实时决策来说有 一个巨大的时间鸿沟，很可能导致管理者错过最佳决策时机。
• Lambda架构属于较早的一种架构方式，早期的流处理不如现在这样成熟，在准确性、扩展性和容错性 上，流处理层无法直接取代批处理层，只能给用户提供一个近似结果，还不能为用户提供一个一致准确 的结果。因此Lambda架构中，出现了批处理和流处理并存的现象。 

不管是传统的还是升级后的，Lambda架构严格来说并不是纯正的实时数仓，而是离线+实时

这就导致Lambda有如下缺点：

• 同样的需求要开发两套一样的代码
• 集群资源使用增多
• 离线结果和实时结果可能不一致，当然以离线为主
• 离线批量计算T+1可能算不完
• 服务器存储压力大

2.2.2 Kappa架构

Kappa架构是纯正的实时架构，可以看到在实时数仓中，使用kafka来运输数据，但是kafka是消息队列，有如下缺点：

• kafka主要用来消息缓存，不能支撑海量数据存储，数据存储有时间限制
• kafka不支持OLAP，即无法用SQL语句进行简单的数据校验
• 无法复用数据血缘管理体系（数据治理），因为kafka没有schema那种字段
• kafka中的数据是append追加，不支持数据的更新、插队

Kappa和Lambda对比

2.2.3 数据湖出现原因：批流一体

• 批流一体既可以处理批数据，又可以处理流数据，从架构角度来看就是Lambda架构；
• 从计算框架角度来看，就是flink、spark框架，既支持批处理，又支持流处理；
• 从SQL角度来看，就是数仓各层统一支持SQL，这就弥补了kappa中kafka不支持SQL的缺点；
• 从存储层面来看，能做到海量数据的存储，而不是像kappa一样存储在kafka缓存中；

那么基于以上痛点，就有了数据湖 

2.2.3 湖仓一体—数据湖

我们看到流批结合的方式与上面几种架构的存储方式发生了变化，由 Kafka 换成 了 Iceberg，IceBerg就是数据湖技术的一种，介于上层计算引擎和底层存储格式之间的一个中间层，我们可以把它定义成一种“数据组织格式”，底层存储还是 HDFS。除此之外还有Hudi（发展最完善）这里不具体阐述。

数据湖支持SQL查询，解决了如下问题：

• 存储统一
• 解决了kafka存储量小，数据有时间限制的问题
• 任意分层都可以OLAP
• 复用同一套相同的血缘关系
• 支持数据实时更新，数据可以update/insert