一、数据仓库的定义
著名的数据仓库专家 W.H.Inmon 在《Building the Data Warehouse》一书中将数据仓库定义为：数据仓库（Data Warehouse）是一个面向主题的、集成的、相对稳定的、且随时间变化的数据集合，用于支持管理决策。
数据仓库从传统数据库系统发展而来，但是数据库仓库中的数据是按照一定的主题域进行组织的。主题是一个抽象概念，是指用户使用数据仓库进行决策时所关心的重点方面。数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改和删除操作很少，通常只需要定期地加载、刷新。数据仓库是专门为数据分析设计的，涉及读取大量数据以了解数据之间的关系和趋势。
1、数据仓库与数据库的对比
比较项目 | 传统数据库 | 数据仓库 |
数据内容 | 当前值 | 历史的、归档的、归纳的、计算的数据 |
数据目标 | 面向业务操作程序、重复操作 | 面向主题域，分析应用 |
数据特向 | 动态变化、更新 | 静态、不能直接更新，只能定时添加、更新 |
数据捕获 | 针对连续写入操作进行了优化，因为新数据能够最大程度地提高事务吞吐量 | 批量写入操作通常按照预定的批处理计划执行 |
数据标准化 | 高度标准化的静态 Schema | 非标准化 Schema，例如星型 Schema 或雪花型 Schema |
数据存储 | 针对在单行型物理块中执行高吞吐量写入操作进行了优化 | 使用列式存储进行了优化，可实现轻松访问和高速查询性能 |
二、数据仓库的传统应用架构
数据仓库被大众观点接受的架构如上图所示，分为数据源、数据的存储与管理、OLAP服务器、前端工具等。
（1）数据源。是数据仓库系统的基础，是整个系统的数据源泉。通常包括企业内部信息和外部信息。内部信息包括存放于 RDBMS（关系型 DBMS）中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等。
（2）数据的存储与管理。是整个数据仓库系统的核心。数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。要决定采用什么产品和技术来建立数据仓库的核心，则需要从数据仓库的技术特点着手分析。针对现有各业务系统的数据，进行抽取、清理，并有效集成，按照主题进行组织。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库（通常称为数据集市）。
（3）OLAP 服务器。在线分析处理（Online Analytical Processing，OLAP）技术是大数据中快速解决多维分析问题的方法之一。由于OLAP需要快速读取大量数据，因此它对数据的读取吞吐量和计算效率有很高的要求。目前，基于大数据的OLAP技术一般从面向读的存储优化、预计算、支持灵活分析等方面不断提高，近几年出现了很多令人激动的产品。对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。其具体实现可以分为：ROLAP、MOLAP 和 HOLAP。
（4）前端工具。主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具及各种基于数据仓库或数据集市的应用开发工具。其中数据分析工具主要针对 OLAP 服务器，报表工具、数据挖掘工具主要针对数据仓库。
三、数据仓库的发展
数据仓库在建设过程中，由于整体大数据经验较少，很多时候数据管理员将数据粗暴的写入数据仓库中，然后发现应用程序并不能高效的获取想要的数据，然后对数据仓库的建设进行的重构，经历了以下几个阶段：
1、混乱时段
这个阶段数据没有经过有效的组织和管理，可能表现为数据冗余、数据不一致和数据缺失等问题，上层应用程序并且不能获取到想要的数据，需要自己进行数据加工以及处理。
2、数据分层阶段
为了解决混乱时段的问题，将数据按照主题和业务逻辑进行分层，建立数据模型和架构，使数据更加清晰和有条理。但现在对数据分层并没有一个统一的定论，很多厂商使用的分层理论都有一些细微区别，但是整体来说，有几个层次是所有数据仓库建设过程中必须考虑的。
他们自下而上分别为：
a).数据操作层 ODS （Operational Data Store）
是最接近数据源中数据的一层，数据源中的数据，经过抽取、洗净、传输，也就是ETL之后写入。本层的数据，总体上大多是按照源头业务系统的分类方式而分类的。比如一些订单、日志、组织架构等原始的业务数据。ODS数据却不等同于原始数据，在源数据写入时，要进行清洗（例如异常出货日志）、去重、维度提取、单位统一（金额单位、SKU单位）、删减字段（仅用于业务系统，但是在数据挖掘中不需要的字段）
b).数据明细层DWD（Data Warehouse Detail)
保持和ODS层一样的数据粒度，并且提供一定的数据质量保证。在该层也会做一部分的数据聚合，将相同主题的数据汇集到一张表中，提高数据的可用性。在这个层次中，基于维表建模，明细宽表。
c).数据服务层DWS （Data Warehouse Service)
数据集市或宽表。按照业务划分，如订单、账务等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。该层特点表少、表的字段较多，因此一般也会称该层的表为宽表。如果为了保证查询数据的效率以及提供数据的并发查询能力，可以直接将这个层次的数据投递到Redis、Elasticsearch等在线数据库中。
3、离线加工阶段
数据分层后，需要对数据进行加工和处理，包括数据清洗、数据转换和数据整合等，这个过程通常在离线状态下进行，因此称为离线加工阶段。
- 离线数据仓库主要基于Hive（可以将结构化的数据文件映射为一张表，并提供类SQL查询功能，将SQL映射为计算引擎运算逻辑）等技术来构建T+1的离线数据
- 通过定时任务每天拉取增量数据导入到Hive表中
- 创建各个业务相关的主题维度数据，对外提供T+1的数据查询接口
4、实时数仓阶段
随着业务需求的发展，需要对数据进行实时处理和快速响应，这就需要建立一个实时数仓，将实时数据处理与离线数据处理结合起来，为业务提供更加及时和准确的数据支持。
- 实时数仓基于数据采集工具，将原始数据写入到KafKa、Redis等数据通道
- 数据最终写入到类似于HBase这样支持快速读写的存储系统
- 对外提供分钟级别、甚至秒级别的查询方案
在真实生产使用过程中，离线数仓与实时数仓并没有完全分离开来，实时数仓的数据也可以定期保存到离线数仓里面去，离线数仓的数据也可以通过数据同步工具投递到实现数仓中，便于应用查询。由此可以构建出大数据处理框架中著名的Lambad架构：
可以看出Lambad架构，实时流式处理层与离线批处理层，由于数据处理的时效性不同，很难做到数据的一致性，造成两边的数据不能进行联合应用。并且这种架构需要实现的链路太多，使用的组件种类也很多，造成的学习成本过高，不利于公司大数据平台的发张，由此提出的Kappa架构：
Kappa架构直接抛弃了离线数仓，只保留了一条链路，解决了Lambad架构中的问题，但是使用Kafak来做数据存储中心，也有几个明显的缺陷。
- Kafka无法支持海量数据存储。对于海量数据量的业务线来说，Kafka一般只能存储非常短时间的数据，比如最近一周，甚至最近一天。
- Kafka无法支持高效的OLAP查询，大多数业务都希望能在DWD\DWS层支持即席查询的，但是Kafka无法非常友好地支持这样的需求。
- Kafka不支持update/upsert，目前Kafka仅支持append。
四、数据湖的诞生
由数据仓库的架构图可以看出来，数据的来源多种多样。并且不同类型的数据，需要不同的组件对数据进行加工然后放入数据仓库。然后在加工过程中，会对原始数据进行一系列的数据加工，形成了结构化的数据，会造成一部分数据的丢失，并且很多非结构化的数据，也不能再数据仓库中保留下来，比如一些日志文件等。如果丢失的那部分数据也是可以提供价值的数据，对企业来说，也是一种损失。
由此数据湖的概念被提出，数据湖是一种在系统或存储库中以自然格式存储数据的方法，它有助于以各种模式和结构形式配置数据，通常是对象块或文件。数据湖的主要思想是对企业中的所有数据进行统一存储，从原始数据（源系统数据的精确副本）转换为用于报告、可视化、分析和机器学习等各种任务的目标数据。数据湖中的数据包括结构化数据（关系数据库数据），半结构化数据（CSV、XML、JSON等），非结构化数据（电子邮件，文档，PDF）和二进制数据（图像、音频、视频），从而形成一个容纳所有形式数据的集中式数据存储。
数据湖从本质上来讲，是一种企业数据架构方法，物理实现上则是一个数据存储平台，用来集中化存储企业内海量的、多来源，多种类的数据，并支持对数据进行快速加工和分析。从实现方式来看，目前Hadoop是最常用的部署数据湖的技术，但并不意味着数据湖就是指Hadoop集群。为了应对不同业务需求的特点，MPP数据库+Hadoop集群+传统数据仓库这种“混搭”架构的数据湖也越来越多出现在企业信息化建设规划中。