数仓理论建模

数仓理论建模

数据仓库

数据仓库是一个面向主题的、集成的、非易失的且随时间变化的数据集合

数仓的使用

1. 结构复杂

   业务数据库通常是根据业务操作的需要进行设计的，遵循3NF范式，尽可能减少数据冗余。这就造成表与表之间关系错综复杂。在分析业务状况时，储存业务数据的表，与储存想要分析的角度表，很可能不会直接关联，而是需要通过多层关联来达到，这为分析增加了很大的复杂度。
   举例：想要从门店的地域分布来分析用户还款情况。基本的还款数据在订单细节表里，各种杂项信息在订单表里，门店信息在门店表里，地域信息在地域表里，这就意味着我们需要把这四张表关联起来，才能按门店地域来分析用户的还款情况。
   此外，随着NoSQL数据库的进一步发展，有许多数据储存在诸如MongoDB等NoSQL数据库中，另外一些通用信息，如节假日等，通常也不会在数据库中有记录，而是以文本文件的形式储存。多种多样的数据储存方式，也给取数带来了困难，没法简单地用一条SQL完成数据查询。如果能把这些数据都整合到一个数据库里，比如构造一张节假日表。这样就能很方便地完成数据查询，从而提高分析效率。

2. 数据脏乱

   因为业务数据库会接受大量用户的输入，如果业务系统没有做好足够的数据校验，就会产生一些错误数据，比如不合法的身份证号，或者不应存在的Null值，空字符串等。

3. 理解困难

   业务数据库中存在大量语义不明的操作代码，比如各种状态的代码，地理位置的代码等等，在不同业务中的同一名词可能还有不同的叫法。

   这些情况都是为了方便业务操作和开发而出现的，但却给我们分析数据造成了很大负担。各种操作代码必须要查阅文档，如果操作代码较多，还需要了解储存它的表。来自不同业务数据源的同义异名的数据更是需要翻阅多份文档。

4. 缺少历史

   出于节约空间的考虑，业务数据库通常不会记录状态流变历史，这就使得某些基于流变历史的分析无法进行。比如想要分析从用户申请到最终放款整个过程中，各个环节的速度和转化率，没有流变历史就很难完成。

5. 大规模查询缓慢

   当业务数据量较大时，查询就会变得缓慢。尤其需要同时关联好几张大表，比如还款表关联订单表再关联用户表，这个体量就非常巨大，查询速度非常慢。美好的青春都浪费在了等待查询结果上，真是令人叹息。

   主题

   面向主题

   主题（Subject）

   将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念
   每一个主题基本对应一个宏观的分析领域
   例如“销售分析”就是一个分析领域，那么这个数据仓库应用的主题就是“销售分析”

   提取主题

   采购子系统：
   订单（订单号，供应商号，总金额，日期）
   订单细则（订单号，商品号，类别，单价，数量）
   供应商（供应商号，供应商名，地址，电话）
   
   销售子系统：
   顾客（顾客号，姓名，性别，年龄，文化程度，地址，电话）
   销售（员工号，顾客号，商品号，数量，单价，日期）
   
   库存管理子系统：
   领料单（领料单号，领料人，商品号，数量，日期）
   进料单（进料单号，订单号，进料人，收料人，日期）
   库存（商品号，库房号，库存量，日期）
   库房（库房号，仓库管理员，地点，库存商品描述）
   
   人事管理子系统：
   员工（员工号，姓名，性别，年龄，文化程度，部门号）
   部门（部门号，部门名称，部门主管，电话）
   
   主题一：顾客
   固有信息：顾客号，姓名，性别，年龄，文化程度，地址，电话
   购物信息：顾客号，商品号，单价，数量，金额，日期，...
   
   主题二：供应商
   固有信息：供应商号，供应商名，地址，电话
   供应商品信息：订单号，供应商号，总金额，日期
   主题三：商品
   固有信息：商品号，商品名，类别，颜色，尺寸，型号
   采购信息：商品号，供应商号，日期，采购价格，采购量
   库存信息：商品号，库房号，库存量，日期
   销售信息：顾客号，商品号，数量，单价，日期
   主题四：订单
   固有信息：订单号，员工号，顾客号，商品号，数量，单价，日期
    员工信息：员工号，姓名，性别，年龄，文化程度，部门号
   顾客信息：顾客号，姓名，性别，年龄，文化程度，地址，电话
   商品信息：商品号，商品名，类别，颜色，尺寸，型号
   

集成

集成性是指数据仓库中数据必须是一致的

1. 数据仓库的数据是从原有的分散的多个数据库、数据文件和数据段中抽取来的
2. 数据来源可能既有内部数据又有外部数据
   例如F/M，0/1，A/B

集成方法：统一（消除不一致），综合（对原有数据进行综合和计算）

非易失（非人为因素）

数据仓库中的数据是经过抽取而形成的分析型数据

• 不具有原始性
• 主要供企业决策分析之用
• 执行的主要是‘查询’操作，一般情况下不执行‘更新’操作
• 一个稳定的数据环境也有利于数据分析操作和决策的制订

随时间变化（人为删除）

数据仓库以维的形式对数据进行组织，时间维是数据仓库中很重要的一个维度

• 不断增加新的数据内容
• 不断删去旧的数据内容
• 更新与时间有关的综合数据

数据仓库和数据库的区别

• 数据库是为捕获和存储数据而设计
• 数据仓库是为分析数据而设计

** **	数据库	数据仓库
本质	数据的集合	数据的集合
定位	事务处理OLTP	数据分析OLAP
面向群体	前端用户	管理人员
操作	增删改查	查询
数据粒度	事件记录	维度
数据粒度	事件记录	维度

OLTP和OLAP的区别

• On-Line Transaction Processing 联机事务处理OLTP
• OLTP是传统的关系型数据库的主要应用

对比属性	OLTP	OLAP
读特性	每次查询只返回少量记录	对大量记录进行汇总
写特性	随机、低延时写入用户的输入	批量导入
使用场景	用户，Java EE项目	内部分析师，为决策提供支持
数据表征	最新数据状态	随时间变化的历史状态
数据规模	GB	TB到PB

数据仓库的架构

Inmon架构

Kimball架构

混合型架构

数据仓库的解决方案

• 数据采集
  Flume，Sqoop，Logstash，Datax

  数据ETL（清洗）

  • 抽取（Extract）
    从操作型数据源获取数据

  • 转换（Transform）
    转换数据，使之转变为适用于查询和分析的形式和结构

  • 装载（Load）
    将转换后的数据导入到最终的目标数据仓库

  • 工具

    Oracle：OWB和ODI
    微软：SQL Server Integration Services
    SAP：Data Integrator
    IBM：InfoSphere DataStage、Informatica
    Pentaho：Kettle

• 数据存储
  MySQL，HDFS，HBase，Redis，MongoDB

• 数据计算
  Hive，Tez，Spark，Flink，Storm

• 数据可视化
  Tableau，Echarts，Superset，QuickBI，DataV

• 任务调度
  Oozie，Azkaban，Crontab

  数据转换
  1.统一数据编码: 比如性别字段, 有些是1和0, 有些使用"F"和"M表示", 我们需要给他统一一下
  2.预计算: 比如订单信息表里有"订单号, 员工号，顾客号，商品号，数量，单价，日期", 这里我们就可以将"数量×单价", 提前做好计算
  3.重新排序: 提高查询性能
  4.去重: 数据可能会有一些重复的, 会影响到后续的分析, 所以我们需要根据实际情况进行去重
  5.行列转置: lateral view explode 
  

数据仓库的建模

数据仓库模型构建

选择业务流程

1. 确认哪些业务处理流程是数据仓库应该覆盖的
   例如：了解和分析一个零售店的销售情况
2. 记录方式
   • 使用纯文本
   • 使用业务流程建模标注（BPMN）方法
   • 使用同一建模语言（UML）

声明粒度

1. 用于确定事实中表示的是什么
   例如：一个零售店的顾客在购物小票上的一个购买条目
2. 选择维度和事实前必须声明粒度
3. 建议从原始粒度数据开始设计
   原始记录能够满足无法预期的用户查询
4. 不同的事实可以有不同的粒度

确认维度

1. 说明了事实表的数据是从哪里采集来的
2. 典型的维度都是名词
   例如：日期、商店、库存等
3. 维度表存储了某一维度的所有相关数据
   例如：日期维度应该包括年、季度、月、周、日等数据

确认事实

1. 识别数字化的度量，构成事实表的记录
2. 和系统的业务用户密切相关
3. 大部分事实表的度量都是数字类型的
   • 可累加，可计算
   • 例如：成本、数量、金额

星型模型

中间一张事实表，周围一圈维度表构成

优点
简化查询
简化业务报表逻辑
获得查询性能
快速聚合
便于向立方体提供数据
缺点
不能保证数据完整性
对于分析需求来说不够灵活

雪花模型

中间一张事实表，周围多层维度表构成

优点
一些OLAP多维数据库建模工具专为雪花模型进行了优化
规范化的维度属性节省存储空间
缺点
维度属性规范化增加了查询的连接操作和复杂度
不确保数据完整性

星座表

两张事实表通过一张维度表关联