数据仓库框架指导

目录
1, 数据仓库 DW
2, 数据库 vs 数据仓库
3，数据仓库历史
        3.1，历史
4，维度建模
        4.1，概念
        4.2，建模模型
        4.3，结构
        4.4，事实表
        4.5，维度表
        4.6，高级事实表技术
        4.7，高级维度表技术
        4.8，维度模型设计的四步骤
        4.8，分层设计
5, ETL子系统
        5.1, E 获取
        5.2, T 清洗及转换
        5.3, L 发布（加载）
        5.4, 管理
6， ETL开发指导
        6.1, 工具集
        6.2, 加载策略
                增量
                全量
                拉链
6.3, ETL 开发规范
        1、设计高层规划
        2、选择ETL工具
        3、开发默认策略【行业标准】
        4、按照目标表钻取数据
        5、历史数据填充维表
        6、事实表加载
        7、维度表增量处理
        8、事实表增量处理
        9、聚集表与OLAP加载
        10、ETL系统操作与自动化
6.4, ETL 实时数据
        7， 大数据分析
        7.1, 工具集
        7.2， 面向大数据管理的最佳实践
        7.3， 面向大数据结构的最佳实践
        7.4，应用于大数据的数据建模的最佳实践
        7.5，大数据的数据治理最佳实践

正文：

1, 数据仓库 DW

from Bill Inmon: 

数据仓库非常具体的原则，包括：

• 数据仓库是面向主题的（Subject-Oriented）、
• 集成的（Integrated）、
• 包含历史的（Time-variant）、
• 不可更新的（Nonvolatile）、
• 面向决策支持的（Decision Support）
• 面向全企业的（Enterprise Scope）
• 最明细的数据存储（Atomic Detail）
• 数据快照式的数据获取（Snap Shot Capture）

这些原则到现在仍然是指导数据仓库建设的最基本原则。

from Ralph Kimball: 

（1）方便存取信息，内容是直观性的，不仅针对开发人员

（2）一致的形式展示信息，同名的度量必须是同义的

（3）适应变化

（4）及时展现信息

（5）安全

（6）为决策制定提供权威和可信的基础

（7）只有业务群体接受了DW/BI才是成功的标志

2, 数据库 vs 数据仓库

OLAP 多维数据库

    更多的复杂安全选项，汇总数据提供更开放的接口（更丰富的分析能力）

    支持事务，周期性快照事实表

    处理累积快照事实表有所困难（方便支持缓慢变化维度类型2变化，但使用其他缓慢变化维度技术重写数据时，需要全部或部分重新处理数据）

数据库：传统关系型数据库的主要应用是OLTP(On-Line Transaction Processing)，主要是基本的、日常的事务处理，例如银行交易。主要用于业务类系统，主要供基层人员使用，进行一线业务操作。

数据仓库：数仓系统的主要应用主要是OLAP（On-Line Analytical Processing），支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。OLAP数据分析的目标是探索并挖掘数据价值，作为企业高层进行决策的参考。

功能	数据库	数据仓库
数据范围	当前状态数据	存储历史、完整、反应历史变化数据
数据变化	支持频繁的增删改查操作	可增加、查询，无更新、删除操作
应用场景	面向业务交易流程	面向分析、支持侧重决策分析
处理数据量	频繁、小批次、高并发、低延迟	非频繁、大批量、高吞吐、有延迟
设计理论	遵循数据库三范式、避免冗余	违范式、适当冗余
建模方式	ER实体关系建模（范式建模）	范式建模+维度建模

3，数据仓库历史

Inmon vs Kimball ： 3. Bill Inmon VS. Ralph Kimball | 记忆不靠谱

3.1，历史

（1）Bill Inmon 1991，自上而下 

  企业级数据仓库 EDW（规范化表）

（2）Ralph Kimball 1994，自底向上 

   数据集市（维度建模, 部门级） -> 数据仓库

源 → 后端： ETL（Extract, Transformation and Load） →  企业级数据仓库总线结构（星型模式或维度建模） -> 前端：（展现 → 商业智能应用）

ETL 交付：划分维度和事实  ->关注数据的质量、完整性、一致性

展现区：星型模式，or  OLAP多维数据库 ,数据时维变化的，原子聚集的，以业务过程为中心的，坚持使用总线结构的企业数据仓库

（3）Bill Inmon 辐射状企业信息工厂 CIF (Corporate Information Factory)     

  ETL -> EDW（规范化表） + 数据集市（维度建模, 部门级）

CIF的核心是将数仓架构划分为不同的层次以满足不同场景的需求，比如常见的ODS、DW、DM等，每层根据实际场景采用不同的建设方案。

（4）混合 辐射状架构 与 Kimball架构   

   ETL -> EDW（规范化表） -> ETL -> 企业级数据仓库总线结构（星型模式或维度建模）

4，维度建模

4.1，概念

（1）事实，度量，度量事件（物理世界度量事件：度量表对应行  1:1）

（2）数值类型，可加性事实

（3）事实表的粒度：事务、周期性快照、累积快照

事实表：两个或更多的外键→维度表，表示的是维度间的关系，描述的是物理世界的度量事件

（4）维度表 who what where when how why ....

（5）维度属性 or 事实表属性 ？

  描述，常量，约束行 or 参与计算的度量？比如产品的标价，经常发生变化，更可能是一种度量事实

  数字量，连续值的基本可以认为属于事实，而不太大的离散数字基本可以认为属于维度属性

4.2，建模模型

星型模型与雪花模型对比：

星型模型和雪花模型主要区别就是对维度表的拆分，对于雪花模型，维度表的设计更加规范，一般符合三范式设计;而星型模型，一般采用降维的操作，维度表设计不符合三范式设计，反规范化，利用冗余牺牲空间来避免模型过于复杂，提高易用性和分析效率。

星型模型因为数据的冗余所以很多统计查询不需要做外部的连接，因此一般情况下效率比雪花型模型要高。星型结构不用考虑很多正规化的因素，设计与实现都比较简单。

雪花型模型由于去除了冗余，有些统计就需要通过表的联接才能产生，所以效率不一定有星型模型高。正规化也是一种比较复杂的过程，相应的数据库结构设计、数据的ETL、以及后期的维护都要复杂一些。因此在冗余可以接受的前提下，数仓构建实际运用中星型模型使用更多，也更有效率。

此外，在数据仓库中星座模型也使用比较多，当多个事实表共用多张维度表时，就构成了星座模型。