数据仓库原理&实战（理论）

1. 数据仓库的诞生背景

     1.1 数据仓库诞生的原因

             *  历史数据积存

             *  企业数据分析需要

     1.2 历史数据积存

             *  历史数据使用频率低，堆积在业务库中，导致性能下降

     1.3 企业数据分析需要

             *  各个部门自己建立独立的数据抽取系统，导致数据不一致

2. 数据仓库概述

      2.1 数据仓库（Data Warehouse, DW）

             *  由数据仓库之父比尔·恩门（Bill Inmon）提出

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

             *  主要用于组织积累的历史数据，并使用分析方法（OLAP，数据分析）进行分析整理，进而辅助决策，为管理者，企业系统提供数据支持，构建商业智能

      2.2 数据仓库特点

​             *  面向主题：为数据分析提供服务，根据主题将原始数据集合在一起

             *  集成：原始数据来源于不同数据源，要整合成最终数据，需要经过抽取，清洗，转换的过程

             *  非易失：保存的数据是一系列历史快照，不允许呗修改，只允许通过工具进行查询，分析

             *  时变性：数据仓库会定期接受，集成新的数据，从而反映出数据的最新变化

      2.3 数据仓库 VS 数据库

             *  数据库面向事物设计，属于OLTP（在线事物处理），主要操作是随机读写；在设计时尽量避免冗余，采用符合范式规范来设计

             *  数据仓库是面向主题设计的，属于OLAP（在线分析处理）系统，主要操作是批量读写；关注数据整合，以及分析，处理性能；会有意引入冗余，采用反范式方式设计

	数据库	数据仓库
面向	事务	分析
数据类型	细节，业务	综合，清洗过的数据
数据特点	当前的，最新的	历史的，跨时间维护
目的	日常操作	长期信息需求，决策支持
设计模式	基于ER模型，面向应用	星型/雪花模型，面向主题
操作	读/写	大多为读
数据规模	GB/TB	>= TB

3. 数据仓库的技术实现

     3.1 传统数据仓库 VS 大数据数据仓库

            1.  传统数据仓库：由关系型数据组成MPP（大规模并行处理）；缺点是：扩展性有限，热点问题

            2.  大数据数据仓库：优势：扩展性，避免热点问题；缺点是：SQL支持率（已经不算问题了），事物支持

                        *  利用大数据天然的扩展性，完成海量数据的存放

                        *  将SQL转化为大数据计算引擎的任务，完成数据分析

4. MPP&分布式架构技术

     4.1 MPP架构

            *  传统数仓中常见的技术架构，将单机数据库节点组成集群，提升整体处理性能

            *  节点间为非共享架构（Share Nothing），每个节点都有独立的磁盘存储系统和内存系统

            *  每个数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供服务

            *  设计上优先考虑C（一致性），其次考虑A（可用性），尽量做好P（分区容错性）

            优点：  运算方式精细，延迟低，吞吐低

                         适合中等规模的结构化数据处理

            缺点：  存储位置不透明，通过Hash确定数据所在的物理节点，查询任务在所有节点均会执行

                         并行计算时，单节点瓶颈会成为整个系统短板，容错性差

                         分布式事物的实现导致扩展性降低

     4.2  分布式架构

             *  大数据常见的技术架构，也成为Hadoop架构/批处理架构

             *  各阶段实现场地自治（可以单独运行局部应用），数据在集群中全局透明共享

             *  每台节点通过局域网或广域网相连，节点间的通信开销比较大，在运算时致力减少数据移动

             *  优先考虑的是P（分区容错性），然后是A（可用性）， 最后再考虑C（一致性）

      4.3  MPP + 分布式架构

              *  数据存储采用分布式架构中的公共存储，提高分区容错性

              *  上层架构采用MPP，减少运算延迟 

5. 常见的数据仓库产品

      5.1  传统数据仓库：Oracle RAC，DB2，Teradata，Greenplum

      5.2  大数据数据仓库：Hive， Spark SQL，HBase， Impala，  HAWQ， TIDB

6. 数据仓库架构设计

     6.1  架构图

   

     6.2  ETL流程

             *  将数据从来源端经过抽取（extract），交互转换（transform），加载（load）至目的端的过程

             *  构建数据仓库的重要一环，用户从数据源抽取所需的数据，经过数据清洗，最终按照预先定义好的数据仓库模型，将数据加载到数据仓库中去

             *  ETL规则的设计和实施约占整个数据仓库搭建工作量的60%~ 80%

             6.2.1 数据抽取（extract）

                      *  抽取的数据源可以分为结构化数据，非结构化数据，半结构化数据

                      *  结构化数据一般采用JDBC，数据库日志方式，半结构化数据会监听文件变动

                      抽取方式：

                             *  数抽取方式有全量同步，增量同步两种方式

                             *  全量同步会将全部数据进行抽取，一般用于初始化数据装载

                             *  增量同步方式会检测数据的变动，抽取发生变动的数据，一般用于数据更新

             6.2.2 数据转换（transform）

                      *  数据转换要经历数据清洗和转换的两个阶段：

                         -- 数据清洗主要对出现的重复，多义，不完整，违反业务或逻辑规则等问题的数据进行统一的处理

                         -- 数据转换主要对数据进行标准化处理，进行字段，数据类型，数据定义的转换

                      *  结构化数据在转换过程中的逻辑比较简单，非结构和半结构化数据的转换比较复杂

             6.2.3 数据加载（Loading）

                      *  将最后处理完的数据导入到对应的目标源中

     6.3  数据积存之ODS层

             *  数据与原业务数据保持一致，可以增加字段来进行数据管理

             *  存储的历史数据是只可读的，提供业务系统查询使用

             *  业务系统对历史数据完成修改后，将update_type字段更新为update，追加到ODS中

             *  在离线数仓中，业务数据 定期通过ETL流程导入到ODS中，导入方式有全量、增量两种方式

                  -- 首次导入：全量

                  -- 增量导入：非首次导入，每次只导入新增，修改的数据，建议使用外链接&全覆盖的方式 

     6.4  数据分析之DW层

              6.4.1 数据明细层（DWD）

                       *  数据明细层对ODS层的数据进行清洗，标准化，维度退化（时间，分类，地域）

                       *  数据仍然满足3NF模型，为分析运算做准备

             6.4.2 数据汇总层（DWS）

                       *  数据汇总层的数据对数据明细层的数据按照分析主题进行计算汇总，存放便于分析的宽表

                       *  存储模型并非3NF，而是注重数据聚，复杂查询，处理性能更优的数仓模型，如维度模型

             6.4.3 数据应用层（ADS）

                       *  数据应用层也被成为数据集市

                       *  存储数据分析结果，为不同业务场景提供接口，减轻数据仓库的负担

                           -- 数据仓库擅长数据分析，直接开发业务查询接口，会加重其负担

7.  数仓建模

       7.1  基本概念

                7.1.1 OLTP系统建模方法

                         *  OLTP（在线事务处理）系统中，主要操作是随机读写

                         *  为保证数据一致性，减少冗余，常使用关系模型

                         *  在关系模型中，使用三范式规则来减少冗余

                7.1.2 OLAP（在线联机分析） 

                          *  主要作用是复杂分析查询，关注数据整合，以及分析，处理性能

                          *  OLAP根据数据存储的方式不同，又分为ROLAP，MOLAP，HOLAP

                7.1.3 OLAP系统分类

                          *  ROLAP（Relation OLAP，关系型OLAP）：使用关系模型构建，存储系统一般为RDBMS

                          *  MOLAP（Multidimensional OLAP，多维型OLAP）：预先聚合计算，使用多维数据的形式保存数据结果，加快查询分析时间

                          *  HOLAP（Hybrid OLAP，混合架构的OLAP）：ROLAP和MOLAP两者的集成；如底层是关系型的，高层是多维矩阵型的；查询效率高于ROLAP, 低于MOLAP

       7.2  ROLAP

                *  典型的数据仓库建模方法有ER模型，维度模型，Data Value，Anchor

                    -- ER模型：出发点是整合数据，为数据分析决策服务。需要全面的了解业务和数据。实施周期长。最建模人员能力要求高

                    -- 维度建模：为分析需求服务，更快的完成需求分析。具有较好大规模复杂查询相应性能。最流行的数仓建模模型，最经典

                    -- Data Value和 Anchor 略

                7.2.1 维度模型

                         *  维度模型中，表被分为维度表，事实表，维度是对事实的一种组织

                         *  维度一般包含分类，时间，地域等

                         *  维度模型分为星型模型（维度只有一层，分析性能最好），雪花模型（多层维度，比较灵活），星座模型（公用维度表，大型数据仓库的常态，与模型设计无关）

                             -- 宽表模型：是维度建模的衍生，适合join性能不佳的数据仓库产品

                             -- 宽表模型：将维度冗余到事实表中，形成宽表，以此减少join操作

                         *  维度模型建立后，方便对数据进行多维分析   

       7.3  MOLAP（偏向产品实现--Kylin）

                *  将数据进行与计算结果，并将聚合结果存储到CUBE模型中

                *  CUBE模型以多维数组的形式，物化到存储系统中，加快后续的查询

                *  生成CUBE需要大量的时间，空间，维度处理可能会导致数据膨胀

       7.4  OLAP多维分析

                *  OLAP主要操作是复杂查询，可以多表关联，使用Count，Sum，Avg等聚合函数

                *  OLAP对复杂查询操作做了直观的定义，包括钻取，切片，切块，旋转

                7.4.1  钻取
                          *  对维度不同层次的分析，通过改变维度的层次来变换分析的粒度

                          *  钻取包括上卷（Roll-up）、下钻（Drill-down）

                          *  上卷（Roll-up）：维度从低层次到高层次的切换，如：组-->村->镇->县->市->省->国

                          *  下钻（Drill-down）：与上卷相反

                7.4.2  切片（Slice）、切块（Dice）、旋转（Pivot）

                          *   选择某个维度进行分割成为切片

                          *   按照多维进行的切片成为切块 

                          *   对维度方向的互换

8.  数仓应用要点

       8.1  维度建模中表的分类

                *  事实表：指一个现实存在的业务对象，比如用户，商品，商家， 销售员等等

                *  维度表：对应一些业务状态，代码的解释，可以对事实表中的数据进行统计，聚合运算

                *  事务事实表：业务产生的数据，一旦产生不会在变化，如交易流水，操作日志，出库入库记录

                *  周期快照事实表：随着业务周期性的推进而变化，完成间隔周期内的度量统计，如年，季度累计

                                                使用周期+状态度量的组合，如年累计订单数，年是周期，订单总数据是量度

                *  累积快照事实表：记录不确定周期的度量统计，完全覆盖一个事实的生命周期，如订单状态表

                                                通常有多个时间字段，用于记录生命周期中的关键时间点

                                                只有一条记录，针对此记录不断更新

                *   拉链表：拉链表记录每条信息的生命周期，用于保留数据的所有历史（变更）状态

                                  拉链表将数据的随机修改方式，变为顺序追加

                 8.1.1  累积快照事实表的实现方式

                           实现方式一：

                                   *  使用日期分区表，全量数据记录，每天的分区存储昨天全量数据与当天增量数据合并的结果

                                   *  数据量大会导致全量表膨胀，存储大量永远不更新的冷数据，对性能影响较大

                                   *  适用于数据量少的情况

                           实现方式二：

                                   *  使用日期分区表，推测数据最长生命周期，存储周期内数据；周期外的冷数据存储到归档表

                                   *  需要保留多天的分区数据，存储消耗依然很大       

                           实现方式三：   

                                   *  使用日期分区表，以业务实体的结束时间分区，每天的分区存放当天结束的数据；设计一个时间非常大的分区，如9999-12-31，存放截止当前未结束的数据

                                   *  已结束的数据存放到相应分区，存放未结束数据的分区，数据量也不会很大，ETL性能好

                                   *  无存储浪费，数据全局唯一

                                   *  业务系统可能无法标识业务实体的结束时间，可以使用其他相关业务系统的结束标志作为此业务系统的结束，也可以使用最长生命周期时间或全段系统的数据归档                                         时间

       8.2  ETL策略

                8.2.1  全量同步

                          *  数据初始化装载一定是全量同步的方式

                          *  因为业务，技术原因，使用全量同步的方式做周期数据更新，直接覆盖原有数据即可

                8.2.1  增量同步

                          *  传统数据整合方案中，大多数采用merge方式（update + insert）

                          *  主流大数据平台不支持update操作，可采用全外连接+数据全量覆盖方式

                              --如果担心数据更新出错，可以采用分区方式，每天保存最新的全量版本，保留较短周期

       8.3  任务调度

                *  解决任务单元间的依赖关系

                *  自动化完成任务的定时执行

                *  常见的任务类型：Shell，  Java程序，  MapReduce程序，SQL脚本

                *  常见的调度工具：Azkaban，Oozie