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架构逐步过渡。