数据仓库概念及概述

数据仓库概念

数据仓库里的 DM 层，事实上就是按照多维数据库的方式构建而成的。但数据仓库要比 OLAP 所涵盖的内容更广。

数据仓库之父比尔·恩门（Bill Inmon）于 1990 年提出数据仓库概念并被广泛接受——数据仓库（Data Warehouse）是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

之后 Kimball 又提出了自己对于数据仓库的不同见解，从而引发了 Inmon 和 Kimball 这两种数据仓库构建方法间的长期争论。

事实上，数据仓库的构建是一个复杂的过程，是数据采集、存储、管理、计算、应用相关的一系列逻辑概念及方法论。

虽然数据仓库的概念已经提出，但Inmon 提出数据仓库的构建过程，应该是自顶而下的（注意：这里的顶不是架构图的上层，而是数据流的上游，也就是数据源）。从数据源到数据仓库再到数据集市，采用范式建模的方法构建数据仓库，遵从第三范式

1.每一个属性都是不可分割的原子项，而不是集合数组记录等，2.每个属性都有且仅依赖于主键，

3.每个属性都不能传递依赖于主属性，如果有就拆分成两张表）。构建过程类似于瀑布模型，这就对构建者在业务理解、数据源真实现状、数据建模方法论等有非常高的要求，且构建周期较长。

Kimball 提出数据仓库的构建过程，采用维度建模的方法，根据业务需求优先构建数据集市，数据再从各个不同的数据集市汇集到数据仓库。这样对数据仓库构建者的各方面要求就没有那么高，而且能够快速对外提供数据应用。但随着需求变更、随着数据集市的越来越多，会使得数据仓库的管理变得极其困难：

数据存储模型没有事先的统一规划会变的越来越乱。
相同或相似的数据内容在不同数据集市内会重复计算造成资源浪费的同时也可能造成数据不一致。
从 ODS 直接到 DM，ETL 的处理逻辑会比较复杂，如果数据源或者需求变更，改动起来会很难且容易出错。

数据仓库实践

实际项目中，究竟应该采用那种建模方法呢？各有优劣，只能具体问题具体分析了。

总的来说需要综合考虑以下几点：

团队内成员对数据仓库理论（分层架构，维度建模，ETL 设计）的掌握程度
业务知识的熟悉程度（广度和深度）
任务需求的紧迫程度
需求的性质（短期任务还是长期任务，探索型还是永久落地型）

Inmon，ODS>DW>DM，耗时长，对业务知识及数仓理论要求高，好处是规范统一，易于维护。

kimball，ODS>DM>DW，好处是可以快速输出成果，探索型或者短期任务完全可以使用这种方式。但缺点是数据集市直接从 ODS 取数，每一次处理都要数据清洗、编码映射、缺失数据处理等等一些列细节操作，维护困难。

因此，在实际的数据仓库项目中，通常会是两种建设方法混合使用，两者共存才是更好的实践方案。

数据仓库组成

数据存储与管理（warehouse）
数据采集与计算（extract transform load）
数据应用（business intelligence）

Excel也有很强大的数据分析工具！数据挖掘实际案例——想上大学的有哪些人