往期推荐
目录
0. 前言
- 1991年，数据仓库之父 比尔·恩门 著书《Building the DataWarehouse》，要求构建数据仓库时，遵循范式建模，即从关系型数据库中提取的范式数据，仍按范式存储到数据仓库中，这样就导致数仓中有很多小表，查询的时候必然会有很多表的关联，极大地影响查询效率和性能。
- 1994年，拉尔夫·金博尔 著书《The DataWarehouse Toolkit》，提出维度建模和数据集市的概念，维度建模是反范式建模，自下而上，然而这种方式仍有缺点：那就是每个业务平台的数据有各自的数据集市，集市之间数据隔离，存在数据不一致、重复的情况。
- 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 湖仓一体—数据湖
标签：数仓,Kappa,数据仓库,数据库,离线,集市,架构,数据 From： https://blog.csdn.net/qq_73181349/article/details/140787541我们看到流批结合的方式与上面几种架构的存储方式发生了变化，由 Kafka 换成 了 Iceberg，IceBerg就是数据湖技术的一种，介于上层计算引擎和底层存储格式之间的一个中间层，我们可以把它定义成一种“数据组织格式”，底层存储还是 HDFS。除此之外还有Hudi（发展最完善）这里不具体阐述。
数据湖支持SQL查询，解决了如下问题：
- 存储统一
- 解决了kafka存储量小，数据有时间限制的问题
- 任意分层都可以OLAP
- 复用同一套相同的血缘关系
- 支持数据实时更新，数据可以update/insert