数仓架构设计方法论

数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数仓之父比尔·恩门(Bill Inmon)在1991年出版的《Building the Data Warehouse》一书中所提出的定义被广泛接受:数据仓库是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合,用于支持管理决策(Decision Making Support)。

早期的数仓多是基于关系型数据库(比如Oracel、SQLServer)搭建,数仓设计主要由从事系统开发的软件工程师完成。随着互联网大数据技术的发展,现在互联网公司的数仓主要基于Hadoop技术生态构建,并逐渐分化出专门从事数仓架构和数据开发的数仓工程师。受关系型数据库的设计影响,大部分软件工程师转向做数仓设计时,会不自觉地遵循三范式要求。但是数仓设计与关系型数据库设计有很大区别,不能完全遵循三范式设计。

数仓的三层架构:ODS-DW-DM

ETL是英文Extract-Transform-Load的缩写,它描述了数仓数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的整个生产过程。早期数仓直接从数据源产出分析报表,ETL过程比较简单,可以通过简单的脚本实现。但是,随着数据量的爆发增长和数据应用的拓展(除数据分析外,数据挖掘,人工智能等应用都强依赖数仓),数仓的ETL过程变得越来越复杂,需要工程化手段对数仓做架构设计。现在数仓总体架构会分三层:ODS源数据层,DW中间层和DM集市层,如下图所示。

ODS层存储最原始的数据,不对数据做任何加工处理。DW层存储ETL过程的中间表,简化ETL实现的复杂度,提高中间数据的复用度。为了便于工程实现和维护,DW层会进一步细分为DWD明细层和DWM汇总层。DM层为最终输出的满足业务场景需求的数据表。DIM层存放维度数据,维度数据是一些基础数据不需要经过复杂的ETL过程,相对比较稳定,可以被DW和DM层共用。各层的详细职责划分如下。

采用分层架构后,ETL过程被分解为各层之间的子过程,全局过程通过依赖关系级联调度完成。为避免循环依赖和更好的维护性,每层数据的ETL过程只能使用本层和下层数据,不能依赖上层数据。例如,DWD层数据不能依赖DWM或DM层数据。

ODS层数据表通过数据采集而来。DW和DM层数据表通过ETL过程输出。那么对于这两层的数据表,该如何进行建模设计呢?主要有两种方式:① 数据仓库之父Inmon提出的集线器的自上而下(EDW-DM)的范式建模;② 数仓大师Ralph Kimball提出的总线式的自下而上(DM-DW)的维度建模。DW层数据表主要采用范式建模,而DM层数据表偏向维度建模。

DW层数据表:范式建模

范式建模源自关系型数据库的范式理论。它从“实体-关系”的角度对客观世界建模,和关系型DB的建模方式相同。范式建模的完整过程是从数据源到数据仓库再到数据集市。它从数据源出发,探索性地去获取尽量符合预期的数据,并将数据按预期划分为不同的表需求。

范式建模有利于维护数据的一致性、稳定性和可扩展性,减少数据冗余,降低ETL过程的实现复杂度。但是由于它从实体-关系角度建模,不利于分析理解数据。所以主要用于DW层中间表建模。DW层数据表基于ODS层数据产出,ODS层中来自业务数据库的数据表也是范式建模,相同的建模方法更有利于ODS层到DW层的ETL处理。

DM层数据表:维度建模

维度建模从“维度-指标”的角度对客观世界建模,它面向分析,反范式设计要求,为了提高查询性能可以增加数据冗余。维度建模的过程和范式建模相反,它以最终需求目标为导向,数据表的设计遵循易于理解和快速反应的准则。

维度建模主要使用的模型有:星形模型雪花模型星座模型(如下图所示)。三种模型的建模方式相同,都是围绕事实表和维度表建模。区别在于是否在维度表,事实表之间引入关系范式约束。星形模型完全不做范式约束,有极大的数据冗余,但也因此获得最好的查询分析性能。雪花模型对维度表作了一些范式约束,减少了维度数据冗余。星座模型允许多个事实表共享维度表。大型数仓一般采用星座模型。

和范式建模相比,维度建模的数据表更易于理解和OLAP查询分析。但是由于大量的数据冗余,维度建模不利于的数据一致性和稳定性。此外维度建模紧贴分析需求,需求的灵活变更会导致ETL过程也会复杂多变,不利于维护。因此他不适用于DW层数据表的建模。而DM层数据表对最终用户开放使用,需要面向具体的数据分析需求。维度建模能有效地满足DM层的设计要求。由于增加了DW中间层,复杂的数据处理逻辑会沉淀到DW层的ETL过程,大大简化DM层的ETL过程。

 

强可读性的命名规范

DB设计的数据表主要为程序所用,只有参与开发和运维的工程师等少数人类需要理解。但是数仓面向的用户有大量不同角色的人类。BI、运营、市场、销售、老板,几乎公司所有员工都需要使用数仓。因此,数仓设计必须遵循一套非常强的可读性命名规范。命名规范没有严格的标准,关键是统一,便于理解。以下是业内较为普遍的一种数仓表命名规范。

发布了10 篇原创文章 · 获赞 11 · 访问量 2112

猜你喜欢

转载自blog.csdn.net/Tim_mwt/article/details/104302349
今日推荐