本文从数据存储格式的演变介绍了数据工程领域的大数据处理框架发展，从Hive到Iceberg、Delta Lake以及数据湖屋的发展过程：

数据如何存储（在文件和内存中）
开源文件格式（如Avro、Parquet、ORC和Arrow）能够高效存储和访问数据，并可从多种编程语言和工具进行读写操作。

但文件格式只是整个数据堆栈的一层。它们对于独立工作或小规模工作的数据科学家很有帮助。但就其本身而言，它们并没有真正为数据引擎提供管理大规模、不断发展的数据集所需的一切。

这就是Hive格式、Iceberg 和 Delta Lake等更高级别存储层的用途：

• Netflix开发了 Iceberg 来克服Hive的一些限制，特别是在性能和​​可扩展性方面
• 然后Databricks开发并最终开源了Delta Lake，它是 Iceberg 的替代品。
• Iceberg 和Delta Lake 都使用 Parquet作为各自的文件格式
• Hive、Delta Lake 和 Iceberg 都支持模式注册表或元存储。
• 在Hive中，HMS（Hive MetaStore）几乎可以是任何RDBMS。当然，Iceberg 和 Delta Lake 具有类似的概念（Iceberg Catalogs、Unity Catalog），甚至允许组织管理其数据的治理（即谁或哪些团队可以访问哪些表）。

大规模数据管理——Iceberg 和 Delta Lake
Iceberg和Delta Lake是用于管理大规模、演进的数据集的高级存储层，它们提供了元数据和模式注册表，都使用Parquet作为文件格式，

Delta Lake 和 Iceberg 本身都不是查询或存储引擎。相反，它们是开放规范，允许查询引擎完成其工作。它们支持许多功能，并支持分区、模式演化、数据压缩、ACID事务等功能。

• 分区：具体来说，Iceberg 支持分区演进。这意味着你可以改变表的分区方案（或分区键），而无需重写所有现有数据。这是 Netflix 的一大痛点，也是他们创建 Iceberg 的原因之一。
• Schema演变
• 围绕Schema变化的 ACID 事务
• 高效查询优化（如列剪枝、谓词下推和统计数据收集，以加速查询）
• 时间旅行（时间点查询）

Delta Lake 和 Iceberg本质上以不同的方式解决相同的问题。鉴于 Delta Lake 的开发在贡献者方面不像 Iceberg 那样多样化，因此关于 Delta Lake 的“开放”程度也存在很多争论。

在过去几年中，许多不同的提供商宣布支持 Iceberg（Redshift、BigQuery、Snowflake、Athena、Dremio等）。

所有数据库系统迟早都必须支持Iceberg。

什么是数据湖和数据湖屋？
数据湖Data Lake、数据仓库Data Warehouse 和数据湖屋Lakehouse 是存储大量数据的地方：

• 数据湖以原始格式存储数据，例如OCR或Parquet，甚至CSV 文件（想象一下包含大量此类文件的S3 存储桶）。
• 数据仓库 则结构化存储数据并支持SQL查询和数据治理
• 数据湖屋是将数据湖与执行SQL 查询、运行批处理作业和设置数据治理方案等操作的能力之间的结合。

数据湖屋都可以通过 Iceberg 与一些查询引擎和其他 "附加组件 "一起构建在数据湖之上，而以前则需要采用数据仓库（或更经典的 DMBS）才能完成这些工作。

数据湖屋利用某种可扩展存储作为所有数据的位置（HDFS 或类似 S3 的云 Blob 存储）。他们还优化了查询引擎，使其在这些存储引擎上的运行速度非常快。因此，数据湖屋基本上就是数据仓库的开放版本。数据湖屋示例是Databricks和Dremio

而数据仓库和数据湖屋之间的界限变得越来越模糊，因为某些仓库（例如Snowflake和BigQuery）添加了对 Iceberg 等开放数据格式的支持。