数据仓库（一）概念

参考文章
Hive(3) 数据仓库

数据仓库的诞生

• 结构复杂
  业务数据库通常是根据业务操作的需要进行设计的，遵循3NF范式，尽可能减少数据冗余。这就造成表与表之间关系错综复杂。在分析业务状况时，储存业务数据的表，与储存想要分析的角度表，很可能不会直接关联，而是需要通过多层关联来达到，这为分析增加了很大的复杂度。

  • 举例：要从门店的地域分布来分析用户还款情况。基本的还款数据在订单细节表里，各种杂项信息在订单表里，门店信息在门店表里，地域信息在地域表里，这就意味着我们需要把这四张表关联起来，才能按门店地域来分析用户的还款情况。
  • 此外，随着NoSQL数据库的进一步发展，有许多数据储存在诸如MongoDB等NoSQL数据库中，另外一些通用信息，如节假日等，通常也不会在数据库中有记录，而是以文本文件的形式储存。多种多样的数据储存方式，也给取数带来了困难，没法简单地用一条SQL完成数据查询。如果能把这些数据都整合到一个数据库里，比如构造一张节假日表。这样就能很方便地完成数据查询，从而提高分析效率。

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

• 理解困难
  业务数据库中存在大量语义不明的操作代码，比如各种状态的代码，地理位置的代码等等，在不同业务中的同一名词可能还有不同的叫法。
  这些情况都是为了方便业务操作和开发而出现的，但却给我们分析数据造成了很大负担。各种操作代码必须要查阅文档，如果操作代码较多，还需要了解储存它的表。来自不同业务数据源的同义异名的数据更是需要翻阅多份文档。

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

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

数据仓库含义

数据仓库简称为DW。里面放的是数据。
目的是构建面向分析的集成化数据环境，主要职责是做分析。对于仓库里面的数据来进行数据分析可以支持我们做决策。数据仓库的作用为：数据清洗，转移，分类，重组，合并，拆分。

数据分析特征：

1、面向主题
2、集成性
3、非易失性
4、时变性

数据仓库与数据库的区别

数据库：OLTP （On-Line Transaction Processing）
也可以称面向交易的处理系统，它是针对具体业务在数据库联机的日常操作，通常对少数记录进行查询、修改。用户较为关心操作的响应时间、数据的安全性、完整性和并发支持的用户数等问题。 传统的数据库系统作为数据管理的主要手段，主要用于操作型处理OLTP。

数据仓库：OLAP （On-Line Analytical Processing）
一般针对某些主题的历史数据进行分析，支持管理决策。其产生是因为有大量，不同类型的数据，需要将数据方便的聚合起来进行分析才产生的数据仓库概念。

两者不是相互取代的

• 数据库是面向事务的设计，数据仓库是面向主题设计的。
• 数据库一般存储业务数据，数据仓库存储的一般是历史数据。
• 数据库设计是尽量避免冗余，一般针对某一业务应用进行设计；比如一张简单的User表，记录用户名、密码等简单数据即可，符合业务应用，但是不符合分析；数据仓库在设计是有意引入冗余，依照分析需求，分析维度、分析指标进行设计。
• 数据库允许增删改查，数据仓库一般不允许增删改。

数据仓库的分层

数据仓库层来源于不同的源数据，并提供多样的数据应用，数据自下而上的流入数据仓库后开放给应用，而数据仓库只是其中的一层。数据仓库模型一般分为三层：

• 源数据层（ODS）：这一层数据没有任何更改。直接沿用系统数据结构和数据不对外开放，作为临时接口层，为后一步的数据处理中做准备。
• 明细数据层（DWD层）：明细数据层，结构与粒度与ODS层一致。对ODS层的数据进行清洗。
• 服务数据层（服务数据层）：以DWD为基础，进行轻度汇总。这层通常会以某一个维度为线索，组成跨主题的宽表。一般以用户当日，设备当日等粒度进行聚合。
• 数据仓库层（DW）：细节层，DW层的数据应该是一致的，准确的，干净的数据，即对于源数据清洗后的。
• APP层（数据应用层） ：展示分析之后的结果

数据的流动

数据仓库中，数据由源数据层流向APP层。一层层进行处理。

数据从业务层到数据仓库的流向例子为：

ETL： extract（抽取） transform（转换） load（加载）