本质上，数据仓库试图提供一种从操作型系统到决策支持环境的数据流架构模型。数据仓库概念的提出，是为了解决和这个数据流相关的各种问题，主要是解决多重数据复制带来的高成本问题。
数据仓库之父Bill Inmon在1991年出版的Building the Data Warehouse 一书中首次提出了被广为认可的数据仓库定义。Inmon将数据仓库描述为一个面向主题的、集成的、 随时间变化的、非易失的数据集合，用于支持管理者的决策过程。
面向主题 传统的操作型系统是围绕组织的功能性应用进行组织的，而数据仓库是面向主题的。主题是一个抽象概念，简单地说就是与业务相关的数据的类别，每一个主题基本 对应一个宏观的分析领域。数据仓库被设计成辅助人们分析数据。例如，一个公司要分析销售数据，就可以建立一个专注于销售的数据仓库，使用这个数据仓库，就可以回答类似于“去年谁是我们这款产品的最佳用户”这样的问题。这个场景下的销售，就是一个数据主题，而这种通过划分主题定义数据仓库的能力，就使得数据仓库是面向 主题的。主题域是对某个主题进行分析后确定的主题的边界，如客户、销售、产品都是主题域的例子
集成 集成的概念与面向主题是密切相关的。还用销售的例子，假设公司有多条产品线和多种产品销售渠道，而每个产品线都有自己独立的销售数据库。此时要想从公司层面整体分析销售数据，必须将多个分散的数据源统一成一致的、无歧义的数据格式后，再放置到数据仓库中。因此数据仓库必须能够解决诸如产品命名冲突、计量单位不一致等问题。当完成了这些数据整合工作后，该数据仓库就可称为是集成的。
随时间变化 为了发现业务变化的趋势、存在的问题，或者新的机会，需要分析大量的历史数据。这与联机事务处理(OLTP)系统形成鲜明的对比。联机事务处理反应的是当前时间点的数据情况，要求高性能、高并发和极短的响应时间，出于这样的需求考虑，联机事务处理系统中一般都将数据依照活跃程度分级，把历史数据迁移到归档数据库 中。而数据仓库关注的是数据随时间变化的情况，并且能反映在过去某个时间点的数据是怎样的。换句话说，数据仓库中的数据是 反映了某一历史时间点的数据快照，这也就是术语“随时间变化”的含义。当然，任何一个存储结构都不可能无限扩展，数据也不可能只入不出地永久驻留在数据仓库中，它在数据仓库中也有自己的生命周期。到了一定时候，数据会从数据仓库中移除。移除的方式可能是将细节数据汇总后删除、将老的数据转储到大容量介质后删除和直接物理删除等。
非易失 非易失指的是，一旦进入到数据仓库中，数据就不应该再有改变。操作型环境中的数据一般都会频繁更新，而在数据仓库环境中一般并不进行数据更新。当改变的操作型数据进入数据仓库时会产生新的记录，这样就保留了数据变化的历史轨迹。也就是说，数据仓库中的数据基本是静态的。这是一个不难理解的逻辑概念。数据仓库的目的就是要根据曾经发生的事件进行分析，如果数据是可修改的，将使历史分析变得没有意义。
粒度 数据仓库还有一个非常重要的概念就是粒度。粒度问题遍布于数据仓库体系结构的各个部分。粒度是指数据的细节或汇总程度，细节程度越高，粒度级别越低。例如，单个事务是低粒度级别，而全部一个月事务的汇总就是高粒度级别。 数据粒度一直是数据仓库设计需要重点思考的问题。在早期的操作型系统中，当细节数据被更新时，几乎总是将其存放在最低粒度级别上;而在数据仓库环境中，通常都不这样做。例如，如果数据被装载进数据仓库的频率是每天一次，那么一天之内的数据更新将被忽略。 粒度之所以是数据仓库环境的关键设计问题，是因为它极大地影响数据仓库的数据量和可以进行的查询类型。粒度级别越低，数据量越大，查询的细节程度越高，查 询范围越广泛，反之亦然。 大多数情况下，数据会以很低的粒度级别进入数据仓库，如日志类型的数据或单击流数据，此时应该对数据进行编辑、过滤和汇总，使其适应数据仓库环境的粒度级别。如果得到的数据粒度级别比数据仓库的高，那将意味着在数据存入数据仓库前，开发人员必须花费大量设计和资源来对数据进行拆分。
现在你应该已经熟悉了数据仓库的概念，那么数据仓库里的数据从哪里来呢?通常数据仓库的数据来自各个业务应用系统。业务系统中的数据形式多种多样，可能是:
Oracle、MySQL、SQL Server等关系数据库里的结构化数据，可能是文本、CSV等平面文件Word、Excel文档中的非结构化数据，还可能是HTML、XML等自描述的半结构化数据。 这些业务数据经过一系列的数据抽取、转换、清洗，最终以一种统一的格式装载进数据仓库。数据仓库里的数据作为分析用的数据源，提供给后面的即席查询、 分析系统、数据集市、报表系统、数据挖掘系统等。从以上描述可以看到，从存储的角度看，数据仓库里的数据实际上已经存在于业务应用系统中，那么为什么不能直接操作业务系统中的数据用于分析，而要使用数据仓库呢?实际上在数据仓库技术出现前，有很多数据分析的先驱者已经发现，简单的“直接访问”方式很难良好工作，这样做的失败案例数不胜数。
下面列举一些直接访问业务系统无法工作的原因:
某些业务数据由于安全或其他因素不能直接访问。业务系统的版本变更很频繁，每次变更都需要重写分析系统并重新测试。很难建立和维护汇总数据来源于多个业务系统版本的报表。业务系统的列名通常是硬编码，有时仅仅是无意义的字符串，这让编写分析系统更加困难。业务系统的数据格式，如日期、数字的格式不统一。业务系统的表结构为事务处理性能而优化，有时并不适合查询与分析。没有适当的方式将有价值的数据合并进特定应用的数据库。没有适当的位置存储元数据。用户需要看到的显示数据字段，有时在数据库中并不存在。通常事务处理的优先级比分析系统高，所以如果分析系统和事务处理运行在同一硬件之上，分析系统往往性能很差。有误用业务数据的风险。极有可能影响业务系统的性能。在辅助战略决策层面，数据仓库的重要性更加凸显。
下面简单总结一下使用数据仓库的好处:
将多个数据源集成到单一数据存储，因此可以使用单一数据查询引擎展示数据。缓解在事务处理数据库上因执行大查询而产生的资源竞争问题。维护历史数据。 通过对多个源系统的数据整合，使得在整个企业的角度存在统一的中心视图。通过提供一致的编码和描述，减少或修正坏数据问题，提高数据质量。一致性地表示组织信息。提供所有数据的单一通用数据模型，而不用关心数据源。重构数据，使数据对业务用户更有意义。向复杂分析查询交付优秀的查询性能，同时不影响操作型系统。开发决策型查询更简单。[Book]Hadoop构建数据仓库实践, 第一章第一节 —— 什么是数据仓库
