这张图是我画的。

两周前我在我的通讯中发布了这篇文章。免费订阅 https://vutr.substack.com 即可更早在您的邮箱中收到我的文章。

我在2019年开始了我的数据工程之旅，我们将数据首先落地到数据湖，然后再将其转换到数据仓库的架构看起来是最自然的选择。

数据流的这种顺序让我觉得数据湖存在的时间比数据仓库早得多。

(请告诉我我也不是唯一一个这么想的人。)

大约两年前，当我开始研究“湖屋”概念时，事情才开始变得清楚了。

结果表明，数据仓库已经存在了一段时间，而数据湖则是在2010年左右才出现的。

今天我想分享一些关于数据仓库、数据湖以及Lakehouse发展的笔记，作为我系列文章中重新审视数据工程基础的一部分。

注意啊： 这是我的一些个人想法，可能有点不全面。欢迎大家批评指正，谢谢！

想象一下，比如说，在一家公司开始工作，你得负责根据公司产品收集的数据为业务团队制作报告和数据可视化。

一开始，事情就挺简单的。

只有一个是记录交易数据的数据库；你可以直接从中提取数据来制作炫酷的报表。

接着，公司开始使用第三方服务，业务用户要求将这些数据纳入他们的报告中。这还勉强能应付。你从数据库和第三方API获取数据，并进行一些连接和聚合，就这样，你仍然可以提供用户需要的报告。

但随着你公司的产品迅速增长，它扩展了更多服务，并与其他外部工具进一步集成，每个工具都会生成相应数据。因此，你的用户希望这些数据能整合到他们的报告里。

到了这个地步，你已经不能分别手动从每个来源提取数据再手动合并这些数据了。

作者创作的这张图片。

这就是我们需要数据仓库的原因。

作者自制的图片。

这是一个存储库，我们可以在这里集中存储和管理来自不同数据源的大量数据，来满足公司的分析需求。

最初，数据从多个来源抽取，转换为读时模式，并直接加载到数据仓库中。数据仓库提供了一个集中化的存储和检索系统，帮助企业与组织更高效地存储、管理和分析数据。

它很快就会遇到挑战。

数据不仅限于表格形式；它也可以是视频、音频或文本文档。非结构化数据给关系型数据仓库带来了巨大的困扰，后者主要处理结构化数据。

在你的职业生涯中，你很可能听说过“大数据”这个词。

在2000年代初互联网泡沫中幸存下来的大科技公司，如雅虎、谷歌和亚马逊，引领了大数据的处理。最初，这些公司仍然依赖传统的数据仓库来集中数据。然而，这些系统在数据量和格式增加时显得力不从心。

雅虎开发了 Apache Hadoop 来处理大规模数据。它包括基于谷歌两篇论文的处理（MapReduce）和存储（HDFS）技术，这两篇论文分别是 MapReduce 和 Google 文件系统。

在这个时代，数据不再主要以结构化格式存在。人们意识到诸如视频、文本或文档等非结构化数据可以对商业见解做出重大贡献。关键在于关系型数据仓库只能处理结构化的数据。

就这样，数据湖的概念被提出来了。

我创作的这张图片。

数据湖是一个概念，描述了如何以原始格式（例如HDFS或后来的云对象存储）存储大量数据的过程。与传统数据仓库不同，数据湖不需要我们在存储数据之前预先定义模式，因此可以将所有数据（包括非结构化数据）存入数据湖，无需担心格式限制。

一开始，人们试图直接在数据湖上进行处理来替代传统的数据仓库。然而，这种方法存在很多严重的问题；由于缺乏诸如数据发现、数据质量保证、数据完整性、ACID约束和数据DML支持等适当的数据管理功能，数据湖很快变成了数据沼泽……

因此，把数据湖和数据仓库合二为一是个更好的选择。

作者自制的这张图片。

在湖泊中，我们可以接收任何格式的原始数据而无需担心预定义的模式。之后，数据会被转换后加载到数据仓库系统中用于报告和分析。更高级的应用场景如机器学习仍然可以访问数据湖里的原始数据。

然而，保持上述的两级数据结构会带来一些挑战。

• 数据过时性： 数据仓库中的数据与数据湖中的数据相比已经过时。与原始的数据仓库架构相比，这是一个倒退，因为在原有的架构中，新的操作数据能立即用于分析需求。
• 可靠性： 整合数据湖和数据仓库既复杂又昂贵，需要投入工程资源来在两个系统之间进行数据的ETL操作。

对高级分析的支持有限: 起初，数据仓库并不擅长支持机器学习工作负载，因为这些任务需要处理大量数据集和复杂的程序代码。供应商通常推荐将数据导出到文件中，这样做进一步增加了整体系统的复杂性。或者，用户可以直接在以开放格式存储的数据湖数据上运行这些工作负载。然而，这种做法通常会丧失数据仓库提供的丰富管理特性，例如ACID事务或数据版本控制。不过，这种情况可能已经改变，如今像BigQuery这样的现代数据仓库产品提供了高效处理机器学习工作负载的功能。

• 所有权总成本: 用户需为其数据湖和仓库中数据的重复存储支付两倍的费用。

Lakehouse 模型被引入了，是 Databricks 引入的吗？

正如名称所示，在湖仓架构中，人们力求将数据仓库的功能直接整合到数据湖中。

这是一个基于低成本存储（如对象存储）的架构，它提升了传统分析型数据库管理系统（DBMS）的管理和性能特性，如ACID事务、版本控制、缓存以及查询优化。Lakehouse结合了两者的最佳特性。

图片由作者制作。

与过去的努力不同，当时人们也尝试将处理直接放在数据湖的顶部，这次引入了更高效的元数据层，不同之处在于。Databricks 创建了 Delta Lake，Netflix 则开发了 Iceberg，而 Uber 推出了 Hudi。这些举措使得更高效地在 S3 上管理分析数据，并将数据的插入与更新以及增量处理能力引入数据湖。

在 Lakhouse 中，所有数据相关的操作都必须通过这些开放表格式来支持数据仓库功能，如表快照、时间旅行、ACID 属性、模式演变和分区调整。这些表格式还记录了用于帮助查询引擎优化数据的统计信息，比如，列的最小和最大值。

想要深入了解这些表格格式细节的人可以看看我之前写的文章。

本文中，我尽力介绍了不同类型的数据架构及其应用背景。

在我看来，Lakehouse 架构的采用将继续迅速增长，尤其是在数据基础设施领域中，比如 AWS 推出了 S3 Tables。

正如之前提到的，本文可能没有涵盖所有方面，所以您可以在下面留言——我很期待看到您的观点。

现在，是时候说再见了。希望在下一期内容里见到你！

[1] Databricks,Lakehouse：新一代统一数据仓库与高级分析的开放平台 (2020).

[2] 詹姆斯·塞拉 (James Serra)，解读数据架构：选择现代数据仓库、数据织网、数据湖和数据网状 一书 (2024)_