我们真的需要湖屋架构吗？

作者自制的图片。

原文最初发布于_https://vutr.substack.com_。

• 挑战与环境
• 动机所在
• 湖仓架构

我在2019年浏览Dremio的文档时第一次听到“Lakehouse”这个词。我当时持保守态度，认为这只是一个营销术语。五年过去了，讨论完AI之后，他们就开始讨论Lakehouse了；所有主要的云数据仓库现在都支持直接在对象存储中读取Hudi、Iceberg或Delta Lake格式。创新远不止于此；Apache XTable（原名为OneTable）提供了将Lakehouse表格式元数据抽象和转换的工具。最近，Confluent宣布了TableFlow的发布，该工具可以直接将Apache Kafka的数据作为Apache Iceberg表输入到数据湖、仓库或分析引擎中。这让我重新审视了过去的看法：Lakehouse真的只是个营销术语吗？

这周，我会通过我的论文《Lakehouse：新一代统一数据仓库与高级分析的开放平台》来回答这个问题，就用。在我的论文中提到。

从数据湖到数据仓库的数据流给我的印象让我以为数据湖的概念比数据仓库的概念更晚。但实际上并非如此。“数据湖”这一术语是在2011年提出的（参见维基百科上），而这个概念要早得多。

本图由作者绘制。

数据仓库最初被引入，目的是帮助业务用户通过整合操作数据库中的数据到中央仓库来获取分析洞察。分析用户利用这些数据支持他们的业务决策。数据采用写入时模式(schema-on-write)以确保数据模型被优化，便于BI工具的消费。这就是第一代数据分析平台。

在过去，组织通常会在本地将计算和存储结合在一起以构建数据仓库。当分析需求和数据量增加时，这迫使企业购买或升级更多的硬件。此外，数据不再仅限于表格形式；它可以是视频、音频或文本数据。这种非结构化数据给原本设计用来处理结构化数据的数据仓库系统造成了巨大的麻烦。

第二代数据分析平台应运而生。人们开始将大量原始数据放入数据湖中，数据湖是低成本存储系统，采用文件接口，存储开放格式的数据，例如Apollo Parquet改为Apollo Parquet，CSV，或ORC。这种方法随着Apollo Hadoop改为Apollo Hadoop的兴起而开始。与数据仓库不同，数据湖采用读时模式(schema-on-read)架构，允许更灵活地存储数据，但仍对数据质量和治理带来了一些挑战，这在一定程度上影响了数据处理的可靠性和一致性。这种方法会将湖中的一部分数据移动到仓库中（ETL）。数据移动的过程确保分析用户能够利用数据仓库的强大功能来挖掘有价值的见解。自2015年以来，云对象存储，例如亚马逊的S3存储服务或GCS，开始取代HDFS。它们具有更出色的耐久性和可用性，且成本极低。在云端，第二代平台的其余部分基本保持不变，包括像Redshift、Snowflake或BigQuery这样的数据仓库。这种两层的数据湖加数据仓库架构在当时主导了行业（我想现在仍然如此）。尽管这种架构仍然占据主导地位，它却仍然面临以下挑战。

这张图是作者自己绘制的。

• 可靠性： 数据湖和数据仓库的整合困难且成本高昂，需要大量的工程工作来在两个系统之间进行ETL数据处理。
• 数据过时： 数据仓库中的数据相较于数据湖中的数据较为过时。这相对于第一代系统是一个倒退，因为第一代系统能够即时将新的操作数据提供给分析需求。
• 对高级分析支持有限： 机器学习系统，如TensorFlow或XGBoost，需要处理大量数据集，还得使用复杂的编程代码。通过ODBC/JDBC读取这些数据不是个好方法，也没有办法直接访问内部仓库的数据格式。数据仓库供应商建议将数据导出到文件中，这进一步增加了系统的复杂度。相反，用户可以在开放格式的数据湖数据上运行这些系统。然而，这样做会牺牲掉数据仓库的一些高级管理功能，如ACID事务或数据版本控制。
• 总拥有成本： 除了支付ETL管道的费用，用户还需要为数据湖和数据仓库中的数据重复存储支付两倍的存储成本。

这里有个说明：由于像 BigQuery、Snowflake 或 Redshift 这样的主要云数据仓库对机器学习工作负载提供了很好的支持，目前“对高级分析的支持有限”这一说法并不准确。如果您有不同的看法，欢迎在评论区和我讨论。

基于这些观察，Databricks 讨论了以下技术问题：“能否让这些基于标准开放数据格式（如 Parquet 和 ORC）的数据湖变得像高性能系统一样，这些系统能够提供数据仓库的性能和管理功能，同时也能提供高级分析任务所需的快速直接 I/O？”

他们认为，这种被称为Lakehouse的模式可以解决数据仓库中的一些问题。Databricks认为，由于最近的创新解决了Lakehouse存在的根本性问题，Lakehouse有望获得更多关注。

• 可靠的数据湖管理：和数据湖一样，Lakehouse 必须能够存储原始数据并支持 ETL/ELT 过程。最初，数据湖仅仅意味着“一堆文件”，以各种格式存在，使得提供数据仓库的关键管理功能（如事务或回退到旧表版本）变得困难。然而，像 Delta Lake 或者 Apache Iceberg 这样的系统为数据湖提供了事务层，从而实现了这些管理功能。在这种情况下，ETL 步骤的整体数量减少了，分析师也可以根据需要快速高效地查询原始数据表，就像在第一代分析平台上那样。
• 支持机器学习和数据科学：ML 系统可以方便地直接读取数据湖中的数据，从而高效访问 Lakehouse 中的数据。
• SQL 性能：Lakehouse 必须在数据湖中的大规模数据集上提供最先进的 SQL 性能。Databricks 表明，可以通过多种技术来维护数据的辅助信息，并优化数据在现有格式中的布局，以达到高性能。

在接下来的部分中，我们将了解Lakehouse平台的动机和目的、技术设计和研究意义。

这里有一些原因，让Databricks认为这种Lakehouse架构可以解决数据仓库的缺点，比如：

• 数据质量和可靠性是企业数据用户面临的主要挑战。高效地实现数据管道很困难，主流的分开数据湖和数据仓库的架构则增加了这一问题的复杂性。
• 越来越多的商业应用需要实时更新的数据。然而，两层架构通过在数据加载到仓库前设置一个独立的数据进入区域，使用周期性的ETL/ELT任务来加载数据，增加了数据的延迟。
• 现在有大量的非结构化数据。
• 数据仓库和数据湖对机器学习和数据科学应用的支持不够好。

一些当前的行业趋势显示，客户对二元模式感到不满。

• 所有大型数据仓库都支持 Parquet 和 ORC 格式外部表。
• 在直接运行于数据湖上的 SQL 引擎方面进行了大量投资，例如 Spark SQL 或 Presto。

然而，这些改进只能解决湖泊数据和仓库架构的一些问题：湖泊数据仍然需要诸如ACID一致性事务和高效的访问方法等管理功能，以达到与仓库分析相匹配的性能。

Databricks 将 Lakehouse 定义为一种基于低成本存储的数据管理方案，增强了传统分析型数据库管理系统（DBMS）的管理与性能特性，如 ACID 事务、版本管理、缓存机制和查询优化功能。因此，Lakehouse 结合了数据湖和传统数据库管理系统两个世界的优点。接下来的部分中，我们将了解 Databricks 提出的 Lakehouse 设计。

作者自制的图片。

他们提出的第一种实现湖仓的想法是将数据存储在低成本的对象存储（例如，Google Cloud 存储）中，使用如 Apache Parquet 这样的标准文件格式，并在其上添加一个额外的事务元数据层来定义哪些对象属于某张表。这个元数据层允许他们实现诸如 ACID 事务等管理功能，同时保持对象存储的低成本优势。元数据层的实现选择有 Delta Lake、Apache Iceberg 或 Apache Hudi。此外，湖仓可以增强高级分析工作负载，并通过提供声明性的 DataFrame API 来更好地支持数据管理。许多机器学习框架，如 TensorFlow 和 Spark MLlib，可以读取 Parquet 这样的数据湖文件格式。这意味着将它们与湖仓集成的最简单方法是查询元数据层来确定哪些 Parquet 文件属于某张表，并将这些信息传递给 ML 库。

元数据层

这样的数据湖存储系统如 S3 或 HDFS 只提供低级别的对象存储或文件系统接口。多年来，随着 Apache Hive 的出现，数据管理层次的需求逐渐浮现。Apache Hive 记录了哪些数据文件属于某个特定的 Hive 表。

在2016年，Databricks开始开发Delta Lake，它将关于哪些对象属于哪个表的信息作为事务日志以Parquet格式存储在对象存储中。Netflix首次引入了Apache Iceberg，采用了类似的设计。Apache Hudi由Uber开发，是这一领域中另一个专注于将流数据摄入数据湖的系统。Databricks观察到，这些系统在性能方面与原始的Parquet/ORC数据湖类似甚至更好，同时改善了数据管理，比如事务处理、零拷贝和时间旅行，如零拷贝和时间旅行。

这里需要注意一点：对于已经拥有数据湖的组织来说，这些技术很容易采用：例如，Delta Lake 可以通过在其现有文件上加上事务日志，将现有的 Parquet 文件目录组织成一个 Delta Lake 表，而无需移动数据。此外，元数据层有助于实施数据质量约束。例如，Delta Lake 的约束 API 允许用户在新数据上应用约束（例如，特定列的有效值范围）。Delta 的客户端库会拒绝所有违反这些约束的记录，确保数据质量。最后，元数据层有助于实施治理功能，例如访问控制，例如，它在授予读取权限前检查客户端是否有权访问该表。

虽然元数据层增加了管理功能，但要达到数据仓库的能力还需要更多。SQL性能，即引擎直接处理原始数据，可能是Lakehouse方法中最重要的技术挑战。Databricks提出了几种优化Lakehouse中SQL性能的方法。这些优化方法与所选的数据格式无关。具体来说，这些优化包括：

作者创作的这张图片。

• 缓存 — 在使用元数据层时，Lakehouse 系统可以将存储在云对象存储中的文件缓存到更快的设备，例如 SSD 和 RAM 上。
• 辅助数据 ：Lakehouse 可以维护其他辅助文件数据来优化查询性能。在 Delta Lake 和 Delta Engine 中，Databricks 维护每个数据文件的列最小值和最大值信息，并将其存储在同一 Parquet 事务日志中。这使引擎在扫描阶段可以跳过不必要的数据读取。他们还正在实现一个 布卢姆过滤器 用于数据跳过目的。
• 数据布局 ：Lakehouse 可以优化许多布局决策。第一个是记录排序优化，其中记录被聚类在一起；这使得引擎更容易一起读取它们。Delta Lake 支持使用单独维度或空间填充曲线（如 Z 曲线）对记录进行排序，以提供多维局部性优化。

这些优化在分析系统中常见的访问模式下效果显著。更关注在分析工作负载中的‘热’数据子集上，可以从缓存优化中获益匪浅。对于云对象存储中的‘冷’数据而言，性能的关键在于每个查询扫描的数据量。通过结合数据布局优化和辅助数据结构，Lakehouse系统可以高效地减少I/O操作。

一种方法是提供机器学习库中DataFrame API的声明式版本，该版本将数据准备的计算映射到Spark SQL查询计划，从而可以利用Delta Lake中的优化功能。因此，在实现Delta Lake数据源时，它们利用上述缓存、数据跳过和数据布局优化措施来加速从Delta Lake读取数据，并加快机器学习和数据科学任务的执行。

如果解决方案能够解决实际问题，它就不仅仅是一个陈词滥调。Lakehouse 最初被提出是为了缓解两层架构带来的痛点：维护两个独立的系统，一个用于存储（湖），另一个用于分析（仓库）。通过将分析能力直接带入湖中，Lakehouse 需要面对最棘手的问题：查询性能；直接在原始数据上进行分析意味着引擎对数据事先了解不多，这可能会给优化过程带来一些困难。得益于近年来如 Hudi、Iceberg 或 Delta Lake 等开源表格式的创新技术，Lakehouse 在性能上似乎不输于传统仓库。看着 Lakehouse 的崛起，与湖-仓库范式共存，或将两层架构彻底取代，未来充满了期待，谁知道又会是怎样一番景象呢？

感谢阅读我的博客。下见哦 ^-^；)

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

我的周报是一封像博客一样的每周邮件，记录从比我聪明的人那里学到的知识。

所以，想不想和我一起学习，一起成长？在这里关注：https://vutr.substack.com。