数据仓库理论篇与Flume

数据仓库理论篇

数据仓库Data Warehouse - 数仓是一种思想,数仓是一种规范,数仓是一种解决方案

数据处理方式

在这里插入图片描述

数据处理大致可以分为两大类:

联机事务处理OLTP(On-Line Transaction processing)
联机分析处理OLAP(On-Line Analytical Processing)

OLTP(联机事物处理)

面向于业务(事务)的,主要用于捕获数 据,主要对数据进行CURD操作,存储最近业务 使用数据,交互性强,存储数据量较小。并且满足三范式。

OLAP(联机分析处理)

面向于主题的,主要用于数据分析,对数据进行查询操作,存储过去既定发生过 的数据(历史数据),交互性弱但存储数据量比较 大 可以进行复杂的聚合计算

数据建模

数据建模指的是对现实世界各类数据的抽象组织(就是对数据的一种抽象管理方式),确定数据库需管辖的范围、数据的组织形式等直至转化成现实的数据库。

将经过系统分析后抽象出来的概念模型转化为物理模型

ER模型(关系)

用实体加关系描述的数据模型

特点:规范性较好,冗余度小,但不适合分析数据

遵循三范式:

- 列不可再分
- 所有的列必须依赖于主键
- 如果有部分列不依赖于主键,就将这些列重新构建一张表 

维度建模

在这里插入图片描述

以分析决策的需求构建模型,主要完成用户如何快速完成分析需求 冗余度比较高

维度建模中的重要概念:

事实表
	表中的每行数据代表一个业务事件  数据非常大定时更新,不保留历史数据
	事实表中的每行:具有可加性的数值型的度量值  与维表相连接的外键 通常有两个或两个以上外键
	事务型事实表   周期型快照事实表   累积型快照事实表
维度表
	一般是对事实的描述信息,一张表对应世界中一个对象或概念
	选择业务 > 定义粒度 > 选择维度 > 确定事实                
度量值
	度量值是对一次行为的度量(如一个事件的个数,金额等)

维度建模表分类

在维度建模中,将度量称为“事实” , 将环境描述为“维度”。

例:今天张三买了一瓶两块的矿泉水
在这里:”今天“、“张三”、“买”、”矿泉水“是维度,“一瓶”,“两块”是事实

维度表

维度表概念

维度建模四部曲:
选择业务处理过程 > 定义粒度 > 选择维度 > 确定事实

辅助我们分析事实数据,维度的列成为维度的属性,这些也是将要分析数据的重点特征
维度表的范围很宽,有可能将多维的数据叠加到一起。方便计算
和事实表相比行数比较少–商品
内容相对固定

维度表设计原则

  • 1.维度属性尽量丰富,为数据使用打下基础
    上游维度丰富,下游计算才会灵活

  • 2.给出详实的、有意义的文字描述

  • 3.区分数值型属性和事实

  • 4.沉淀出通用的维度属性,为建立一致性维度做好铺垫

  • 5.退化维度(DegenerateDimension)
    去除表与表之间的关联数据,直接替换成指定数据

  • 6.缓慢变化维(Slowly Changing Dimensions)

    维度的属性会随着时间变化
    	a直接覆盖原来的值
    	b拉链表增加三列(有效日期,截止日期,行标识)
    	c增加属性列
    
  • 7.冗余维度.

    把常用的维度冗余到事实表

维度设计方法

在这里插入图片描述

  1. 有则选择,无则创建 -选择或创建维度
  2. 选择主维度表
  3. 确定相关维度
  4. 确定维度属性
    1. 第一个阶段是从主维表中选择维度属性或生成新的维度属性
    2. 第二个阶段是从相关维表中选择维度属性或生成新的维度属性

维度设计高级主题

在这里插入图片描述

  • 维度整合
    • 垂直整合
      • 存储的是相同的数据集,但是存储在不同的表中
    • 水平整合
      • 判断数据是否交叉(重复)去重
      • 没有交叉就将信息放在一张表中,需要保留原来的主键信息
  • 水平拆分
    • 可以按照类别或类型进行细分
  • 垂直拆分
    • 反规范化处理
    • 常用为主,较少为辅

事实表

事实表概念

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-EGv0kgNp-1656827481708)(E:笔记资源image-20220630201349050.png)]

  • 事实表中的每行数据代表一个业务事件。“事实”表示的是业务事件的度量值(可以统计次数、个数、金额等)
  • 粒度:
    这个事件发生的一个频度[天- 小时- -分钟] 用什么来衡量?
  • 度量值:
    一个变化的数值
    • 可加:页面的PV可以根据时间维度区划维度用户分类维度
    • 半可加:有些维度可以累加,有些维度不可以累加
    • 不可加:空气湿度23.5%及格率0.75
      相对维表来说,通常事实表要细长得多,行的增加速度也比维表快很多。

事实表设计原则

原则1:尽可能包含所有与业务过程相关的事实
原则2:只选择与业务过程相关的事实
原则3:分解不可加性事实为可加的组件
原则4:在选择维度和事实之前必须先声明粒度
原则5:在同-个事实表中不能有多种不同粒度的事实—年级班级学校
原则6:事实的单位要保持一致— 元角分
原则7:对事实的null值要处理
原则8:使用退化维度提高事实表的易用性

事实表设计方法

在这里插入图片描述

  • 选择业务过程以及确定事实表类型

比如淘宝的订单流转的业务过程有四个:创建订单,买家付款,卖家发货,买家 确认收货

  • 明确了业务过程后,根据具体业务需求来选择与维度建模有关的业务过程。

比如买家付款这个业务过程,那么事实表应只包括买家付款这一个业务过程的单 事务事实表 总而言之就是选择了哪些业务过程,那么所建立的事实表应为包含了所有业务过 程的累积快照事实表

  • 声明粒度

粒度声明非常重要,尽量选择最细级别的原子粒度,以确保事实表的应用具有最 大的灵活性 比如一次购物车下单,一个父订单可能是购物车,一个子订单是每个商品的订 单,那么订单事实表选择子订单粒度

  • 确定维度

完成粒度声明意味着声明了主键,对应的维度组合就可以确定了 应该选择能够清楚描述业务过程的维度信息 例如订单事实表,粒度为子订单,相关的维度有卖家、买家、商品,收货人,时 间等维度

  • 确定事实

应该选择与业务过程有关的所有事实,且事实的粒度要和声明的粒度一致,比如 在淘宝订单付款事务事实表中,同粒度的事实有子订单分摊的支付金额、邮费、 优惠金额等

  • 冗余维度

大数据的事实表设计中,冗余尽可能多的维度让下游方便使用,减少连表数量

事实表分类

在这里插入图片描述

  • 事务型事实表: 一次操作即可完成(有一条记录就做一条记录) 如一笔订单 一笔支付记录
  • 周期型快照事实表:定时更新实时数据 保留固定时间间隔的数据 如每周销售额
  • 累积型快照事实表:需要多次操作才能完成 如送快递 从发出到签收 经过多次时间更新才能完成

数据组织类型

维度建模按数据组织类型划分可分为星型模型、雪花模型、星座模型

在这里插入图片描述

星型模型

是一种多维的数据关系,它由一个事实表(Fact Table)和一组维表(Dimension Table)组成。每个维表都有一个维作为主键,所有这些维的主键组合成事实表的主键。事实表直接来连接维度表,维度表不再分;查询效率高,数据冗余性也高。
在这里插入图片描述

雪花模型

他是有一个或多个维表没有直接连接到事实表上,而是通过其他维表连接到事实表上。事实表直接连接主维度表,主维度表连接子维度表。冗余性低、灵活度高、查询效率低。

在这里插入图片描述

星座模型

多个事实表共享维度表,类似多个星型模型连在一起,减少中间的维表,增加数仓的容量。

模型的选择跟数据和需求有关,跟设计无关, 按实际需求选择

在这里插入图片描述

维度建模步骤

  • 选择业务处理过程 > 声明粒度 > 选择维度 > 确定事实选
  • 在这里插入图片描述
  • 选择业务:选择感兴趣的业务线,如下单,支付,退款,活动 。
  • 声明粒度:一行代表信息:一条订单?一天的订单?一周的订单? 选择最小粒度
  • 确认维度:维度退化:谁 。 什么时间 什么地点
  • 确认事实:度量值:如个数,件数,金额

数据仓库分层

数仓分层原因:
	空间换时间:通过预处理来提升用户效率
	增加扩展性:不分层,当源业务系统的规则发生变化会影响整个数据清洗
	分层管理:通过数据分层简化数据清洗过程,将复杂的工作分成多个步骤

数仓分层优点:
	清晰数据结构  方便数据血缘追踪  减少重复开发  把复杂问题简单化  屏蔽原始数据的异常

在这里插入图片描述

阿里数仓进化史

在这里插入图片描述

ETL

在这里插入图片描述

概念:

ETL是将业务系统的数据经过抽取、清洗转换之后加载到数据仓库的过程,目的是将企业中的分散、零乱、标准不统一的数据整合到一起,为企业的决策提供分析依据。

  • 抽取(Extract) 、
    • 将各个系统中的数据统- -汇 聚到ODS过程-买菜
  • 清洗转换(Transform)
    • 从业务系统到ODS清洗掉脏数据,无效数据,对敏感数据空值进行转换
  • 加载 (Load)
    • 将操作之后的数据载入到DW中
五大模块:
数据抽取、数据清洗、库内转换、规则检查、数据加载。
各模块可灵活进行组合,形成ETL处理流程。

ETL工具

在这里插入图片描述

加载策略

系统日志分析方式:
	通过分析数据库自身的日志来判断变化的数据。
	
触发器方式:
	直接进行数据加载利用增量日志表进行增量加载
	
时间戳方式:
	在源表上增加一个时间戳字段,系统中更新修改表数据的时候,同时修改时间戳字段的值。
	
全表比对方式:
	全表比对即在增量抽取时,ETL 进程逐条比较源表和目标表的记录,将新增和修改的记录读取出来。

源系统增量(delta)数据直接或者转换后加载:
	日常的 ETL 更新中,还会遇到目标表的数据来源来自于多张源表,通过关键字段的拼接进行更新操作。
	如果多张源表都有时间戳字段,可以利用时间戳进行增量更新,另外还可以采用全表比对的方式进行增量更新。

常见概念描述

  • 数据仓库:
    数据仓库是一个功能概念,历史数据的集合体.使用维度建模.存储介质为分布式文件系统 日常倾向于OLAP

  • 数据集市:
    数据集市是一个结构概念,小型的数据仓库,多个数据集可以组成数据仓库
    面向对象的业务和对应的主题—教务医务图书

  • 数据孤岛:
    业务系统之间各自为政、相互独立造成的数据孤岛,体现在业务不集成流程不互通、数据不共享。在大数据中要打破孤岛,实现数据共享

  • 数据湖-数据洋--数据水洼:
    数据湖是一种数据存储理念,存储企业各种各样的原始数据的大型仓库,包括结构化、非结构、二进制图像、音频、视频等等。
    HUDI — Detal Lake

  • 数据中台:
    数据中台是一个逻辑概念,使数据对内优化管理提高业务,对外可以数据合作价值释放
    宽表窄表:
    宽表:字段比较多的数据库表,方便我们计算

    窄表:减少了数据的冗余度,相对来说数据就少

大数据架构

互联网大数据平台

大数据平台由上到下,可分为三个部分:数据采集、数据处理、数据输出与展示

在这里插入图片描述

Lambda架构

  • 优点:
    • 它具有很好的灵活性和可扩展性,也对硬件故障和人为失误有很好的容错性。
      批处理层(Batch Layer) 速度处理层(Speed Layer) 响应查询的服务层(Serving Layer)
      数仓的分层主要是应用于批处理操作,速度处理一般操作很少分层直接计算出最后的结果
  • 缺点:
    • 架构师需要维护两个复杂的分布式系统,井且保证他们逻辑上产生相同的结果输出到服务层中。
      一般情况下要维护两套代码,当业务发生变化,实时和离线的计算代码都需要重新编写

Kappa架构

速度处理层(Speed Layerf) 响应查询的服务层(Serving Layer)
每次开启一个新的业务从0开始计算,当新的计算 的数据虽达到老的计算的数据量,就用新的结果

Flume

Flume是一个分布式、可靠、和高可用的海量日志聚合的系统,就是一个数据采集工具。支持在系统中定制各类数据发送方,用于收集数据;同时,Flume提供对数据进行简单处理,并写到各种数据接受方(可定制)的能力。

优点   
	当收集数据速度超过写入数据速度时  会自动做出调整保证两者之间平衡    
	管道是基于事务 保证了数据在传送和接收时的一致性    
	可靠 容错性高 可升级 易管理 支持多路径流量 多管道 接入接出流量  上下文路由

Flume的体系架构

在这里插入图片描述

  • 客户端 Client: 生产数据
  • 事件 Event : 一个数据单元 由消息头和消息体组成
  • 流 Flow: Event 事件从源头到目的地的抽象过程
  • 选择器 selector: 作用于源文件Source端 决定数据发往那个地方
  • 拦截器 interceptor: Flume允许使用拦截器拦截数据 作用于 源文件 和 目标地址
  • 代理 Agent : 一个独立的Flume进程,包含组件Source、 Channel、 Sink
  • 源文件Source :数据收集组件 (文件 路径 命令)
  • 管道 Channel:中转事件Event的一个临时存储,保存由Source组件传递过来的事件Event(内存 文件 数据表)
  • 目标地址Sink ;从Channel中读取并移除Event, 将Event传递到下一个代理Agent(文件 HDFS Flume 数据库)

组件详解

在这里插入图片描述

Agent 是一个进程  包含 源文件Source  管道Channel  目标地址Sink  是Flume最小运行单位

Source 接受客户端的数据输入 将数据封装成Event事件向Channel 传输
Channel 缓存 Source 传递的数据 
Sink    数据的输出方 根据需求从Channel 中拿event 输出到任意位置
interceptor  根据业务需求拦截指定的数据

Flume特性

复杂流动
	允许多个代理流向一个代理  或将事件流复用到一个或多个目的地

执行流程

1 Source 接受数据   传给Channel
2 Channel Processor加工器 处理Event  将Event传递给interceptor拦截器 链对 Event 进行过滤操作 
3 过滤完之后再把 Event 发送回 Channel Prodessor加工器
4 Channel Processor加工器 把 Event 发送给Channel selectors 判断是发往那个Channel 的
5 根据返回的结果,将Event发送到指定的Channel 
6 Sink 从 Channel 中拉去数据 发出去

Flume事务

推送事务流程:把批数据写入到临时缓冲区putList,检查Channel容量 够就写入 不够就回滚到putList
拉取事务流程:数据读取到临时缓冲区takeList 检查数据是否发送成功 成功就移除 不成功回滚到Channel
可靠		只有当sink接收到,数据落地完成的信息之后,才会将数据从通道中删除
可恢复		当数据丢失 可从磁盘中 找回数据

Flume使用

启动   netcat2logger.conf
flume-ng agent -n a1 -c options/ -f netcat2logger.conf -Dflume.root.logger=INFO,console
向6666端口 输入数据  telnet localhost  6666

本图文内容来源于网友网络收集整理提供,作为学习参考使用,版权属于原作者。
THE END
分享
二维码
< <上一篇
下一篇>>