Lakehouse: 统一数据仓库和高级分析的新一代开放平台

1. 摘要

数仓架构在未来一段时间内会逐渐消亡，会被一种新的Lakehouse架构取代，该架构主要有如下特性

• 基于开放的数据格式，如Parquet；
• 机器学习和数据科学将被作为头等公民支持；
• 提供卓越的性能；

Lakehouse可以解决数据仓库面临的几个主要挑战，如数据陈旧，可靠性，总成本，数据格式不开放和有限场景支持。

2. 数据分析平台发展

数据仓库将业务数据库的数据收集到集中式仓库来帮助企业领导者获得分析见解，然后将其用于决策支持和商业智能（BI），仓库使用写模式（schema-on-write）写入数据，对下游消费者进行了优化，此为第一代数据分析平台。

慢慢地第一代系统开始面临若干挑战，首先是计算与存储耦合使得扩容成本增加；其次越来越多的数据集是非结构化的，例如视频，音频和文本文档，数据仓库无法存储和查询这些数据。

为了解决这些问题，引入第二代数据分析平台，其将所有原始数据导入数据湖：具有文件API的低成本存储系统，该API以通用且通常是开放的文件格式保存数据，例如Apache Parquet和ORC，可以基于HDFS实现低成本数据湖存储，数据湖是一种读模式（schema-on-read）架构，可以灵活地以低成本存储任何数据。

该架构中的一小部分数据随后将被ETL到下游数据仓库以提供最重要的决策支持和BI应用程序。

从2015年起，S3，ADLS，GCS，OSS等云数据湖开始取代HDFS，云上的架构与第二代系统中的架构基本相同，云上有Redshift、Snowflake和ADB等数据仓库，这种两层的数据湖+数仓架构在行业中占主导地位（财富500强企业中几乎都在使用）。但这种架构也面临了一些挑战，尽管由于分开的存储（例如S3）和计算（例如Redshift）而使云数据湖和仓库的体系架构表面上便宜，但是对于用户来说，两层体系结构却非常复杂。在第一代平台中所有数据都从运营数据系统直接ETL到仓库，而在这种架构中，数据首先被ETL到数据湖，然后又被ELT到数仓，引入额外的复杂性、延迟和故障率，而且企业用例中包括机器学习之类的高级分析，数据湖和仓库都支持得不理想，具体来说，当前的数据架构通常会遇到如下四个问题：

• 可靠性。保持数据湖和数仓一致是困难且昂贵的，需要对两个系统之间的ETL作业进行仔细设计，每个ETL步骤还有发生故障或引入错误的风险，例如由于数据湖和仓库引擎之间的细微差别而导致数据质量降低的风险。
• 数据陈旧。与数据湖的数据相比，仓库中的数据是陈旧的，新数据的加载通常需要几天的时间。与第一代分析系统相比是个倒退，第一代分析系统中新的运营数据可立即用于查询。
• 对高级分析的支持有限。企业希望使用数据进行预测，但TensorFlow，PyTorch和XGBoost等机器学习系统都无法在数仓之上工作，与BI查询提取少量数据不同，这些系统需要使用复杂的非SQL代码处理大型数据集，而通过ODBC/JDBC读取此数据效率很低，并且无法直接访问仓库内部专有格式，对于这些用例会建议将数据导出到文件中，这进一步增加了复杂性和陈旧性（添加了第三个ETL步骤！），或者用户可以针对开放格式的数据湖数据运行这些系统，但会失去数据仓库的丰富管理功能，例如ACID事务，数据版本控制和索引。
• 总成本。除了支付ETL作业费用外，用户还为复制到仓库的数据支付了两倍的存储成本，而商业仓库使用内部专有格式增加了将数据或工作负载迁移到其他系统的成本。

一种被广泛采用的解决方案是不使用数据湖，将所有数据存储在内置了计算和存储分离功能的仓库中，但这种解决方案可行性有限，因为其不支持管理视频/音频/文本数据或从ML和数据科学工作负载中直接访问。

随着越来越多的业务应用开始依赖运营数据和高级分析，Lakehouse架构可以消除数据仓库中的一些主要挑战，Lakehouse的时机已经到来。

Lakehouse为以下关键问题提供解决方案：

• 数据湖上可靠的数据管理：Lakehouse需要存储原始数据，同时支持ETL/ELT流程来提高数据分析质量，而传统数据湖将半结构化格式数据作为"一堆文件"进行管理，很难提供一些简化数据仓库中ETL/ELT的关键管理功能，例如事务、版本回滚以及零拷贝等。一些新型的数据湖框架（如Delta、Hudi、Iceberg）提供了数据湖的事务视图，并提供了管理功能，减少了ETL步骤，并且分析人员可以高效地查询原始数据表，这与第一代分析平台非常类似。
• 支持机器学习和数据科学：ML系统支持直接读取数据湖格式，很多ML系统采用DataFrames作为操作数据的抽象，而声明式DataFrame API可以对ML工作负载中的数据访问进行查询优化，可以直接享受在Lakehouse中的许多优化。
• SQL性能：Lakehouse需要在海量Parquet/ORC数据集上提供很好的SQL性能，相比之下经典数仓对SQL进行更彻底的优化（包括使用专有存储格式）。Lakehouse可以使用多种技术来维护有关Parquet/ORC数据集的辅助数据，并在这些现有格式内优化数据布局以实现更好的性能。

当前的行业趋势表明客户对两层数据湖+数仓架构并不满意，首先近年来几乎所有的数据仓库都增加了对Parquet和ORC格式的外部表支持，这使数仓用户可以从相同的SQL引擎查询数据湖表（通过连接器访问），但它不会使数据湖表更易于管理，也不会消除仓库中数据的ETL复杂性、陈旧性和高级分析挑战。实际上这些连接器的性能通常较差，因为SQL引擎主要是针对其内部数据格式进行了优化，而仅凭这些分析引擎并不能解决数据湖的所有问题并取代仓库，数据湖仍然缺乏基本的管理功能（例如ACID事务）和有效的访问方法（例如与数据仓库性能匹配的索引）。

3. Lakehouse架构

Lakehouse可定义为基于低成本，可直接访问存储的数据管理系统，该系统还提供传统的分析型DBMS管理和性能功能，例如ACID事务，数据版本，审计，索引，缓存和查询优化。因此Lakehouse结合了数据湖和数据仓库的主要优势：开放格式的低成本存储可通过前者的各种系统访问，而后者则具有强大的管理和优化功能。而核心问题是能否可以有效地结合这些优势：特别是Lakehouse对直接访问的支持意味着它们放弃了数据独立性的某些方面，这一直是关系型DBMS设计的基础。

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

3.1 实现Lakehouse系统

实现Lakehouse的第一个关键思想是使用标准文件格式（如Apache Parquet）将数据存储在低成本的对象存储（例如Amazon S3）中，并在对象存储上实现元数据层，其定义哪些对象是表版本一部分。这使系统可以在元数据层实现诸如ACID事务处理或版本控制之类的管理功能，同时将大量数据保留在低成本对象存储中，并允许客户端使用标准文件格式直接从该存储中读取对象，尽管元数据层增加了管理功能，但不足以实现良好的SQL性能，数据仓库使用多种技术获得很好的性能，例如将热数据存储在SSD等高速设备、维护统计信息、构建有效的访问方法（例如索引）以及优化数据格式和计算引擎。基于现有存储格式的Lakehouse中无法变更格式，但是也可以实现在保持数据文件不变情况下的其他优化，包括缓存、辅助数据结构（例如索引和统计信息）和数据布局优化。

Lakehouse既可以加快高级分析负载，又可以为其提供更好的数据管理功能。许多ML库（例如TensorFlow和Spark MLlib）已经可以读取数据湖文件格式（如Parquet）。因此将它们与Lakehouse集成的最简单方法是查询元数据层，以确定哪些Parquet文件属于表，然后将它们传递给ML库。

3.2 用于数据管理的元数据层

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仅支持单表事务，但也可以扩展以支持跨表事务，优化事务日志的格式和管理对象的大小也是未解决的问题。

3.3 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开销，尽管使用标准的开放文件格式（相比于数仓内置文件格式）。

3.4 高级分析高效访问

高级分析库通常不是使用SQL命令编写，其需要访问大量数据，如何设计数据访问层以最大程度地提高运行在顶部的代码的灵活性，仍然可以从Lakehouse的优化中受益。

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

我们需要标准ML接口以使数据科学家能够充分利用Lakehouse（甚至数据仓库）中强大的数据管理功能，如事务，数据版本控制和时间旅行等。

4. 研究问题和启示

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管理功能的数据湖来实现特征存储功能可能会更简单。无服务器引擎之类的云原生DBMS设计将需要与更丰富的元数据层集成，而不是直接扫描数据湖中的原始文件，可以能够提高查询性能。最后Lakehouse的设计易于分布式协作，因为可以从对象存储库直接访问所有数据集，这使得共享数据变得很简单。

5. 结论

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