关于 Lakehouse 的一些笔记和看法

数据仓库历史

1980年代到2010年代的数据仓库

这是最经典的数据仓库模型，模型上面的不多说，可以参考数据仓库理论。从技术角度上来说，

• 进行 ETL 的数据直接来源于操作性数据库（OLTP数据库）
• 有表结构、索引和事务等丰富的SQL特性

2010 年代以后的数据湖

2010年左右的时候，传统的数据仓库碰上了互联网时代。传统的数据仓遇到了大量的问题，比如：

• 不能很好地支持非结构化和半结构化数据：时间序列、日志、图片和文档等；
• 需要非常高的代价去存储大量的数据；
• 不支持数据科学和机器学习。

于是就有了数据湖理论。数据湖拥有着：

• 低成本的存储：可以使用文件API（S3、HDFS）存储所有原生数据；
• 开放的文件格式（Parquet）：可以被机器学习和深度学习引擎直接接触；
• 可以使用ETL任务将特定数据加载进数据仓库里。

数据湖的问题

数据湖也面临着着不少的问题。

• 它引入了多个不同的计算引擎，比如有着 Hive、Impala 等等，它们都有着不同的SQL方言，提高了复杂性；
• 数据仓库要使用数据湖数据时，需要额外的 ETL 步骤；
• 因为没有良好的理论规范，有时候会面临着重复存储的问题。

于是，Databricks 公司提出了 Lakehouse 的概念，试图解决这些问题。

Lakehouse 概念

Lakehouse 将数据仓库建立在数据湖之上，赋予了数据湖事务支持、表结构、报表以及分析应用的支持等功能。除了这些外，Lakehouse 还具有着如下特征：

• 数据类型扩展：数据类型扩展：数仓仅可以支持结构化数据，而 Lakehouse 的结构可以支持更多不同类型的数据，包括文件、视频、音频和系统日志。
• 端到端的流式支持：Lakehouse 可以支持流式分析，从而能够满足实时报表的需求，实时报表在现在越来越多的企业中重要性在逐渐提高。
• 计算存储分离：我们往往使用低成本硬件和集群化架构来实现数据湖，这样的架构提供了非常廉价的分离式存储。Lakehouse 是构建在数据湖之上的，因此自然也采用了存算分离的架构，数据存储在一个集群中，而在另一个集群中进行处理。
• 开放性：Lakehouse 在其构建中通常会使 Iceberg，Hudi，Delta Lake 等构建组件，首先这些组件是开源开放的，其次这些组件采用了 Parquet，ORC 这样开放兼容的存储格式作为下层的数据存储格式，因此不同的引擎，不同的语言都可以在 Lakehouse 上进行操作。

Lakehouse 关键技术

Lakehouse 的关键技术在于赋予了数据湖的一个元数据层，让可追踪的文件格式变成了表的变更版本的一部分，以提供丰富的管理特征，比如事务。

我的观点

Lakehouse 最重要的变革在于让基于 HDFS 的数据仓库可以处理单行数据的增删改查。因为 HDFS 本身是不支持对单行或多行数据的删改的，导致基于 HDFS 的计算引擎也不支持单行或多行数据的删改，但是 Lakehouse 通过引入了一个元数据层和后台的合并数据操作，让这些计算引擎也能够支持单行或多行数据的删改了。由此进而赋予了 HDFS 存储系统也能支持流式分析能力了。

参考文章：

• 英文 http://cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html https://www.xplenty.com/glossary/what-is-a-data-lakehouse/
• 中文 https://www.iteblog.com/archives/9905.html https://www.mdeditor.tw/pl/pcAN