1.架构图
有空再补
2.技术简介
| 组件 | 版本 | 简介 |
|---|---|---|
| FLINK | 1.12.1 | 分布式计算引擎 |
| HIVE | 3.1.2 | 最常用的 HQL 数仓工具 |
| PHOENIX | 5.0.0 | HBase SQL 化查询分析工具 |
| SPARK | 3.0.1 | 分布式计算引擎 |
| SQOOP | 1.4.7 | 数据采集与转储服务 |
| TEZ | 0.10.0 | 优化 MapReduce 任务的 DAG |
| YARN | 3.1.1 | 分布式资源调度服务 |
| HDFS | 3.1.1 | 分布式存储服务 |
| ZOOKEEPER | 3.4.13 | 分布式应用程序协调服务 |
| ALERTMANAGER | 0.21.0 | 发送监控告警信息 |
| GRAFANA | 6.5.1 | 展示监控数据 |
| INFLUXDB | 1.8.0 | 存储监控数据 |
| NODEEXPORTER | 1.0.0 | 读取节点资源监控指标 |
| PROMETHEUS | 2.18.1 | 拉取监控数据 |
| USDPMONITOR | 1.0.0 | 读取组件监控指标 |
| HUE | 4.8.0 | 可视化管理服务 |
| ZEPPELIN | 0.9.0 | 可视化管理服务 |
| DOLPHINSCHEDULER | 1.3.6 | 任务调度服务 |
3.数仓中表的种类及其概念
一般表分为两个类型,分别是维度表和事务表
3.1事实表
事实表分为两类:事务型事实表和周期型事实表
事务型事实表,一般指随着业务发生不断产生的数据.特点是一旦发生不会再变化. 一般比如,交易流水,操作日志,出库入库记录等等
周期型事实表,一般指随着业务发生不断产生的数据.与事务型不同的是,数据会随着业务周期性的推进而变化.比如订单,其中订单状态会周期性变化. 再比如,请假 贷款申请,随着批复状态在周期性变化
事实表的特征:表里没有存放实际的内容,他是一堆主键的集合,这些ID分别能对应到维度表中的一条记录.事实表包含了与各维度表相关联的外键,可与维度表关联.事实表的度量通常是数值类型,且记录数会不断增加,表数据规模迅速增长
3.2.维度表
一般是指对应一些业务状态,代码的解释表,也可以称之为码表.比如地区表,订单类型,支付方式,商品分类等等
维度表可以分为两类:一般维度表和固定维度表
一般维度表的数据是不断增加和变化的
固定维度表的数据是不变的
每个维度表都包含单一的主键列.维度表的主键可以作为与之关联的任何事实表的外键.维度表通常比较宽,是扁平型非规范表,包含大量的低粒度的文本属性
3.3.表的概念总结
总的说来,在数据仓库中不需要严格遵守规范化设计原则.因为数据仓库的主导功能就是面向分析,以查询为主,不涉及数据更新操作.事实表的设计是以 能够正确记录历史信息 为准则,维度表的设计是以 能够用合适的角度来聚合主题内容 为准则
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.星座模型
星座模式是星型模式延伸而来,星型模式是基于一张事实表的,而星座模式是基于多张事实表的,而且共享维度信息
前面介绍的两种维度建模方法都是多维度表对应单事实表,但在很多时候维度空间内的事实表不止一个,而一个维度表也可能被多个事实表用到,在业务发展后期,绝大部分维度建模都采用的是星座模式
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层
建模方式及原则
- 尽量减少数据访问时计算,优化检索
- 维度建模,星型模型
- 事实拉宽,度量预先计算
- 分表存储