数仓架构设计方法论

数据仓库是面向主题、集成、非易失、反映历史的数据集合,用于决策支持。早期基于关系型数据库,现在常使用Hadoop生态。数仓通常有ODS、DW、DM三层,ETL过程涉及抽取、转换和加载。建模包括自上而下的范式建模和自下而上的维度建模,DM层适合维度建模以优化分析性能。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

        数据仓库,英文名称为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、运营、市场、销售、老板,几乎公司所有员工都需要使用数仓。因此,数仓设计必须遵循一套非常强的可读性命名规范。命名规范没有严格的标准,关键是统一,便于理解。以下是业内较为普遍的一种数仓表命名规范。

### 电子商务离线数据仓库架构设计最佳实践 #### 数据源集成 在构建电子商务离线数据仓库时,需考虑来自不同系统的多种异构数据源。这些数据可能来自于交易系统、客户关系管理系统(CRM)、网站点击流日志以及其他第三方服务。由于数据仓库旨在支持复杂查询并提供历史数据分析能力,因此应确保能够处理大规模的历史记录以及实时更新的数据[^1]。 #### ETL流程设计 ETL(Extract, Transform, Load)过程是离线数据仓库的核心组成部分之一。此过程中会抽取原始数据,对其进行清洗转换以适应目标模型结构的要求,并最终加载到数据仓库中供后续分析使用。针对电商业务特点,在设计ETL作业时可以特别关注如下方面: - **增量提取**:仅获取自上次同步以来发生变化的新纪录或修改过的旧记录; - **性能优化**:利用分区表技术加快写入速度;减少不必要的字段映射降低计算开销; - **错误容忍机制**:当遇到异常情况时不中断整个批处理任务而是跳过有问题的部分继续执行剩余部分的工作。 ```sql INSERT INTO sales_fact (order_id, product_id, quantity_sold) SELECT o.order_id, p.product_id, SUM(od.quantity) FROM orders o JOIN order_details od ON o.order_id = od.order_id JOIN products p ON od.product_id = p.product_id WHERE o.date >= 'last_sync_date' GROUP BY o.order_id, p.product_id; ``` #### 多维建模方法论应用 为了更好地服务于BI报表需求,建议采用星型/雪花型模式来进行维度建模。其中事实表用于保存度量数值如销售额、访问次数等具体指标;而围绕着它的各个维度则描述了与之关联的对象属性比如时间戳、地理位置、顾客群体特征等等。这样的组织方式不仅有助于简化复杂的联结操作还便于实现灵活多样的聚合统计功能。 #### 存储策略考量 鉴于电商行业产生的海量交易流水及行为轨迹信息往往具有较高的价值密度特性,所以在规划物理层面上的空间分配方案时应当充分权衡成本效益因素。一方面可以通过压缩算法减小磁盘占用空间;另一方面也可以借助分布式文件系统(HDFS)或者对象存储(S3)来承载冷热分离后的静态资源副本从而达到节省开支的目的[^2]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值