数据仓库之各种表
在数仓项目中最大的感觉就是各种表各种分类,有丢丢搞坨坨不清,本文目的就是梳理一下数据仓库的各种“表”。
在此之前需要弄清楚OLTP和OLAP的恩恩怨怨,以及为什么要从OLTP到OLAP呢?
OLTP(On-Line Transaction Processing),操作型处理,也叫联机事务处理,也可以称面向交易的处理系统,它是针对具体业务在数据库联机的日常操作,通常对少数记录进行查询、修改。
OLAP(On-Line Analytical Processing),分析型处理,叫联机分析处理,一般针对某些主题的历史数据进行分析,支持管理决策。简单来说数据库和数据仓库的区别某种程度和意义上就是等同于OLTP和OLAP的区别。
也就是说如果OLTP它储存的是最新的数据,而数据仓库或者说OLAP它是基于历史数据进行分析的,因为不要忘了我们是分析过去的数据呀~~
那么为什么就是说要从OLTP到OLAP呢?
首先对于前期数据需求较少,不需要你去提供各种指标给各个业务部门,当时通常的做法就是说写脚本,从命令行输入参数,连接数据库,将需要的原始数据提取出来,在内存中计算数据,然后将结果写入一个专门存放统计结果的DB,最后再写一个PHP页面作为报表提供给需求方,那么后面就会出问题的说,你前面偷的懒后面是要还的!所以说随着需求的增加和精细化,问题变得棘手,而且还严重影响的开发效率,基于美团数据仓库搭建过程中的各种困难场景举例说明:比如说在这过程中有很多重复劳动和代码,比如连接数据库的代码,每个人都要写,各种写法不同,分布在很多地方,如果哪个DB的连接方法变更了,需要更改很多地方。中间数据缺失,中间计算结果不能共享。不同的人写报表,每人都可能要重算一次。很难管理和维护,程序语言五花八门,同一指标可以写多种统计方法,各种语言各种执行方式,缺少文档,其他人很难接手维护。数据的清洗和转换没有统一方法,比如,哪天是每月第一天或每周第几天这种需求,靠手工调用各种时间函数来计算,非常容易出错。不同数据源的数据很难综合使用, 比如一个数据需要使用主站的数据和合同系统的数据, 要把这些数据组织在一起就很麻烦。所以我们就需要OLAP。
那就是基于OLAP,才引出了后面一大堆表!
实体表
实体表,一般是指一个现实存在的业务对象,比如用户,商品,商家,销售员等等。大家可以自行想象假如你是老板,你会怎么登记你顾客的信息,那么这个顾客的信息,就是对应实体表里面的一条数据。。。
维度表
维度表,一般是指对应一些业务状态,编号的解释表。也是对事实的描述信息,也就是这件事到底是啥样。也可以称之为码表。每一张维表对应现实世界中的一个对象或者概念。