数据仓库架构

伊泽瑞尔

发布于 2022-06-01 08:30:25

2K0

发布于 2022-06-01 08:30:25

文章被收录于专栏：大数据与知识图谱

一、数仓

二、维度建模

星型模型

雪花模型

比较

三、Kimball的DW/BI架构

四、独立数据集市架构

五、辐射状企业信息工厂Inmon架构（CIF）

六、混合辐射状架构与Kimball架构

一、数仓

数据仓库的核心是展现层和提供优质的服务。ETL 及其规范、分层等所做的一切都是为了一个更清晰易用的展现层。

数仓架构的原则：

1.底层业务的数据驱动为导向同时结合业务需求驱动 2.便于数据分析屏蔽底层复杂业务简单、完整、集成的将数据暴露给分析层 3.底层业务变动与上层需求变动对模型冲击最小化业务系统变化影响削弱在基础数据层（资金订单改造）结合自上而下的建设方法削弱需求变动对模型的影响数据水平层次清晰化 3.高内聚松耦合主题之内或各个完整意义的系统内数据的高内聚主题之间或各个完整意义的系统间数据的松耦合 4.构建仓库基础数据层使得底层业务数据整合工作与上层应用开发工作相隔离，为仓库大规模开发奠定基础仓库层次更加清晰，对外暴露数据更加统一

数仓模型不只是考虑如何设计和实现功能，设计原则应该从访问性能、数据成本、使用成本、数据质量、扩展性来考虑。

当前主流建模方法为：ER模型、维度模型。

ER模型：常用于OLTP数据库建模，应用到构建数仓时更偏重数据整合，站在企业整体考虑，将各个系统的数据按相似性一致性、合并处理，为数据分析、决策服务，但并不便于直接用来支持分析。缺陷：需要全面梳理企业所有的业务和数据流，周期长，人员要求高。维度建模：面向分析场景而生，针对分析场景构建数仓模型；重点关注快速、灵活的解决分析需求，同时能够提供大规模数据的快速响应性能。针对性强，主要应用于数据仓库构建和OLAP引擎低层数据模型。优点：不需要完整的梳理企业业务流程和数据，实施周期根据主题边界而定，容易快速实现demo，而且相对来说便于理解、提高查询性能、对称并易扩展。

大数据时代，数据来源更加广泛，针对的业务域也更加宽广，所以维度建模相对来说更加灵活并适用。

二、维度建模

用于度量的事实表：

事实表一般会有两个或者多个外健与维度表的主键进行关联。事实表的主键一般是组合健，表达多对多的关系。物理世界的每一个度量事件与对应的事实表行具有一对一的关系，这一思想是维度建模的基本原则。

用于描述环境的维度表：

单一主键。维度表的属性是所有查询约束和报表标示的来源。维度提供数据的入口点，提供所有DW/BI分析的最终标识和分组。

所以维度模型表示每个业务过程包含事实表，事实表存储事件的数值化度量，围绕事实表的是多个维度表，维度表包含事件发生时实际存在的文本环境。

一个数字量到底是事实还是维度属性，对设计者来说是一个两难的问题，很难做出决策。连续值数字基本可以认为属于事实，来自于一个不太大的列表的离散数字基本可认为是维度属性。

星型模型

当所有维表都直接连接到事实表上时，整个图解就像星星一样，故将该模型称为星型模型。星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。

从上图可看出，维度模型（星型模型）比较简单，而且适于变化，各个维度的地位相同。可根据业务情况进行新增或者修改（只要维度的单一值已经存在事实表中）。

雪花模型

当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花型对维度正规化是一种比较复杂的过程，相应的数据库结构设计、数据的 ETL、以及后期的维护都要复杂一些。

比较

星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。

雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。

在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。

三、Kimball的DW/BI架构

将DW/BI环境划分为4个不同的部分：操作型源系统、ETL系统、数据展现和商业智能应用。

源事务：业务库或者日志等各个方面的数据源，一般不维护历史信息。

ETL：目的是构建和加载数据到展现区的目标维度模型中，划分维度和事实。

模型：围绕业务过程度量事件进行构建，为满足用户无法预估的需求，必须包含详细的原子数据。

总线架构

多维体系结构(总线架构) 数据仓库领域里，有一种构建数据仓库的架构，叫Multidimensional Architecture（MD），中文一般翻译为“多维体系结构”，也称为“总线架构”（Bus Architecture）。多维体系结构的创始人是数据仓库领域中最有实践经验的Kimball博士。多维体系结构主要包括后台（Back Room）和前台（Front Room）两部分。后台也称为数据准备区（Staging Area），是MD架构的最为核心的部件。在后台，是一致性维度的产生、保存和分发的场所。同时，代理键也在后台产生。前台是MD架构对外的接口，包括两种主要的数据集市，一种是原子数据集市，另一种是聚集数据集市。原子数据集市保存着最低粒度的细节数据，数据以星型结构来进行数据存储。聚集数据集市的粒度通常比原子数据集市要高，和原子数据集市一样，聚集数据集市也是以星型结构来进行数据存储。前台还包括像查询管理、活动监控等为了提供数据仓库的性能和质量的服务。在多维体系结构中，所有的这些基于星型机构来建立的数据集市可以在物理上存在于一个数据库实例中，也可以分散在不同的机器上，而所有这些数据集市的集合组成的分布式的数据仓库。

一致性维度

在多维体系结构中，没有物理上的数据仓库，由物理上的数据集市组合成逻辑上的数据仓库。而且数据集市的建立是可以逐步完成的，最终组合在一起，成为一个数据仓库。如果分步建立数据集市的过程出现了问题，数据集市就会变成孤立的集市，不能组合成数据仓库，而一致性维度的提出正式为了解决这个问题。一致性维度的范围是总线架构中的维度，即可能会在多个数据集市中都存在的维度，这个范围的选取需要架构师来决定。一致性维度的内容和普通维度并没有本质上区别，都是经过数据清洗和整合后的结果。一致性维度建立的地点是多维体系结构的后台（Back Room），即数据准备区。在多维体系结构的数据仓库项目组内需要有专门的维度设计师，他的职责就是建立维度和维护维度的一致性。在后台建立好的维度同步复制到各个数据集市。这样所有数据集市的这部分维度都是完全相同的。建立新的数据集市时，需要在后台进行一致性维度处理，根据情况来决定是否新增和修改一致性维度，然后同步复制到各个数据集市。这是不同数据集市维度保持一致的要点。在同一个集市内，一致性维度的意思是两个维度如果有关系，要么就是完全一样的，要么就是一个维度在数学意义上是另一个维度的子集。例如，如果建立月维度话，月维度的各种描述必须与日期维度中的完全一致，最常用的做法就是在日期维度上建立视图生成月维度。这样月维度就可以是日期维度的子集，在后续钻取等操作时可以保持一致。如果维度表中的数据量较大，出于效率的考虑，应该建立物化视图或者实际的物理表。这样，维度保持一致后，事实就可以保存在各个数据集市中。虽然在物理上是独立的，但在逻辑上由一致性维度使所有的数据集市是联系在一起，随时可以进行交叉探察等操作，也就组成了数据仓库。

一致性事实

在建立多个数据集市时，完成一致性维度的工作就已经完成了一致性的80%－90%的工作量。余下的工作就是建立一致性事实。一致性事实和一致性维度有些不同，一致性维度是由专人维护在后台（Back Room），发生修改时同步复制到每个数据集市，而事实表一般不会在多个数据集市间复制。需要查询多个数据集市中的事实时，一般通过交叉探查（drill across）来实现。为了能在多个数据集市间进行交叉探查，一致性事实主要需要保证两点。第一个是KPI的定义及计算方法要一致，第二个是事实的单位要一致性。如果业务要求或事实上就不能保持一致的话，建议不同单位的事实分开建立字段保存。

这样，一致性维度将多个数据集市结合在一起，一致性事实保证不同数据集市间的事实数据可以交叉探查，一个分布式的数据仓库就建成了。