本文简单梳理一下整个发展演进的过程。
Data Warehouse就是我们平时说的数据仓库(简称数仓),数仓最典型的代表就是MPP数据库。最原始的时候,数据量还不是很大,传统的单体数据库可以支撑平时的分析、决策、报表等需求。但随着后来应用的不断增多,数据量也激增,单体DB已经无法承载,于是便出现了数仓这种新型的架构。
数仓一般包含以下元素:
数仓的一些特点:
我觉得用一个不太准确但易于理解的描述就是数仓像是一个“分布式的数据库”,因为是分布式的,可以扩展节点,所以可以承载的数据量比以前大了。但它的灵魂依旧还是数据库,所以像传统单体DB中的一些特性在数仓中依旧存在,比如事务、模型(表结构)、隔离性等概念。简言之,数仓主要解决了传统单体DB无法承载越来越多的数据量的问题(当然还有一些其它功能)。
但随着技术的发展和业务需求的不断产生,数仓也开始暴露出一些问题:
于是,便出现了数据湖。
数据湖本质上可以看成是一个接近无限容量,且支持任何格式数据的廉价存储系统。像我们熟知的AWS S3、Azure Data Lake Storage (ADLS)、Google Cloud Storage (GCS)、阿里OSS、腾讯的COS等对象存储系统都可以认为是数据湖。
数据湖的特点是:
本来,数据湖的设计初衷是解决数仓容量和数据格式支持的不足,将所有格式的数据全部存储在数据湖里面,然后使用的时候直接使用湖里面的数据进行分析、查询、计算。但真正使用的时候,大家发现数据湖缺失了一些关键特性,导致湖里的数据无法直接使用。概括来说,主要存在三个方面的问题:
当然,还有其它一些问题,比如不支持事务、原子写、并发等。结果最终数据湖就变成了数据沼泽(“data swamps”):数据都扔进了数据湖,但无法直接使用。当真正需要使用的时候,还是要读出来放到其它地方(比如数仓)进行使用。但鉴于数仓又存在前面提到的问题,所以企业不得不同时维护一个数仓系统和一个数据湖系统,像极了计算领域的Lambda架构。但是同时维护两套系统的成本和复杂性是很高的,于是又出现了Data LakeHouse。
Data LakeHouse一种湖仓一体的新型架构:
可以看到,其实就是把互补的两套架构(数仓和数据湖)融合成了一个架构,这样只用维护一套系统,就可以解决所有问题。概括来说LakeHouse架构的主要特点有:
开放(Openness)
机器学习支持更好
低成本下更好的性能和可靠性
目前可以算得上是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对比:
Data warehouse | Data lake | Data lakehouse | |
---|---|---|---|
Data format | Closed, proprietary format | Open format | Open format |
Types of data | Structured data, with limited support for semi-structured data | All types: Structured data, semi-structured data, textual data, unstructured (raw) data | All types: Structured data, semi-structured data, textual data, unstructured (raw) data |
Data access | SQL-only, no direct access to file | Open APIs for direct access to files with SQL, R, Python and other languages | Open APIs for direct access to files with SQL, R, Python and other languages |
Reliability | High quality, reliable data with ACID transactions | Low quality, data swamp | High quality, reliable data with ACID transactions |
Governance and security | Fine-grained security and governance for row/columnar level for tables | Poor governance as security needs to be applied to files | Fine-grained security and governance for row/columnar level for tables |
Performance | High | Low | High |
Scalability | Scaling becomes exponentially more expensive | Scales to hold any amount of data at low cost, regardless of type | Scales to hold any amount of data at low cost, regardless of type |
Use case support | Limited to BI, SQL applications and decision support | Limited to machine learning | One data architecture for BI, SQL and machine learning |
不管是数仓,还是数据湖,亦或是现在的融合架构LakeHouse,都是为了解决不断发展和产生的业务需求而迭代产生的新架构和解决方案,特别是随着AI的发展,Machine Learning技术已经越来越成熟,慢慢已经成为数据分析的主要组成部分,所以现在新的架构在与AI生态的结合方面考虑的越来越多。目前LakeHouse正在快速发展,提供解决方案和一体化平台的商业公司也在逐渐增多,对于我们这些技术人,能不断见证和学习这些优秀的技术,也算是一件幸事和乐趣。
更多信息可参考下面引用部分的文章。
References: