湖中小屋：从数据仓库到数据湖

Posted 2022-01-31 cdai

湖中小屋：从数据仓库到数据湖

昨天读完了一篇不错的论文《Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics》。虽然篇幅不长，而且也没涉及到具体的理论和技术实现，但可以当作是对当前比较火的数据湖领域知识的导读。论文标题也比较有趣，Data Warehouse + Data Lake = Lakehouse。有点文字游戏，但非常契合文章主旨：是否能够融合数据仓库和数据湖的优点，解决当前主要痛点。下面我们就来学习一起这篇论文。

---

1.第一代：数据仓库

说到数据存储，我们最熟悉的就是数据库了，包括最初的关系型数据库，以及后来火起来的NoSQL数据库。而数据仓库的初衷则是通过保存大量的历史数据，帮助各种企业领导者更好地做出决策。其实现方式就是从各种数据库中（Operational Database）提取数据到一个中央数据仓库（Centralized Warehouse），提取时数据遵从预定好的schema，即所谓的Schema-on-write。这样后续的分析工作就会十分容易和高效。在论文中，这样的线上数据库到数据仓库架构被称为第一代系统架构。

---

2.第二代：数据湖+数据仓库

十几年前，第一代系统开始遇到问题。一是数据仓库计算和存储绑定在了一起。一方面数据仓库要应对大量的分析查询请求，而同时数据量也在不断增大。计算和存储都没有良好的分层，导致了高昂的硬件成本。二是越来越多的数据是非结构化的，比如视频、语音、文本文件等等，数据仓库的严格性导致没法存储这些数据。为了解决这些问题，数据湖的概念应运而生。

所谓数据湖（Data Lake）就是使用低成本的存储（通常是文件/对象API和存储系统），同时采用开放式文件格式而非内部格式（例如Apache Parquet、ORC等）来保存数据，方便各种应用程序直接访问。数据从各种客户端、数据库采集到数据湖，再从数据湖ETL到数据仓库。这也就是论文里提到的第二代系统架构，也是现在500强等企业中占主导地位的架构。

---

3.已有方案和问题

数据湖+数据仓库的架构解决了前面提到的计算和存储分离、非结构化数据保存等问题，但同时却增加了系统复杂度、延迟以及新的故障模式。论文中指出这些复杂度不是内在于大数据问题本身，而是软件工程中所说的Accidental Complexity，即由具体设计和实现方案导致的。既然有这些痛点，那肯定有人已经着手解决，两种现有方案是：

1. 外部表：近年来几乎所有数据仓库都加入了对External Table的支持，这让用户能在同一个SQL引擎里查询外部表里Parquet或ORC格式的数据。它提供给用户同时查询数据湖的能力，却并没有增强数据管理的能力，也并不能完全消除ETL和数据实效问题。而且这些外部数据源的Connector性能也通常很差，因为数据仓库的SQL优化只对自己的内部数据格式有效。
2. 新SQL引擎：此外还有大量数据湖之上的新SQL引擎，例如Hive、Spark SQL、Presto、AWS Athena等。这些专门针对数据湖的引擎性能不错，然而它们不能解决所有上面提到的所有问题，也不能取代数据仓库。

于是论文提出了一个疑问，就是如何将数据仓库的性能和数据管理优点融合到数据湖中。

Is it possible to turn data lakes based on standard open data formats, such as Parquet and ORC, into high-performance systems that can provide both the performance and management features of data warehouses and fast, direct I/O from advanced analytics workloads?

当然答案是肯定的，至少这条路是可以走通的。

---

4.新一代：Lakehouse

论文里将新一代的架构成为Lakehouse。具体如何实现分成三个部分。

4.1 事务型元数据

不管是HDFS还是AWS S3，都只提供了最底层的文件操作API。带来的问题就是想要一起更新几个文件都无法保证原子性，而并发访问、版本管理等功能就更是没有了。这些问题的根源是抽象的层次，在数据湖中只有文件这个抽象，而没有数据库、表等高级抽象。但通常我们想操作的其实是表，就像传统数据库里那样，而不是想直接面对一大堆物理文件。

Apache Iceberg、Hudi以及Delta Lake被称为数据湖的Table Formats，就是为了解决这些问题的。比如Delta Lake支持事务、版本管理、访问权限控制等功能。迈向Lakehouse的第一步就是利用这些Table Format，实现一个事务型的元数据层（Transactional Metadata Layer）。

4.2 海量数据的查询优化

因为数据湖中的数据是海量的，对其直接查询需要进行特殊的优化：

1. 缓存：元数据层的存在使得缓存成为了可能，将热数据保存到SSD或者内存，这样可以极大加快查询。
2. 辅助数据结构：还可以创建额外的数据结构来加快检索，比如Delta Lake保存了每个文件中列的min-max值范围。除此之外，各种索引技术经过改造都可以应用到数据湖文件。
3. 数据排列：此外还可以优化数据记录的排列，使之能更高效地读写。

4.3 高效的直接数据访问

对Parquet或ORC数据的直接访问，更多地是服务各种机器学习程序。论文中提到了Spark SQL中提供了声明式Data Frame API，使得各种机器学习和数据分析应用都可以基于Data Frame的抽象进行开发。