随着数据量、速度和种类的增加，选择合适的数据平台来管理数据从未像现在这样重要。它应该是迄今为止满足我们需求的古老数据仓库，还是应该是承诺支持任何类型工作负载的任何类型数据的数据湖？
在这里，我们深入探讨了这两个平台。
数据湖
数据湖是一个中央存储库，可以大量存储所有数据（结构化和非结构化数据）。数据通常以原始格式存储，无需首先进行处理或结构化。在这种情况下，它可以针对手头的目的进行优化和处理，无论是交互式分析、下游机器学习或分析应用程序的仪表板。
可以这样想，数据湖就像一个大水体，比如说一个处于自然状态的湖。数据湖是使用来自各种来源的数据流创建的，然后，多个用户可以来到湖中对其进行检查并取样。数据湖的美妙之处在于每个人都在查看和操作相同的数据。消除多个数据源并在数据湖中拥有一个可引用的“黄金”数据集来保障组织内的一致性，因为用于访问组织中智能的任何其他下游存储库或技术都将同步。这很关键。使用这种集中的数据源，就不会从不同的孤岛中提取数据；组织中的每个人都有一个单一的事实来源。
该模式为公司的分析生命周期提供了近乎无限的能力：
摄取：数据以任何原始格式到达并存储以供将来分析或灾难恢复。公司通常会根据隐私、生产访问以及将利用传入信息的团队来划分多个数据湖。
存储：数据湖允许企业管理和组织几乎无限量的信息。云对象存储以较低的成本为大数据计算提供高可用性访问。
流程：借助云计算，基础设施现在只需一个 API 调用即可。这是从数据湖中的原始状态获取数据并格式化以与其他信息一起使用的时候。这些数据也经常使用高级算法进行聚合、合并或分析。然后将数据推回数据湖以供商业智能或其他应用程序存储和进一步使用。
消费：当我们谈论自助服务数据湖时，消费通常是生命周期中的阶段。此时，数据可供业务和客户根据需要进行分析。根据复杂用例的类型，最终用户还可以间接或直接以预测（预测天气、财务、运动表现等）或感知分析（推荐引擎、欺诈检测、基因组测序、 ETC）。
数据湖支持原生流，数据流在其中被处理并在到达时可用于分析。数据管道在从数据流接收数据时转换数据，并触发分析所需的计算。数据湖的原生流式传输特性使其非常适合流式分析。
数据仓库
数据仓库发明于1980 年底，专为业务应用程序生成的高度结构化数据而设计。它将组织的所有数据集中在一起并以结构化方式存储。它通常用于连接和分析来自异构来源的数据。
数据仓库架构依赖于数据结构来支持高性能的 SQL（结构化查询语言）操作。数据仓库是专门为基于 SQL 的访问而构建和优化的，以支持商业智能，但为流分析和机器学习提供有限的功能。它们受到 ETL 要求的限制，需要在存储数据之前对其进行预处理。
数据仓库在数据用于分析之前需要顺序 ETL摄取和转换数据，因此它们对于流式分析效率低下。一些数据仓库支持“微批处理”以经常以小增量收集数据。它支持顺序 ETL 操作，其中数据以瀑布模型从原始数据格式流向完全转换的集合，并针对快速性能进行了优化。
数据仓库以专有格式存储数据。一旦数据存储在数据仓库中，对该数据的访问仅限于 SQL 和数据仓库提供的自定义驱动程序。一些较新的数据仓库支持半结构化数据，例如 JSON、Parquet 和 XML 文件；与结构化数据集相比，它们对此类数据集的支持有限且性能下降。数据仓库不能完全支持存储非结构化数据。
数据湖和数据仓库之间的区别
数据仓库和商业智能工具支持历史数据的报告和分析，而数据湖支持利用数据进行机器学习、预测和实时分析的新用例。
虽然一些数据仓库扩展了基于 SQL 的访问以提供机器学习功能，但它们不提供原生支持来运行广泛可用的程序化数据处理框架，例如 Apache Spark、Tensorflow 等。
相比之下，数据湖是机器学习用例的理想选择。它们不仅提供基于 SQL 的数据访问，还通过 Python、Scala、Java 等语言为 Apache Spark 和 Tensorflow 等编程分布式数据处理框架提供原生支持。
数据仓库需要在数据用于分析之前顺序 ETL摄取和转换数据，因此它们对于流式分析效率低下。一些数据仓库支持“微批处理”以经常以小增量收集数据。这种流到批处理的转换增加了数据到达与用于分析之间的时间，使得数据仓库不适用于多种形式的流分析。
数据湖支持本地流式传输，其中数据流在到达时被处理并可供分析。数据管道在从数据流接收数据时转换数据，并触发分析所需的计算。数据湖的原生流式传输特性使其非常适合流式分析。
数据仓库支持顺序 ETL 操作，其中数据以瀑布模型从原始数据格式流向完全转换的集合，并针对快速性能进行了优化。
相比之下，对于需要持续数据工程的用例，数据湖异常强大。在数据湖中，ETL 的瀑布方法被迭代和连续的数据工程所取代。可以通过 SQL 和编程接口迭代地访问和转换数据湖中的原始数据，以满足用例不断变化的需求。这种对持续数据工程的支持对于交互式分析和机器学习至关重要。
揭穿关于数据湖和数据仓库的三大神话
让我们解决一些关于两种流行的数据存储类型的常见误解：
误区一：只需要数据湖或数据仓库中的一个
如今，经常听到人们谈论数据湖和数据仓库，好像企业必须选择其中一个。但现实情况是，数据湖和数据仓库服务于不同的目的。虽然两者都提供数据存储，但它们使用不同的结构，支持不同的格式，并针对不同的用途进行了优化。通常，公司可能会从使用数据仓库和数据湖中受益。
数据仓库最适合希望为商业智能分析操作系统数据的企业。数据仓库在这方面工作得很好，因为存储的数据是结构化、清理和准备分析的。同时，数据湖允许企业以任何格式存储数据以用于几乎任何用途，包括机器学习 (ML) 模型和大数据分析。
误区 2：数据湖是流行趋势，数据仓库不是
人工智能 (AI) 和 ML 代表了一些增长最快的云工作负载，组织越来越多地转向数据湖来帮助确保这些项目的成功。由于数据湖允许存储几乎任何类型的数据（结构化和非结构化）而无需事先准备或清理，因此组织能够保留尽可能多的潜在价值以供将来使用，未指定使用。此设置非常适合更复杂的工作负载，例如尚未确定具体数据类型和用途的机器学习模型。
数据仓库可能是这两种选择中更为人所知的一种，但数据湖和类似类型的存储基础设施可能会随着数据工作负载的趋势而继续流行。数据仓库适用于某些类型的工作负载和用例，而数据湖代表了服务于其他类型工作负载的另一种选择。
误区三：数据仓库易于使用，而数据湖很复杂
数据湖需要数据工程师和数据科学家的特定技能来分类和利用其中存储的数据。数据的非结构化性质使得那些不了解数据湖如何工作的人更不容易访问它。
但是，一旦数据科学家和数据工程师构建了数据模型或管道，业务用户通常可以利用与流行业务工具的集成（自定义或预构建）来探索数据。同样，大多数业务用户通过连接的商业智能 (BI) 工具访问存储在数据仓库中的数据。在第三方 BI 工具的帮助下，业务用户应该能够访问和分析数据，无论该数据存储在数据仓库还是数据湖中。
构建现代数据平台的原则
尽量减少数据平台中人员、网络和磁盘操作的影响。虽然人类永远无法像计算机一样快，但网络和磁盘操作是客观问题。为了减少这些问题的影响，避免在各处复制数据，加强平台读取和处理来自不同位置的数据的能力，包括事务性、发布/子系统和数据仓库系统，而无需当天移动。构建现代数据平台的原则是：
- 把事情简单化，不要过度架构或过度设计；
- 为正确的工作使用正确的工具；
- 让用例决定你应该使用什么；
- 使用云进行扩展；
- 将数据与上下文分开，这将使数据能够用于多个用例。
数据湖和数据仓库：用例
Data Lake 已经成为一个强大的平台，企业可以使用它来管理、挖掘大量非结构化数据并将其货币化，以获得竞争优势。因此，公司对数据湖平台的采用率急剧增加。
在这种利用大数据的热潮中，一直存在一种误解，即 Data Lake 旨在取代数据仓库，而实际上，Data Lake 旨在补充传统的关系数据库管理系统 (RDBMS)。
数据仓库适用于某些类型的工作负载和用例，而数据湖代表了服务于其他类型工作负载的另一种选择。
用例应该驱动数据平台架构。如果您的用例需要速度、具有已知的数据模型、完全结构化或非常接近它，那么 SQL 数据仓库就足够了。但是，如果您需要及时灵活地对数据进行建模并将其用于多种工作负载，您应该使用数据湖。
组织将依靠多种技术的最佳解决方案，包括数据仓库和数据湖。最终，组织的选择需要平衡管理多种技术的复杂性和 TCO 与以高性能和经济高效的方式运行更多种类的工作负载的能力。
未来该如何选择
我们现在处于这样一个阶段，我们不仅可以使用数据来回顾过去，还可以了解现在，甚至可以预测未来。数据和工具将不断发展，以帮助我们几乎实时地到达那里。
将数据与上下文分开。进来的数据不一定有你想用它的上下文。所以，在弄清楚你想用它做什么之前，把将数据获取到一个位置的想法分开。因为实际上，您将对该数据进行多种用途。因此，您永远不知道您可以将这些数据用于什么用途。因此，如果您首先获取数据，然后弄清楚您想用它做什么，通常会导致使用这些数据产生更积极的结果。
数据仓库供应商正在逐渐从他们现有的模型转向数据仓库和数据湖模型的融合。同样，数据湖的供应商现在正在扩展到数据仓库领域，双方正在趋同。例如，BigQuery 现在允许组织在 Amazon S3 上查询数据。同样，Databricks 和 Qubole 等数据湖平台现在正在果断地转向数据仓库用例。您可以使用 ACID 属性、事务一致性、快照等来管理存储，并将查询引擎更多地与存储管理集成，为客户创建湖仓模式。数据湖和数据仓库之间的融合不仅仅是在谈论，而是正在现实中应用。
