论文阅读 - Lakehouse A New Generation of Open Platforms

Lakehouse平台代表了数据仓库与高级分析工具整合的新一代开放平台架构；该系统通过创新的技术手段实现了数据存储与处理功能的无缝衔接； Lakehouse不仅提升了数据处理效率还增强了对复杂业务场景的支持能力；其独特的设计理念使得该平台成为该领域的重要参考； Lakehouse平台的成功应用为相似类型的产品开发提供了新的思路和借鉴；

本文是对 Databricks 的 Lakehouse 论文（Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics）的阅读总结。该论文详细探讨了 Lakehouse 架构背后的原因、其具体设计以及在构建 Lakehouse 系统中尚可深入研究的问题。通过研读这篇论文，读者能够更深入地理解 Lakehouse 架构产生的背景与意义，并对该新兴的数据平台架构形成更加全面的认识。

本文不打算全面翻译论文, 而是从以下主要线索分析论文的核心观点及结构, 并融入笔者的观点与分析:

1. 当前的数据平台架构体系及其存在的挑战.
2. 构成Lakehouse成功的基础性技术要求.
3. Lakehouse体系的构成要素及其核心特征.

现有数据平台及问题

第一代数据平台

该技术体系诞生于上世纪80年代末期, 其核心理念是整合来自各业务数据库的数据资源, 并通过先进的技术手段实现高效整合, 从而存储于统一的数据中心. 这种系统设计不仅能够帮助企业高层管理者获取分析洞察, 更能为企业战略制定者提供精确的市场分析支持. 此外, 该系统平台还可以持续用于构建强大的商业智能（BI）体系, 并通过实时数据分析为企业决策层提供精准反馈.

它主要用于建立数据分析的基础架构。其处理流程如图所示。其中存储于业务数据库（通常为关系型数据库）中的结构化信息将经ETL工具提取并转换后导入至数据分析平台。该平台采用Schema-on-write模式进行 writes以动态优化目标用户的数据分析模型。

在当前快速发展的背景下, 第一代数据平台在运行过程中暴露出一些问题(以下是论文原话的翻译):

• 首先, 它们通常将计算与存储的整合部署于本地设备上. 这迫使企业为峰值用户负载与受管理的数据进行调度与付费, 随着数据量的增长, 这一模式变得极为高昂.
  • 其次, 不仅有大量 portion 的数据集呈快速增长趋势, 而且越来越多的数据集完全非结构化形态呈现. 例如: 视频流、语音记录以及文本文件等类型的数据文档. 这使得它们难以被存储于数据仓库并实现有效的检索.

就目前而言，在第一点上笔者认为该论文对理论部分的阐述存在一定局限性，并未充分反映当前技术发展情况。数据仓库构建技术正经历着持续演进的过程，在小规模数据环境下仍多采用基于关系型模型的数据存储方案（如Oracle等厂商的产品），这种架构虽然功能完善但在横向扩展方面存在一定瓶颈。当面临数据量快速增长导致性能瓶颈时，则不得不依赖于底层系统的扩展优化工作，在成本方面往往难以承受相应的开销。然而随着实际应用中处理的数据体量逐渐扩大并突破一定阈值，在这一阶段MPP架构逐渐展现出其优势价值，并得到了广泛的技术实践支持（如Greenplum、ClickHouse等开源平台）。此外，在云计算时代的兴起下，“云原生”的概念开始被更多厂商引入到大数据分析领域中来（如AWS提供的Redshift服务以及阿里云推出的AnalyticDB产品），这些解决方案不仅降低了大规模数据分析的成本门槛而且在处理非结构化或半结构化数据时展现出更强的能力优势

第二代数据平台

由于第一代数据平台的上述问题, 在2010年前后, 第二代数据平台开始出现.

在这一架构设计中, 所有的原始数据会被整合到中央化的存储平台中进行统一管理. 该平台采用文件API的方式实现低成本存储功能, 并支持多种通用且开放的文件格式进行数据存储, 其中包括Apache Parquet和ORC等国际主流标准. 随后, 根据需求部分数据可通过ETL流程转换后导入至下游的数据仓库系统中, 主要用于关键业务决策支持及基于智能分析的应用开发. 此外, 由于采用了开放格式的数据存储方案, 数据库中的资源能够直接连接至各种分析型工具系统, 包括机器学习算法等先进应用.

最初主要采用Apache Hadoop的HDFS作为数据存储方案。
然而随着云存储技术的发展（如AWS S3、阿里云OSS等），这种传统方案已逐步被替代。
其主要原因在于这些新方案不仅具备卓越的持久性（通常超过10个9），而且还具有异地多副本等特性最为关键的是成本极为低廉，并可实现更为经济的分层式存储策略。

数据湖是一种基于读时模式(Schema-on-read)的体系结构, 其通过较低的成本实现对各种类型数据的高效存储能力, 然而这一架构却将对数据质量和治理的关注置于后续环节.

从外观上看, 第二代数据平台能够实现存储与计算的分离, 这一设计有助于降低运营成本, 然而该平台仍存在一些问题(以下是论文原话的翻译).

• 可靠性(Reliability). 保持数据湖和数据仓库的一致性既困难又昂贵. 需要持续在两个系统之间进行ETL, 使其可用于高性能决策支持和BI. 每个ETL步骤也有招致失败或引入降低数据质量的错误的风险, 例如, 由于数据湖和数据仓库引擎之间的细微差别而引起的.
• 数据陈旧(Data staleness). 与数据湖中的数据相比, 数据仓库中的数据是陈旧的, 新数据经常需要几天才能加载. 与第一代数据平台架构相比这是一种倒退, 在第一代数据平台中, 新的业务数据可以立即用于查询. 根据Dimensional Research和Five-tran的调查, 86%的分析师使用过时的数据, 62%的分析师报告每月要等待工程资源多次.
• 对高级分析的支持有限(Limited support for advanced analytics). 企业希望使用他们的数据仓库数据回答预测性问题, 例如, “我应该向哪些客户提供折扣?” 尽管对ML和数据管理的融合进行了大量研究, 但没有一个领先的机器学习系统, 如TensorFlow, PyTorch和XGBoost, 能够在数据仓库上很好地工作. 与提取少量数据的BI查询不同, 这些系统需要使用复杂的非SQL代码处理大型数据集. 通过ODBC/JDBC读取这些数据是低效的, 而且没有办法直接访问数据仓库内部的专有格式. 对于这些用例, 数据仓库供应商建议将数据导出到文件, 这进一步增加了复杂性和陈旧性(增加了第三个ETL步骤!). 或者, 用户可以针对开放格式的数据湖数据运行这些系统. 然而, 它们会失去数据仓库丰富的管理特性, 比如ACID事务, 数据版本控制和索引.
• 总拥有成本(Total cost of ownership). 除了为连续ETL付费之外, 用户还要为复制到数据仓库的数据支付双倍的存储成本, 而且商业仓库将数据锁定为专有格式, 这增加了将数据或工作负载迁移到其他系统的成本.

Lakehouse架构概览

鉴于当前数据平台架构中存在的诸多问题, 论文提出了一项研究课题: 是否有可能将基于标准开放数据格式（如Parquet和ORC）的数据湖转换为高性能系统？该系统需既能满足传统数据分析环境所需的性能与管理功能, 又能实现从高级分析工作负载中直接获取I/O操作的支持？

显然, 研究者认为上述问题显然是有可能存在的. 因此, 提出了如下Lakehouse平台架构设计. 其在数据湖之上构建了一层轻量级封装模块, 从而能够有效支撑数据仓库类的应用需求, 同时具备了高效的数据输入/输出能力，并为机器学习系统提供了相应的支持.

Lakehouse必备的技术条件

基于Lakehouse数据平台架构的实现需要一定的技术条件作为支撑。该研究探讨了三个关键的技术要求，并认为这些要求构成了Lakehouse时代的必要前提。

数据湖上的可靠数据管理： Lakehouse必须能够存储原始数据并类似地管理这些文件, 同时支持ETL/ELT流程, 从而提升分析质量. 传统上, 数据湖仅作为无结构化文件的形式进行管理, 这使得难以提供诸如事务控制、回滚到旧表版本以及零拷贝克隆等关键功能, 这些功能对于简化传统数据分析中的ETL流程至关重要. 近期出现的一些系统, 如Delta Lake和Apache Iceberg, 已经实现了事务视图并增强了管理功能. 然而, 在Lakehouse中实现这些功能仍然需要编写复杂的ETL逻辑以创建经过优化的数据集. 尽管如此, ETL步骤数量有所减少, 并且分析人员仍能轻松高效地访问原始数据表, 这一情况与早期分析平台的功能非常相似.

支持机器学习和数据科学： 大多数ML系统直接支持对数据湖格式的数据读取, 因此已经成功地将自己置于Lakehouse的良好发展位置. 此外, 许多ML系统采用了DataFrame作为操作数据的抽象模型. 最近开发了一系列声明式的DataFrame API, 这些API允许在ML工作负载中执行针对查询优化的数据访问操作. 这些API使ML工作负载能够直接受益于Lakehouse中的许多性能改进.

SQL性能： Lakehouse将依赖于积累海量Parquet/ORC标准格式的数据集(时间跨度可能长达十年)来提供最先进别的SQL性能. 相比之下, 传统的数据分析仓库接受标准SQL并能够自由地对其进行任何优化. 尽管如此, 我们表明可以通过采用多种技术维护辅助数据并优化现有标准格式的数据布局(如Parquet/ORC), 从而在现有架构中实现具有竞争力的SQL性能表现. 我们展示了Databricks Delta引擎在TPC-DS基准测试中的优异表现: 在这一基准测试中,Databricks Delta引擎在TPC-DS上的性能超过了当前领先的云数据库解决方案.

从上述条件可以看出, 为了实现Lakehouse平台的现实运行, 需要在存储与计算两个方面都具备坚实的 technically solid technical foundation.

• 存储层面上, 传统数据湖需配备事务管理、索引构建以及多版本管理等功能. 同时, 还应具备声明式DF API的支持, 以便机器学习系统可直接接入优化后数据湖中的数据. 当前开源Delta Lake及Apache Hudi/Iceberge等系统旨在解决此类问题, 它们均在原有数据湖架构上引入了table format.
• 计算层面上, 需要有高效的SQL引擎来直接访问优化后数据湖中的数据, 并能提供与传统数据分析平台相当的查询性能. Databricks采用了自研Delta Engine, 其他选项还包括开源Spark/Flink或FPGrowth等MPP引擎, 以及Presto等其他MPP引擎, 根据具体查询场景可灵活选择最优引擎配置. 此外, 阿里云DLF及火山 LAS 等平台也采用了混合引擎方案.

Lakehouse架构及特性

Lakehouse的定义

在相关研究基础上, 论文对Lakehouse做出了明确定义：我们将其定义为一种能够高效利用低成本资源并便于直接获取存储资源的数据管理系统. 该系统不仅具备传统分析型DBMS的核心管理功能（如支持ACID事务处理、提供持久化记录能力以及实现隔离机制）, 还包含完整的Index支持（提升查询效率）、Audit功能（保障数据完整性和追溯性）以及Cache机制（优化数据访问速度）等关键特性.

由定义可知, Lakehouse通过融合数据湖与数据仓库的核心优势实现了高效的数据处理。
其特点包括开放式的低成本存储架构以及具备相应的技术支持。
这种架构能够提供全面的管理与优化功能,
确保在处理大规模数据时依然保持高性能。

值得注意的是,Lakehouse专为云环境中的分布式计算设计,即不同的计算任务可以在各自独立运行的情况下访问共享的数据资源.这种架构不仅适用于机器学习任务中的GPU集群,还可以扩展到其他类型的分布式计算场景.此外,在现有的HDFS等内部存储系统中也可部署Lakehouse架构.

Lakehouse的架构

论文构建了Lakehouse架构如图所示. 在传统数据存储的基础之上, 增设了元数据层, 该层不仅在低成本数据存储中加入了事务管理与多版本控制等实用功能, 并且还提供了缓存辅助以及数据结构支持(包括索引统计等), 同时还能实现数据布局优化. 在元数据层之上, 可以通过SQL API直接获取原始数据库中的原始数据用于BI分析, 同时也可以借助声明式DFRAME API获取原始数据用于数据分析与机器学习任务.

可以看出 Lakehouse 架构具有一种很强的灵活性，在构建 Lakehouse 架构的过程中，能够灵活组合各种存储与计算引擎。论文对 Databricks Lakehouse 平台架构的具体实现进行了深入介绍，其采用的各个引擎如下图所示。

• Metadata层基于Delta Lake实现，并且已有该产品的开源版本，具体来说，其他类似的开源解决方案包括Apache Iceberge和Hudi。
• 计算引擎采用了Databricks内部C++自行研发的Delta Engine，并支持完全兼容Spark SQL功能，并提供丰富的查询优化功能。此外还可以选择使用如Apache Spark、Flink或Presto等开源引擎。

[


](https://towardsdatascience.com/what-does-databricks-do-8a6c4ef9071b)

Metadata Layers for Data Management

元数据层位于现有的数据存储架构之上，并通常支持现有存储格式中的Parquet和ORC等，并提供必要的元数据管理和元分析功能。

• 事务处理机制、零拷贝克隆技术、时间戳管理；
  • 数据约束措施（如字段类型限制等），有助于提升数据湖中的数据质量；
  • 权限验证机制（例如判断某个用户是否能访问特定的表）。

目前开源项目中的Delta Lake、Apache Iceberg/Hudi等系统已实现大部分功能的支持。然而现有研究亦指出数据湖的元数据层尚未完善，仍存在诸多值得进一步探讨的问题。具体而言，在现有系统如Iceberg和Hudi等仅支持单表范围内的事务处理情况下，在未来研究中应探索多表范围内的并发处理技术；此外如何精简事务日志格式及优化管理对象规模仍需深入研究。就当前技术水平而言，在提升系统性能方面仍有许多瓶颈亟待突破；例如针对Delta Lake而言，在其设计架构中若能将事务日志存储于更快捷的数据存储引擎，则有望显著减少数据访问延迟；同时针对现有系统的限制性设计（如单表范围内仅支持并发处理）也应在后续版本中得到相应改进。”

SQL Performance in a Lakehouse

Lakehouse架构能否成功的关键因素在于其在上层架构中能否保障与传统数据仓库相当的SQL执行效率。由于SQL查询基本上构成了一个数据分析平台的核心功能，并且其中很大一部分对于系统的延迟表现有着极高的要求 Lakehouse通过去除专用的数据仓库级SQL执行引擎却依然能够维持与传统数据仓库相当水平的表现这一特性确实面临着严峻的技术挑战。而对于那些对数据分析实时性要求较低的应用场景如高级分析以及机器学习系统 Lakehouse只需提供相应的接口即可满足这些业务需求而无需过分关注快速的数据读取需求

本文指出，在放弃传统数据库管理系统（DBMS）设计中的大部分数据独立性的同时实现最高水平的SQL性能这一目标受到诸多因素的影响。本文阐述了几种优化方案，这些技术已在Databricks的Delta引擎中得到成功应用。以下是论文原文的翻译：

• 缓存(Caching): 当使用诸如Delta Lake之类的事务性Metadata层时, Lakehouse系统可以安全地将来自云对象存储的文件缓存在更快的存储设备上, 例如处理节点上的SSD和RAM. 正在运行的事务可以很容易地确定缓存的文件何时仍然可以读取. 此外, 缓存可以采用代码转换的格式, 这种格式对于查询引擎的运行更有效, 与传统"封闭世界"数据仓库引擎中使用的任何优化相匹配. 例如, 我们在Databricks的缓存部分解压缩了它加载的Parquet数据.
• 辅助数据(Auxiliary data) : 尽管Lakehouse需要公开直接I/O的表格存储格式, 但它可以在其完全控制的辅助文件中维护有助于优化查询的其他数据. 在Delta Lake和Delta Engine中, 我们为表中的每个数据文件维护列最小-最大统计信息, 这些数据文件位于用于存储事务日志的同一个Parquet文件中, 这使得在基本数据按特定列聚集时可以使用数据跳过优化. 我们还在实现基于Bloom Filter的索引. 人们可以想象在这里实现广泛的辅助数据结构, 类似于索引"原始"数据.
• 数据布局(Data layout): 数据布局对访问性能影响很大. 即使我们确定了Parquet等存储格式, Lakehouse系统也可以优化多种布局决策. 最明显的是记录排序: 哪些记录聚集在一起, 因此最容易一起读取. 在Delta Lake中, 我们支持使用个体维度或空间填充曲线(如z阶和希尔伯特曲线)来排序记录, 以提供跨多个维度的局部性. 您还可以想象支持在每个数据文件中以不同顺序放置列的新格式, 为不同的记录组选择不同的压缩策略或其他策略.

研究探讨了在Delta Lake框架下执行Delta Engine时SQL查询效率的相关特性。通过对比分析可以看出，在相同的数据规模下Lakehouse架构所消耗的成本仅为其他方案的30%左右。主要观察到以下几点：第一，在所有对比中Lakehouse展现出显著的成本优势；第二，在相同的运行环境下其SQL查询效率超越了其他三个主流云架构。

从上述分析可见, 湖KateHouse能否取得成功取决于性能卓越的计算引擎. Databricks的Delta Engine目前尚未推出开源版本, 而同样地，在Lakehouse架构中采用Spark/Flink/Presto等现有技术时，则仍存在进一步优化的空间. 我们普遍认为未来在计算引擎查询优化方面的研究方向具有重要意义.

Efficient Access for Advanced Analytics

高级数据分析库多采用基于命令式的编程范式，在不依赖传统SQL查询方式的同时仍需处理海量数据。研究者们发现了一个很有挑战性的问题：如何优化这些平台的数据访问机制以显著提升其运行效率和操作自由度，并仍能从Lakehouse等新型存储架构中挖掘出新的性能提升空间。

Databricks广泛应用于通过其某些库引入声明式的DataFrame API, 这种方法能够将数据读取计划转换为与之等效的Spark SQL查询计划, 并得益于这些存储层的优化设计. 其工作原理如下: 首先, 数据源会被系统识别并构建相应的物理表; 然后, 通过指定API调用者即可启动对目标表的数据访问; 最后, 系统会自动处理数据转换及结果返回的过程.

相比而言, 机器学习API的情况较为复杂. 然而, 如Tensorflow的tf.data等数据访问API并不支持直接查询数据的语言. 最近的研究发现表明, 有效利用现代查询加速器成为一项具有挑战性的任务. 尤其是针对机器学习推理（ML推断）的应用而言, 这一问题尤为突出. 因此, Lakehouse访问库需要解决这一难题. 论文中进一步指出, 目前仍需开发标准接口以帮助数据科学家充分利用Lakehouse及其相关存储系统的强大数据管理功能. 例如，在Databricks平台中实现了Delta Lake格式与MLflow实验跟踪服务的整合, 这使得研究人员能够便捷地追踪实验所使用的数据表版本信息，并在后续工作中方便地复现这些版本的数据.

Lakehouse的特性

基于以上所述内容, 我们能够对Lakehouse的特性进行整理。然而论文中并未有涉及相关内容的具体讨论。具体信息则可参考Databricks官方博客中的详细解析What Is a Lakehouse?。

Lakehouse具有以下主要特征:

• 事务支持(Transaction support): 在企业的Lakehouse中, 许多数据管道经常会并发地读写数据. 对ACID事务的支持确保了多方并发读写数据(通常使用SQL)时的一致性.
• **模式执行和治理(Schema enforcement and governance): **Lakehouse应该有一种支持模式执行和演化的方法, 支持DW模式体系结构, 比如星型/雪花型模式. 系统应该能够推断数据完整性, 并且应该有健壮的治理和审计机制.
• BI支持(BI support): Lakehouse支持直接在源数据上使用BI工具. 这减少了过时性, 减少了延迟, 并降低了必须操作数据湖和数据仓库中的两个数据副本的成本.
• 存储与计算分离(Storage is decoupled from compute): 实际上, 这意味着存储和计算使用独立的集群, 因此这些系统能够扩展到更多并发用户和更大的数据规模. 一些现代数据仓库也具有这种特性**.**
• 开放性(Openness): 它们使用的存储格式是开放和标准化的, 如Parquet, 它们提供了一个API, 因此各种工具和引擎, 包括机器学习和Python/R库, 可以有效地直接访问数据.
• 支持从非结构化数据到结构化数据的各种数据类型(Support for diverse data types ranging from unstructured to structured data): Lakehouse可用于存储, 精化, 分析和访问许多新数据应用程序所需的数据类型, 包括图像, 视频, 音频, 半结构化数据和文本.
• **支持不同的工作负载(Support for diverse workloads): **包括数据科学, 机器学习, SQL和分析. 可能需要多个工具来支持所有这些工作负载, 但它们都依赖于相同的数据存储库.
• 端到端流(End-to-end streaming): 实时报告是许多企业的标准. 对流媒体的支持消除了为实时数据应用提供服务的独立系统的需要.

总结

本文是对Databricks Lakehouse论文的系统性解读与总结。

其次,Lakehouse架构在面对海量异构数据时展现出明显局限性（局限明显）。

再次,Lakehouse体系在云计算时代展现出显著优势（优势明显）。

本文通过深入解析Lakehoue架构的工作原理,并结合实际应用场景探讨了其在大数据时代的价值定位与应用前景。

虽然Lakehouse看似是一个更为完善的架构。然而目前来看，则因原因而尚未得到广泛的使用。同时，在流批一体的存储方面来看的话，则仍然存在进步的空间。因此目前大部分实时应用仍依赖于能够支持实时数据写入的数据仓库。不过笔者深信不疑地认为，在数据湖存储与计算引擎进一步发展的前提下，基于低成本方案的数据湖在未来将被广泛采用。与Lakehouse相关的存储技术和处理方法也将成为大数据系统领域的重要研究方向。

参考

[1] 什么是数据湖？
[2] 深入解析Delta Engine的工作原理
[3]《Delta Lake主题系列5讲》回顾
[4] 对比分析：主流数据湖方案解析
[5] 企业为何趋同于采用lakehouse技术？