本文是对Databricks的Lakehouse(湖仓一体)论文(Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics)的阅读总结. 论文详细阐述了需要Lakehouse的原因, Lakehouse的具体架构以及在Lakehouse构建中可进一步探索的研究性问题. 通过阅读论文可以更深刻地了解Lakehouse产生的前因后果, 从而更加客观地看待这一新兴数据平台架构.
本文不会对论文进行完整的翻译, 而是按如下主线剖析论文的核心观点和内容, 并穿插笔者的见解:
- 现有的数据平台架构及存在的问题.
- 支撑Lakehouse成功的必备技术条件.
- Lakehouse的架构及特性.
现有数据平台及问题
第一代数据平台
数据仓库(Data Warehouse)起源与上世纪80年代, 它将分散在各个业务数据库中的数据, 采集传输到集中的数据仓库中, 以帮助企业领导者获得分析见解, 这些数据仓库还可进一步用于决策支持和商业智能(BI).
第一代数据平台主要用于构建数据仓库, 其处理流程如下图所示. 包含在业务数据库(一般是关系型数据库)中的结构化数据通过ETL导入到数据仓库系统中. 数据仓库中的数据将使用写时模式(Schema-on-write)写入, 这确保了数据模型针对下游BI消费进行了优化.

随着数据量的增长, 第一代数据平台出现了一些问题(以下是论文原话的翻译):
- 首先, 它们通常将计算和存储耦合到本地设备中. 这迫使企业为峰值用户负载和受管理的数据进行调配和付费, 随着数据集的增长, 这变得非常昂贵.
- 其次, 不仅数据集在快速增长, 而且越来越多的数据集完全是非结构化的, 例如视频, 音频和文本文档, 难以在数据仓库中存储和查询.
实际上, 对于第一点笔者认为论文的描述并不完全准确, 数据仓库的实现技术也在不断发展. 在初期的小数据量时代, 数据仓库的实现系统一般以传统的关系型数据库为主, Oracle等厂商也有商用的数据仓库系统, 不过它们大多采用集中式架构. 这确实使得横向扩展困难, 当数据量增大而出现性能问题时, 只能纵向扩展底层系统资源, 需要昂贵的成本. 但是随着数据量的不算增长, MPP架构的出现使得廉价处理更大的数据集成为可能, 当前仍有广泛使用的MPP数据仓库, 如Greenplum, Clickhouse等. 另外, 随着云计算技术的发展, 云原生数据仓库的出现也为低成本地处理大规模数据提供了解决方案, 如AWS的Redshift, 阿里云的AnalyticDB等. 因此, 使用当前最先进的数据仓库系统在大规模数据集下不一定会有多么昂贵的成本, 不过这些数据仓库系统基本上只能处理结构化数据, 确实难以用于半结构化或非结构化数据的处理.
第二代数据平台
由于第一代数据平台的上述问题, 在2010年前后, 第二代数据平台开始出现.
在这一架构中, 所有的原始数据都会被导入到统一的数据湖中. 数据湖是具有文件API的低成本存储系统, 以通用且开放的文件格式保存数据, 如Apache Parquet和ORC. 之后, 数据湖中的一部分数据可进一步被ETL到下游的数据仓库系统中, 用于最重要的决策支持和BI应用. 另外, 开放格式的使用也使得数据湖中的数据可以被其他各种分析引擎直接访问, 例如机器学习系统. 其处理流程如下图所示.
![image.png](https://img-blog.csdnimg.cn/img_convert/9dd8d81253b4181fd50d983a774f0278.png#clientId=u6dd477a6-9c54-4&crop=0&crop=0&crop=1&crop=1&from=paste&height=289&id=uf246f8f4&margin=[object Object]&name=image.png&originHeight=587&originWidth=436&originalType=binary&ratio=1&rotation=0&showTitle=false&size=86020&status=done&style=none&taskId=u6d5e7938-ffda-4db3-81e5-b48272839d