数据仓库----持续更新

最新推荐文章于 2023-01-07 22:56:54 发布

豪横的皮皮虾

最新推荐文章于 2023-01-07 22:56:54 发布

阅读量633

点赞数 2

文章标签：数据仓库

本文链接：https://blog.csdn.net/weixin_39867854/article/details/105178830

版权

数据仓库的诞生

历史数据积存 —> 业务系统数据累计增多
企业数据分析需要 —> 数据分析为导向,减轻业务数据库的压力

数据仓库

面向主题、集成的、非易失且岁时间变化的数据集合
组织积累历史数据，使用分析方法（OLAP，数据分析）辅助决策，为管理提供数据支持

特点

面向主题：
用户行为表->支付表，商品表用户表，订单表整合成一个宽表
用户购买商品明细表->支付表，商品表用户表，订单表整合成一个宽表
集成：
数据来源不同系统，需要整合，需要ETL，标准化，数据治理
非易失：
保存的数据是一系列的历史快照表，不允许修改，只能查询，分析
时变性：
定期接收集成新数据，反应数据最新变化

数据仓库与数据库

传统数仓建设方案

由单机关系型数据库组成MPP（大规模并行处理）集群
优点：
兼容原有sql，学习成本低
问题：
扩展性有限：
依赖告诉网络支撑数据传输，分库分表方式（有限制）
热点问题：
数据分散不均匀

大数据数据仓库

利用大数据集群，分布式存储天然海量数据
sql转换为计算引擎，完后数据分析
移动计算而非移动数据 spark
解决扩展问题：
HDFS ：分布式文件系统，利用源数据还原成表结构数据，

问题
sql支持率问题，有些需要自定义函数
事务支持不全（面向分析，不关注这点）
数据量小时性能不好，任务转换分发汇总，时间处理场

MPP架构

单机数据库组成集群
非共享架构，每个节点独立存储和内存（自己算自己的，节点间通过高速网络传输，完成协同运算），依托于整体集群对外提供运算支持。
先考虑C一致性，其次A可用性，尽量做好P分区容错性（一般只能兼顾好两个）
架构优点：
运行方式精细（完整事务机制），延迟低，吞吐低
适合中等规模结构化数据
架构缺点
存储位置不明确（hash决定存放节点），在所有节点执行
并行计算，单个节点瓶颈成为整个系统的短板，容错性差
分布式事务的实现导致扩展性差

分布式架构

海量数据批处理
hadoop架构
场地自制，单独运行局部程序（移动计算），数据存储位置透明，计算资源与存储资源分离（hdfs。yarn，spark），共享数据
节点间通过局域网相连，网络开销大，尽量减少数据移动
优先考虑P分区容错性，然后A可用性，最后在考虑C一致性

MPP+ 分布式架构

存储：分布式架构中的公共存储（HDFS），提高分区容错性
上层：采用MPP，减少运算延迟

常见产品

传统数仓
oracle RAC 集群版本，商业数据库 100左右节点
DB2 DPF 集群版本，与IBM兼容性好
TeraData 一体机销售，自带数据引擎和查询工具
GreenPlum 开源基于postgreensql

大数据数仓
hive
spark sql
Hbase
Impala
HAWQ hadoop MPP+ 分布式架构
TIDB nosql oltp olap

架构

架构图

DWD 满足三范式存储
DWS 不满足三范式存储，宽表

ETL

数据源从业务数据库
结构化：
数据库 JDBC 链接数据库不推荐，分析数据库日志 wal 预写日志文件OGG，CDC
非结构化、半结构化
监听数据文件

出去方式
全量、增量

ETL工具

结构化工具
sqoop 1.X版本
kettle
Datastage 商业
Informatica 商业
kafka
非半结构化数据
flume
logstash Elastic家族产品

操作数据层ODS

与源业务系统数据一致，可增加字段进行数据管理（loadTime）
减小业务系统多次查询

全量导入
增量导入：
外连接&全覆盖方式（减少冗余）

数据明细层 DWD

对ODS数据进行清洗，标准化、维度退化（时间，分类，地域）数据尽量整合一张表
数据扔满足三范式，为分析运算做准备

数据汇总层 DWS

按主题进行计算汇总，存放便于分析的宽表
存储模型非三范式，注重数据聚合，复杂查询，处理性能更优

数据应用层 ADS

数据集市
存储分析结构，为不同场景提供接口，减轻数仓负担
数仓擅长数据分析，如直接开发业务查询接口，会增加负担
数据应用层

OLAP 在线数据处理

在线数据处理，主要操作随机读写
减少冗余，使用关系模型
满足三范式规则

OLAP 在线联机分析

复杂分析查询，关注数据整合，分析，处理能力
根据数据存储方式不同分为：
ROLAP：
使用关系模型创建，存储一般为RDBMS，关系型数据库
MOLAP：
预先聚合计算，使用多维数组的方式保存数据，加快查询分析
HOLAP：
混合架构，前两者集成，效率两者之间
加快数据分析能力

ROLAP 建模方式

ER
维度模型
data value
Anchor
建模方式

维度模型

表分为维度表、事实表
维度分为时间、分类、地域

星型模型

维度只有一层，分析性能最优

雪花模型

具有多层维度，比较接近三范式，设计较为灵活，性能差一些

星座模型

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

宽表模型

维度模型的衍生，适合join性能不佳的数仓产品
将维度冗余到事实表中，形成宽表，一次较少join操作

MOLAP

将数据进行预计算，并将结果整合到CUBE模型中，
CUBE以多维数组的形式，物化到存储系统中，加快后续查询
生成CUBE需要大量时间空间，维度预处理可能导致数据膨胀
CUBE 数据立方体
维度越多，计算越大
使用ADS层
kylin 开源计算能力依靠产品性能，数据存储到nosql Hbase数据库
Druid

OLAP多维分析

主要操作是复杂查询，可以多表关联，使用count sum、avg等聚合函数
对复杂查询做了直观定义，包括钻取、切片、切块、旋转

钻取

对维度不同层次分析，通过改变维度来变换分析粒度
钻取分为
上卷：低层次向高层次
下钻：高层次向低层次
一个维度

切片

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

切块

按照多维进行的切片成为切块
切片的基础上选择一个单一维度为切块

旋转

对维度方向的互换，类似于交换坐标轴上卷
三维选两维

维度建模中表的分类

事实表：
业务库中查询结果的核心数据（数字、价格等）
维度表：
业务状态、业务代码的解释表。也叫码表。通常使用维度表对事实表中的数据进行统计、聚合计算

事务事实表：
随着业务不断产生、一旦产生不会在变化，入交易流水出入库记录，操作日志，追加即可

周期快照事实表：
随着业务周期进行变化，完成间隔内的度量统计，如年季度累计
使用周期加状态的组合，如累计年订单，年是周期，订单是量度

累计快照事实表：
记录不确定周期的度量统计，完全覆盖一个事实表的生命周期，入订单状态表
通常有多个时间字段，用于记录生命周期的关键节点
只有一条记录，不对更新

累计快照事实表实现方式

方式一：
使用日期表分区，全量数据记录与昨天记录合并插入新增天分区
数据量大表膨胀，存储大量永远不更新的冷数据，性能有影响
适用于少量数据
方式二：
使用日期分区，基于方式一，推测数据生命周期，删除周期外的数据
需要保留多天，存储消耗依然很大
方案三：
使用时间分区表，也业务结束时间为分区，没天分区只存结束的数据。
在设计一个时间分区大的表，存未结束的数据，值更新未结束的数据。
数据全局只保存一份，性能好，无浪费
问题：业务结束时间更新不及时，或者丢失，可以使用其他业务结束标志的时间做替代。

拉链表

记录每条数据的生命周期，用于保留数据虽有的变更状态
将表数据的随机修改方式变为顺序追加
拉链表

数据抽取

全量同步
增量同步：
传统数据库可以采用merge方式（update+inser）
大数据平台不支持update，可采用全外连接+数据全量覆盖
如果担心更新出错，可采用分区，每天保存最新的全量数据，保留周期较短

任务调度

解决任务依赖关系
完成自动化定时执行
常用调度工具：
Azkaban
Oozie

数据仓库分层介绍

1、ODS原始数据层

ODS层保存所有操作数据，不对原始数据做任何处理。在业务系统和数据仓库之间形成一个隔离，源系统数据结构的变化不影响其他数据分层。减轻业务系统被反复抽取的压力，由ODS统一进行抽取和分发

ODS层数据要保留数据的原始性。根据源业务系统表的情况以增量或全量方式抽取数据
ODS层以流水表和快照表为主，按日期对数据进行分区保存，不使用拉链表；
ODS层的数据不做清洗和转换，数据的表结构和数据粒度与原业务系统保持一致

具体实现逻辑

大多是按照源头业务系统的分类方式而分类的
为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可，至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。

2、DWD数据明细层

DWD层的数据是经由ODS层数据经过清洗、转换后的明细数据，满足对标准化数据需求。如对NULL值处理，对数据字典解析，对日期格式转换，字段合并、脏数据处理等。

数据结构与ODS层一致，但可以对表结构进行裁剪和汇总等操作；对数据做清洗、转换；
DWD层的数据不一定要永久保存，具体保存周期视业务情况而定
更多地采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性

具体实现实现逻辑

该层一般保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。同时，为了提高数据明细层的易用性，该层会采用一些维度退化手法，将维度退化至事实表中，减少事实表和维表的关联。
在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性

3、DWS数据汇总层

按主题对数据进行抽象、归类，提供业务系统细节数据的长期沉淀。这一层是一些汇总后的宽表，是根据DWD层数据按照各种维度或多种维度组合，把需要查询的一些事实字段进行汇总统计。可以满足一些特定查询、数据挖掘应用，面向业务层面，根据需求进行汇总。

面向全局、数据整合；
存放最全的历史数据，业务发生变化时易于扩展，适应复杂的实际业务情况；
尽量减少数据访问时的计算量，优化表的关联。维度建模，星形模型、雪花模型、星座模型；
事实拉宽，度量预先计算，基本都是快照表。反规范化，有数据冗余。
汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工

具体实现逻辑

按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等
该层的数据表会相对比较少，一张表会涵盖比较多的业务内容，由于其字段较多，因此一般也会称该层的表为宽表。
如果直接从DWD或者ODS计算出宽表的统计指标，会存在计算量太大并且维度太少的问题，因此一般的做法是，在DWM层先计算出多个小的中间表，然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定，也可以去掉DWM这一层，只留DWS层，将所有的数据在放在DWS亦可。

4、AWS数据明细层

ADS应用层是根据业务需要，由DWD、DWS数据统计而出的结果，可以直接提供查询展现，或导入至Oracle等关系型数据库中使用。这一层的数据会面向特定的业务部门，不同的业务部门使用不同的数据，支持数据挖掘。

形式各式，主要按不同的业务需求来处理；
保持数据量小，定时刷新数据；
数据同步到不同的关系型数据库或hbase等其他数据库中。
提供最终数据，来满足业务人员、数据分析人员的数据需求
个性化指标加工：不公用性、复杂性（指数型、比值型、排名型指标）。
基于应用的数据组装：大宽表集市、横表转纵表、趋势指标串。

具体实现逻辑

主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用

维表层（Dimension）

高基数维度数据：一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
低基数维度数据：一般是配置表，比如枚举值对应的中文含义，或者日期维表。数据量可能是个位数或者几千几万。

设计原则

高内聚和低耦合——一个逻辑或者物理模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚和低耦合原则。主要从数据业务特性和访问特性两个角度来考虑：将业务相近或者相关、粒度相同的数据设计为一个逻辑或者物理模型；将高概率同时访问的数据放一起，将低概率同时访问的数据分开存储；
核心模型与扩展模型分离——建立核心模型与扩展模型体系，核心模型包括的字段支持常用的核心业务，扩展模型包括的字段支持个性化或少量应用的需要，不能让扩展模型的字段过度侵入核心模型，以免破坏核心模型的架构简洁性与可维护性。
公共处理逻辑下沉及单一——越是底层公用的处理逻辑越应该在数据调度依赖的底层进行封装与实现，不要让公用的处理逻辑暴露给应用层实现，不要让公共逻辑多处同时存在。
成本与性能平衡——适当的数据冗余可换取查询和刷新性能，不宜过度冗余与数据复制。
数据可回滚——处理逻辑不变，在不同时间多次运行数据结果确定不变。
一致性——具有相同含义的字段在不同表中的命名必须相同，必须使用规范定义中的名称。
命名清晰、可理解——表命名需清晰、一致，表名需易于消费者理解和使用。