我想更详细地了解数据仓库和数据湖。
在我看来，这个主题有不同的信息。 Inmon将数据仓库定义为
面向主题，集成，时变和非易变的数据集合，以支持管理层的决策过程
现在我明白这只是一种架构形式，并不意味着任何技术。这意味着底层数据可以是任何也可以是S3对象存储的结构。此外，Waas et al. in On-Demand ELT Architecture for Right-Time BI: Extending the Vision提出了一个数据仓库，其中包含集成数据的ELT流程。
说到数据湖，我发现了以下定义
可扩展的存储库，以原始格式（“原样”）保存大量原始数据，直到需要时加上处理系统（引擎），可以在不影响数据结构的情况下提取数据
现在数据仓库可以成为更严格的数据湖吗？有一种观点认为数据仓库必须使用ETL，但根据Inmon，definiten不包括对数据转换的任何限制？如果数据集成可以是ELT，那么变换是敏捷的，例如它可以很容易地扩展。数据仓库看起来非常像数据湖。
我的假设是正确的，还是从偏斜的角度看这个。
数据仓库和数据湖是独立的系统，可以用于不同的目的，可以/应该是互补的，并且都是更大的数据架构的一部分。数据湖作为一个概念，可以只是数据仓库中维度模型的另一个数据源（尽管数据湖的技术实现可以直接查询原始数据）。
您可以将Data Lake视为“着陆区”，其中多个系统以“复杂/原始格式”转储数据，例如来自客户支持电话的MP3文件，来自Web服务器的gzip压缩日志。这意味着坐在那里用于历史目的并进一步处理成可以容易地分析/报告的格式，例如，从MP3文件中提取文本。
数据仓库还聚合来自不同系统的数据，但数据被建模为适合报告的格式（如维度模型），其模型反映业务/域的流程和事务，并且通常是高度策划的。
想象一下：如果您使用Web服务器日志记录对在线商店的访问，您可以将gzip压缩日志（“事务数据”）保存在数据湖中，然后将数据处理为维度模型（如this），这将是“专门用于查询和分析的交易数据副本”，因此业务用户可以在Excel或其他一些报表工具中轻松浏览它。