DataWareHouse

数据仓库概念

Posted by Jackson on 2017-09-15

数据仓库的分层不是越多越好，合理的层次设计，以及计算成本 和人力成本的平衡，是一个好的数仓架构的表现。

数据仓库

数据仓库，英文名称为Data Warehouse，可简写为DW或DWH。

数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合，它是单个数据存储，出于分析性报告和决策支持目的而创建，为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。

数据分为log类型(insert) db关系型(insert update delete)两种类型

作用：挖掘有效价值 report(静态报表 动态报表 运营)、实时大屏、对其他业务系统提供指标计算(智能分单 包装方案智能推荐)、钉钉应用(IDSS)，提供企业决策。

底层存储只需要：各仓库各个供应商每小时订单量

1
2
3
4
B01 供应商1 2017-10-01 00   1000
B02 供应商2 2017-10-01 00   2000
B01 供应商1 2017-10-01 01   3000
B01 供应商1 2017-10-02 00   3000

一般存储 只存储最小粒度的多维汇总数据

根据每小时的可以计算出每天，每月的数据量

数据集市

数据集市(Data Mart) ，也叫数据市场，数据集市就是满足特定的部门或者用户的需求，按照多维的方式进行存储，包括定义维度、需要计算的指标、维度的层次等，生成面向决策分析需求的数据立方体。从范围上来说，数据是从企业范围的数据库、数据仓库，或者是更加专业的数据仓库中抽取出来的，在分析、内容、表现，以及易用方面。数据中心的用户希望数据是由他们熟悉的术语表现的。

数据集市说白了就是数据仓库的一个子集

数据仓库和数据集市的区别：

数据仓库 数据集市
企业级别 部门级别
大量的全的数据 仅自己的数据

数仓分层

ODS(operation data store) 原始数据层 存放原始数据 不做任何的处理

DWD/DWI(data warehouse detail) 结构和粒度与ODS层是一致的，只做对ODS层数据进行清洗(脏数据 空值) 拉链表 脱敏 手机号 银行卡 密码(mysql加密)

DWS(data warehouse service) 以DWD层为基础 进行轻度汇总 宽表(join)

ADS/APP/domain域表(application data store) 按主题提供统计数据(group计算 少量可能做join计算取决于宽表没有你想要的字段)

命名规范

表的前缀: ods dwd(fact dim) dws ads
对于同一个含义的字段名称 ，在dws层的各表设计为统一的
订单号orderno orderid id,统一为orderno
创建时间createtime cretime ctime create_time。。。不统一，可以统一命名为==>createtime

为什么要分层？

复杂问题简单化: 将一个超级复杂的任务进行分解成多个步骤来完成，每一层只处理单一的步骤，比较简单，方便定位问题

减少重复开发：规范好数仓的分层，通过中间层的数据，能够减少重复计算，增加一次计算的复用。

隔离原始数据: 数据的敏感，使得真实的数据 和统计的数据 分离

数据仓库的分层不是越多越好，合理的层次设计，以及计算成本 和人力成本的平衡，是一个好的数仓架构的表现。

主表明细表设计

订单全表

订单主表+明细表

订单主表+明细表+商品表 生产上 上游MySQL的设计

mysql: --> hive ods层+dwd层 --》hive dws层
orderinfo orderinfo order
orderitems orderitems

业务表建表规范

加上createtime字段
加上updatetime字段

比如12-11 号需要抽取12-10号整天的数据
select * from t where createtime>='2019-12-10 00:00:00’
and createtime<‘2019-12-11 00:00:00’;

里面的参数可以写成shell变量动态传入

抽取的模式是抽取T + 1 天的数据，也就是今天抽取前一天的数据
我们增加的updatetime字段不会影响业务，这个是由数据库自己维护的，不需要变更上游

1
2
3
alter table xxxx
add column updatetime timestamp not null default current_timestamp 
on update current_timestamp;

修改表字段的方式：

  1. QA环境 ：主 第一层MySQL修改
  2. mysql单节点 主 写–》mysql 从节点 读----》mysql 从从节点加上updatetime
  3. cretaetime 每天 先把hive删除干净 全量
  4. binlog文件 --》canal、maxwell–》kafka–>flume–>hive/hdfs 伪实时
    binlog文件 --》canal、maxwell–》kafka–>spark/flink–>hbase 实时

数据建模

数据建模就是规划表结构，如果上游的表设计时候很规范，下游处理会相对轻松

fact表(事实表): 事实产生的 比如订单表
dim表(维度表): 时间维表(数据不变化) 供应商商家维表 仓库维表(缓慢变化)

维度建模

1.星型模型

一个fact事实表，多个dim表
额外：变态版星型模型(head事实表 + item事实表–>fact_depotitems)

此种设计中数据是有冗余的。以存储空间为代价，降低维度表连接数，提高性能。
简单，高度并行化，join的操作效率是很低的。

比如商品表，存在:
商品名称 第一类别 第二类别
A果 新鲜水果 热带鲜果
B果 新鲜水果 热带鲜果

2.雪花模型

一个fact事实表，多个dim表
是星型模型的扩展，不同的是维度表被规划化，进一步分解到附加表里
维度表设计符合3NF，规范化，有效降低数据冗余。
但是性能差。复杂，并行度低

商品名称 类别ID
A果 25
B果 25

子父表
类别ID 名称 父ID
25 热带鲜果 18
25 热带鲜果 18
18 新鲜水果 -1
18 新鲜水果 -1

3.星座模型

是星型模型延伸的， 是基于多个事实表，而且共享维度信息。

参考星型模型，但是性能：
多个事实表，共享维度表，业务复杂，开发复杂，性能不高

降维 ：商品+商品类别表—》商品表




FEATURED TAGS
DataWareHouse
FRIENDS