数据湖和数据仓库的对比_关于数据仓库和数据湖的主要差别,以下哪项描述是不正确的

定义

看下维基百科的定义：

A data lake is a system or repository of data stored in its natural/raw format, usually object blobs or files. A data lake is usually a single store of data including raw copies of source system data, sensor data, social data etc.and transformed data used for tasks such as reporting, visualization, advanced analytics and machine learning. A data lake can include structured data from relational databases (rows and columns), semi-structured data (CSV, logs, XML, JSON), unstructured data (emails, documents, PDFs) and binary data (images, audio, video).A data lake can be established “on premises” (within an organization’s data centers) or “in the cloud” (using cloud services from vendors such as Amazon, Microsoft, or Google).

A data swamp is a deteriorated and unmanaged data lake that is either inaccessible to its intended users or is providing little value.

大概的意思：数据湖是一个以原始格式(通常是对象块或文件)存储数据的系统或存储库。数据湖通常是所有企业数据的单一存储。用于报告、可视化、高级分析和机器学习机器学习等任务。数据湖可以包括来自关系数据库的结构化数据(行和列)、半结构化数据(CSV、日志、XML、JSON)、非结构化数据(电子邮件、文档、pdf)和二进制数据(图像、音频、视频)。

数据沼泽是一个恶化且不受管理的数据湖，其目标用户无法访问或提供的价值很小

定义中的重点内容我用红色字体标注出来，简单说明一下这几点。

• 原始格式：数据不做预处理，保存数据的原始状态
• 单一存储：存储库中会汇总多种数据源，是整个企业数据的唯一存储
• 用于机器学习：除了 BI 、报表分析，数据湖更适用于机器学习

数据湖并不是新概念，最早 2015 年就被提出来了，可以看到数据湖经常被拿来跟目前的数据仓库作比较。至于为什么数据湖慢慢走近大家的视野，并且越来越多的跟仓库作比较。我认为主要是跟机器学习的广泛应用有很大关系。

数据湖和数据仓库的对比

大数据刚兴起的时候，数据主要用途是 BI 、报表、可视化。因此数据需要是结构化的，并且需要 ETL 对数据进行预处理。这个阶段数据仓库更适合完成这样的需求，所以企业大部分需要分析的数据都集中到数据仓库中。而机器学习的兴起对数据的需求更加灵活，如果从数据仓库中提数会有一些问题。比如：数据都是结构化的；数据是经过处理的可能并不是算法想要的结果；算法同学与数仓开发同学沟通成本较大等。我在工作中就遇到这种情况，做算法的同学需要经常理解我们的数仓模型，甚至要深入到做了什么业务处理，并且我们的处理可能并不是他们的想要的。基于上面遇到的各种问题，数据湖的概念应运而生。下面的表格对比一下数据湖和数据仓库的区别 。

从以上表格的区别上我们可以看到数据湖的应用场景主要在于机器学习，并且在用的时候再建 Schema 更加灵活。虽然数据湖能够解决企业中机器学习应用方面的数据诉求，可以与数据仓库团队解耦。但并不意味着数据湖可以取代数据仓库，数据仓库在高效的报表和可视化分析中仍有优势。

附国外网站的一篇文章：

接下来，让我们重点介绍数据湖的五个关键差异因素，以及它们与数据仓库方法的差异。

1.数据湖保留所有数据

在数据仓库的开发过程中，花费了大量时间来分析数据源，理解业务流程和分析数据。结果是设计用于报告的高度结构化的数据模型。此过程的很大一部分包括决定要在仓库中包含和不包含哪些数据。通常，如果不使用数据来回答特定问题或在已定义的报告中使用数据，则可能会将其从仓库中排除。通常这样做是为了简化数据模型，并节省昂贵的磁盘存储上的空间，这些磁盘存储使数据仓库具有出色的性能。

相反，数据湖保留所有数据。不仅是今天正在使用的数据，而且可能只是因为某天可能要使用的数据，甚至可能永远不会使用的数据。数据也一直保存着，这样我们就可以回到过去的任何时间进行分析。

这种方法之所以成为可能，是因为数据湖的硬件通常与数据仓库所用的硬件差异很大。商品，现成的服务器与廉价的存储相结合，使将数据湖扩展到TB和PB相当经济。

2. Data Lakes支持所有数据类型

数据仓库通常由从交易系统中提取的数据组成，并由定量指标和描述它们的属性组成。Web服务器日志，传感器数据，社交网络活动，文本和图像等非传统数据源在很大程度上被忽略。继续发现这些数据类型的新用途，但消费和存储它们可能既昂贵又困难。

数据湖方法包含这些非传统数据类型。在数据湖中，我们保留所有数据，无论其来源和结构如何。我们将其保留为原始格式，只有在准备使用它时才对其进行转换。与数据仓库中使用的“写入时的架构”方法相比，这种方法被称为“读取时的架构”。

3. Data Lakes支持所有用户

在大多数组织中，80％或更多的用户是“可操作的”。他们希望每天获取报告，查看关键绩效指标或在电子表格中分割同一组数据。数据仓库通常是这些用户的理想选择，因为它结构合理，易于使用和理解，并且专门用于回答他们的问题。

接下来的10％左右，对数据进行更多分析。他们使用数据仓库作为源，但经常返回源系统以获取未包含在仓库中的数据，有时还会从组织外部引入数据。他们最喜欢的工具是电子表格，他们创建新报告，这些报告通常分布在整个组织中。数据仓库是数据的首选来源，但它们往往超出其范围

最后，最后百分之几的用户进行了深入分析。他们可能会根据研究结果创建全新的数据源。他们合并了许多不同类型的数据，并提出了全新的问题要回答。这些用户可能会使用数据仓库，但通常会忽略它，因为他们通常承担超出其功能的负担。这些用户包括数据科学家，他们可能会使用高级分析工具和功能，例如统计分析和预测建模。

数据湖方法同样对所有这些用户提供了很好的支持。数据科学家可以去湖边，处理他们需要的非常大的各种数据集，而其他用户则可以使用提供给他们的数据的结构化视图。

4.数据湖轻松适应变化

关于数据仓库的主要抱怨之一是更改它们需要多长时间。在开发过程中，要花大量时间预先准备好正确的仓库结构。一个好的仓库设计可以适应变更，但是由于数据加载过程的复杂性以及简化分析和报告的工作量，这些变更必然会消耗一些开发人员资源并花费一些时间。

许多业务问题迫不及待地希望数据仓库团队适应他们的系统以回答问题。对更快的答案的不断增长的需求已经引起了自助式商业智能的概念。

另一方面，在数据湖中，由于所有数据都以原始格式存储，并且始终可供需要使用该数据的人访问，因此用户被授权超越仓库结构，以新颖的方式探索数据并回答他们的问题。以他们的步调提问。

如果探索的结果被证明是有用的并且希望重复进行，那么可以将更正式的方案应用于它，并且可以开发自动化和可重用性来帮助将结果扩展到更广泛的受众。如果确定结果无效，则可以将其丢弃，并且不对数据结构进行任何更改，也不会消耗开发资源。

5.数据湖提供更快的见解

最后一个差异实际上是其他四个的结果。因为数据湖包含所有数据和数据类型，所以它使用户能够在数据进行转换，清理和结构化之前访问数据，因此它使用户比传统的数据仓库方法更快地获得结果。

但是，这种对数据的早期访问需要付出一定的代价。对于执行分析所需的部分或全部数据源，可能无法完成数据仓库开发团队通常完成的工作。这样一来，用户就可以坐在驾驶员座位上来浏览和使用他们认为合适的数据，但是我上面描述的第一层业务用户可能不想做这项工作。他们仍然只想要他们的报告和KPI。

在数据湖中，这些操作报告使用者将利用数据湖中数据的结构化视图，这类似于他们以前在数据仓库中拥有的视图。不同之处在于，这些视图主要以元数据的形式存在，该元数据位于湖泊中的数据之上，而不是需要开发人员进行更改的刚性表。

我应该选择哪种方法？

这是一个困难的问题。如果您已经拥有完善的数据仓库，那么我当然不主张将所有工作扔到窗外并从头开始。但是，像许多其他数据仓库一样，您的数据库可能会遇到我描述的一些问题。在这种情况下，您可以选择在您的仓库旁边实施一个数据湖。仓库可以像往常一样继续运行，您可以开始向湖中填充新的数据源。您还可以将其用于存放仓库数据的归档存储库，并可以使之实际可用，以使用户可以访问比以往更多的数据。随着仓库的老化，您可以考虑将其移至数据湖，也可以继续提供混合方法。

如果您只是开始构建集中式数据平台，我敦促您考虑这两种方法。