数仓理论学习笔记

213 阅读15分钟

什么是数仓以及为什么需要数仓建模

数据仓库(Data Warehouse)是一个用于集成、存储和管理组织内部和外部数据的中心化数据存储系统。它的主要目标是将来自各种不同来源和系统的数据整合到一个单一的位置,以便进行数据分析、报告和决策支持。数据仓库通常包括以下特点:

  1. 集成性:数据仓库整合了来自不同数据源、不同部门和不同格式的数据,使数据在一个统一的环境中可用。
  2. 主题性:数据仓库按照主题或业务领域组织数据,而不是按照源系统的结构组织。这样可以更容易地满足业务需求。
  3. 历史性:数据仓库保留了历史数据的副本,以支持时间序列分析和趋势分析。
  4. 高性能:数据仓库通常经过性能优化,以支持复杂的查询和大规模数据分析。

为什么需要数据仓库建模?

数据仓库建模是设计和构建数据仓库的关键步骤之一,它包括定义数据模型、数据结构和数据抽取、转换、加载(ETL)过程。以下是为什么需要数据仓库建模的一些原因:

  1. 支持业务分析:数据仓库建模使数据仓库能够更好地满足业务需求。通过按照主题域组织数据,将数据建模为维度和事实表,以及定义事实与维度之间的关系,分析师可以更轻松地执行复杂的查询和报告,从而支持业务分析。
  2. 数据质量和一致性:建模过程可以包括数据清洗和转换,以确保数据在仓库中的一致性和准确性。这有助于消除数据质量问题,提高数据可信度。
  3. 查询性能优化:通过合理的建模和索引设计,可以优化数据仓库的查询性能,使用户能够更快速地访问和分析数据。
  4. 数据安全和隐私:建模过程可以考虑数据安全和隐私需求,确保只有授权的用户可以访问敏感数据。
  5. 数据变化管理:数据仓库建模还可以考虑如何处理数据的变化,包括数据历史记录的管理和维护。

数据模型简述

关系数据库和数据仓库

数据库(Database)和数据仓库(Data Warehouse)是两个不同但相关的数据管理概念,它们在数据存储、用途和设计方面有一些重要区别。

  1. 用途和目标:

    • 数据库:数据库通常用于支持应用程序的日常操作,例如事务处理(Transaction Processing)或在线事务处理(OLTP)。数据库设计主要关注数据的实时读写、数据完整性和事务处理。数据库通常包含当前数据的快照,用于支持实时操作和在线查询。
    • 数据仓库:数据仓库旨在支持数据分析、决策支持和报告等用途。它集成了来自不同来源的数据,提供历史数据的存储,并支持复杂的查询和分析操作。数据仓库的设计侧重于数据的历史记录、主题建模和性能优化,以满足分析需求。
  2. 数据结构和组织:

    • 数据库:数据库通常包含多个表,这些表用于存储不同类型的数据,例如用户信息、订单信息、库存信息等。表之间的关系通常是规范化的,以减少数据冗余。
    • 数据仓库:数据仓库通常包含维度表和事实表,这是一种星型或雪花型的模式,用于组织数据以支持分析。维度表包含有关业务维度(如时间、地点、产品等)的详细信息,而事实表包含与度量相关的数据,如销售金额、数量等。
  3. 数据类型和时间范围:

    • 数据库:数据库通常包含当前和瞬时的数据,重点是实时更新和事务处理。数据的时间范围通常较短,覆盖了当前操作的需求。
    • 数据仓库:数据仓库通常包含历史数据的副本,用于支持时间序列分析和趋势分析。数据的时间范围可以跨多年,使用户能够查看和分析长期趋势。
  4. 查询性能:

    • 数据库:数据库优化了实时查询的性能,通常具有快速的读取和写入操作。查询通常是短暂的,针对当前数据。
    • 数据仓库:数据仓库通常针对复杂的分析查询进行了性能优化,可能包括数据预聚合、索引、分区和列式存储等技术,以支持大规模数据分析。
  5. 数据更新:

    • 数据库:数据库通常支持频繁的数据更新和插入,用于维护实时状态。
    • 数据仓库:数据仓库的数据更新通常是批处理过程,周期性地将数据从源系统导入数据仓库。

数据域和主题域

数据域与主题域的区别

数据域和主题域都是数据仓库中的概念,但它们的含义略有不同。

  1. 数据域指的是特定的业务领域或业务过程,例如销售、采购、人力资源管理、财务等。在数据仓库中,每个数据域都对应一个或多个源系统,数据仓库会从这些源系统中提取数据,经过清洗、转换和集成等处理后将 据存储在数据仓库中。数据域是数据仓库中的一个高层次概念,用于组织和管理数据仓库中的数据。
  2. 主题域指的是特定的主题或领域,其中包含相关的概念、术语、知识和实践。在数据仓库中,每个主题域都包含了一个或多个维度表和一个或多个事实表,用于存储与该主题相关的数据。主题域通常是与业务相关的,例如销售分析、客户关系管理、供应链管理等。主题域是数据仓库中的一个更细粒度的概念,用于描述和分析特定的业务领域或主题。

因此,数据域和主题域之间存在一定的层次关系。数据仓库中的每个数据域都包含了一个或多个主题域,每个主题域都包含了与其相关的维度表和事实表,以及其他的数据对象和元数据,用于支持数据的分析和决策。

从OLTP 和OLAP 系统的区别

OLTP 系统通常面向的主要数据操作是随机读写,主要采用满足 3NF 的实体关系模型存储数据,从而在事务处理中解决数据的冗余和一 致性问题:而OLAP 系统面向的主要数据操作是批量读写,事务处理中 的一致性不是OLAP 所关注的,其主要关注数据的整合,以及在一次性 的复杂大数据查询和处理中的性能,因此它需要采用一些不同的数据建 模方法。

OLTP(联机事务处理)系统:

  1. 目的

    • OLTP系统旨在支持日常的业务运营活动,例如订单处理、交易记录、客户服务等。
    • 主要用于处理短期的、实时的交易型数据,通常以高并发和低延迟为目标。
  2. 数据模型

    • OLTP系统通常采用规范化的数据模型,以最小化数据冗余,提高数据一致性。
    • 通常具有大量的表和关联关系,以支持复杂的事务。
  3. 查询和操作

    • OLTP系统主要用于支持事务性操作,如插入、更新和删除记录。
    • 查询通常涉及到单个记录或少量记录的检索。
  4. 性能要求

    • OLTP系统要求低延迟和高吞吐量,以支持大量的并发事务。
    • 数据库的设计和优化侧重于事务处理性能。
  5. 数据存储

    • OLTP数据通常存储在在线数据库中,以便实时访问。

OLAP(联机分析处理)系统:

  1. 目的

    • OLAP系统旨在支持分析和决策支持活动,例如数据挖掘、报表生成、趋势分析等。
    • 主要用于处理历史数据,支持复杂的查询和聚合操作。
  2. 数据模型

    • OLAP系统通常采用星型或雪花型的数据模型,以便进行高效的查询和分析。
    • 数据通常被汇总和预计算以提高查询性能。
  3. 查询和操作

    • OLAP系统主要用于复杂的查询和分析操作,例如聚合、连接和多维分析。
    • 查询通常涉及大量记录的检索和计算。
  4. 性能要求

    • OLAP系统通常可以容忍较高的查询延迟,但要求能够处理复杂的分析查询。
    • 数据库的设计和优化侧重于查询性能和数据存储的压缩。
  5. 数据存储

    • OLAP数据通常存储在专门的数据仓库或数据湖中,以便进行大规模数据分析。

数据体系

ONEDATA体系架构

image.png

规范定义

规范定义指以维度建模作为理论基础, 构建总线矩阵,划分和定义 数据域、业务过程、维度、度量/ 原子指标、修饰类型、修饰词、时间 周期、派生指标。

image.png

名词术语

数据域

指面向业务分析,将业务过程或者维度进行抽象的集合。其中, 业务过程可以概阔为一个个不可拆分的行为事件, 在业务过程之下, 可以定义指标; 维度是指度 的环境,如买家下单事件,买家是维度。为保障整个体系的生命力, 数据域是需要 抽象提炼,并且长期维护和更新的, 但不轻易变动。在划分数据域时, 既能涵盖当 前所有的业务需求,又能在新业务进入时无影响地被包含进已有的数据域中和扩展 新的数据域

业务过程

指企业的业务活动事件,如下单、支付、退款都是业务过程。请注意,业务过程 是一个不可拆分的行为亨,件, 通俗地讲,业务过程就是企业活动中的事件

时间周期

用来明确数据统计的时间范用或者时间点,如最近30 天、自然周、截至当日等

修饰类型

是对修饰词的一种抽象划分。修饰类型从属于某个业务域,如日志域的访问终端 类型涵盖无线端、PC 端等修饰词

修饰词

指除了统计维度以外指标的业务场景限定抽象。修饰词隶属于一种修饰类型,如 在日志域的访问终端类型下, 有修饰词PC 端、无线端等

度量、原子指标

原子指标和度自含义相同,基于某一业务事件行为下的度盟,是业务定义中不可 再拆分的指标,具有明确业务含义的名词,如支付金额

维度

维度是度盟的环境,用来反映业务的一类属性, 这类属性的集合构成一个维度, 也可以称为实体对象。维度属于一个数据域,如地理维度(其中包挤国家、地区、 省以及城市等级别的内容)、时间维度(其中包括年、季、月、周、日等级别的内容)

维度属性

维度属性隶属于一个维度, 如地理维度里面的国家名称、同家ID 、省份名称等 都属于维度属性

派生指标

派生指标=一个原子指标+多个修饰词(可选)+时间周期。可以理解为对原子指 标业务统计范围的圈定。如原子指标: 支付金额,最近l 天海外买家支付金额则为 派生指标(最近l 天为时间周期, 海外为修饰词, 买家作为维度,而不作为修饰词)

数仓分层

分层目的

  • 数据赋值业务价值:数仓分层其实和业务上没有一定关系,只是明确每个层的具体职责,比如图书馆纵向上有几层,并不存在太大的意义,横向上其实就是主题的划分,就像图书馆每层不同的区域会有标签存放不同类目的书籍,这也是为什么dwd层要做主题划分的原因,目的是有组织有类别的存放数据
  • 减少重复计算:公共逻辑下沉,对越上层越友好,避免烟囱式开发
  • 简化复杂问题:将复杂问题拆分成多个步骤,达到解耦的目的。避免出现问题错误直接溯源到ods层,方便问题的排查和追溯定位
  • 数据血缘的追踪:层级关系明显,上游和下游表之间存在依赖关系。如果某个环节或者某个模型发生错误可以借助血缘快速定位

分层结构

image.png

  • ODS(近源层 / 原始数据层)
    • 理论上不会对源数据做任何处理 。根据具体公司的需求 , 可能会在ods层之前加一个stage层,将数据缓冲到stage层,ods做一些加工处理
    • 数据构成:业务数据 + 外域数据 (+ 爬虫数据+埋点等多个异构数据源融合)
    • 主要职责:同步数据、清洗、保留历史数据,解耦业务数据(同步工具:Datax / Sqoop等等)
    • 依赖:dwd层和dim层都是基于ods层加工得出
  • DWD(明细数据层)
    • 划分主题域,构建事实表和维度表
    • 主题域:主题域划分是基于整个业务过程中有哪些实体,整个业务过程可以抽象成几个大类,以此来划分,比如常见的主题域:营销、用户、流量。大家不用过多纠结于数据域和主题域的区别,个人认为可以当成一样理解,减少理解成本,而且主题域划分的时候通常会有一级主题域、二级主题域、三级主题域等,已经体现出自上而下的层级或者说子集关系。比如:以肯德基App为例,首先用户肯定是很多业务过程中抽离出的一个实体对象,再一个渠道,想让一个用户去使用你的app或者小程序,通常会使用导流操作,导流就会有很多渠道,有的可能是跳转,有的是网站引导,有的是广告,甚至还有一些线下推广。比如:微博很多时候有美团的广告或者肯德基的广告,这种就属于广告引流,所归属的渠道域是不一致的
    • 注意点:金融行业中用户和客户是有区别的,客户是用户的子集,比如花呗,注册了支付宝,但是没有花呗支付的行为只是用户,参与了直接业务交易的才是客户
    • 特殊情况:dwd层有的时候可能会拆分成两层
      • 以淘宝为例,在天猫超市购买多个物品时,1个包裹无法满足,则会拆分成两个运单,即1个订单多个运单,这个时候如果想看订单明细表,则需要将订单和运单关联装载到一起形成一张明细表。新产出的这张明细表一定程度上已经跨模型跨二级主题域,单独放到一层,类似一张宽表。或者可以理解成交易为一级主题域名,而订单和运单明细则为二级主题域
  • DWS(汇总数据层)
    • 基于DWD明细数据汇总整合
    • 指标体系后续会提到(比如:指标体系和主题、分层之间的关系等等)
  • Dim(公共维度层)
    • dim层存放的是一些业务事实或者实体的一些维度信息,比如:地区,货币形式等等
    • 关系:dim层和dwd,dws层是一个横向的关系,dim层其实是横跨dwd层和dws层的。比如:dim层可以和dws层关联支持app层应用。同样,dim层也可以和dwd层去关联支持dws层的一些分析
  • 维度退化:当一些维度经常使用时,可以适当退化一些维度信息到dwd层的事实表中,但是不能退化太多。比如:一家企业的注册号和社会统一代码是作为企业的代码信息 ,我们在处理的过程中其实放在了dwd的事实表中,一方面作为高频使用的高保字段,可以确定数据的唯一性,而且退化到事实表中减少关联,提高了明细数据的易用性。维度退化的本质是为了上层的方便使用,不能过度退化,比如:dim层一些维度信息发生了比较频繁的变化,但是又退化到dwd事实表中,那么dwd的事实表就需要经常去刷数据。所以退化维度的依据:常用、变化不频繁
  • ADS(应用数据层)
    • 存放应用层指标,支持一些分析系统,比如:报表,数据产品
    • 进行宽表的组装
    • 业务研发的缓冲层:当新的业务需求入手,但是dws层没有相应的逻辑和指标,这个时候可以根据应急程度在ads层先揉合一张表应用,当反馈效果较好时,再进行拆分,落到核心模型和扩展模型