第一章 数据仓库理论专题

1、数据仓库概述

1.1、诞生背景

（1）历史数据积存

历史数据使用频率低，积压在业务库中，导致业务系统的性能下降;
	企业定期将冷数据存储到数据仓库中

（2）企业数据分析需要

各个部门自己建立独立的数据抽取系统，导致数据不一致
	各个部门直接从业务库抽数进行报表生成,资源浪费，权限管理风险;
	数据仓库为各个部门建立了一个统一的数据视图，各个部门的数据统一一致;

1.2、数据仓库概念

1.2.1、数据仓库定义

• 概念：面向主题的、继承的、非易失的且随时间变化的数据集合

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

1.2.2、数据仓库特点

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

范例：将业务数据库中的一些零散的表里面的原始数据进行聚合集合成为一张用户行为表，比如从支付流水表,商品表、用户表，订单表抽成一张大宽表 - 用户行为表，然后再用户行为表上做一系列相关分析;

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

不同数据源采用不同的数据规范
Ⅰ、针对性别的编码：系统A(男，女),系统B(1,0)
Ⅱ、针对计量单位的差异：系统A(cm),系统B(英尺)

• Ⅲ、非易失：保存的是一系列历史快照，不允许被修改，只能通过工具进行查询、分析；

数仓保存的数据为一系列的历史快照，每天从业务数据库同步，故数据与业务数据库保持一致;

• Ⅳ、数仓定期接收、集成新的数据，从而反映出数据的最新变化；

将最新的数据追加到我们系统中，然后以时间戳标记版本，修改后的数据时间戳是最新的，之前老旧的数据;

1.2.3、数据仓库与数据库的区别

• Ⅰ、数据库

1、面向事务设计,属于OLTP(在线事务处理)系统；
2、主要操作是随机读写，为业务系统提供存储服务；
3、在设计时避免冗余，常采用范式规范来设计;

• Ⅱ、数据仓库

1、面向分析设计，属于OLAP(在线分析处理)系统
2、主要操作是批量读写，存储各个业务数据库经过清洗后的数据;
3、采用反范式设计，有意引入冗余(避免关联多张表，采用大宽表)，关注数据整合(count,group by等操作)，以及分析、处理性能

• 数据库VS数据仓库

1.3、数据仓库技术实现

1.3.1、传统数据仓库

（1）由多个单机的关系型数据库组成MMP（大规模并行处理）集群，进行数据存储和计算

（2）数据通过提前调度分配到各个节点进行存储，一般数据采用hash分配，每个节点存储一部分数据；

（3）每个节点的计算/查询任务计算出的结果也是部分结果，这些部分结果会汇总成一个准确的完整的结果进行返回；？？？

• 传统数仓的缺点

//数据量级一旦达到某个量级，会出现以下问题：

//(1)扩展性有限
	/*在MPP的每个节点本质上还是一个数据库,数据库有很精细的内存管理，在MPP架构独立进行运算，如果需要用到数据交换，需要通过高速网络与其他节点连接进行交换数据，高速网络直接限制了节点上限;
	数据存储的时候采用分库分表，因为架构所限，将一张大表拆分到各个节点进行存储，每张表存储的数据多再将表进行拆分，但分库分表也存在上限，粒度越细性能越差;
	*/

//(2)热点问题
	/*比如：有100w行的数据，存储的时候被拆成了10分，恰好前10w行是热点数据，再访问的频率是其他数据的五倍,则这个节点是承受压力是其他节点的五倍，这个节点容易出现宕机或超时的情况，则这个节点会成为集群的瓶颈;
	*/
	
/*热点问题解决方式
		通过数据加盐方式及来解决，相当于给表中的数据增加前缀，将其打乱随机分布到各个节点中，但是数据加盐本身就是额外操作，会带来额外问题;*/

1.3.2、大数据数仓

• Ⅰ、大数据数仓概述

（1）分布式存储，分布式计算，利用大数据天然扩展性，完成海量的数据存放；

（2）将SQL转换为大数据计算引擎任务，完成数据分析；

（3）将SQL转换为大数据计算任务引擎，完成数据分析；

• Ⅱ、数据处理方面 - 移动计算（而不是移动数据）

1、使用了移动计算，而非移动数据的架构，为了避免海量数据移动造成IO和网络的开销；
2、数据在哪存储的，就将计算任务分发到那个节点上进行计算；
	一份数据被拆分为并存放到多个节点上，所以每个节点接收到这个计算任务是并发进行的，得到的结果是部分结果，对结果进行汇总得到最终结果

• Ⅲ、大数据数仓特点

1、分布式文件系统：将数据库中的结构化数据看作文件进行存储；
2、将数据文件自动拆分，拆分完之后分发到各个节点进行存储；
3、上层数据处理的时候，采用元数据将文件还原为表结构；
	解决了数据热点问题 - 可选降低
4、数据文件被存储到分布式文件系统时，默认备份三分，数据为一致的；
5、计算任务再分发的时候可选，相同的数据被存在三个节点，则可以选择最空闲的数据节点，将任务分发过去;

• Ⅳ、大数据数仓的缺点
  • 大数据的数据仓库在数据少的时候计算速度比较慢，因为是完全分布式的；
  • 任务计算时，会对任务进行拆分，然后调度到各个节点，最后对结果进行合并；
  • 在数据量没有达到一定程度时，只是人物的转换、分发、调度、汇总整个过程就会花费大量时间；

1.4、MPP架构

1.4.1、MPP架构概述

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

（2）节点间为非共享架构（每个节点独立存在，不关心集群整体状态，不关心其他节点的存储信息），每个节点都有独立的磁盘存储系统和内存系统；

（3）每台数据节点通过专用网络或商业通用网络互相连接，彼此协同计算，为整体提供服务；

• 计算任务中，如需要使用其他节点的数据，则通过高速网络点对点传输；

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

1.4.2、MPP架构优点

（1）运算方式精细，延迟低，吞吐低；

（2）适合中等规模的结构化数据处理；

（3）MPP致力于实现分布式事务

（4）MPP架构没办法单独运行局部应用，只能作为整体进行对外服务；

1.4.3、MPP架构缺点

（1）存储位置不透明，通过hash确定数据所在的物理节点，查询任务在所有节点执行；

• 非共享架构导致数据存储位置不透明，导致执行查询任务时在所有节点执行；

（2）并行计算时，**单个节点会成为整个系统短板，**容错性差；

• 解决方式：当这个节点运行缓慢时，将缓慢数据节点的数据通过高速网络分发到其他节点进行处理，但是集群规模越大，单个节点发生故障的几率越大；

（3）分布式事务的实现会导致扩展性降低

• 集群规模越大，单个节点发生故障的几率越大；

1.5、分布式架构

（1）大数据中常见的技术架构，也成为Hadoop架构/批处理架构；

（2）各个节点实现场地自治（可单独运行局部应用），数据在集群中全局透明共享；

• 将每个节点存储资源拿出来共同组成一个分布式存储文件系统，各个节点被拿走存储资源后，剩下就是计算资源；
• 当每个任务分发到单个节点上，节点进行计算时，可访问公共的存储系统，找到数据在那个位置进行计算，所以可以单独进行局部应用

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

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

• 对中间结果进行存储，且数据移动开销会比较大

1.6、MPP+分布式架构

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

相当于把数据透明化

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

1.7、常见数据仓库产品

//1、传统数据仓库
Oracle 
DB2
Teradata
Greenplum

//2、大数据数据仓库
Hive
Spark SQL
HBase
impala
HAWQ
TIDB

2、数据仓库架构

2.1、数据仓库架构设计

2.1.0、OLTP与大数据仓库的关系

1、数据仓库数据来源
	业务数据:来自OLTP集群，通过Sqoop落HDFS上
	日志数据:来自服务的日志文件 ,通过kafka落HDFS上

2.1.1、ETL - 数据抽取、清洗、转换、加载

结构化数据：sqoop，Kettle
	结构化数据：直接将原系统数据抽取、加载到ODS层
非结构、半结构化数据(日志、文件)：Flume

2.1.2、ODS层 - 数据贴源层

目的：与原始数据保持一致存储业务数据库的数据，不进行数据修改

2.1.3、DW层 - 公共维度模型层

• Ⅰ、DWD层：数据明细层 – 满足三范式形式
  • 明细层：存的是各种零散表，零散表与业务系统相差不多的，只不过是清洗后的业务系统的表；

DWD层：接受ODS层数据，ODS层拿的业务系统的数据
	将ODS层数据进行清洗、标准化，将异常数据剔除掉，做统一的编码，字段描述，将数据统一规范后存储到数据明细层;

• Ⅱ 、DWS层：数据汇总层 – 脱离三范式，维度建模，以宽表形式存在
  • 对DWD层的明细表进行汇总，比如将用户行为相关的数据存进一张大表，形成用户行为宽表；

DWS层:将DWD层进行维度建模,建立宽表形式存在

2.1.4、ADS层 - 数据应用层(数据集市层)

ADS层:保存数据分析的结果数据,使用传统数据库搭建

2.2、ETL流程

2.2.1、ETL概述

（1）将数据从来源端经过抽取、交互转换、加载至目的端的过程；

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

（2）ETL规则的设计和实时约占整个数据仓库搭建工作量的60%-80%；

2.2.2、数据抽取(E-JOB)

（1）数据源

• 抽取的数据源可以分为结构化数据、非结构化数据、半结构化数据;
• 结构化数据一把采用JDBC、数据库日志方式,非/半结构化数据会监听文件变动

抽取关系型数据库：
JDBC直连：消耗数据库的IO，影响数据库的运转，一般抽取在凌晨业务量较少的；
	对于业务数据库压力很大
直接抽取数据库的日志：直接采集预写日志文件，需要将日志文件解析后获取数据;
	对于业务数据库压力很小

（2）抽取方式

• 数据抽取方式有全量同步、增量同步两种方式

全量同步:会将全部数据进行抽取,一般用于初始化装载;
增量同步:检测数据的变动,抽取发生变动的数据,一般用于数据更新;

2.2.3、数据清洗

• 数据清洗要经历数据清洗和转换两个阶段
  • 结构化数据抽取与源系统保持一致,数据清洗任务量很小,基本只要去重即可;
  • 数据清洗和转换主要集中在非结构化、半结构化数据;

①数据清洗:主要是对出现的重复、二义性、不完整、违反业务或逻辑规则等问题进行统一处理
	数据清洗在结构化数据很少,否则业务数据库就会产生极大的风险;
	数据清洗主要是对非结构化,半结构化数据进行清洗;
②数据转换:主要是对数据进行标准化处理,进行字段、数据类型、数据定义的转换

2.2.4、数据加载

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

2.2.5、ETL工具

// 1、结构化数据ETL工具
Sqoop
    通过JDBC连接结构化数据库进行数据抽取,使用并发处理方式,批量导入大数据的数据仓库里面;
	生产中使用1.x版本,2.0版本功能完善导致性能下降;
Kettle
Datastage
Information
Kafka
    kafka是一个消息队列,提供ETL功能,支持ETL操作,将数据抽取出来之后存在消息队列里面,等待下游的数据仓库的抽取;

// 2、非/半结构化数据
Flume
    支持对日志文件进行数据监控,一旦有变动将数据抽取出来;
Logstash

2.3、数据积存(ODS层)

（1）数据与源业务数据保持一致，可以增加审计字段用来进行数据管理

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

• 业务系统会将定期将导入数据仓库的业务数据库中的数据删除掉

（3）修改只可追加：业务系统对历史数据完成修改后，将update_type字段更新为UPDATE，追加回ODS层

（4）在离线数仓中业务数据定期通过ETL流程放到如ODS中，导入方式有两种

--全量导入：数据的第一次导入，选择此种方式；
--增量导入：数据非第一次导入，每次只需倒入新增、更改的数据,建议使用外连接&全覆盖方式

case：针对大数据平台不能修改数据的限制

• Ⅰ、外连接

• Ⅱ、全覆盖

2.4、数据分析(DWD/DWS/ADS)

2.4.1、DWD - 数据明细层

• 数据仍满足3NF模型，为分析运算做准备；
• 数据明细层对ODS层的数据进行清洗，标准化、维度退化
  • 范例：将维表数据整合到事实表中；
  • 范例：各个不同城市子公司的用户表，添加一个城市字段后union

维度退化:
	在大数据的数据仓库里面,大量join操作会涉及到一个海量数据的移动,导致性能会很差

2.4.2、DWS - 数据汇总层

• 数据汇总层：对数据明细层的数据进行计算汇总，存放便于分析的大宽表；

• 存储模型：更加注重与数据聚合，复杂查询，处理性能更优的数仓模型；

  • 传统数仓：以维度模型为主；
  • 大数据数仓：以宽表模型为主

DWS层：将ODS层的零散表聚集成一张面向主题的大宽表

2.4.3、ADS - 数据应用层

• 数据应用层：数据集市;
• 主要作用：存储数据分析结果,为不同业务场景提供外部接口，减轻数据仓库的负担

--数据仓库擅长数据分析，直接开放业务查询借口，会增加其负担
	①报表决策的快速查询：kylin
	②前端业务的并发查询：Hbase
	③前端业务的只能检索：ElasticSearch

3、数据仓库建模

3.1、建模基本概念

3.1.1、OLTP传统建模方法

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

用于业务数据，主要是对业务数据库提供数据存储和数据操作的服务;

（2）使用关系模型建模（ER模型），保证数据一致性，减少冗余；

ER模型原则尽量将表拆分，拆分的越细越好，尽量满足3NF的规则，减少冗余

3.1.2、OLAP在线联机分析

（1）基本概念

• OLAP系统：主要操作是复杂分析查询，关注数据整合以及分析，处理性能

• OLAP根据存储方式的不同：分为ROLAP、MOLAP、HOLAP;

（2）系统分类

• Ⅰ、ROLAP：关系型OLAP

使用关系模型构建，存储系统一般为RDBMS；

• Ⅱ、MOLAP：多维型OLAP

预先聚合计算,使用多位数组的形式保存数据结果，加快查询分析时间；

• Ⅲ、HOLAP：混合架构的OLAP

1、ROLAP和MOLAP两者的集成；
2、底层是关系性的，高层是多维矩阵的；
3、查询效率高于ROLAP,低于MOLAP;

3.2、ROLAP - DWS层

• 业务场景：ADS层

3.2.1 维度模型

• 分为星形模型，雪花模型，星座模型

• 方便对数据多维分析

事实表维度表

3.2.2、星型模型

• 标准的星型模型维度只有一层,分析性能最优;

查询的时候,找到维度表对事实表直接聚合;

• 星型模型与雪花型模型的区别

星型模型和雪花模型的主要区别在于对维度表的拆分，
	雪花模型:维度表的设计更加规范，一般符合3NF；
	星型模型:一般采用降维的操作，利用冗余来避免模型过于复杂，提高易用性和分析效率。

3.2.3、雪花模型

• 雪花模型具有多层维度,比较接近三范式设计

3.2.4、星座模型

• 星座模型基于多个事实表,事实表之间会共享一些维度表;

星座模型是大型数据仓库中的常态,是业务增长的结果,与模型设计无关;

3.2.5、宽表模型

• 大数据数仓里面,join使得大量数据移动导致性能不佳

• 宽表模型:将维度冗余到事实表中,形成宽表,以此减少join操作;

3.3、MOLAP - ADS层

• 特点：以空间换时间；灵活性较低，不存储原始数据
• 业务场景：应用于ADS层

（1）MOLAP将数据进行预结算，并将聚合结果存储到CUBE模型中；

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

（3）生成cube需要大量的时间，空间，维度预处理可能导致数据膨胀；

• 常见的MOLAP产品：Kylin，Druid

1、读取Hadoop，hive...各种数据源获取后；
2、由Kylin加工成cube,加工时进行多种维度组合;
3、预计算结果存储到Hbase中;
4、前端业务人员/程序员查询kylin,kylin返回Hbase中的数据;

3.4、OLAP多维分析

• OLAP主要操作时复杂查询,可以多表关联,使用count、sum、avg等函数;
• OLAP对复杂查询做了直观的定义,包括钻取、切片、切块、旋转;

3.4.1、钻取

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

钻取包括上卷、下钻;
	上卷:向上钻取,指从低层次到高层次的切换;
	下钻:指从高层次到低层次的切换;

3.4.2、切片/切块

• 切片：选择某个维度进行分割；
• 切块：按照多维进行切片；

3.4.3、旋转

• 旋转：对维度方向的互换，类似于坐标轴上卷

1、先查询产品类型,之后每个产品类型按照时间进行筛选;
2、旋转之后,先查询时间,之后按每年的产品类型进行分类;

4、数据仓库最佳实践

4.1、表的分类

4.1.1、事实表

• 事实表数据：一般指一个现实存在的业务对象；比如用户，商品，商家等；

（1）事务事实表 – 顺序追加

• 随着业务不断产生的数据，一般产生不会再发生变化，如交易流水，操作日志，出库入库记录；

（2）周期快照事实表 – 顺序追加

• 随着业务周期型的推进而变化，完成间隔周期内的度量统计，如年、季度累计；

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

银行/金融行业中:业务随着业务周期的变化,数据重新计算
	比如年累计,月累计,天累计

（3）累计快照事实表 – 随机修改

• 记录不确定周期的度量统计，完全覆盖一个事实的生命周期，如订单状态表；
• 通常有多个时间字段，用于记录生命周期中的关键节点；
• 只有一条记录，针对此记录不断更新；

两种实现方式：
	1、事务事实表;
	2、对之前历史数据的随即修改 --拉链表

• 累计快照事实表实现方式

1、实现方式一
	使用日期分区表,全量数据记录,每天的分区存储昨天全量数据于当天增量数据的合并结果;
	数据量过大会导致全量表碰撞,存储永远不更新的冷数据,对性能影响较大;
	业务场景:适合于数据量少的情况;

2、实现方式二
	使用日期分区表,存储周期内的数据,周期外的冷数据存储到归档标中;
	需要保留多天的分区数据,存储消耗依然很大;

3、实现方式三
	使用日期分区表,以业务实体的结束时间分区,每天的分区存放当太难结束的数据,设计一个时间非常大的分区如9999-12-31,存放截至当前未结束的数据;
	优点:已结束的数据存放到相应分区,存放未结束数据分区,数据量也不是很大,ETL性能好;
		无存储浪费,数据全局唯一;

4.1.3、维度表

• 维度表数据：一般是指一些业务状态，代码的解释表（即码表）。
  • 通常使用维度对事实表中的数据进行统计、聚合运算

4.1.4、拉链表

• 拉链表：记录每条信息的生命周期，用于保留数据的所有历史变化状态；
• 拉链表将表数据的随机修改方式变为顺序追加；

• 拉链表的实现策略
  • 1、拉链表实现方式 – 增量数据与目标表通过主键做全量关联

/*
更新最新数据,以主键是否存在判断是否取增量表中数据,还是T-1的全量表中数据;
	(1)没有关联上的数据:插入insert分区;
					 
	(2)关联上的数据:插入update分区;
	
*** 每次增量数据须和DWI表做关联,会吃很多资源
*/
insert overwrite table dwi_t_9000 partition(date)
select 
	if(tmp.id is null,ods.id,temp.id) as id
from temp full join dwi on temp.id = ods.id
 

4.2、ETL策略

• ETL策略分为两种：全量同步&增量同步；

4.2.1、全量同步

• 业务场景：数据初始化装载使用全量同步方式；
  • 因为业务/技术原因，比如第三方给的数据，使用全亮的方式做周期数据更新，直接覆盖原有的数据即可；
  • 利用分区保存每天数据，可保存较短周期；

结构化数据:
	JDBC：直接连接数据库进行数据抽取，会给数据库带来较大的负载和压力，影响数据库的稳定性；
		  一般抽取备库;
	抽取数据库日志方式：开放CDC功能抽取日志，oracle使用OGG工具，mysql或者sqlserver使用CDC工具；

4.2.2、增量同步

• 业务场景：除了第一次全量同步完后，之后的每次的数据都是增量同步；

（1）结构化数据

• 抽取方式：
  • JDBC抽取：业务数据的时间戳抽取；
  • 日志抽取：对数据库日志进行抽取，数据库日志是追加的，对某个时间点之后的数据会更容易追加到；

日志抽取相比于JDBC抽取：抽取速度快，且对数据库影响较小;

（2）非结构/半结构化数据

• 抽取工具：自带监控功能，可以实时监控变动数据；

（3）增量数据更新方式

• Ⅰ、传统数据整合方案：大多数采用merge方式（update+insert）
• Ⅱ、主流大数据平台：不支持update操作，可采用全外连接+数据全量覆盖方式

大数据平台担心数据出错,可以采用分区方式,每天保存最新的全量版本,保留较短周期;

insert overwrite table dw_user_inc
select 
--如果ODS表中有数据,以新增数据为准;如果没有则追加;
case when b.uid is not null then b.uid else a.uid end as uid,
case when b.uid is not null then b.ename else a.ename end as uname
...
from dw_user_inc outer join ods_user_inc b
on a.uid = b.uid

4.3、任务调度

4.3.1、任务调度必要性

• 定时：自动化完成任务的定时执行;
• 制定节点：解决任务单元间的依赖关系;

4.3.2、调度任务类型

• shell：用于启动数据仓库的集群组件，比如ETL的采集组件；
• java：数据清洗任务；
• mapreduce：Mapreduce执行特定功能，吞吐量更高；
• SQL脚本：数据的DDL，数据处理任务等；

4.3.3、常见调度工具

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Yx4C9AFA-1627957839829)(C:\Users\李海伟\AppData\Roaming\Typora\typora-user-images\image-20210604164125162.png)]

5、常见面试题

5.1、范式建模和维度建模的区别

范式模型:从流程上看是自上而下的，自上而下指的是数据的流向，“上”即数据的上游，“下”即数据的下游，即从分散异构的数据源 -> 数据仓库 -> 数据集市。
	   :以数据源头为导向，然后一步步探索获取尽量符合预期的数据，因为数据源往往是异构的，所以会更加强调数据的清洗工作，将数据抽取为实体-关系模型，并不强调事实表和维度表的概念。
特点	
	:1、能够结合业务系统的数据模型，较方便的实现数据仓库的模型；
	:2、同一份数据只存放在一个地方，没有数据冗余，保证了数据一致性；
	:3、数据解耦，方便维护。
	缺点:表的数量多；查询时关联表较多使得查询性能降低。

维度模型:从流程上看是自下而上的，即从数据集市-> 数据仓库 -> 分散异构的数据源。
	  :Kimball 是以最终任务为导向，将数据按照目标拆分出不同的表需求，数据会抽取为事实-维度模型，数据源经ETL转化为事实表和维度表导入数据集市，以星型模型或雪花模型等方式构建维度数据仓库，架构体系中，数据集市与数据仓库是紧密结合的，数据集市是数据仓库中一个逻辑上的主题域。
特点
	:1、维度建模：模型结构简单，面向分析，为了提高查询性能可以增加数据冗余，反规范化的设计，开发周期短，能够快速迭代。
	缺点:就是数据会大量冗余，预处理阶段开销大，后期维护麻烦；还有一个问题就是不能保证数据口径一致性，原因后面有讲解。

范式建模:必须符合准三范式设计规范，如果使用混合建模，则源表也需要符合范式建模的限制，即源数据须为操作型或事务型系统的数据。通过ETL抽取转换和加载到数据仓库的ODS层，ODS层数据与源数据是保持一致的，所以ODS层数据也是符合范式设计规范的，通过ODS的数据，利用范式建模方法，建设原子数据的数据仓库EDW，然后基于EDW，利用维度建模方法建设数据集市。

• 建模思路

结合两种建模方式的各自规范，混合建模按照“松耦合、层次化”的基本架构原则进行实施。混合数据仓库架构方法主要包含以下关键步骤：业务需求分步构建、分层次保存数据、整合原子级的数据标准、维护一致性维度等。