数据仓库理论篇与Flume

数据仓库理论篇

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

数据处理方式

数据仓库理论篇与Flume_第1张图片

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

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

OLTP(联机事物处理)

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

OLAP(联机分析处理)

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

数据建模

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

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

ER模型(关系)

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

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

遵循三范式:

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

维度建模

数据仓库理论篇与Flume_第2张图片

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

维度建模中的重要概念:

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

维度建模表分类

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

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

维度表

维度表概念

数据仓库理论篇与Flume_第3张图片

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

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

维度表设计原则

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

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

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

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

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

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

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

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

维度设计方法

数据仓库理论篇与Flume_第4张图片

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

维度设计高级主题

数据仓库理论篇与Flume_第5张图片

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

事实表

事实表概念

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

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

事实表设计原则

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

事实表设计方法

数据仓库理论篇与Flume_第6张图片

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

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

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

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

  • 声明粒度

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

  • 确定维度

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

  • 确定事实

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

  • 冗余维度

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

事实表分类

数据仓库理论篇与Flume_第7张图片

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

数据组织类型

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

数据仓库理论篇与Flume_第8张图片

星型模型

是一种多维的数据关系,它由一个事实表(Fact Table)和一组维表(Dimension Table)组成。每个维表都有一个维作为主键,所有这些维的主键组合成事实表的主键。事实表直接来连接维度表,维度表不再分;查询效率高,数据冗余性也高。
数据仓库理论篇与Flume_第9张图片

雪花模型

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

数据仓库理论篇与Flume_第10张图片

星座模型

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

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

数据仓库理论篇与Flume_第11张图片

维度建模步骤

  • 选择业务处理过程 > 声明粒度 > 选择维度 > 确定事实选
  • 数据仓库理论篇与Flume_第12张图片
  • 选择业务:选择感兴趣的业务线,如下单,支付,退款,活动 。
  • 声明粒度:一行代表信息:一条订单?一天的订单?一周的订单? 选择最小粒度
  • 确认维度:维度退化:谁 。 什么时间 什么地点
  • 确认事实:度量值:如个数,件数,金额

数据仓库分层

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

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

数据仓库理论篇与Flume_第13张图片

阿里数仓进化史

数据仓库理论篇与Flume_第14张图片

ETL

数据仓库理论篇与Flume_第15张图片

概念:

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

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

ETL工具

数据仓库理论篇与Flume_第16张图片

加载策略

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

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

常见概念描述

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

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

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

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

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

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

大数据架构

互联网大数据平台

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

数据仓库理论篇与Flume_第17张图片

Lambda架构

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

Kappa架构

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

Flume

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

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

Flume的体系架构

数据仓库理论篇与Flume_第18张图片

  • 客户端 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 数据库)

组件详解

数据仓库理论篇与Flume_第19张图片

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

你可能感兴趣的:(Flume,数据仓库,数据挖掘,人工智能)