[论文解读] The Data Lakehouse: Data Warehousing and More

Dipankar Mazumdar, Jason Hughes+1 more|arXiv (Cornell University)|Oct 12, 2023

Data Quality and ManagementDecision Sciences被引用 3

一句话总结

本文提出数据湖仓架构作为一种统一解决方案，将传统数据仓库的ACID事务处理能力、结构化数据管理及分析性能，与云数据湖的可扩展性、开放格式及成本效益相结合。通过利用Apache Iceberg等开放表格式及多引擎计算层，湖仓在单一统一的数据平台上实现了业务智能与机器学习工作负载的并发处理，无需数据复制或供应商锁定。

ABSTRACT

Relational Database Management Systems designed for Online Analytical Processing (RDBMS-OLAP) have been foundational to democratizing data and enabling analytical use cases such as business intelligence and reporting for many years. However, RDBMS-OLAP systems present some well-known challenges. They are primarily optimized only for relational workloads, lead to proliferation of data copies which can become unmanageable, and since the data is stored in proprietary formats, it can lead to vendor lock-in, restricting access to engines, tools, and capabilities beyond what the vendor offers. As the demand for data-driven decision making surges, the need for a more robust data architecture to address these challenges becomes ever more critical. Cloud data lakes have addressed some of the shortcomings of RDBMS-OLAP systems, but they present their own set of challenges. More recently, organizations have often followed a two-tier architectural approach to take advantage of both these platforms, leveraging both cloud data lakes and RDBMS-OLAP systems. However, this approach brings additional challenges, complexities, and overhead. This paper discusses how a data lakehouse, a new architectural approach, achieves the same benefits of an RDBMS-OLAP and cloud data lake combined, while also providing additional advantages. We take today's data warehousing and break it down into implementation independent components, capabilities, and practices. We then take these aspects and show how a lakehouse architecture satisfies them. Then, we go a step further and discuss what additional capabilities and benefits a lakehouse architecture provides over an RDBMS-OLAP.

研究动机与目标

• 解决传统RDBMS-OLAP系统的局限性，如供应商锁定、数据复制及专有格式。
• 克服云数据湖的不足，包括缺乏ACID事务支持、数据治理不一致以及对复杂分析工作负载支持有限。
• 统一数据仓库的能力（如数据建模、ETL/ELT、数据质量）与数据湖的可扩展性及开放性。
• 实现单一、开放且面向未来的数据架构，支持在单一数据副本上运行多样化的分析工作负载——业务智能、机器学习与实时分析。
• 证明湖仓架构可在降低复杂性与成本的同时，提供与传统数据仓库相当或更优的能力。

提出的方法

• 将传统数据仓库分解为与技术无关的组件：技术组件（如存储、计算）、技术能力（如ACID、SQL）以及与技术无关的实践（如数据建模、ETL）。
• 通过Apache Iceberg等开放表格式实现湖仓，提供ACID事务、模式演化及时间旅行功能，数据存储于云对象存储（如S3）中。
• 集成目录系统（如Project Nessie）以管理元数据，并实现数据环境（开发、生产）的Git式版本控制，提升数据治理与隔离能力。
• 使用基于SQL的分布式查询引擎（如Dremio Sonar）直接在数据湖的Iceberg表上实现低延迟、交互式分析。
• 通过向Apache Spark和scikit-learn暴露相同的Iceberg表，支持机器学习工作负载，消除ETL管道或数据移动的需求。
• 通过实时查询支持BI仪表板与流失预测模型训练，端到端演示分析流程，两者均基于同一数据源运行。

Figure 1. What is Data Warehousing?

实验结果

研究问题

• RQ1 数据湖仓架构能否复现传统RDBMS-OLAP数据仓库的核心技术与操作能力？
• RQ2 湖仓如何在单一统一的数据平台上支持业务智能与机器学习工作负载，且无需数据复制？
• RQ3 与传统数据仓库或原始数据湖相比，湖仓在多大程度上减少了供应商锁定并提升了数据治理？
• RQ4 哪些架构模式可实现在云原生、开放格式数据湖中支持ACID事务与一致的数据访问？
• RQ5 湖仓的开放可扩展特性如何支持未来扩展性及分析工作负载间的工具互操作性？

主要发现

• 通过Apache Iceberg等开放表格式，数据湖仓原生支持ACID事务、模式演化及时间旅行，实现可靠且一致的数据访问。
• 集成Project Nessie等目录系统可实现Git式版本控制与环境隔离，显著提升数据治理与操作敏捷性。
• 业务智能工作负载可直接使用Dremio Sonar等SQL引擎在Iceberg表上执行，实现低延迟、交互式查询性能，无需数据移动。
• 机器学习流水线可直接从湖仓使用Apache Spark消费数据，消除ETL管道需求，降低延迟与工程开销。
• 统一架构支持BI与ML工作负载在相同数据集上的并发执行，减少数据复制并提升数据一致性。
• 湖仓的开放特性允许多个分析引擎（如Dremio、Spark）在相同数据上共存与互操作，降低供应商锁定风险，提升工具灵活性。

Figure 2. A generic representation of an RDBMS-OLAP data warehouse. Note that all the technical components are bundled into a single unit.