从数仓到数据湖，再到Data LakeHouse

Data LakeHouse是一种新型的湖仓一体架构，该架构旨在用一套系统实现原来的数据仓库（Data Warehouse）加数据湖（Data Lake）的功能。数仓、数据湖、LakeHouse的发展演进过程如下图（图片出自Databricks）：

本文简单梳理一下整个发展演进的过程。

Data Warehouse

Data Warehouse就是我们平时说的数据仓库（简称数仓），数仓最典型的代表就是MPP数据库。最原始的时候，数据量还不是很大，传统的单体数据库可以支撑平时的分析、决策、报表等需求。但随着后来应用的不断增多，数据量也激增，单体DB已经无法承载，于是便出现了数仓这种新型的架构。
​
数仓一般包含以下元素：

• Metadata – a guide to what data was located where
• A data model – an abstraction of the data found in the data warehouse
• Data lineage – the tale of the origins and transformations of data in the warehouse
• Summarization – a description of the algorithmic work designed to create the data
• KPIs – where are key performance indicators found
• ETL – enabled application data to be transformed into corporate data

数仓的一些特点：

• 数据格式以结构化数据为主，也能很有限的支持一些类似JSON的半结构化数据
• 数据的使用（分析、BI、报表）方式以SQL为主
• 对机器要求较高，一些商用的MPP数据库甚至是定制的一体机

我觉得用一个不太准确但易于理解的描述就是数仓像是一个“分布式的数据库”，因为是分布式的，可以扩展节点，所以可以承载的数据量比以前大了。但它的灵魂依旧还是数据库，所以像传统单体DB中的一些特性在数仓中依旧存在，比如事务、模型（表结构）、隔离性等概念。简言之，数仓主要解决了传统单体DB无法承载越来越多的数据量的问题（当然还有一些其它功能）。

但随着技术的发展和业务需求的不断产生，数仓也开始暴露出一些问题：

• 无法存储非结构化的文本、图像、视频、音频等越来越常见的数据格式
• 容量上限不够大
• SQL这种使用数据的形式太单一，有很多局限，从而导致了一些问题。比如现在有些机器学习算法是需要直接访问数据进行迭代，而不是通过SQL；再比如无法高效的ETL，因为需要通过ODBC先读取数据，而不是直接访问原始数据

于是，便出现了数据湖。

Data Lake

数据湖本质上可以看成是一个接近无限容量，且支持任何格式数据的廉价存储系统。像我们熟知的AWS S3、Azure Data Lake Storage (ADLS)、Google Cloud Storage (GCS)、阿里OSS、腾讯的COS等对象存储系统都可以认为是数据湖。

数据湖的特点是：

• 接近无限容量
• 理论上支持任何数据格式
• 存储格式开放，最常见的是Apache Parquet和ORC，这样有两方面的好处，一方面可以避免被某一个厂商绑死；另一方面可以很好的与其它产品形成生态
• 存储成本低，普通的硬件即可

本来，数据湖的设计初衷是解决数仓容量和数据格式支持的不足，将所有格式的数据全部存储在数据湖里面，然后使用的时候直接使用湖里面的数据进行分析、查询、计算。但真正使用的时候，大家发现数据湖缺失了一些关键特性，导致湖里的数据无法直接使用。概括来说，主要存在三个方面的问题：

1. 安全问题（Security）。数据湖中的数据基本都是以文件的形式存放的，这样就无法提供细粒度的访问控制，比如无法提供文件内容级别的控制，只能针对文件、目录等级别进行控制。
2. 性能问题（Performance）。因为数据湖的本质是以文件存储系统，所以没有特别针对数据访问进行优化，一旦数据量多了以后，访问性能比较差，比如列出湖中存储的文件这种非常常用的操作在数据多的时候计算量很大。
3. 数据质量问题（Quality）。数据湖缺乏数仓中的一些数据管控（governance）和校验（validation）机制，比如Schema，这样数据的质量就无法得到保障。

当然，还有其它一些问题，比如不支持事务、原子写、并发等。结果最终数据湖就变成了数据沼泽（“data swamps”）：数据都扔进了数据湖，但无法直接使用。当真正需要使用的时候，还是要读出来放到其它地方（比如数仓）进行使用。但鉴于数仓又存在前面提到的问题，所以企业不得不同时维护一个数仓系统和一个数据湖系统，像极了计算领域的Lambda架构。但是同时维护两套系统的成本和复杂性是很高的，于是又出现了Data LakeHouse。

Data LakeHouse

Data LakeHouse一种湖仓一体的新型架构：

可以看到，其实就是把互补的两套架构（数仓和数据湖）融合成了一个架构，这样只用维护一套系统，就可以解决所有问题。概括来说LakeHouse架构的主要特点有：

• 开放（Openness）

  • 开放文件格式（Open File Formats）：使用开放标准的文件格式，比如Apache Parquet、Apache ORC
  • 开放API：提供开放、高效的直接访问数据的API，不和特定引擎、厂商绑定
  • 支持多种语言：不再局限于SQL一种，还支持各种各样的第三方库、工具、引擎、框架，比如TensorFlow、Pytorch等

• 机器学习支持更好

  • 支持各种格式的数据
  • 可以通过R/Python库高效的直接访问数据
  • 支持DataFrame API
  • 支持数据版本，用于审计、回退或者重新实验

• 低成本下更好的性能和可靠性

  • 集成了多种性能优化技术，比如缓存、多维汇聚、索引、压缩
  • 支持数据校验和治理，提高数据质量
  • 支持事务，保证数据一致性的同时提供更好的并发
  • 廉价的存储

目前可以算得上是LakeHouse的开源系统有：Apache Hudi（Uber开源）、Apache Iceberg（Netflix开源）、Delta Lake（Databricks开源）。其中Delta Lake的这篇论文算是目前对Data LakeHouse架构的一个“标准定义”：Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores。
​
Data Warehouse、Lake、LakeHouse对比：

最后

不管是数仓，还是数据湖，亦或是现在的融合架构LakeHouse，都是为了解决不断发展和产生的业务需求而迭代产生的新架构和解决方案，特别是随着AI的发展，Machine Learning技术已经越来越成熟，慢慢已经成为数据分析的主要组成部分，所以现在新的架构在与AI生态的结合方面考虑的越来越多。目前LakeHouse正在快速发展，提供解决方案和一体化平台的商业公司也在逐渐增多，对于我们这些技术人，能不断见证和学习这些优秀的技术，也算是一件幸事和乐趣。
​
更多信息可参考下面引用部分的文章。
​
References：

• What Is a Lakehouse?
• Delta Lake: High-Performance ACID Table Storage over Cloud Object Stores
• Frequently Asked Questions About the Data Lakehouse
• Evolution to the Data Lakehouse
• Frequently Asked Questions About the Data Lakehouse