大数据-数据仓库（原理+实战）

1、简介

诞生原因：历史数据积存+企业分析数据需要（统一，不用建立多个数据抽取系统而且可以保证数据的一致性）
data warehose DW
数据集合（面向主题，集成，非易失，时变性）
不允许修改

数据库	数据仓库
OLTP 在线事务处理 随机读取 注重冗余，范式规范 基于ER模型，面向应用 GB-TB	OLAP 在线分析 批量读写 注重数据整合，引入冗余，反范式 基于星形/雪花，面向主题 >=TB

	传统数据仓库	大数据数据仓库
定义	多个关系型数据库组成MPP集群（大规模并行处理），一个数据多个节点，结果是汇总	分布式SQL引擎（SQL向大数据的转换）-大数据计算引擎-分布式文件系统
优缺点	扩展性有限： 需要用到数据交换，要用高速网络，限制节点上线 分库分表也存在上限，力度越细，性能越差 热点问题： 如果高频访问数据只存在了一个节点，会容易出问题	可扩展：文件系统，把结构数据变成文件，很粗犷，不细分，利于扩展性 解决热点：对数据进行备份，备份三份，分发任务的时候可以选择一个空闲的数据节点。 问题在于SQL支持率较低，缺少事务支持，数据量较小的时候慢。
两个架构区别	单机数据库节点组成集群 非共享，每个节点有独立的磁盘存储和内存系统，不关心其他节点。但是只能作为一个整体去提供服务。 通过专用网络连接，速度很快。架构上遵从数据一致性（C）事务、然后A可用性、然后P分区容错性。 所以更注重锁、事务啥的。太精细了，只适合中等的。 缺陷：数据存储不透明，分配的时候用的是HASH,但是查询时候所有节点都进行。扩展性问题，单个节点一定成为系统的短板。随着集群增大，节点故障率会越来越高。	也称为批处理、Hadoop 场地自治，可以单独运行局部应用。数据是共享的。计算的时候，访问公共存储系统，找到位置。 通过局域网、广域网，所以在运算的时候要减少数据移动。 优先考虑P（分区容错性）、A可用性、C一致性。（数据存在多个节点上，备份。） 这两个合起来： 数据存储采用分布式架构中的公共存储，提高分区容错性，但是上层用MPP，减少运算延迟
常见产品	oracle：单个集群只能支持100左右，适合数据量不大的场景 DB2：半身是mpp架构，并不占优势。 teradata：商业数据库，一体机，自带数据引擎和查询 greeplum：开源。学习资料多。稳定性。易用性，性能比teradata差	hive：SQL转成MapReduce，也支持转spark。海量数据 hql sparkSQL：运行更快 hbase：底层是nosql 实时流处理 非结构化 ddl频繁 impala：数据查询，底层兼容hive，sparkSQL，Hbase。提供快速交互查询。一般作为数据仓库的查询接口 HAWQ：分布式+mpp TIDB：mpp+smp，nosql存储，同时用来做olap/oltp，更侧重oltp

2、数据仓库架构

• ETL：定期从业务数据库同步数据，sqoop、kattle、flume

本身对数据库的抽取不复杂，对于非结构化的比较复杂，比如日志，这个时候会清晰复杂

• ODS-操作数据源层：原始数据 ——非易失
• CDM-公共维度模型层：首先是DMD数据明细层，对原始数据统一规范后的数据

其次是数据汇总层DWS，对明细表进行汇总，汇成一个宽表，减少对其他表的join
对宽表可能进行数据建模，以模型形式储存

• ADS-数据应用层：主要注重查询速度，也被叫做数据集市。
  

ETL

这个部分占比60%-80%，之后数据进入ODS里

数据抽取	不同数据： 结构化——JDBC：很慢，IO问题，这种会选择在凌晨，有业务甚至不允许 结构化——数据库日志，直接采，不走IO 对于非/半结构——监听文件变动 更新最新 抽取方式： 全量同步（刚开始）+增量
数据转换	清洗 主要是非结构化、半结构 转换 标准化 字段、数据类型
数据加载	导入到目标源

工具：
sqoop 1.x 抽取 从业务数据库
kettle 可视化
datastage informatica/
kafka 消息队列 也提供ETL 数据抽取存在队列里面
半结构化：flume/logstash（日志监控）

ODS操作数据层

可以扩充字段，用来管理数据（update_type）
全量导入/增量导入（区分是新增还是修改的 与现在的ods表join一下 如果没有就是追加）
增量数据与历史数据做一个外连接，直接可以判断

DWD数据明细层

维度退化（时间/分类/地域），多张表汇总到一张表上

DWS数据汇总表

定期信息汇总表 脱离三范式

ADS数据应用层

存储数据结果，为不同业务场景提供借口
不同场景提供不同的 报表——kylin 并发查询-hbase 搜索检索-elastic search

3、建模

OLTP（在线事务处理）系统中，主要操作事随机读写，减少冗余，使用关系模型
OLAP（在线联机分析）复杂分析查询，分析/处理
ROLAP：关系模型构建
MOLAP：预先聚合计算，使用多维数组 依赖数仓产品选型
HOLAP：上面两者的集成 低层是关系型的 高层是多维矩阵型的 依赖数仓产品选型

ROLAP

主要是dws层
ER模型——datavalue模型——anchor模型——维度模型（最流行）
前三个是比较稳定
维度模型比较灵活
维度表/事实表，维度是对事实的一种组织
比如要查询今天的数据，时间就是维度 维度模型可以分为星型模型，中间是事实表，周围是维度表

• 星型模型标准的只有一层
• 多层维度——雪花模型
• 星座模型-事实表会共享一些维度表

宽表模型——维度冗余到事实表中

molap

其实不是靠人工 而是靠产品的选型 主要是ads层 主要是加快结果查询
cube模型 多维数组 是一个魔方
kylin；获取数据 进行加工 存到hbase.

多维分析

低层次到高层次——上卷roll-up
下钻——drill- down
切片选择某个维度，切块就是同时选了多个维度
旋转——维度方向的互换

4、最佳实践

表的分类

事实表 现实存在的业务对象

事务事实表：顺序追加 之前的数据不会修改。交易流水

周期快照事实表： 随着周期变化 需要计算。比如间隔周期内的度量统计
比如 年累计 每天统计（年初到现在） 周期+状态度量
相比事务事实表，计算量要小一点

累计快照事实表：不确定周期的度量统计
多个时间字段，记录关键时间点 ： 比如一个订单从下单到支付。
具体实现：
日期分区表：每天分区存储昨天全量数据与当天增量数据合并的结果，但是会有存储大量不更新的冷数据，对性能影响较大，适用于数据量少的情况
日期分区表：基于第一种方式进行更新，推测出数据最长的生命周期，来存储，周期外的冷数据就归档表。（比如推测订单的周期是一个月，一个月之前的数据就不要）。但是这方式也要存储多天的分区数据。
日期分区表：以业务实体的结束时间进行分区，每天的分区就放那个当天结束的数据，设置一个时间非常大的分区 9999-12-31，没结束的数据就在这个里面更新。这样的话数据量不会很大，无存储浪费。存在的问题就是业务可能没法标识业务实体的结束时间，可以用其他相关业务系统的结束标志来替代。

维度表 码表 直观上就是对数据进行筛选或者组织 进行聚合运算

拉链表：


可以看到300.5的这个 待支付这个状态1.3的时候结束了 变成已支付

ETL策略

全量同步

1、是数据初始化装载
jdbc
ogg cdc(开源免费）
2、由于给的就是全量表 就是只能全量同步

增量同步

结构化数据：数据库日志ogg ,cdc jdbc（使用创建时间啥的筛选 SQL）
非结构化/半结构化：抽取数据自带数据监控功能，可以实时监控变动的数据
增量数据和历史数据 outjoin 然后在历史数据里面更新 重写覆盖数据

任务调度

可以解决依赖关系，自动化
shell 启动数仓组件
java/mapreduce 数据清洗 自定义功能
sql ddl/数据处理
常见工具：azkaban/Oozie

5、项目实战

背景

背景：数据积存，需要分析，提供分析访问接口。
目标：完成用户复购率分析计算。一级品类下，品牌月单次复购率，多次复购率
表：
订单表/订单详情表（用户、商品ID）/商品表（商品ID，品牌ID、品类ID）/用户表/
商品一级分类/二级分类/三级分类（通过三级分类依次关联到一级分类）

架构

presto 快速查询

环境安装-略

虚拟机是oracle vm virtual
xshell-连接虚拟机
为啥要改IP地址？

虚拟机修改IP地址的背后原因包括：‌

1. 方便远程访问和连接：‌通过将IP地址设置为静态，‌可以方便地使用远程连接工具（‌如xshell）‌进行连接，‌避免了每次需要重新查询虚拟机IP地址的麻烦，‌提高了工作效率。‌
2. 满足多台虚拟机之间互联的需求：‌在某些情况下，‌可能需要多台虚拟机之间进行互联，‌通过设置静态IP地址，‌可以确保虚拟机之间的网络连接稳定性，‌满足特定的网络需求

用的脚本安装

项目开发

业务数据生成

create database mall
建表—商品分类数据插入——函数脚本——存储过程脚本

ETL数据导入

调用 sqoop ：swoop_import 脚本
两个参数：一个表名，一个时间
提交成mapreduce ，swoop 作业没有reduce，只有map
执行完成查看文件系统

创建ODS层，完成HDFS数据接入

建表：8张表 保持和原数据一致
ods_ddl
create database if not exists mall;
use mall;
drop table if exists ods order_info;
create table ods_order_info(

数据导入：传入参数 时间

DWD层分析

建表：5个表
改变一个商品分类表 扩充了品类

数据导入：
制定hive运行非严格
insert overwrite table “&APP”,dwd_order_info partition(dt)

特别注意商品表


可以看到hive中已经有了，注意不同的层命名方式不同

DWS层分析

注意汇聚成

建表：

数据导入：

ADS层分析

建表

数据导入
、
ADS数据导出
导出到mysql

数据导入
还用swoop sqoop_export.sh

Azkaban调度

import.job

ods.job

dwd.job
dws.job
ads.job
export.job
把这些文件压缩成mall-job
在三个节点上启动

在上面看到可以调度