从数据仓库到数据湖
传统上，数据仓库工具用于从数据中驱动商业智能（BI）。业界随后认识到，数据仓库通过强制schema on write限制了智能的潜力。显然，在收集数据时不能考虑到所收集数据集的所有方面，但是可能有许多其他有价值的概念，从未处理的、自然状态的数据中获得。这意味着，强制执行一个模式或删除一些看起来无用的项，从长远来看可能会损害商业智能。此外，数据仓库技术无法跟上数据增长的步伐。由于数据仓库通常基于数据库和结构化数据格式，因此它不足以应对当前数据驱动世界所面临的挑战。
因为在人工智能、机器学习和大数据的时代，数据仓库对于实时决策并不是很有用，因为处理时间长，以及其他一些缺点。这导致了数据湖的出现，这些数据湖针对非结构化和半结构化数据进行了优化，可以轻松地扩展到PB级，并允许更好地集成各种工具，以帮助企业最大限度地利用其数据。数据湖提供了一个完整和权威的数据存储，可以为数据分析、商业智能和机器学习提供动力。
数据湖是保存大量原始数据的中心位置。数据湖是企业数据的中央存储池，它接收各种数据源的的输入信息。这些源可能以非结构化、半结构化和结构化的格式包括从数据库到原始音频和视频片段的任何内容。无论格式如何，数据湖都可以广泛接受新数据。这明显不同于传统关系数据库中充满规则、高度结构化的存储（在数据仓库只存放结构化数据）。
数据仓库和数据湖在处理输入数据的方式上是不同的，如下图所示。
数据湖被划分为一个或多个数据区域，具有不同程度的转换和清洁度。其中原始区域是所有其他湖泊区域数据构建的基础。数据湖倡导的是“store now, find value later”，即先存储数据，后寻找数据的价值。
与将数据存储在文件或文件夹中的分层数据仓库相比，数据湖使用扁平架构和对象存储来存储数据。对象存储使用元数据标签和唯一标识符存储数据，便于跨分区查找和检索数据，提高性能。数据湖的建立向用户隐藏了底层数据结构和物理数据存储的复杂性。数据湖和数据仓库的一般特性对比，见下表。
| 维度 | 数据湖 | 数据仓库 |
|---|---|---|
| 数据主要类型 | 所有类型：结构化数据，半结构化数据，非结构化数据（原始数据） | 仅结构化数据 |
| 模式Schema | Schema on read 数据存储之后才需要定义Schema 提供敏捷、简单的数据集成 数据的价值尚未明确 |
Schema on write 数据存储之前需要定义Schema 数据集成之前完成大量工作 数据的价值应提前明确 |
| 成本 | ￥ | ￥￥￥ |
| 可扩展性 | 可扩展以低成本保存任意数量的数据，而不管数据类型如何 | 由于供应商成本的原因，扩展的成本将呈指数级增长 |
| 复杂性 | 复杂的大数据处理 | 复杂的SQL连接 |
| 目标用户 | 数据分析师，数据科学家 | 数据分析师 |
| 厂商锁定 | 非 | 是 |
| 优点 | 低成本，灵活性，可扩展性，允许存储机器学习所需的原始数据 | 用户接口是传统数据库用户所熟悉的 |
| 缺点 | 如果没有组织和编目数据的工具，探索大量的原始数据可能会很困难 | 昂贵的、always-on架构、专有软件，无法保存机器学习所需的非结构化(原始)数据 |
数据湖作为一个术语，通常在不同的上下文中有不同的含义，但是在所有数据湖定义中有几个重要的属性是一致的，即它们都支持以下特性：
- (1) 支持非结构化和半结构化数据。
- (2) 可扩展到PB及以上级规模。
- (3) 使用类SQL的接口与存储的数据交互。
- (4) 能够尽可能无缝地连接各种分析工具。
- (5) 现代数据湖通常是解耦存储和分析工具的组合。
从数据仓库到数据湖的过渡具有将业务逻辑与存储分离的优点，以及能够独立扩展计算和存储的能力。但在这种转变中，人们忽略了确保数据可靠性的问题。
