Create your Gitee Account
Explore and code with more than 12 million developers,Free private repositories !:)
Sign up
This repository doesn't specify license. Please pay attention to the specific project description and its upstream code dependency when using it.
Clone or Download
contribute
Sync branch
Cancel
Notice: Creating folder will generate an empty file .keep, because not support in Git
Loading...
README

[架构]

MPP架构优点

  1. 传统数仓常见的随机数架构,将单机数据库节点组成集群,提升性能
  2. 节点间为非共享架构(Share Noting),没个节点都有独立的磁盘存储系统和内存系统
  3. 每台数据通过专用网络或者商业通用网络互相连接,彼此协同计算,作为整体提供服务
  4. 设计上优先考虑C 其实A P

MPP架构缺点

  1. 存储位置不透明,通过hash确定数据所在物理节点,查询任务在所有节点均会执行
  2. 并行计算式,单节点瓶颈会成为整个系统短板,容错性差
  3. 分布式事务的实现会导致扩展性降低

分布式架构(Hadoop 架构)

  1. 各节点实现场地自治(可以单独运行局部应用),数据在及群众全局透明共享
  2. 每个节点通过局域网连接,节点间的通信开销较大,运算时致力减少数据移动
  3. 有效考虑分区容错 然后是A C

MPP + 分布式架构

  1. 数据存储采用分布式架构中的公共存储,提高分区容错
  2. 上层架构采用MPP,减少运算延迟

通用架构

ETL(Extract-Transform-Load)数据同步模块,将业务数据抽酒进行交互转换清洗,标准化。

ODS 存储清洗过后的原始数据(不允许修改,保证数据一致)

CDM

DWD 数据明细

DWS 数据汇总(宽表,提升数据分析)

ADS 数据应用

ETL流程

Extract-Transform-Load

  • 将数据从来源段经过抽取,交互转换,加载至目的端的过程
  • 构建数据仓库的重要一环,用户从数据源抽取所需的数据,经过数据清洗,最终按照预先定义好的数据仓库模型,将数据加载到数据仓库中。

数据抽取[Extraction]

  • 抽取的数据源可分为结构化、非结构化数据、半结构化数据
  • 结构化的数据一般采用JDBC、数据库日志的方式,非|半结构化的数据会监听文件变动

抽取方式

  • 数据抽取方式有全量同步、增量同步两种方式
  • 全量同步会将全部数据进行抽取,一般用于初始化数据装载
  • 增量同步方式会检测数据的变动,抽取发生变动的数据,一般用于数据更新

数据转换[Transformation]

  • 数据转换姚经理数据清洗和转换两个阶段
    • 数据清洗主要是对出现的重复、二义性、不完整、违反业务或者逻辑规则等问题的数据进行统一的处理
    • 数据转换主要是对数据进行标准化处理,进行字段、数据类型、数据定义的转换
  • 结构化数据在转换过程中的逻辑较为简单,非|半结构化的数据转换较为复杂

数据加载[Loading]

  • 将最后处理完的数据导入到对应的目标源里

结构化数据ETL工具:Sqoop Kettle

半|非结构化数据ETL工具:Flume Logstash

数据积存 ODS

操作数据层[ODS]

  • 数据与原业务数据保持一致,可以增加字段用来进行数据管理(扩充集)
  • 存储的历史数据是只读的,提供业务系统查询使用
  • 业务系统对历史数据完成修改后,将update_type字段更新为UPDATE,追加回ODS中

比如业务系统需要对N年前的数据进行修改,那ODS层提供了查询功能,业务系统修改数据后,发现ODS层数据不能被修改。

所以业务系统只能将查询的出来的数据追加到ODS层将update_type修改为UPDATE,然后将历史数据删除,保证数据仓库最新的时效性

  • 在离线数据中,业务数据定期通过ETL流程导入到ODS中,导入的方式也有全量、增量两种
    • 全量导入:数据第一次导入时,选择此种方式
    • 增量导入:数据非第一次导入是,每次只需要导入新增、修改的数据,建议使用外连接&全覆盖

数据分析 DWD DWS ADS

数据明细层[DWD]

  • 数明细层对ODS层的数据进行清洗、标准化、维度退化(时间、分类、地域)
  • 数据仍然班组3NF模型,为分析运算做准备

维度退化(多张表合并成一张表)

数据汇总层[DWS]

  • 数据汇总层的数据对数据明细层的数据,按照分析主题镜像计算汇总,存放便于分析的宽表
  • 存储模型并非3NF,而是注重数据聚合,复杂查询、性能处理更优的数仓模型

在这里插入图片描述

DWS层应该包含模型和基于模型汇总的数据

数据应用层[ADS]

  • 数据应用层也被称为数据集市
  • 存储数据分析结果,为不用业务场景提供接口,减轻数据仓库的负
    • 数据仓库擅长数据分析,直接方法业务查询结构,会加重其负担

在这里插入图片描述

[建模]

OLTP,OLAP

OLTP系统建模方法

OLTP(在线事务处理)系统中,主要操作是随机读写

  • 为了保证数据一致性、减少冗余,尝试用关系模型
  • 在关系模型中,使用三范式规则来减少冗余

OLAP

OLAP系统中,主要操作是复杂分析查询,关注数据整合,以及分析、处理性能。根据存储的方式不同,又可以分为ROLAP,MOLAP和HOLAP

  • ROLAP(Relation OLAP,关系型OLAP):使用关系模型构建,存储系统一般为RDBMS
  • MOLAP(Multidimensional OLAP,多维度OLAP):预先聚合计算,使用多维度数组的形式保存数据结果,加快查询分析时间
  • HOLAP(Hybrid OLAP,混合架构的OLAP):ROLAP和MOLAP两者的继承,如底层是关系型,高层是多维矩阵型;查询高于ROLAP,低于MOLAP

ROLAP,MOLAP建模理论

ROLAP系统建模方法

典型的数仓建方法有ER模型,维度模型,DataValue,Anchor(维度模型适合频繁变动的业务)

在这里插入图片描述

维度模型
  • 维度模型中,表被分为维度表、事实表,维度是对事实的一种组织
  • 维度一般包含分类、时间、地域

在这里插入图片描述

在这里插入图片描述

中间的订单就是事实表,旁边围绕的就是维度表

建立好维度表后,可以根据不同的维度进行分析,比如地区,年份的分析

维度模型分为星型模型、雪花模型、星座模型,模型建立后方便对数据进行多维分析。

星型模型

标准的星型模型,维度只有一层,性能分析最优

在这里插入图片描述

雪花模型

雪花模型具有多层维度,比较接近3NF,较为灵活

在这里插入图片描述

星座模型
  • 星座模型基于多个事实表,事实表之间会共享一些维度表
  • 是大型数据仓库中的常态,是业务增长的结果,与模型设计无关

在这里插入图片描述

宽表模型
  • 宽表模型是维度模型的衍生,适合Join性能不佳的数据仓库产品
  • 宽表模型将维度冗余到事实表中,形成宽表,以此减少Join操作
在这里插入图片描述

MOLAP系统建模方式

  • MOLAP将数据进行预结算,并将聚合结果存储到CUBE模型中
  • CUBE 模型以多维数组的形式,物化到存储系统中,加快后续的查询
  • 生成CUBE需要大量的时间、空间,维度预处理可能为导致数据膨胀

在这里插入图片描述

常见MOLAP产品:KylinDruid

多维分析

  • OLAP主要操作是复杂查询,可以多表关联,使用COUNT,SUM,AVG等聚合函数
  • OLAP对复杂查询操作做了直观的定义,包括钻取、切片、切块、旋转。

在这里插入图片描述

[钻取]

  • 对维度不同次的分析,通过改变维度的层次来变换分析的粒度
  • 钻取包括上卷,下钻

上卷(Roll-up)也称为向上钻取,指从低层次到高层次的切换

下钻(Drill-down),指从高层次到低层次的切换

在这里插入图片描述

[切片,切块]

选择某个维度进行分割称为切片

按照多维进行的切片称为切块

在这里插入图片描述

[旋转]

对维度方向的转换,类似交换坐标轴上卷

在这里插入图片描述

[最佳实践]

数据仓库表类型

维度建模中的表分类

  • 事实表
  • 维度表
  • 事务事实表
  • 周期快照事实表
  • 累计快照事实表
事实表

一般是指一个现实存在的业务对象,比如用户,商品,商家,销售员等

在这里插入图片描述

维度表

一般是指对应一些业务状态,代码的解释表。通常使用维度对事实表中的数据进行统计,聚合运算

在这里插入图片描述

事务事实表

随着业务不断产生的数据,一旦生产不再会发生变化,比如交易流水,操作日志,出库入库记录 在这里插入图片描述

周期事实表
  • 随着业务周期型的推荐而变化,完成建个周期内的度量统计,如年,季度累计。
  • 使用周期+状态度量的组合,如年累计订单数量。

在这里插入图片描述

累计快照事实表

记录不确定周期的度量统计,完全覆盖一个事实的生命周期,如订单状态,通常有多个时间字段记录生命周期的关键时间点,只有一条记录针对此记录不断更新

在这里插入图片描述

实现方式一

  • 使用日期分区表,全量记录数据,每天的分区存储全量数据与当天增量数据合并的结果
  • 数据量大会导致全量表膨胀,存储大量永远不更新的冷数据,对性能影响较大
  • 适用于数据量少的情况

实现方式二

  • 使用日期分区表,推测数据最长的生命周期,存储周期内数据,周期外的类数据存储到归档表
  • 需要保留多天的分区数据,存储消耗依然很大

实现方式三

  • 使用日期分区表,以业务实体结束的时间分区,每天分区存放当天结束的数据;设计一个时间非常大的分区
  • 已结束的数据存放到相对应的分区,未结束的数据分区,数据量也不会很大,ETL性能好
  • 无存储浪费,数据全局唯一
  • 业务系统可能无法表示业务实体的结束时间,可以用奇台相关业务系统的结束标志作为此业务系统的结束,业务以使用最长生命周期时间或者前端系统的数据归档时间
拉链表

拉链表记录每条信息的生命周期,用于保存历史数据的所有(变更)状态,拉链表将表数据的随机修改方式变城顺序追加

在这里插入图片描述

ETL策略

[全量同步]

数据初始化装在一定使用全量同步的方式,因为业务技术原因,使用全量同步的方式做周期数据更新,直接覆盖原有数据即可。

[增量同步]

传统数据整合方案中,大多采用merge方式,主流大数据平台不支持update操作,可采用全外连接覆盖方式,如果担心数据更新出错,可采用分区方式,每天保证最小的全量版本,保存较短周期。

任务调度

为什么需要任务调度

  • 解决任务单元间的依赖关系
  • 自动化完成任务的定时执行

常见任务类型

shell, Java程序,MapReduce程序,sql脚本

Empty file

About

2021年11月27号开始学习大数据 hadoop 2021年12月24号开始学习hive expand collapse
Cancel

Releases

No release

Contributors

All

Activities

Load More
can not load any more
马建仓 AI 助手
尝试更多
代码解读
代码找茬
代码优化