摘要

论文认为数据仓库架构在未来一段时间内会逐渐消亡，取而代之的是一种新型 Lakehouse架构，该架构具有如下特特性：

• 基于开放的数据格式，例如 Apache Parquet
• 完全支持机器学习和数据科学
• 提供卓越的性能

Lakehouse 解决数据仓库面临的主要挑战——数据陈旧、可靠性不高、总成本大、数据格式受限、场景支持受限。论文下面会讨论 Lakehouse 架构为何取得工业界青睐以及如何影响数据管理。

数据分析平台发展

数据仓库将业务数据库的数据收集到集中式仓库，帮助企业领导分析数据，之后被用于决策支持和商业智能Business Intelligence。数据仓库使用写模式schema-on-write写入数据，优化下游BI消费的数据模型。这就是第一代数据分析平台。

后来第一代平台开始面临诸多挑战。首先是计算与存储耦合使得扩容成本增加，这迫使企业支付用户负载和数据管理峰值的成本，这个成本随着数据规模增加而迅速增加。其次，越来越多的数据集是非结构化的，例如视频、音频和文本文档，而数据仓库无法存储、查询这类数据。

为了解决这些问题，第二代数据分析平台将所有原始数据导入数据湖：具有文件 API 的低成本存储系统，该系统可存储开放数据格式，例如 Apache Parquet 和 ORC。这个方法源起于 Apache Hadoop，基于 HDFS 实现低成本存储。数据湖是一种读模式schema-on-read架构，可以灵活、低成本地存储数据，也解决了数据质量和下游管理的问题。该架构中的一小部分数据在进行 ETL 后注入下游数据仓库，再进行决策支持和 BI 分析。开放数据格式使得绝大多数分析引擎可以直接访问数据湖数据。

2015年起，云数据湖（S3、ADLS、GCS、OSS等）开始取代HDFS，它们具有超强的持久性、冗余可靠、超低存储成本。云上架构与第二代平台架构相同，例如Redshift、Snowflake。数据湖 + 数据仓库 两层架构当今在工业界中占主导地位。

如今，这种架构面临新的挑战。尽管存储和计算的分离使得云数据湖 + 数据仓库架构的成本降低，可增加了用户的使用成本。在第一代平台中，所有业务数据库中的数据经过ETL后直接注入数据仓库。第二代平台却在中间引进了数据湖，增加了额外的复杂性、延迟与故障率。同时，数据湖 + 数据仓库二层架构不能很好支持机器学习之类的高级分析。具体来看，可以归纳为四个问题：

• 可靠性。保持数据湖与数据仓库的一致性是成本高昂且困难的事情。需要对两个系统之间的 ETL 作业进行仔细设计，如此方可进行高性能决策支持与 BI 分析。每个ETL步骤还有发生故障或引入错误的风险，例如由于数据湖和数据仓库引擎之间的细微差别而导致数据质量降低的风险。
• 数据陈旧。数据仓库数据的时效性低于数据湖数据，新数据的加载通常要花费几天。与第一代分析系统相比，这是个倒退，第一代分析系统可以直接查询新的业务数据。根据 Dimensional Research 与 Fivetran 调查，86% 的分析使用过时数据，62% 的报告每月需要等待几次引擎资源。
• 对高级分析支持有限。企业希望使用数据进行预测，例如“我应该为哪些顾客提供折扣？”。 尽管许多研究关注机器学习与数据管理结合，但主流机器学习系统没有一个可以工作在数据仓库上，包括 TensorFlow、PyTorch 和 XGBoost。与 BI 查询少量数据不同，这些机器学习系统需要使用复杂的 No-SQL 代码处理大型数据集，但通过 ODBC/JDBC 读取数据效率很低，并且无法直接访问数据仓库内部专有格式的数据。对于这类场景，数据仓库供应商建议导出数据为文件，但这增加了复杂性和滞后性，因为添加了第三个 ETL。或者，用户可以在支持开发格式的数据湖上运行这些系统，这会抛弃数据仓库丰富的数据管理功能，例如 ACID 事务、数据版本控制与索引。
• 总成本。除了支付 ETL 作业费用外，用户还得为复制到数据仓库的数据支付两倍的存储成本，而数据仓库使用的内部格式额外引入数据或工作负载迁移到其他系统的成本。

一种被广泛采用的解决方案是不使用数据湖 ，将所有数据存储在计算、存储分离的数据仓库中。论文认为这种方案可行性有限，因为不支持视频、音频和文本数据或从机器学习和数据科学工作负载中直接访问。

论文作者提出了一个问题：是否可以将基于开放数据格式（Parquet 与 ORC）的数据湖转为一个高性能系统，该系统既拥有数据仓库强大的性能、管理功能，又可直接、快速访问高级分析工作负载？随着越来越多的业务应用开始依赖运营数据和高级分析，Lakehouse 架构可以消除数据仓库的上述挑战。

作者相信 Lakehouse 的时机已经到来！

Lakehouse可解决以下问题：

1. 数据湖上可靠的数据管理：Lakehouse 需要存储原始数据，同时支持 ETL/ELT 流程来提高数据分析质量。传统数据湖将半结构化数据以“一堆文件”形式进行管理，很难提供一些简化ETL/ELT的关键管理功能，例如事务、回滚、零拷贝。然而，以 Delta Lake 和 Apache Iceberg 为代表的新型数据湖框架提供了数据湖的事物视图，并提供了管理功能，减少 ETL 步骤，并且分析人员可以高效查询原始数据表，这与第一代分析平台很像。
2. 支持机器学习和数据科学：机器学习系统支持直接读取数据湖数据格式，很多系统采用 DataFrames 作为操作数据的抽象，而声明式 DataFrame APIs 可以为机器学习工作负载中的数据访问进行查询优化，可以让机器学习工作负载直接享受 Lakehouse 的优化点。
3. SQL性能：Lakehouse 需要在海量 Parquet/ORC 数据集上提供很好的 SQL 性能，相比之下经典数据仓库对 SQL 优化更彻底。尽管如此，论文提出需要维护 Parquet/ORC 数据集的辅助数据，在现有格式内优化数据布局以实现更好的性能。

出发点：数据仓库的挑战

当前工业界对数据仓库不是很满意。首先是数据质量和可靠性不高，维护数据流分析的准确性是一件很困难的工作。其次，越来越多的商业分析需要最新的数据，但数据仓库不可避免地引入数据滞后性。第三，如今的非结构化数据比重大幅增加，但数据仓库并不能提供很好的非结构化数据分析。最后，现在工业界部署的机器学习与数据科学应用无法从数据仓库和数据湖中得到很好的支持。

当前工业界对数据湖 + 数据仓库的两层架构并不满意。首先是几乎所有的数据仓库近期都增加了对 Parquet 和 ORC 格式的外部表支持，允许数据仓库用户可以从相同的 SQL 引擎查询数据湖表，但这没有降低数据湖管理难度，也没有消除数据仓库 ETL 复杂度、滞后性和高级分析挑战。实际上，这些支持的性能通常较差，因为 SQL 引擎主要针对其内部数据格式进行了优化。其次，直接针对数据湖存储的 SQL 引擎也有广泛产品，例如 Spark SQL、Presto、Hive 和 AWS Athena。然而，这些引擎不能解决数据湖所有问题，也不能取代数据仓库，数据湖仍然缺少包括 ACID 事务的基础管理功能和有效访问方法，例如与数据仓库性能匹配的索引。

Lakehouse 架构

论文为 Lakehouse 提出一个定义：基于低成本、直接访问存储的数据管理系统，该系统具有传统分析型 DBMS 管理和性能，例如 ACID 事务、数据版本管理、数据审计、索引、缓存和查询优化。可以看出，Lakehouse 结合了数据湖和数据仓库的核心优势。问题的关键在于是否可以有效结合这些优势，特别是 Lakehouse 对直接访问的支持意味着其放弃了部分数据独立性。

Lakehouse 天然适合计算、存储分离的云环境：不同的计算应用程序按需分配在完全独立的计算节点（例如 ML 的 GPU 集群），同时直接访问相同的存储数据，但也可以在本地存储系统（如 HDFS）上实现 Lakehouse。

实现 Lakehouse 系统

实现 Lakehouse 的第一个关键思想是使用标准文件格式（如 Parquet）将数据存储在低成本的对象存储（如 Amazon S3、OSS）中，并在对象存储上实现元数据层，其定义了哪些对象是表版本一部分。这使系统可以在元数据层实现如 ACID 事务处理或版本控制之类的管理功能，同时将大量数据保存在低成本对象存储中，并允许客户端使用使用标准文件格式直接从该存储中读取对象。

尽管元数据层增加了管理功能，但不足以实现良好的 SQL 性能。数据仓库使用多种技术获得性能提升，比如将热数据存储在 SSD 等高速设备、维护统计信息、构建有效的访问方法（如索引）以及优化数据格式和计算引擎。基于现有存储格式的 Lakehouse 无法变更格式，但是也可以实现保持数据文件不变情况下的其他优化，包括缓存、辅助数据结构（例如索引和统计信息）和数据布局优化。

最终，Lakehouse 既可以加快高级分析负载，又可以为其提供更好的数据管理功能。许多机器学习库（如 Tensorflow 和 Spark MLlib）已经可以读取数据湖文件格式（如 Parquet）。因此将它们与 Lakeehouse 集成最简单方法是查询元数据层，查询哪些 Parquet 文件属于表，然后将它们传递给机器学习库。这些系统支持 DataFrame API，以便进行更好的优化。R 与 Pandas 推广了 DataFrames，为用户提供包含多种操作符的表抽象，其中大多数映射到关系代数。Spark SQL 等系统通过惰性计算转换与传递结果操作步骤到优化器实现该 API 声明式。因此，这些 API 可利用 Lakehouse 新优化特性实现机器学习加速，例如缓存和辅助数据。

用于数据管理的元数据层

Lakehouses 的第一个组件是元数据层，其可以实现 ACID 事务和其他管理功能。诸如 S3 或 HDFS 之类的数据湖存储系统仅提供了低级的对象存储或文件系统接口，在这些接口中，即使是简单的操作（如更新跨多个文件的表）也不是原子的，这个问题使得一些组织开始设计更丰富的数据管理层，从 Apache Hive ACID 开始，其使用 OLTP DBMS 跟踪给定表版本中哪些数据文件是 Hive 表的一部分，并允许操作以事务方式更新此集合。近年来一些新系统提供了更多功能和改进的可伸缩性，如 2016 年 Databricks 开发的 Delta Lake，其将有关哪些对象是表中一部分的信息存储在数据湖中，作为 Parquet 格式的事务日志，使其能够扩展到每张表数十亿个对象；Netflix 的 Apache Iceberg 也使用类似的设计，并支持 Parquet 和 ORC 存储；Apache Hudi 始于 Uber 也类似，尽管它不支持并发写入（正在支持中），该系统侧重于简化流式数据入数据湖。

这些系统的经验表明它们可以提供与原始 Parquet/ORC 数据湖类似或更好的性能，同时还增加了非常有用的管理功能，例如事务处理，零拷贝和回滚。

元数据层对数据质量非常重要，例如可以对 Schema 进行校验，使其不破坏数据质量。

另外元数据层可以实现诸如访问控制和审核日志记录之类的治理功能，例如元数据层可以在授予客户端凭据以从云对象存储读取表中的原始数据之前，检查是否允许客户端访问表，并且记录所有访问行为。

未来方向和替代设计。由于数据湖的元数据层非常新，因此存在许多悬而未决的问题和替代设计。例如 Delta Lake 设计为将事务日志存储在它运行的同一对象存储中（例如 S3）以简化管理（消除了运行单独存储系统的需要）并提供高可用性和高读取带宽，但对象存储的高延迟限制了它可以支持的每秒事务处理速率，在某些情况下将元数据使用更快的存储系统的设计可能更可取。同样Delta Lake、Iceberg 和 Hudi 仅支持单表事务，但也可以扩展以支持跨表事务，优化事务日志的格式和管理对象的大小也是未解决的问题。

Lakehouse 中的 SQL 性能

Lakehouse 方案的最大技术问题可能是如何提供最新的 SQL 性能，同时又放弃了传统 DBMS 设计中很大一部分的数据独立性，有很多解决方案，例如可以在对象存储上添加一个缓存层，以及是否可以更改数据对象存储格式而不使用现有的标准（例如 Parquet 和 ORC（不断改进这些格式的新设计不断涌现））。无论采用何种设计，核心挑战在于数据存储格式已成为系统公共 API 的一部分以允许快速直接访问，这与传统 DBMS 不同。

我们提出了几种技术可以在 Lakehouse 中优化 SQL 性能，并且与数据格式无关，因此可以将其与现有格式或未来数据格式一起使用，这些与格式无关的优化大致如下：

• 缓存：使用元数据层时，Lakehouse 系统可以安全地将云对象存储中的文件缓存在处理节点上更快的存储设备（例如 SSD 和 RAM）上，正在运行的事务可以确定读取缓存的文件是否还有效，此外缓存可以采用转码格式，其对于查询引擎运行效率更高，例如在 Databricks 的缓存会解压了部分它加载的 Parquet 数据。
• 辅助数据：即使 Lakehouse 为支持直接 I/O 访问需要开放表存储格式（如 Parquet），它也可以维护其他数据来帮助优化查询，如在 Parquet 文件中维护表中每个数据文件的列最小-最大统计信息，有助于跳过数据，以及基于 Bloom 过滤器的索引。可以实现各种各样的辅助数据结构，类似于为"原始"数据建立索引。
• 数据布局：数据布局在访问性能中起着重要作用。Lakehouse 系统也可以优化多个布局决策，最明显的是记录排序：哪些记录聚集在一起可以最容易被批量读取，Delta 中使用 Z-Order，Hudi 中使用基于哪些列进行 Clustering。

对于分析系统中的典型访问模式，这三个优化可以很好地协同工作。典型的工作负载中大多数查询倾向于集中在数据的"热"子集上，Lakehouse 可以使用与数据仓库相同的优化数据结构对其进行缓存，以提供相同的查询性能。对于云对象存储中的"冷"数据，性能的主要决定于每个查询读取的数据量，在该情况下数据布局优化（将共同访问的数据聚类）和辅助数据结构（如区域图，使引擎快速确定要读取的数据文件范围）的组合可以使Lakehouse系统与数仓一样最小化 I/O 开销，尽管使用标准的开放文件格式（相比于数仓内置文件格式）。

性能结果

未来方向和替代设计。设计性能良好且可以直接访问的 Lakehouse 系统是未来工作的重点。一个尚待探索的方向是设计更好适应此类场景的数据湖存储格式，例如为 Lakehouse 系统实现数据布局优化或索引提供更大灵活性的存储格式，或者更适合现代硬件。

即使不改变数据格式，也有许多缓存策略、辅助数据结构和数据布局策略。哪一种对云对象存储中的海量数据集更有效是一个开放式问题。

最后，另一个值得研究的点是确定何时以及如何使用 serverless 计算系统来响应查询、优化存储、元数据层和查询引擎，以实现延迟最小化效果。

高级分析高效访问

高级分析库通常不是使用 SQL 命令编写，其需要访问大量数据。作者认为需要研究以下问题：如何设计数据访问层，最大程度地提高顶部运行代码的灵活性，并且可以从 Lakehouse 的优化中受益？

作者验证了如上图所示的优化方案：将缓存、数据筛选、数据布局优化同时应用，实现了机器学习算法加速。

机器学习 API 迅速发展，但是一些数据访问 API（例如 TensorFlow 的 tf.data）没有尝试将查询语义推入底层存储系统，一些 API 还专注于 CPU 到 GPU 的传输和 GPU 计算，这在数据仓库中并未引起太多关注。

未来方向和替代设计。论文提出需要多关注机器学习系统的数据访问接口。近期一些机器学习框架将算法逻辑融合进 SQL join 操作，其他应用在算法中的查询优化应用在 SQL 中。最后，作者认为需要标准机器学习接口以使数据科学家能够充分利用 Lakehouse（甚至数据仓库）中强大的数据管理功能，如事务，数据版本控制和回滚等。

研究问题和启示

Lakehouse 还提出了其他一些研究问题，功能日益丰富的数据湖的行业趋势也对数据系统研究的其他领域产生了影响。

• 还有其他方法可以实现 Lakehouse 目标吗？可以想像其他方法来实现 Lakehouse 的主要目标，例如构建用于数据仓库的大规模并行服务层，可以支持对高级分析工作负载的并行读取，但是与工作负载直接访问对象存储库相比成本将更高，难以管理，并且性能可能会降低。这种服务层并未得到广泛应用，例如 Hive LLAP。

  除了在性能、可用性、成本和锁定方面的挑战外，还有一些重要的管理原因，如企业可能更喜欢将数据保留为开放格式。随着对数据管理的法规要求不断提高，组织可能需要在短时间内搜索旧数据集，删除各种数据或更改其数据处理基础结构，并且采用开放格式进行标准化意味着它们将始终可以直接访问数据，软件行业的长期趋势一直是开放数据格式，企业数据应该继续保持这种趋势。

• 什么是正确的存储格式和访问 API？Lakehouse 的访问接口包括原始存储格式以及直接读取此格式的客户端库（例如使用 TensorFlow 读取时）以及高级 SQL 接口。有很多不同的方法可以在这些层上放置丰富的功能，例如通过要求读者执行更复杂的“可编程”解码逻辑，可以为系统提供更大的灵活性的存储方案。有待观察哪种存储格式、元数据层设计和访问 API 的组合效果最佳。

• Lakehouse 如何影响其他数据管理研究和趋势？数据湖的流行以及对丰富管理接口的使用不断增加，无论它们是元数据层还是完整的 Lakehouse 设计，都对数据管理研究的其他领域产生了影响。

  Polystore 旨在解决跨不同存储引擎查询数据这一难题，该问题在企业中持续存在，但是在云数据湖中以开放格式提供的数据比例越来越高，也可以通过直接针对云对象存储运行许多 polystore 查询，即使基础数据文件是逻辑上分开的 Lakehouse 的一部分。

  还可以在 Lakehouse 上设计数据集成和清理工具，并可以快速并行访问所有数据，这可以用于大型联接和聚类等新算法。

  可以将 HTAP 系统构建为 Lakehouse 前面的"附加"层，通过使用其事务管理 API 将数据直接归档到 Lakehouse 系统中，Lakehouse 将能够查询数据的一致快照。

  ML 的数据管理也会变得更加简单和强大，如今组织正在构建各种可重新实现标准 DBMS 功能的，特定于 ML 的数据版本控制和特征存储系统，使用带有内置 DBMS 管理功能的数据湖来实现特征存储功能可能会更简单。

  Serverless 引擎之类的云原生 DBMS 设计将需要与更丰富的元数据层集成，而不是直接扫描数据湖中的原始文件，可以能够提高查询性能。

  最后 Lakehouse 的设计易于分布式协作，因为可以从对象存储库直接访问所有数据集，这使得共享数据变得很简单。

结论

在开放的数据湖文件格式上实现数据仓库功能的统一数据平台体系架构可以为当今的数据仓库系统提供具有竞争力的性能，并有助于应对数据仓库用户面临的许多挑战，尽管限制数据仓库的存储层以标准格式直接访问看起来似乎是一个重大限制，但诸如热数据缓存和冷数据数据布局优化之类的优化可以使 Lakehouse 获得很不错的性能，另外鉴于数据湖中已有大量数据，并且有机会大大简化企业数据架构，行业很可能会向 Lakehouse 架构逐步过渡。