1.架构图

有空再补

2.技术简介

3.数仓中表的种类及其概念

一般表分为两个类型,分别是维度表和事务表

3.1事实表

事实表分为两类:事务型事实表和周期型事实表
事务型事实表,一般指随着业务发生不断产生的数据.特点是一旦发生不会再变化. 一般比如,交易流水,操作日志,出库入库记录等等
周期型事实表,一般指随着业务发生不断产生的数据.与事务型不同的是,数据会随着业务周期性的推进而变化.比如订单,其中订单状态会周期性变化. 再比如,请假 贷款申请,随着批复状态在周期性变化

事实表的特征:表里没有存放实际的内容,他是一堆主键的集合,这些ID分别能对应到维度表中的一条记录.事实表包含了与各维度表相关联的外键,可与维度表关联.事实表的度量通常是数值类型,且记录数会不断增加,表数据规模迅速增长

3.2.维度表

一般是指对应一些业务状态,代码的解释表,也可以称之为码表.比如地区表,订单类型,支付方式,商品分类等等
维度表可以分为两类:一般维度表和固定维度表
一般维度表的数据是不断增加和变化的
固定维度表的数据是不变的

每个维度表都包含单一的主键列.维度表的主键可以作为与之关联的任何事实表的外键.维度表通常比较宽,是扁平型非规范表,包含大量的低粒度的文本属性

3.3.表的概念总结

维度和事实.png

总的说来,在数据仓库中不需要严格遵守规范化设计原则.因为数据仓库的主导功能就是面向分析,以查询为主,不涉及数据更新操作.事实表的设计是以 能够正确记录历史信息 为准则,维度表的设计是以 能够用合适的角度来聚合主题内容 为准则

3.4 表的同步策略

3.4.1 维度表

维度表的数据多少都会有变化,可根据实际业务选择全量或者拉链.
有些维度表随着时间缓慢变化,这种维度表称为缓慢变化维,当然这里的缓慢是相对事实表的,维度数据随着时间变化,会产生历史切片问题.如果业务不要求反应维度的历史,可直接全量,否则应该使用拉链表或者历史表.

3.4.2 事实表的同步策略

事务型事实表

每日增量,因为数据不会变化,而且数据量巨大,所以每天只同步新增数据即可

周期型事实表

• 每日全量,首先这类表从数据量的角度,存每日全量的话,数据量太大,冗余也太大
• 每日增量,如果用每日增量的话无法反应数据变化.一般来说这个表,足够计算大部分当日数据,但是这种依然无法解决某一个历史时间点(时间切片)的切片数据
• 拉链表,利用每日新增和变化表,制作一张拉链表,以方便的取到某个时间切片的快照数据,所以我们需要得到每日新增及变化量

3.4.3 拉链表的设计

• 拉链表不存储冗余的数据，只有某行的数据发生变化，才需要保存下来，相比每次全量同步会节省存储空间
• 能够查询到历史快照
• 额外的增加了两列（dw_start_date dw_end_date），为数据行的生命周期,表示某条数据的有效时间和失效时间,失效时间可以默认9999-12-31
  此时,只要数据没有变化,就无需同步.如果数据发生了变化,就将原数据的dw_end_date改为当前时间,同时保存新的数据,新数据的dw_start_date为当前时间
  一般的操作步骤是:第一次全量导入,之后增量的数据导入ODS,再合并历史数据

4.维度模型设计

4.1.维度建模基本概念

维度建模以分析决策的需求出发构建模型,构建的数据模型为分析需求服务,因此它重点解决用户如何更快速完成分析需求,同时还有较好的大规模复杂查询的响应性能
维度建模是专门应用于分析型数据库 数据仓库 数据集市建模的方法.数据集市可以理解为是一种"小型数据仓库"

4.2.维度建模三种模式

目前有三种模式,分别是星型模型,雪花模型,星座模型

4.2.1.星型模型

最常用的维度建模方式.星型模型是以事实表为中心,所有的维度表直接连接在事实表上,像星星一样
星型模型的维度建模由一个事实表和一组维度表组成,且具有以下特点

• 维度表只和事实表关联,维度表之间没有关联
• 每个维度表主键是事实表的外键

• 以事实表为核心,维度表围绕核心呈星型分布
  以下就是典型的星型模型

  
  
  维度和事实.png

4.2.2.雪花模型

雪花模型是星型模型的扩展.虽然这种模型相比星型更规范一些,但是由于这种模型不太容易理解,维护成本比较高,而且需要关联多层维表,性能也比星型模型要低,所以不是很常用

4.2.3.星座模型

星座模式是星型模式延伸而来,星型模式是基于一张事实表的,而星座模式是基于多张事实表的,而且共享维度信息
前面介绍的两种维度建模方法都是多维度表对应单事实表,但在很多时候维度空间内的事实表不止一个,而一个维度表也可能被多个事实表用到,在业务发展后期,绝大部分维度建模都采用的是星座模式

星座模型.png

5.数据仓库理论知识

5.1.为什么要分层

分层的主要原因是在管理数据的时候,能对数据有一个更加清晰的掌控,详细来讲,主要有下面几个原因

• 清晰数据结构
  每一个数据分层都有他的作用域,这样我们在使用表的时候能更方便的定位和理解
• 数据血缘追踪
  简单来说,我们最终给业务呈现的是一个能直接使用的业务表,但是他的来源有很多,如果有一张来源表出问题了,我们希望能够快速准确的定位到问题,并清楚他的危害范围
• 减少重复开发
  规范数据分层,开发一些通用的中间层数据,能够极大的减少重复计算
• 复杂问题简单化
  把一个复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解.而且便于维护数据的准确性,当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤开始修复

5.2.数据分层

每个企业根据自己的业务需求,可以把数据分成不同的层次,但是最基础的分层思想,理论上数据分三个层,数据运营层 数据仓库层 数据服务层.基于这个基础分层之上添加新的分层,来满足不同的业务需求

5.2.1.数据运营层(ODS)

操作数据存储,也是原始数据层,是数据源中的数据,经传说中的ETL装入本层.数据总体上大多是按照源头业务系统的分类方式而分类

建模方式及原则

从业务系统增量抽取,保留时间由业务需求决定.可分表进行周期存储,数据不做清洗转换与业务系统数据模型保持一致,按主题逻辑划分

5.2.2.数据明细层(DWD)

对ODS层的数据进行清洗后的结果,包括但不限于去空值,去脏数据,去异常值.结构和粒度与ODS保持一直,为DWS层提供来源明细数据,提供业务系统细节数据的长期沉淀,为未来分析类需求的扩展提供历史数据支撑

建模方式及原则

为支持数据重跑可额外增加数据业务日期字段 可按年月日进行分表 用增量ODS层数据和前一天DWD相关表进行merge处理

5.2.3.数据服务层(DWS)

在这里，从DWD层中获得的数据按照主题建立各种数据模型.例如以研究人的旅游消费为主题的数据集中,便可以结合航空公司的登机出行信息,以及银联系统的刷卡记录,进行结合分析,产生数据集.在这里,我们需要了解四个概念:维(dimension) ,事实(Fact), 指标(Index)和粒度(Granularity)

建模方式及原则

• 聚合汇总增加派生事实
• 关联其它主题的事实表,本层可能会跨主题域
• 数据模型可能采用反范式设计

5.2.4.数据应用层(ADS)

该层主要是提供数据产品和数据分析使用的数据,包括前端报表 分析图表 KPI 仪表盘 OLAP 专题等分析,一般会存放在ES MySQL等系统中供线上系统使用,也可能会存在Hive或者Druid中
例如:我们经常说的报表数据,或者说那种大宽表,一般就放在这里

建模方式及原则

• 保持数据量小
• 维度建模 星形模型
• 各位维度代理键+度量
• 增加数据业务日期字段,支持数据重跑
• 不分表存储

5.2.5.数据集市层(DM)

处于DWS和ADS中间,也是按照主题建立各种数据模型,但它既可以向数据产品和数据分析提供数据,也可以向ADS层提供数据形成大宽表.一般把数据集市视为小型的数据仓库.如果把公司类比成数据仓库,那么部门就是数据集市,某种程度上,数据集市就可以等于DWS层

建模方式及原则

• 尽量减少数据访问时计算,优化检索
• 维度建模,星型模型
• 事实拉宽,度量预先计算
• 分表存储