数据仓库能包括一个数据湖吗？

Question

我想更详细地了解数据仓库和数据湖。

在我看来，这个话题有不同的信息。Inmon将数据仓库定义为

一种面向主题、综合、时变和非易失性的数据收集，以支持管理层的决策过程。

现在我明白了，这只是一种架构形式，并不意味着任何技术。这意味着底层数据可以是任何也可以是S3对象存储的结构。此外，Waas等人基于即时智能的按需ELT体系结构:扩展视觉还提出了一个具有数据集成过程的数据仓库。

当谈到数据湖时，我发现了以下定义

可伸缩的存储存储库，保存大量原生格式的原始数据(“原样”)，直到需要时再加上可以在不损害数据结构的情况下接收数据的处理系统(引擎)。

取自数据湖治理。

现在，数据仓库能成为一个更严格的数据湖吗？有一种观点认为，数据仓库必须使用ETL，但是根据Inmon，definiten不包括对数据转换的任何限制？如果数据集成可以是ELT，并且在那里转换是灵活的，例如，它可以很容易地扩展。数据仓库看起来非常像一个数据湖。

我的假设是正确的还是从偏斜的角度看这个。

Answer 1

数据仓库和数据湖是独立的系统，它们服务于不同的目的，可以/应该是互补的，两者都是更大的数据体系结构的一部分。作为一个概念，数据湖可以仅仅是数据仓库上的维度模型的另一个数据源(尽管数据湖的技术实现可以直接查询原始数据)。

您可以将Data看作是一个“着陆区域”，其中几个系统以“复杂/原始格式”转储数据，例如来自客户支持调用的MP3文件，来自web服务器的压缩日志。它的目的是为了历史目的和进一步处理成一种易于分析/报告的格式，例如从MP3文件中提取文本。

数据仓库还聚合来自不同系统的数据，但是数据被建模成适合于报告的格式(如维度模型)，它的模型反映了业务/域的流程和事务，并且通常是高度管理的。

想象一下这样的情况:如果使用web服务器日志记录对在线商店的访问，您可以将keep日志(“事务数据”)保存在一个数据湖中，然后将数据处理为一个维度模型(如这)，该模型将是“专门为查询和分析而构造的事务数据的副本”，因此业务用户可以很容易地在Excel或其他报告工具中浏览它。

Answer 2

数据仓库是为了解决企业级分析数据处理和结构化数据处理的需要而创建的，这意味着

• 数据来自整个组织，通常使用来自不同来源的ETL流程将其带到仓库。
• 仓库中的数据以优化的格式进行结构和管理，以便进行密集的分析转换。大多数仓库将数据结构为柱状存储，并提供一个SQL类型的接口来处理数据。

另一方面，data被创建为所有组织数据的一个停止区域。数据是原始的，未经处理的格式，直接从应用程序。您还可以通过将数据转移到仓库或在分布式大数据处理系统中直接使用它们来处理湖泊中的数据。

因此，我们可以看到数据仓库不是数据湖。

• 因为它没有非结构化数据
• 只能用于计算密集型OLAP应用程序。