数据仓库 - 最早的“结构化”范式
概念源头:
- 提出者: 比尔·恩门,被誉为“数据仓库之父”。
- 时间: 1990年代初期。
- 标志性著作/定义: 他在1990年出版的《构建数据仓库》一书中给出了经典定义:“数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合,用于支持管理决策。”
核心思想与源头背景:
- 解决什么问题: 在80-90年代,企业的运营数据分散在各个独立的业务系统(如CRM、ERP)中,形成“数据孤岛”,无法进行有效的跨部门分析。决策者需要一致的、干净的历史数据来做商业智能分析。
- 核心理念:
- ETL: 数据从源系统抽取出来,经过清洗、转换、集成等复杂过程后,加载到数据仓库中。这个过程叫ETL。
- Schema-on-Write(写时建模): 在数据写入之前,就必须事先定义好严谨的数据模型(如星型模式、雪花模式)。这确保了数据的高度结构化、高质量和一致性。
- 服务于BI和报表: 主要用户是业务分析师和决策者,用于运行标准的报表、即席查询和OLAP分析。
- 技术代表: Teradata, IBM Netezza, 以及后来的 Vertica, Greenplum 等。
简单比喻: 数据仓库就像一个高度组织化、分类清晰的瓶装水超市。水都经过净化、标准化包装、贴上标签,整齐摆放在货架上,方便消费者直接购买饮用。但进货(ETL)过程很繁琐。
数据湖 - 应对“多样性”与“原始性”的浪潮
概念源头:
- 提出者: 詹姆斯·狄克逊,当时是Pentaho公司的CTO。
- 时间: 2010年。
- 标志性论述: 在一篇博客文章中,他为了对比ETL和数据抽取,首次提出了“数据湖”的比喻。
核心思想与源头背景:
- 解决什么问题: 随着Web 2.0、移动互联网和物联网的兴起,数据量爆炸式增长,数据类型也变得极其多样(日志、点击流、社交媒体、传感器数据、图片、视频等)。传统数据仓库的ETL流程昂贵、缓慢,且无法处理半结构化和非结构化数据。
- 核心理念:
- “先存储,后处理”: 将企业所有原始数据(原始格式)全部集中存储在一个低成本、可大规模扩展的存储系统中(如HDFS、对象存储S3)。
- Schema-on-Read(读时建模): 与数据仓库相反,数据在存入时不需要预定义结构。只有在读取和分析数据时,才根据需求应用结构(Schema)。这带来了极大的灵活性。
- 支持多种分析: 除了传统的BI,数据湖旨在支持数据科学、机器学习、预测分析等探索性工作。
- 技术代表: Apache Hadoop (HDFS) 是其早期的事实标准,后来云厂商的对象存储(如AWS S3)成为更主流的选择。
简单比喻: 数据湖就像一个天然的湖泊。湖水来自河流、溪流和雨水(各种数据源),以最原始的形式汇聚在一起。用户(如渔民、科学家、游客)可以按照自己的需求来取用湖水(进行分析)。但湖水可能是未过滤的,需要自己处理。
数据湖的挑战: 由于缺乏治理(元数据、数据质量、访问控制),很多数据湖演变成了无人管理的“数据沼泽”,数据难以查找、理解和使用,无法支持关键决策。
湖仓一体 - 融合的必然趋势
概念源头:
- 并非由单个人提出,而是行业为解决数据湖和数据仓库各自的局限性而自然演进出的架构理念。
- 时间: 大约在2010年代末期(2018-2020年左右)。
- 关键推手:
- Databricks公司 在2020年提出了 “Lakehouse”(湖仓一体) 的概念,并将其作为公司核心战略。
- AWS, Google Cloud, Microsoft Azure 等云厂商也几乎同时推出了自己的融合性解决方案(如AWS的Redshift Spectrum、Azure Synapse Analytics)。
核心思想与源头背景:
- 解决什么问题: 企业不想维护两套独立的数据系统(一个做数据科学的数据湖,一个做BI的数据仓库),这带来了数据冗余、高成本、管理复杂和“数据不一致”的问题。他们希望在一个平台上同时获得数据湖的灵活性和数据仓库的管理与性能。
- 核心理念:
- 开放格式存储: 数据以开放、标准的格式(如Parquet、ORC)存储在低成本的对象存储中,避免了厂商锁定。
- 事务支持与管理能力: 在数据湖之上,引入类似数据仓库的 ACID事务 保障,确保数据一致性,并强化数据治理、版本控制、数据血缘等功能。
- 统一的计算引擎: 支持SQL分析、实时流处理、机器学习和数据科学等多种工作负载,减少数据移动。
- 高性能与并发: 通过索引、缓存、数据优化等技术,提供接近传统数据仓库的查询性能和并发能力。
- 技术代表: Databricks Delta Lake(开源项目)、Apache Hudi、Apache Iceberg(这三个被称为“湖仓一体三剑客”,提供了表格式层),以及 Snowflake(从云数仓向湖仓一体扩展)、BigQuery 和 Amazon Redshift 等。
简单比喻: 湖仓一体就像一个现代化的综合水处理与配送中心。它建立在天然湖泊(低成本存储)的基础上,但配备了先进的水处理厂(事务管理、治理)、多条标准化的生产线(BI、数据科学)和高效的配送管道(高性能查询)。既能保存原始样本,也能按需提供瓶装水、桶装水或工业用水。
Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics [1]
总结演进脉络
| 特性 |
数据仓库 |
数据湖 |
湖仓一体 |
| 概念源头 |
比尔·恩门 (1990) |
詹姆斯·狄克逊 (2010) |
行业演进 (2020前后) |
| 核心哲学 |
Schema-on-Write |
Schema-on-Read |
融合与统一 |
| 数据 |
清洗后的结构化数据 |
原始全量数据(结构化/半结构化/非结构化) |
原始数据 + 治理后的可信数据 |
| 存储成本 |
高(专有硬件/存储) |
低(商用硬件/对象存储) |
低(基于对象存储) |
| 主要用户 |
业务分析师、决策者 |
数据科学家、数据工程师 |
分析师、科学家、工程师(所有数据用户) |
| 优势 |
高性能、强一致性、易用 |
灵活性高、支持多样数据、成本低 |
兼具两者优势:灵活、低成本、强治理、高性能 |
| 劣势 |
不灵活、成本高、难以处理非结构化数据 |
易成“数据沼泽”、缺乏事务支持、BI性能差 |
仍处于成熟期,最佳实践在形成中 |
演进逻辑: 从专一但封闭的数仓,到开放但无序的数据湖,最终走向开放且有序的湖仓一体。其根本驱动力是业务对数据的诉求从“事后分析”走向了“实时数据驱动”,需要在一个统一的平台上,用更低的成本,满足从传统报表到AI的所有数据用例。
参考资料
[1] Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics: https://www.databricks.com/sites/default/files/2020/12/cidr_lakehouse.pdf
|