数据仓库和建模

原创已于 2022-10-17 10:48:52 修改 · 2.6k 阅读

40 ·

CC 4.0 BY-SA版权

文章标签：

#大数据 #数据仓库 #数据仓库建模

于 2019-07-04 18:11:36 首次发布

大数据专栏收录该内容

4 篇文章

订阅专栏

一、数据库和数据仓库

1、数据库：OLTP（on-line transcation processing），注重：响应实时，可靠性（事务）。遵循3范式。主要有mysql，oracle等
2、数据仓库：OLAP（online analyze procss）。注重：分析和整合分析决策。通常反范式设计，以空间换时间。主要有hive。
数据仓库的目标是实现集成、稳定、反映历史变化有组织有结构的面向主题的存储数据的集合。
汇总所以的数据，为各个部门提供统一的规范的数据出口
特征：

面向主题：汇总所以的数据，针对某个主题
集成性：数据口径一致性（数据字典解释一致，比如男女、M/F）
稳定的：不会删除和更新，只会增加
变化的：历史版本也会保存

二、数仓的分层

大致可以分为4层，企业可根据实际情况调整层次。

ODS（Operational Data Store）操作数据存储层。保存的是原始业务数据库/行为数据，数据结构和数据库保持一致，通常遵循第三范式，采用ER建模
DWD（Data Warehouse Detail）数据明细层。对ODS层数据进行数据清洗、脱敏、规范化、整合，把脏数据、垃圾数据、规范不一致的、状态定义不一致的、命名不规范的数据处理掉。大多数是维度建模，可分为事实表和维度表，事实表通常会简单的宽化（维度退化）
DWS（Data Warehouse service）服务数据层/公共汇总层。对DWD的数据进行轻度汇总，周期粒度包括日、周、历史等。采用维度建模，这边事实表会建更大的宽表减少join的使用。能够满足80%的指标需求。
DM（Data market）数据集市层。面向特定的主题（通常通过部门或者业务切分），做汇总报表和指标的统计信息；使用维度建模

三、数据仓库技术架构

总体架构：
在这里插入图片描述

3.1.数据采集

数据源主要包括：

业务数据：如订单数据，用户数据。
行为数据：如用户访问记录，停留页面时间等。
其他文件数据：第三方的文件数据等。

3.1.1 业务数据

业务数据通常在RDB中，通过RDB–>同步工具–>数据仓库的方式。
同步工具有：datax，sqoop，kettle。

datax：有reader writer的json配置
优点：支持的数据源广泛，流量控制
缺点：单节点运作，无页面操作
Sqoop：采用Sqoop1的方式
优点：基于map的分布式同步
缺点：RDBMS->HDFS、HDFS->RDBMS 类型支持的少，但是够用了
kettle
优点：可视化界面，易操作
缺点：分布式的吗（待确认）

3.1.1 行为数据

行为数据通常在log中或需要埋点。通过客服端/服务端埋点–>log日志–>采集工具–>数据通道–>数据仓库
采集日志工具有：flume、logstash 都很占资源。
行为埋点：
使用CID和UID做匹配，只有在重新登录、重新注册的时候才会切换cid；通过uid打通不同设备
有app埋点和服务端埋点；属性分为共有属性和私有属性

3.1.1 其他文件数据

通过scp，ftp或者文件上传、kettle同步解析离线同步到数据仓库。

3.2.数据通道

使用kafka，能够起到解耦、消峰的作用。单节点吞吐量很高。且数据不会丢失。

3.3.数据存储

hive 高延迟。适合离线。有行数存储和列式存储。列式存储能够有更高的压缩比，针对少量列查询有更好的新能，通常采用parquet列出存储，配合使用Snappy压缩
hbase 低延迟列式存储通常用于实时计算

3.4.计算引擎

MR < sparkCore < sparksql
我们采用的hive on spark，sparkcore

3.5.系统调度

Oozie：重量级，功能全面，基于xml配置，通常封装封装web页面；监控hive等依赖hive等的版本
Azkaban：轻量级

四、数据仓库建模理论

建模的理论：数据仓库建模的目标是通过建模的方法更好的组织、存储数据，以便在性能、成本、效率和数据质量之间找到最佳平衡点。

4.1.数据库3范式

为了减少数据冗余，尽量让每个数据只出现一次，保证数据一致性；获取数据时通过 join 拼接出最后的数据

4.1.1 函数依赖概念

函数依赖：若x确定则y也确定，则称y函数依赖于x
完全函数依赖：若y函数依赖于x，且y不函数依赖于x的真子集，则y完全函数依赖于x
部分函数依赖：若y函数依赖于x，但y不完全函数依赖于x，则y部分函数依赖于x
传递函数依赖：若z函数依赖于y，且y函数依赖于x，则z传递函数依赖于x

4.1.2 3范式

1NF：数据表中的字段不能再切割了，是原子的；若不符合，则把表示多个含义的一个字段拆分成多个字段
2NF：在1NF基础上，字段都完全函数依赖于主键，没有部分函数依赖的关系；若不符合，则把部分函数依赖的关系拆分出来，单独一张表
3NF：在2NF的基础上，字段都完全依赖于主键，不能有传递依赖的关系；若不符合，则把传递依赖关系拆分出来，单独一张表

4.2.ER建模

ER：entity-relation 实体-关系-属性，主要面对OLTP

实体：客观存在的主体使用矩形表示
属性：对主体的描述、修饰使用椭圆形表示
关系：实体或实体的物理事件使用菱形表示

对照关系：实体和实体或者实体和关系之间的对账关系，1对1，m对n。
举例：学生选课；实体：学生，课程；关系：选课
在这里插入图片描述
此建模不适合数据仓库建模，实体太多，需要分析所以的实体和之间的关系，大系统比较复杂，难以分析。

4.3.维度建模

分为维度表和事实表，主要面向分析OLAP 。

4.3.1 事实表

在现实世界中，每一个操作型事件，基本都是发生在实体之间的，伴随着这种操作事件的发生，会产生可度量的值，而这个过程就产生了一个事实表，存储了每一个可度量的事件。
用来存储事实的度量（measure）及指向各个维的外键值；维度表主键、度量数据、事件描述信息
举例：下单
订单表：（维度表主键）时间外建，用户外建，商品外键，（度量数据）下单数量、价格、（事件描述信息）状态、付款时间

4.3.2 维度表

每个维度表都包含单一的主键列。维度表的主键可以作为与之关联的任何事实表的外键，当然，维度表行的描述环境应与事实表行完全对应。通常为实体
用来保存该维的元数据，即维的描述信息，包括维的层次及成员类别等；
举例：下单
用户表，商品表，时间区域信息

4.3.3 举例

具体实例：
1.背景
某电商平台，经常需要对订单进行分析，以某宝的购物订单为例，以维度建模的方式设计该模型。
2.事实表与维度表的划分
事实表为订单表、子订单表，维度包括商品维度、用户维度、商家维度、区域维度、时间维度。
3.事实表分析
订单中包含的度量：商品件数、总金额、总减免金额；描述性属性：下单时间、付款时间、订单状态等；
子订单包含度量：商品ID、单价、减免金额；描述性属性：加入购物车时间、下单时间、付款时间、状态；
4.维度表分析
商品维度：商品 ID、商品名称、商品品类、单价、颜色、尺寸、生产商等；
用户维度：用户 ID、姓名、性别、生日、职业、信用值、收货地址等；
时间维度：日期 ID、日期、周几、是否周末、是否假期等；
区域维度：区域 ID，县/区、县/区 ID、市、市 ID、省、省 ID；
我们往往会避免事实表之间产生关系；子订单中会冗余主订单的用户id，区域id，时间id
在这里插入图片描述

4.3.4 星型模型和雪花模型

星型模型：一个事实表关联多个维度表，一个维度表扁平的设计，反范式减少join，减少MR
雪花模型：一个事实表关联多个维度表，维度表也会关联其他维度表，符合3范式设计
星座模型：多个事实表共用了维度表，组成了大的星座模型

模型的选择：尽量选择星型模型，用空间换时间，通常我们的系统里面都是星座模型
建模的方式：
1、完全按照维度标准建模
2、将常用字段做事实表，不常用作为维度表
3、维度退化（降维）：上面2个相结合，将维度表中经常使用的字段放到事实表中

五、维度建模方法

5.1.同步数据策略

全量同步：
适合数据量小的，如果关注状态变更（行的属性值有变动，如果订单状态），一天一个分区；
增量同步：
针对表数据量比较大的，以ID/CreateTime或者updateTime为标记同步

无状态：每天同步增量数据，已ID/CreateTime作为每天同步的切割标志。
有状态：需要关注状态变化的。抽取昨天有更新的表记录，和前天的全量数据，做拉链表，通过starttime和endTime做分割

5.1.维度表设计

1、代理键：代理键是由数据仓库处理过程中产生的、与业务本身无关的、唯一标识维度表中一条记录并充当维度表主键的列，也是描述维度表与事实表关系的纽带。可以是业务主键，也可以是专门的代理键；在合并多种维度出现相同业务id或拉链表时使用
2、稳定维度：属性不会变化的维表；时间维度、区域维度；全量同步/增量
3、缓慢渐变维：维度属性会随着时间发生变化，变化速度比较缓慢，这种维度数据通常称作缓慢渐变维；比如用户维度：修改用户收件地址、用户昵称等

每天全量快照：适合数据量小的
增加历史值的字段，一般不使用
采用拉链表：一个原始记录再拉链表中有多条记录，通过startTIme和endtime来区分，这样原始业务id会重复，需要增加额外的代理主键；事实表中存代理键，在事实表新增数据时，需要通过原来的主键，通过time取到代理主键

5.2.事实表设计

增量同步

无状态：增量
有状态且需要记录：拉链表

全量快照

5.2.1 明细事实表

来自dwd层，优化说明
1、数据降维：将维度表中的常用字段放到事实表中
2、独立维度的选择：维度之间可以合并，把不是重点关注的维度合并到其他维度：滴滴下单。用户信息、司机信息、汽车信息。汽车维度可以合并到司机信息里面
3、事实表中不一定有度量信息，比如信息审核表，没有度量信息

设计方案
1、单事件事实表：每个事件一个表
2、流程事件表：一个流程一个表，可能包括多个事件
举例：滴滴打车：单事件：下单接单跑单支付评价
单事件：
优点：接近于无状态事实表，流程清晰，更方便跟踪业务流程细节数据，针对特殊的业务分析场景比较方便和灵活，数据处理上也更加灵活；
缺点：想要分析整个行为不够直观，join太多
流程事实表：
优点：很直观看到结果，适合大多数应用场景，比较少的join
缺点：缺失细节，特殊场景的分析不够灵活
可结合2中设计，一般都有。