数据仓库的特点
面向主题的
与传统数据库面向应用进行数据组织的特点相对应，数据仓库的数据是面向主题进行组织的。主题是较高层次上企业信息系统中的数据综合、归类并进行分析利用的抽象。在逻辑意义上，它是对应企业中某一宏观分析领域所涉及的分析对象。面向主题的数据组织方式，就是在较高层次上对分析对象的数据的一个完整、一致的描述，能完整、统一地刻画各个分析对象所涉及的企业的各项数据，以及数据之间的联系。所谓较高层次是相对应用的数据组织方式而言的，是指按照主题进行数据组织的方式具有更高的数据抽象级别。
集成的
数据仓库的数据是从原有的分散的数据库数据抽取来的。操作型数据与DSS分析型数据之间差别甚大。第一，数据仓库的每一个主题所对应的源数据在原有的各分散数据库中有许多重复和不一致的地方，且来源于不同的联机系统的数据都和不同的应用逻辑捆绑在一起；第二，数据仓库中的综合数据不能从原有的数据库系统直接得到。因此在数据进入数据仓库之前，必然要经过统一与综合，包括：要统一源数据中所有矛盾之处，如字段的同名异义、单位不统一、字长不一致等等以及进行数据综合和计算，数据仓库中的数据综合工作可以在从原有数据库抽取数据时生成，但许多是在数据仓库内部生成的，即进入数据仓库以后进行综合生成的。
数据仓库的数据是不可修改的
数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一般情况下并不进行修改操作。数据仓库的数据反映的是一段相当长的时间内历史数据的内容，是不同时点的数据库快照的集合，以及基于这些快照进行统计、综合和重组的导出数据，而不是联机处理的数据。数据库中进行联机处理的数据经过集成输入到数据仓库中，一旦数据仓库存放的数据已经超过数据仓库的数据存储期限，这些数据将从当前的数据仓库中删去。因为数据仓库只进行数据查询操作，所以数据仓库管理系统相比数据库管理系统而言要简单得多。数据库管理系统中许多技术难点，如完整性保护、并发控制等等，在数据仓库的管理中几乎可以省去。但是由于数据仓库的查询数据量往往很大，所以就对数据查询提出了更高的要求，它要求采用各种复杂的索引技术。
随时间不断变化的
数据仓库中的数据不可更新是针对应用来说的，即数据仓库的用户进行分析处理时是不进行数据更新操作的。但并不是说，在从数据集成输入数据仓库开始到最终被删除的整个数据生存周期中，所有的数据仓库数据都是永远不变的。
数据仓库的数据是随时间的变化而不断变化的。主要体现在以下3个方面：
（1）数据仓库随时间变化不断增加新的数据内容。数据仓库系统必须不断捕捉OLTP数据库中变化的数据，追加到数据仓库中去，也就是要不断地生成OLTP数据库的快照，经统一集成后增加到数据仓库中去；但对于确实不再变化的数据库快照，如果捕捉到新的变化数据，则只生成一个新的数据库快照增加进去，而不会对原有的数据库快照进行修改。
（2）数据仓库随时间变化不断删去旧的数据内容。数据仓库的数据也有存储期限，一旦超过了这一期限，过期数据就要被删除。只是数据仓库内的数据时限要远远长于操作型环境中的数据时限。在操作型环境中一般只保存有60~90天的数据，而在数据仓库中则需要保存较长实现的数据（如5 ~ 10年），以适应DSS进行趋势分析的要求。
（3）数据仓库中包含有大量的综合数据，这些综合数据中很多跟时间有关，如数据经常按照时间段进行综合，或隔一定的时间片进行抽样等等。这些数据要随着时间的变化不断进行重新综合。因此，数据仓库的数据特征都包含时间项，以标明数据的历史时期。
数据仓库与数据库的区别
数据库:是一种逻辑概念，用来存放数据的仓库，通过数据库软件来实现。数据库由很多表组成，表是二维的，一张表里面有很多字段。字段一字排开，对数据就一行一行的写入表中。数据库的表，在于能够用二维表现多维的关系。Oracle、DB2、MySQL、Sybase、MS SQL Server等都是流行的数据库。
在IT的架构体系中，数据库用来存储数据的。比如电商：物品的存货、货品的价格、用户的账户余额等。这些数据都是存放在后台数据库中。或者社交软件如的账户和密码，在后台数据库必须是一个User表，字段包括用户名和密码，然后用户数据就一行一行的存在表上面。当登录的时候，输入的用户名和密码，这些数据就会回传到回台去跟表上面的数据匹配，匹配成功了，就能登录。匹配不成功就会报错，这就是数据库，数据库在生产环境就是用来干活的。凡是跟业务有关应用挂钩的，都使用数据库。
数据仓库：是数据库概念的升级。从逻辑上理解，数据库和数据仓库没有区别，都是通过数据库软件实现存放数据的地方，只不过从数据量来说，数据仓库要比数据库更庞大德多。数据仓库主要用于数据挖掘和数据分析，辅助领导做决策。
数据仓库是BI下的一种技术。由于数据库跟业务应用挂钩的，所以一个数据库不可能装下一家公司的所有数据。数据库的表设计往往是针对某一个应用进行设计的。比如登录功能，这张User表上就只有这两个字段：用户名和密码。但是通过这张表无法进行分析，比如：在哪个时间段，用户的量最多？哪个用户一年购物最多？诸如此类的指标。数据仓库的表结构是依照分析需求，分析维度，分析指标进行设计的。
数据库与数据仓库的区别实际讲的是OLTP与OLAP的区别。
操作型处理，叫联机事务处理OLTP（On-Line Transaction Processing），也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发的支持用户数等问题。传统的数据库系统作为数据管理的主要手段，主要用于操作型处理。
分析型处理，叫联机分析处理OLAP（On-Line Analytical Processing）一般针对某些主题历史数据进行分析，支持管理决策。
| OLTP | OLAP |
|---|
| 操作特点 | 日常业务操作 | 统计报表、大批量数据加载 |
| 响应速度 | 响应速度很高 | 速度不高、吞吐量大 |
| 吞吐量 | 小 | 大 |
| 并发访问量 | 非常高 | 不高 |
| 访问方式 | 按索引访问 | 全表扫描 |
| 是否支持数据更新 | 可更新的 | 只读、只追加 |
| 面向事务 | 面向分析 |
| 短的、简单事务 | 复杂查询 |
数据仓库结构
数据仓库标准上可以分为三层：ODS（临时存储层）、DW（数据仓库层）、APP（应用层）。具体数据仓库分层可参照这篇博客
数据仓库多维数据模型的设计
数据模型是数据关系的一种映射， 就是将业务之间的关系，用模型图形化的描绘出来，而不再是脑海的一个模糊的关系。
基本概念
主题（Subject）
主题就是指我们所要分析的具体方面。例如：某年某月某地区某机型某款App的安装情况。主题有两个元素：一是各个分析角度（维度），如时间位置；二是要分析的具体量度，该量度一般通过数值体现，如App安装量。
维度
即观察数据的角度。比如员工数据，可以从性别角度来分析，也可以从入职时间或者地区的维度来观察。
度量
即被聚合(观察)的统计值，也就是聚合运算的结果。比如说员工数据中不同性别员工的人数，又或者说在同一年入职的员工有多少。度量就是要分析的具体的技术指标，它们一般为数值型数据。
分层（Hierarchy）
OLAP需要基于有层级的自上而下的钻取，或者自下而上地聚合。所以我们一般会在维的基础上再次进行分层。每一级之间可能是附属关系（如市属于省、省属于国家），也可能是顺序关系（如天周年）。
粒度
数据的细分层度，例如按天分按小时分。
事实表和维表
事实表是用来记录分析的内容的全量信息的，包含了每个事件的具体要素，以及具体发生的事情。事实表中存储数字型ID以及度量信息。 如系统的日志、销售记录、用户访问日志等信息，事实表的记录是动态的增长的，所以体积是大于维度表。
用户访问日志（事实表）：用户名、url、时间…
维度表（Dimension Table）也称为查找表（Lookup Table是与事实表相对应的表，是对事实表中事件的要素的描述信息，就是观察该事务的角度，是从哪个角度去观察这个内容的。这个表保存了维度的属性值，可以跟事实表做关联，相当于是将事实表中经常重复的数据抽取、规范出来用一张表管理，常见的有日期（日、周、月、季度等属性）、地区表等，所以维度表的变化通常不会太大。 维度表的存在缩小了事实表的大小，便于维度的管理和CURD维度的属性，不必对事实表的大量记录进行改动，并且可以给多个事实表重用。
省份表（维度表）：北京市、广东省、上海市…
事实表和维表通过ID相关联，如图所示：
维度如果会经常变更该怎么处理（缓慢渐变维度）加个版本号
处理缓慢变化维的方法通常分为三种方式：
第一种方式是直接覆盖原值。这样处理最容易实现，但是没有保留历史数据，无法分析历史变化信息。第一种方式通常简称为“TYPE 1”。
==>
第二种方式是添加维度行。这样处理，需要代理键的支持。实现方式是当有维度属性发生变化时，生成一条新的维度记录，主键是新分配的代理键，通过自然键可以和原维度记录保持关联。第二种方式通常简称为“TYPE 2”。本例中PK就是指代理键(代理主键)，当然可以添加生失效字段，生失效时间等。
===>
| PK | 颜色 | 自然键 | 状态 |
|---|
| 123 | 蓝色 | nbr123 | 生效 |
| 456 | 绿色 | nbr123 | 生效 |
第三种方式是添加属性列。这种处理的实现方式是对于需要分析历史信息的属性添加一列，来记录该属性变化前的值，而本属性字段使用TYPE 1来直接覆盖。这种方式的优点是可以同时分析当前及前一次变化的属性值，缺点是只保留了最后一次变化信息。第三种方式通常简称为“TYPE 3”。
数仓建模阶段划分
业务建模：业务分解和程序化，确定好业务的边界及业务流程，如订单、支付都是一个单独的业务模块
领域建模：业务概念的抽象、分组，整理分组之间的关联，比如用户购物的业务，抽成一个更大的模型，这个模型一般相对于行业。
逻辑建模：领域模型中的业务概念实体化，并考虑实体的具体属性及实体与实体之间的关系，比如订单（订单号、付款人…）和支付（金额、支付时间…）的关系。
物理建模：解决实际应用的落地开发、上线等问题，及性能等一些具体的技术问题。
范式建模法
数据仓库的概念模型（域模型）应该包含企业数据模型的概念模型（域模型）之间的关系，以及各主题域的定义。数据仓库的概念模型（域模型）应该比业务系统的主题域模型范围更加广。在数据仓库的逻辑模型需要从业务系统的数据模型中的逻辑模型中抽象实体，实体的属性，实体的子类、关系等，在某些时候反而限制了数据仓库模型的灵活性，在底层数据向数据集市汇总时，需要进行一定的变通。
维度建模法
以事实表为核心，与多个维度表形成的星型模型，是维度建模的典型实现方式。事实表记录业务过程中发生的可度量事件，如订单中的消费金额，折扣金额或是库存数量等，在实际业务中事实表占据主要的存储，如订单表；而维度表，则是对业务过程度量有关的文本环境，描述“谁、什么、哪里、何时、如何、为什么”，常用的维度表有日期、产品、用户、地址等。一般维度表会冗余信息，有超过100个列的维度表，这样的不规范化带来数据组织上的简单。
维度建模与范式建模：
数据量比较大，完全规范的3范式在数据的交互的时候效率比较低下，所以通常会根据实际情况在事实表上做一些冗余，减少过多的数据交互。维度建模作为企业资源不太好维护，结构复杂，数据集市集成困难。
维度冗余就是反三范式建模，比如三范式不能省份编码和省份名称在一张表里面，因为可能存在传递依赖浪费存储空间，但是数仓里面就可以，为了查询快，可以存在维度冗余。牺牲空间换时间。
关系建模
关系建模，被称为“实体-关系”模型，以一种“标准化”的方式存在，强调数据之间非冗余，满足三范式。在建设过程中，将数据标准化到细节级数据，如用户主题下，会有用户与姓名、用户与年龄、用户与住址等。
实体建模法
实体建模法是一种抽象客观世界的方法，细分为一个个实体，以及实体之间的关系，将一个业务划分为3个过程，因此只能局限在业务建模和领域建模的阶段，因此到了逻辑建模阶段和物理建模阶段，则是范式和维度建模的发挥了。
设计逻辑模型
星型模型架构 VS 雪花模型架构
当设计好概念模型时，就要根据概念模型设计逻辑模型，而在设计逻辑模型是，通常根据事实表和维度表的关系，将常见的模型架构分为星型模型和雪花型模型。
星型模型是一种多维的数据关系，它由一个事实表和一组维表组成。每个维表都有一个维作为主键，所有这些维的主键组合成事实表的主键。强调的是对维度进行预处理，将多个维度集合到一个事实表，形成一个宽表。这也是在使用Hive时，经常会看到一些大宽表的原因，大宽表一般都是事实表，包含了维度关联的主键和一些度量信息，而维度表则是事实表里面维度的具体信息，使用时候一般通过join来组合数据，相对来说对OLAP的分析比较方便。
当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。它对星型模型的维表进一步层次化，原有的各维表可能被扩展为小的事实表，形成一些局部的 "层次 " 区域，这些被分解的表都连接到主维度表而不是事实表。雪花模型更加符合数据库范式，减少数据冗余，但是在分析数据的时候，操作比较复杂，需要join的表比较多所以其性能并不一定比星型模型高。
雪花模式可以减少冗余，但是减少的那点空间和事实表的容量相比实在是微不足道，而且多个表联结操作会降低性能，所以一般不用雪花模式设计数据仓库。事实星座模式就是星形模式的集合，包含星形模式，也就包含多个事实表。
| 属性 | 星型模型 | 雪花模型 |
|---|
| 数据总量 | 多 | 少 |
| 可读性 | 容易 | 差 |
| 表个数 | 少 | 多 |
| 查询速度 | 快 | 慢 |
| 冗余度 | 高 | 低 |
| 对实时表的情况 | 增加宽度 | 字段比较少，冗余低 |
| 扩展性 | 差 | 好 |
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。
星型模型/雪花模型应用场景
星型模型的设计方式主要带来的好处是能够提升查询效率，因为生成的事实表已经经过预处理，主要的数据都在事实表里面，所以只要扫描实时表就能够进行大量的查询，而不必进行大量的join，其次维表数据一般比较少，在join可直接放入内存进行join以提升效率，除此之外，星型模型的事实表可读性比较好，不用关联多个表就能获取大部分核心信息，设计维护相对比较简答。
雪花模型的设计方式是比较符合数据库范式的理念，设计方式比较正规，数据冗余少，但在查询的时候可能需要join多张表从而导致查询效率下降，此外规范化操作在后期维护比较复杂。
上卷（汇总数据）
上卷就是乘坐电梯上升观测人的过程。按城市汇总的人口数据上卷，观察按国家人口的数据。就是由细粒度到粗粒度观测数据的过程，应该还会记录相应变化。
下钻（明细数据）
上卷的反向操作，可以按照城市汇总的人口数据下钻，观察按城镇人口汇总的数据。由粗粒度变为细粒度。
数据仓库设计步骤
1、确定主题
主题与业务密切相关，所以设计数仓之前应当充分了解业务有哪些方面的需求，据此确定主题
2、确定量度
在确定了主题以后，我们将考虑要分析的技术指标，诸如年销售额之类。量度是要统计的指标，必须事先选
择恰当，基于不同的量度将直接产生不同的决策结果。
3、确定数据粒度
考虑到量度的聚合程度不同，我们将采用“最小粒度原则”，即将量度的粒度设置到最小。例如如果知道某些数据细分到天就好了，那么设置其粒度到天；但是如果不确定的话，就将粒度设置为最小，即毫秒级别的。
4、确定维度
设计各个维度的主键、层次、层级，尽量减少冗余。
5、创建事实表
事实表中将存在维度代理键和各量度，而不应该存在描述性信息，即符合“瘦高原则”，即要求事实表数据条数尽量多(粒度最小)，而描述性信息尽量少。
