第1章和第2章介绍了数据驱动组织的概念，并在大数据计划的背景下定义了数据操作的概念。现在，是时候退一步，探索一些其他基本但重要的概念了。在这一点上，我们最重要的任务之一是清楚地描述数据仓库和数据湖之间的区别。
当我谈论自助服务数据时，不可避免地会出现问题。数据湖和数据仓库的区别是什么？我需要在两者之间做出选择还是两者都需要？在数据仓库和数据湖之间建立关系的当前最佳实践是什么？本章回答了这些问题以及更多的问题，并详细解释了为什么在各种技术目前的成熟状态下，使用数据湖来扩充现有的数据仓库是最好的选择。
数据仓库：一个最基本的定义.
数据仓库是组织业务系统中收集的所有数据的中央存储库。数据被提取、转换和加载（称为ETL）到数据仓库中，该数据仓库支持在此提取和管理的数据集上进行报告、分析和数据挖掘的应用程序（图3-1）。上一代数据基础设施以数据仓库为中心，基于Teradata、Oracle、Neteeza、Greenplum和Vertica等技术。
图3-1.一个典型的数据仓库
在过去，企业将获取原始数据和处理过的数据；使用从头开始、Informatica等引擎对其执行ETL；然后将其加载到数据仓库中，供业务分析师或用户使用。然而，随着数据量的增加，这种方法产生了两个问题：第一，分析人员无法访问原始数据，只能使用从数据仓库中提取的子集；第二，在数据仓库中只能处理结构化数据。没有使用非结构化信息的深度学习应用程序或分析是可行的。这两个问题都在使数据和处理变得更广泛方面造成了严重的限制。
在以数据仓库为中心的世界中，如果数据仓库中定义的数据结构不适合您的分析，或者您希望分析非结构化内容，那么您只是运气不佳。您需要与数据团队联系以提交您的数据请求，等待它拥有原始数据集，对它们进行处理，并派生出您感兴趣的信息和结构。然后，等待数据团队将其加载到数据仓库中。这是一个非常缓慢的过程。
由于所有这些和更多的原因，在现代数据体系结构中只拥有一个数据仓库来支持数据驱动的企业根本不是最优的。
什么是数据湖？
早在2010年，Pentaho的创始人兼首席技术官詹姆斯迪克森（James Dixon）就首次提出了data lake这个词。狄克逊认为，数据湖是一个存储库，它保存大量原始数据，并以其原始格式保存到需要时为止。
数据湖从两个方面解决了数据仓库的缺点。首先，在数据湖中，数据可以以结构化、半结构化或非结构化格式存储。其次，数据模式取决于数据的读取，而不是加载或写入。因此，如果您需要原始数据中的额外信息或结构，则可以始终更改模式，从而提高组织的灵活性。这也意味着数据是快速可用的，因为它不必在被处理引擎使用之前进行处理。
由于数据湖具有成本效益，因此无需丢弃或存档原始数据。它总是应该有你的任何用户想要重新访问它。
所有这些要点都是：所有内容的经济高效的存储、结构化和非结构化数据上不同类型的处理能力、数据的快速可用性、灵活性和灵活性，这些都是组织走向自助服务数据基础架构时必不可少的（请参见图3-2）。
图3-2. 数据湖的优势
数据湖和数据仓库之间的差异
越来越多的企业正在用数据湖扩充数据仓库，使其大数据真正实现自助服务。数据湖和数据仓库之间有八个基本区别。
以下是其中最重要的一个：
- 进入数据的类型
- 数据在接收过程中要进行多少处理
- 可以对这些数据进行多少不同类型的处理
图3-3显示了数据湖和数据仓库之间的主要区别。
数据仓库之所以继续流行，是因为它们是非常成熟的技术，从20世纪90年代就开始出现了。此外，它们与业务分析师和用户在使用仪表板或其他类型的机制时已经习惯的工具配合良好，通过这些机制，他们可以从常驻数据中获取见解。事实上，对于某些用例，数据仓库表现得非常好，因为数据是完全管理和结构化的，能够快速地回答某些查询模式。
图3-3. 数据湖和数据仓库之间的差异
因此，数据仓库继续在大多数组织中占据主导地位。但越来越多的企业遇到了我们前面提到的障碍。为了克服这些问题，他们正在用数据湖来扩充数据仓库，以使他们的大数据真正实现自助服务。在许多情况下，lake可以作为数据仓库的暂存区域，然后充当要分析的更精确的数据。
当Facebook的数据仓库失去动力时。
2007年我第一次来到Facebook时，我们只有一个数据仓库，由中央数据团队管理和维护。但事实证明，这限制了Facebook从收集的所有数据中获得的可操作洞察力的数量。
尽管数据团队会执行ETL并将数据加载到数据仓库中，但数据量增长得如此之快，以至于在加载了计划版本之后，团队不得不丢弃原始数据。
通过创建一个基于Hadoop的数据湖，Facebook能够将其所有数据加载到仍然集中的存储库中，并且通过架构的读模式特性，Facebook能够向我们的数据湖添加不同的处理引擎，支持不同类型的分析，更快地提供更多数据，并为所有员工创建灵活的自助服务模型，而无需删除或存档任何原始数据。
是在使用一种策略还是一种可能的策略？
在我定义了数据湖和数据仓库之间的区别之后，总会出现另一个问题：您真的需要两者，还是可以使用其中一个来解决您的数据自助服务计划？这个问题的答案现在不是“不”。考虑到所涉及技术的成熟阶段，您需要两者。
的确，数据仓库正在慢慢积累以前仅在数据湖中发现的许多特性。但是，规模经济是这样的，即使你能够在数据仓库中使用大数据做所有你需要的事情，它也会非常昂贵，以至于你很快就会希望除了数据仓库之外，你还创建了一个单独的数据湖。此外，由于采用并使用模式定义来优化存储的体系结构，传统数据仓库技术要转变为数据湖就更困难了。它们在体系结构上也基于与其处理引擎强耦合的专有存储格式，而创建一个数据湖可以支持的更为解耦的体系结构是非常难以实现的。
另一方面，随着Hadoop体系结构在开放源代码世界中的变形和成熟，它们也在借鉴数据仓库中已经流行的概念，例如列格式和用于提高速度的特殊处理引擎。事实上，随着时间的推移，这些体系结构已经开始合并，这样一个体系结构就可以包含当今支持大数据分析所需的高性能、低成本和高度集成的功能。Presto和Impala这样的引擎的出现专门解决了Hadoop和Hive等开源技术传统上所面临的数据湖性能问题。
常见的误解
当我谈到数据湖和数据仓库时，我发现一些常见的误解存在，甚至在技术成熟的设计师、架构师和工程师中也是如此。这里有一些。
数据仓库死了
关于数据仓库与数据湖关系的一个最常见的误解是，拥有数据湖之后，就不再需要数据仓库了。也就是说，一旦达到数据湖的最终目标，就可以关闭数据仓库。虽然世界正朝着这个方向发展，但目前情况并非如此。数据湖并不支持数据仓库所做的一切。主要关注的是与生态系统工具的集成日趋成熟。数据仓库作为上一代的技术，在与商业智能（BI）、ETL和其他基于SQL的数据工具的集成方面更为成熟。数据湖在这方面仍在成熟。
数据仓库将成为数据湖
另一些人认为，随着数据仓库开始增加数据湖的功能，不需要完整的数据湖。这也是一个谬论，鉴于数据仓库技术（在本节后面提到）固有的体系结构耦合，这是不太可能的结果。走上这条道路的组织最终会意识到，如果他们建立了一个数据湖，他们本可以做得更具成本效益，而且会成为一个更灵活的企业。或许最重要的是，它们在分析数据仓库的类型上可能非常有限。
正如第2章告诉我们的，有四种不同类型的分析：描述性、诊断性、预测性和规定性，如图3-4所示。
图3-4 分析价值金字塔
尽管SQL查询可以覆盖其中一些类型的分析，特别是在描述和诊断领域，但它们不能覆盖所有类型的分析。对于那些希望从大数据计划中获得最大收益的公司来说，这是一个严重的限制。
在数据湖架构中，不同的处理引擎和不同类型的分析之所以可能是因为数据格式与处理引擎的考虑因素是分离的。在数据湖中，数据以开放格式存储，如逗号分隔值（CSV）或JavaScript对象表示法（JSON，一种开放标准格式，使用人类可读文本来传输由属性-值对组成的数据对象）或压缩稀疏格式（CSC），而不是耦合到处理引擎的封闭格式。这意味着在相同的原始数据上，可以应用不同的数据处理引擎。
相反，对于数据仓库，在数据以该技术专有的格式构造和存储之后，不可能使用专有SQL引擎以外的引擎来处理它。
例如，将数据放入Vertica数据仓库。以Vertica列格式显示后，数据只能由Vertica的处理引擎理解。您不能获取存储在该环境中的数据并在其上应用深度学习或机器学习工具包。您必须从Vertica中提取它并将其输入这些库中的任何一个，这是一个固有的耗时过程，需要数据团队的帮助。
在数据湖中，由于数据处理引擎与数据断开连接，您可以选择使用哪个引擎来分析数据。您可以使用Spark进行机器学习，或者在同一个开放格式数据集上使用Google的TensorFlow，或者在开放数据格式中使用自然语言处理（NLP）库。
难以找到合格人员
一个组织在构建数据湖时面临的最大挑战之一是寻找合格的人员。您现有的数据团队将非常熟悉数据仓库，它们已经存在了很长一段时间，相当成熟，并且与数据工具的生态系统有很强的集成。
但数据湖架构还不成熟。在这一领域，技术仍在不断发展，因此很难找到专门知识。通常，数据湖项目由数据工程团队发起。这给使用数据湖的所有用例使用自助基础设施带来了挑战。
所以，创建一个数据湖需要更多的人和专业知识，正是因为它的不成熟，而有限的时间数据湖到目前为止才在公众意识中出现了6年多。此外，管理数据湖的操作工具也在不断发展，尽管它们在过去几年中取得了重大进展。在管理访问控制、监控成本、根据使用情况向不同团队分配计费、管理存储使用情况以及管理数据湖的其他方面都取得了很大进展。但对于公司来说，从运营的角度支持数据湖仍然困难得多。
摘要
总之，数据湖为组织特性提供了更多的灵活性和灵活性，这些特性对于构建数据驱动企业非常重要。与尝试使用数据仓库相比，他们能够以很小的成本完成这项工作。在许多方面，数据仓库正在变成过去一年的数据集市。另一方面，数据湖架构不太成熟，可能具有显著的操作复杂性。然而，云在降低复杂性方面扮演着重要角色，因此每个企业都可以期望在数据基础架构战略中包含一个数据湖架构。有了云和基于云的数据湖软件即服务平台，组织可以消除操作的复杂性，同时在构建数据湖架构时享受巨大的总体拥有成本效益。我们将在第6章中对此进行更详细的介绍。
