1.技术简介

组件

版本

简介

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

任务调度服务

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

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

2.1事实表

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

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

2.2.维度表

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

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

2.3.表的概念总结

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

2.4 表的同步策略

2.4.1 维度表

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

2.4.2 事实表的同步策略

事务型事实表

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

周期型事实表

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

2.4.3 拉链表的设计

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

3.维度模型设计

3.1.维度建模基本概念

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

3.2.维度建模三种模式

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

3.2.1.星型模型

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

  • 维度表只和事实表关联,维度表之间没有关联
  • 每个维度表主键是事实表的外键
  • 以事实表为核心,维度表围绕核心呈星型分布
    以下就是典型的星型模型

3.2.2.雪花模型

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

3.2.3.星座模型

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

4.数据仓库理论知识

4.1.为什么要分层

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

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

4.2.数据分层

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

4.2.1.数据运营层(ODS)

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

建模方式及原则

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

4.2.2.数据明细层(DWD)

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

建模方式及原则

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

4.2.3.数据服务层(DWS)

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

建模方式及原则

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

4.2.4.数据应用层(ADS)

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

建模方式及原则

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

4.2.5.数据集市层(DM)

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

建模方式及原则

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

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注