Cloudera 客户运行着地球上一些最大的数据湖。这些数据湖为关键任务大规模数据分析、商业智能 (BI) 和机器学习用例（包括企业数据仓库）提供动力。近年来，创造了“数据湖仓（Data Lakehouse）”一词来描述这种对数据湖中的数据进行表格分析的架构模式。在急于拥有这个术语的过程中，许多供应商忽略了这样一个事实，即数据架构的开放性是其持久性和寿命的保证。
1. 关于数据仓库和数据湖
数据湖和数据仓库将大量和各种数据统一到一个中心位置。但是有着截然不同的建筑世界观。数据仓库是为 SQL 分析垂直集成的，而数据湖优先考虑 SQL 之外的分析方法的灵活性。
为了实现这两个世界的好处——数据湖分析的灵活性和数据仓库中简单快速的 SQL——公司经常部署数据湖来补充他们的数据仓库，最后一步是数据湖为数据仓库系统提供数据提取、转换、加载 (ETL) 或 ELT 管道。在这样做的过程中，他们已经接受了数据在仓库中的锁定。
但是有一个更好的方法：进入 Hive Metastore，这是过去十年数据平台的沉睡者之一。随着用例的成熟，我们看到需要高效的交互式 BI 分析和事务语义来修改数据。
2. 数据湖仓的迭代
第一代 Hive Metastore 试图解决在数据湖上高效运行 SQL 的性能考虑。它提供了数据库、模式和表的概念，用于描述数据湖的结构，让 BI 工具可以有效地遍历数据。它添加了描述数据逻辑和物理布局的元数据，支持基于成本的优化器、动态分区修剪以及针对 SQL 分析的一些关键性能改进。
第二代 Hive Metastore 添加了对使用 Hive ACID 的事务更新的支持。湖仓虽然尚未命名，但非常兴旺。事务启用了持续摄取和插入/更新/删除（或 MERGE）的用例，从而打开了数据仓库样式的查询、功能以及从其他仓储系统到数据湖的迁移。这对我们的许多客户来说非常有价值。
Delta Lake 等项目采用了不同的方法来解决这个问题。Delta Lake 为湖中的数据添加了事务支持。这允许数据管理，并为数据湖带来了运行数据仓库式分析的可能性。
在这个时间线的某个地方，“数据湖仓”这个名称是为这种架构模式创造的。我们相信 Lakehouses 是简洁地定义这种模式的好方法，并且很快在客户和行业中获得了共识。
3. 客户告诉我们什么？
在过去的几年里，随着新数据类型的诞生和新的数据处理引擎的出现以简化分析，公司开始期望两全其美的真正需要分析引擎的灵活性。如果对企业的大而有价值的数据进行管理，那么企业必须开放以选择不同的分析引擎，甚至是供应商。
湖仓模式在实施过程中存在一个严重的矛盾：虽然数据湖是开放的，但数据湖仓却不是。
在添加 Impala、Spark 等引擎之前，Hive Metastore一直遵循着 Hive-first 的演变。而Delta lake是一个Spark密集型的演变；如果客户需要自由选择不同的引擎，而不是以某种表格式为主，他们的选择会迅速减少。
客户从一开始就要求更多。更多格式、更多引擎、更多互操作性。今天，Hive 元存储被多个引擎和多个存储选项使用。当然包括 Hive 和 Spark，还有 Presto、Impala 等等。Hive Metastore 有机地发展以支持这些用例，因此集成通常很复杂且容易出错。
为满足互操作性需求而设计的开放数据湖仓从根本上解决了这一架构问题。这会让那些在一个平台上“全力以赴”的人感到不舒服，但社区驱动的创新是关于使用同类最佳工具以务实的方式解决现实世界的问题，并克服供应商锁定，无论他们是否批准。
4. 一个开放的湖仓，以及Apache Iceberg的诞生
从一开始构建Apache Iceberg的目标是在多个分析引擎和云原生规模上轻松互操作。Netflix是这项创新诞生地，可能是需要将100 PB 规模的 S3 数据湖构建到数据仓库中的最佳示例。云原生的表格格式由其创建者开源到 Apache Iceberg 中。
Apache Iceberg 真正的超级大国是它的社区。在过去三年中，Apache Iceberg 有组织的与蓬勃发展的社区增加了令人印象深刻的一流集成名册：
- 数据处理和 SQL 引擎 Hive、Impala、Spark、PrestoDB、Trino、Flink
- 多种文件格式：Parquet、AVRO、ORC
- 社区中的大型采用者：Apple、LinkedIn、Adobe、Netflix、Expedia 等
- 使用 AWS Athena、Cloudera、EMR、Snowflake、腾讯、阿里巴巴、Dremio、Starburst 提供的托管服务
使这个多样化的社区蓬勃发展的原因是数千家公司的集体需求，以确保数据湖可以演变为包含数据仓库，同时保持跨引擎的分析灵活性和开放性。这使得开放式湖仓成为可能：为未来提供无限的分析灵活性。