数据仓库理论篇

数据处理方式

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

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

OLTP（联机事物处理）

OLAP(联机分析处理)

数据建模

ER模型（关系）

维度建模

维度建模表分类

维度表

维度表概念

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

维度表设计原则

维度设计方法

维度设计高级主题

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

事实表

事实表概念

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

事实表设计原则

事实表设计方法

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

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

• 声明粒度

• 确定维度

• 确定事实

• 冗余维度

事实表分类

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

数据组织类型

星型模型

雪花模型

星座模型

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

维度建模步骤

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

数据仓库分层

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

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

阿里数仓进化史

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的体系架构

组件详解

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