诞生原因：历史数据积存+企业分析数据需要（统一，不用建立多个数据抽取系统而且可以保证数据的一致性）
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 |
本身对数据库的抽取不复杂，对于非结构化的比较复杂，比如日志，这个时候会清晰复杂
其次是数据汇总层DWS，对明细表进行汇总，汇成一个宽表，减少对其他表的join
对宽表可能进行数据建模，以模型形式储存
这个部分占比60%-80%，之后数据进入ODS里
| 数据抽取 | 不同数据： 结构化——JDBC：很慢，IO问题，这种会选择在凌晨，有业务甚至不允许 结构化——数据库日志，直接采，不走IO 对于非/半结构——监听文件变动 更新最新 抽取方式： 全量同步（刚开始）+增量 |
|---|---|
| 数据转换 | 清洗 主要是非结构化、半结构 转换 标准化 字段、数据类型 |
| 数据加载 | 导入到目标源 |
工具：
sqoop 1.x 抽取 从业务数据库
kettle 可视化
datastage informatica/
kafka 消息队列 也提供ETL 数据抽取存在队列里面
半结构化：flume/logstash（日志监控）
可以扩充字段，用来管理数据（update_type）
全量导入/增量导入（区分是新增还是修改的 与现在的ods表join一下 如果没有就是追加）
增量数据与历史数据做一个外连接，直接可以判断
维度退化（时间/分类/地域），多张表汇总到一张表上
定期信息汇总表 脱离三范式
存储数据结果，为不同业务场景提供借口
不同场景提供不同的 报表——kylin 并发查询-hbase 搜索检索-elastic search
OLTP（在线事务处理）系统中，主要操作事随机读写，减少冗余，使用关系模型
OLAP（在线联机分析）复杂分析查询，分析/处理
ROLAP：关系模型构建
MOLAP：预先聚合计算，使用多维数组 依赖数仓产品选型
HOLAP：上面两者的集成 低层是关系型的 高层是多维矩阵型的 依赖数仓产品选型
主要是dws层
ER模型——datavalue模型——anchor模型——维度模型（最流行）
前三个是比较稳定
维度模型比较灵活
维度表/事实表，维度是对事实的一种组织
比如要查询今天的数据，时间就是维度 维度模型可以分为星型模型，中间是事实表，周围是维度表
宽表模型——维度冗余到事实表中
其实不是靠人工 而是靠产品的选型 主要是ads层 主要是加快结果查询
cube模型 多维数组 是一个魔方
kylin；获取数据 进行加工 存到hbase.
低层次到高层次——上卷roll-up
下钻——drill- down
切片选择某个维度，切块就是同时选了多个维度
旋转——维度方向的互换
事实表 现实存在的业务对象
事务事实表：顺序追加 之前的数据不会修改。交易流水
周期快照事实表： 随着周期变化 需要计算。比如间隔周期内的度量统计
比如 年累计 每天统计（年初到现在） 周期+状态度量
相比事务事实表，计算量要小一点
累计快照事实表：不确定周期的度量统计
多个时间字段，记录关键时间点 ： 比如一个订单从下单到支付。
具体实现：
日期分区表：每天分区存储昨天全量数据与当天增量数据合并的结果，但是会有存储大量不更新的冷数据，对性能影响较大，适用于数据量少的情况
日期分区表：基于第一种方式进行更新，推测出数据最长的生命周期，来存储，周期外的冷数据就归档表。（比如推测订单的周期是一个月，一个月之前的数据就不要）。但是这方式也要存储多天的分区数据。
日期分区表：以业务实体的结束时间进行分区，每天的分区就放那个当天结束的数据，设置一个时间非常大的分区 9999-12-31，没结束的数据就在这个里面更新。这样的话数据量不会很大，无存储浪费。存在的问题就是业务可能没法标识业务实体的结束时间，可以用其他相关业务系统的结束标志来替代。
维度表 码表 直观上就是对数据进行筛选或者组织 进行聚合运算
拉链表：
1、是数据初始化装载
jdbc
ogg cdc(开源免费）
2、由于给的就是全量表 就是只能全量同步
结构化数据：数据库日志ogg ,cdc jdbc（使用创建时间啥的筛选 SQL）
非结构化/半结构化：抽取数据自带数据监控功能，可以实时监控变动的数据
增量数据和历史数据 outjoin 然后在历史数据里面更新 重写覆盖数据
可以解决依赖关系，自动化
shell 启动数仓组件
java/mapreduce 数据清洗 自定义功能
sql ddl/数据处理
常见工具：azkaban/Oozie
背景：数据积存，需要分析，提供分析访问接口。
目标：完成用户复购率分析计算。一级品类下，品牌月单次复购率，多次复购率
表：
订单表/订单详情表（用户、商品ID）/商品表（商品ID，品牌ID、品类ID）/用户表/
商品一级分类/二级分类/三级分类（通过三级分类依次关联到一级分类）
presto 快速查询
用的脚本安装
create database mall
建表—商品分类数据插入——函数脚本——存储过程脚本
调用 sqoop ：swoop_import 脚本
两个参数：一个表名，一个时间
提交成mapreduce ，swoop 作业没有reduce，只有map
执行完成查看文件系统
建表：8张表 保持和原数据一致
ods_ddl
create database if not exists mall;
use mall;
drop table if exists ods order_info;
create table ods_order_info(
建表：5个表
改变一个商品分类表 扩充了品类
注意汇聚成
建表：
数据导入：
建表
数据导入
、
ADS数据导出
导出到mysql
数据导入
还用swoop sqoop_export.sh
import.job
ods.job
dwd.job
dws.job
ads.job
export.job
把这些文件压缩成mall-job
在三个节点上启动
在上面看到可以调度