开放式湖仓是湖仓一体架构的最终归宿

由于现有架构中的数据仓库和数据湖有着各种各样的问题，湖仓一体架构就应运而生了，接下来我们来看看什么是湖仓一体。

湖仓一体是什么

Databricks 公司在 CIDR 2021 发表论文首次正式提出了 Lakehouse 的概念 ，但实际上湖仓一体的概念并非由单一个体提出，而是随着技术的发展和需求的变化逐渐形成的，下图分别列举了国外主流厂商对 Lakehouse 的理解。

与"湖 + 仓"混合架构简单地把数据湖和数据仓库进行简单的堆积不同，湖仓一体架构（Lakehouse）是一种新兴的数据架构，将数据湖和数据仓库的特点融合在一起。它旨在解决传统数据湖和数据仓库各自的局限性，并提供更强大的数据管理和分析能力。湖仓一体架构的特点如下：

• 统一数据存储：湖仓一体架构将结构化、半结构化和非结构化数据以原生格式存储在数据湖中。这种统一的数据存储方式消除了数据复制和转换的需求，简化了数据管理过程。
• 事务支持：与传统的数据湖相比，湖仓一体架构提供了事务支持。它允许在数据湖中执行事务操作，如插入、更新和删除，确保数据的一致性和可靠性。
• 数据质量和治理：湖仓一体架构注重数据质量和治理。它提供了数据血缘追踪、数据质量监控和数据访问控制等功能，确保数据的准确性、完整性和安全性。
• 实时和批处理：湖仓一体架构支持实时和批处理数据处理。它可以处理实时数据流和大规模批量数据，并提供实时分析和即席查询的能力。
• 弹性和可扩展性：湖仓一体架构具有弹性和可扩展性。它可以根据需求自动扩展计算和存储资源，以适应不断增长的数据量和变化的工作负载。

湖仓一体架构通过将数据湖和数据仓库的优势结合起来，提供了更灵活、可扩展和强大的数据管理和分析能力。它适用于各种数据场景，包括实时分析、机器学习、数据探索和报表等。

传统数据仓库和数据湖的老玩家，演进到湖仓一体架构有两个主要方向：一是“湖上建仓”，即在数据湖的基础上构建数据仓库，保留数据湖的灵活性和可扩展性，同时引入数据仓库的治理和分析能力，典型的例子是 Databricks 和开源 Hadoop 体系；二是“仓外挂湖”，即在数据仓库外部挂载数据湖，让数据湖成为数据仓库的一个数据源，以便企业更好地利用数据湖中的数据，典型的例子是 Amazon Redshift、Google BigQuery、阿里云 MaxCompute。由此可见，湖仓一体技术的发展，旨在融合数据湖和数据仓库的优势，形成一种更强大、灵活且易于管理的数据管理架构。通过湖仓一体，企业可以更好地处理和分析各种数据类型，实现数据价值的释放，因此湖仓一体架构已经成为当代大数据平台的事实标准。

湖仓一体发展趋势

随着用户场景和业务需求的不断变化，湖仓一体架构在发展过程中也出现了新的趋势。Dremio 在 2023 年发表的论文《The Data Lakehouse: Data Warehousing and More》中，提出 Lakehouse 是一个与具体实现无关的模块化湖仓一体架构：

模块化的湖仓一体架构，核心模块包括以下几个方面：

• 数据存储（Data Storage）：使用云对象存储来保存原始数据文件，需要能够高效地存储大量来自不同来源的数据。
• 存储引擎（Storage Engine）：负责处理数据管理任务，如数据压缩、重分区和索引等。存储引擎通过优化数据的组织方式，提高查询性能，并确保数据在云对象存储中的高效存储。
• 文件格式（File Format）：它将原始数据以特定的格式存储在对象存储中。数据湖仓使用开放的文件格式（如 Apache Parquet、ORC 等），这些格式具有高效的压缩和查询性能，并且可以被不同的分析引擎使用。
• 表格格式（Table Format）：表格格式是数据湖仓的一个重要组件，它在数据湖上添加了逻辑模型和可靠的数据治理。表格格式简化了数据文件的组织和管理，并提供了元数据管理和数据版本控制的功能。常见的表格格式包括 Apache Iceberg、Apache Hudi 和 Delta Lake 等。
• 计算引擎（Compute Engine）：计算引擎负责处理数据操作和计算任务，它与表格格式进行交互，实现数据的查询、转换和分析等功能。Lakehouse 可以支持多种计算引擎，如 Apache Spark、Presto 等。
• 元数据服务（Catalog）：用于管理数据湖中的表格信息和元数据，它跟踪每个表格的名称、模式和其他相关信息，提供了数据发现和搜索的功能。

模块化的设计让湖仓一体架构更加清晰和可解释，这个观点与 Voltron Data（开源项目 Apache Arrow 背后的商业公司）提出的 Composable Codex 不谋而合。

Voltron Data 联合 Meta 和 Databricks 发表在 VLDB 23 上的论文《The Composable Data Management System Manifesto》指出，不仅模块化是数据系统的正确发展方向，基于开放标准和开源模块构建的数据系统才是未来，可以带来很多好处：

• 提高灵活性和可扩展性：模块化的设计可以将数据计算引擎拆分为多个组件，使得每个组件可以独立开发、维护和优化。这样可以提高系统的灵活性和可扩展性，使得引擎可以适应不同的工作负载和需求。
• 促进互操作性：开放标准可以使不同的数据计算引擎之间实现互操作性，使得它们可以无缝地集成和协同工作。这样可以避免数据孤岛的问题，提高数据生态系统的整体效率和一致性。
• 降低开发和维护成本：模块化的设计和开放标准可以促进组件的重用和共享，减少重复开发的工作量。同时，开放标准可以吸引更多的开发者和厂商参与，形成一个庞大的社区，共同推动引擎的发展和优化，从而降低开发和维护的成本。
• 促进创新和进步：模块化的设计和开放标准可以为不同的开发者和厂商提供一个共同的平台，使他们可以自由地创新和实验新的功能和技术。这样可以推动数据计算引擎的不断进步，满足不断变化的需求和挑战。

开放式湖仓才是未来

传统数据仓库对用户最大的困扰是很容易被运营商锁定（Vendor Lock-in），通常有以下几个原因：

• 专有技术和格式：传统数据仓库通常使用特定厂商的专有技术和格式。这些技术和格式是特定厂商的商业机密，不公开或不兼容其他厂商的系统。因此，一旦选择了特定厂商的数据仓库解决方案，就会受到其技术和格式的限制，难以无缝地迁移到其他厂商的解决方案。另外，有一些开源项目使用了自有文件格式来存储数据，虽然源代码开源的，但其文件格式没办法被其他主流计算引擎理解，仍然不属于开放式的架构设计。
• 闭源软件：传统数据仓库通常使用闭源的商业软件，用户无法查看或修改其内部实现细节。这意味着用户对软件的定制和扩展能力受到限制，只能依赖于特定厂商提供的功能和更新。
• 依赖特定硬件和操作系统：传统数据仓库可能依赖于特定的硬件和操作系统。这意味着用户需要购买和维护特定的硬件设备，并且只能在特定的操作系统上运行数据仓库。这增加了用户的成本和依赖性，限制了他们在硬件和操作系统选择上的灵活性。
• 高度集成的架构：传统数据仓库通常采用高度集成的架构，将数据存储、计算和查询等功能紧密耦合在一起。这使得用户难以将数据仓库的不同组件替换为其他厂商的解决方案，因为这些组件之间存在复杂的依赖关系。
• 供应商锁定策略：一些数据仓库供应商可能采用锁定策略，通过限制用户的选择和迁移选项来维持其市场份额。这可能包括限制数据迁移工具、封闭的 API 接口、高昂的许可费用等。这使得用户难以切换到其他供应商的解决方案，从而导致供应商锁定。

湖仓一体架构发展到今天，其最吸引人的一个特点就是就是数据开放性，这是因为其独特的模块化设计带来的：

• 数据格式的灵活性：Lakehouse 架构使用开放的数据格式，例如 Parquet、Avro 或 ORC，这些格式是通用的、开放的标准。这意味着数据可以以一种独立于特定供应商的方式存储和处理，而不会受到特定供应商的限制。这样，即使更换或切换供应商，数据仍然可以保持可访问和可用。
• 开放的数据处理工具和技术：Lakehouse 架构支持使用各种开放的数据处理工具和技术，例如 Apache Spark、Apache Hive、Presto 等。这些工具和技术是开源的，可以在不同的供应商之间进行迁移和切换。这样，即使更换供应商，组织可以继续使用相同的数据处理工具和技术，而不需要重新学习或更换整个技术栈。
• 数据所有权和控制：在 Lakehouse 架构中，数据湖是组织自己拥有和控制的。这意味着组织可以自由地管理和操作数据，而不受运营商的限制。即使切换供应商，组织仍然可以保持对数据的完全控制，并且可以根据需要进行数据迁移或复制。
• 多云和混合云支持：Lakehouse 架构可以在多个云提供商之间进行部署，或者与本地数据中心进行混合部署。这种灵活性使得组织可以根据需求选择最适合的云提供商，而不会受到单一供应商的限制。这样，即使更换或切换云提供商，数据仍然可以保持可访问和可用。

值得一提的是，有些厂商声称自己是“开放式”湖仓一体架构，但所谓的“开放”实际是存算分离架构的“开放”，其实是与开放式湖仓一体混为一谈。存算分离是一种大数据处理架构，它将存储和计算节点分开，数据节点负责数据的存储和管理，而计算任务则由单独的计算节点来负责执行。相对于传统的存算一体架构，存算分离架构设计使得系统能够扩展到更大规模的并发能力和数据容量。相较于湖仓一体架构的开放数据设计，存算一体架构只是把数据放在了存储节点上，并没有保证数据的开放性（如使用开源表格式 Apache Iceberg，或者开源文件格式 Apache Parquet 等），因此并不能认为存算分离架构也是开放的。

随着人工智能（AI）和大语言模型（LLM）的热潮，AI 给数据平台带来新的挑战：AI 需要更丰富的数据，数据需要更多样的 BI+AI 应用。Data 与 AI 的关系不再是 Data+AI，而是 Data*AI ——数据平台不再是一对一的计算和存储架构，而是 m 对 n 关系的架构。这样的架构改变变化下，数据平台的架构更应有兼具一体化与开放性的设计。开放式湖仓一体架构，是面向 Data+AI 融合场景的新趋势。

云器开放式湖仓的设计理念

我们（云器科技）是一家新兴的数据平台服务提供商，主打多云及一体化的数据平台服务。我们依照 Open Lakehouse 的设计理念，实现了一套完整的系统，并服务多家头部客户。存储层设计兼容各种主流的开放存储格式，确保与广泛的数据环境的无缝集成：

• 开放元数据服务：采用 Catalog 形式开放，增强数据管理的灵活性和可访问性。
• 安全的数据访问：保障数据安全的同时，通过身份认证和鉴权机制，允许外部引擎访问云器 Lakehouse 中的数据文件。
• 统一安全策略与开放性结合：结合统一的安全策略与开放性，借助丰富的开源生态系统，最大化地释放企业数据的潜在价值。

文章前半部分讲述了 Open Lakehouse 的架构优势、设计目标和原则。文章后半部分，重点介绍我们在实现过程中的设计、取舍和经验总结。

云器开放式湖仓的设计实践

拥抱 Apache Iceberg 打造开放生态

Apache Iceberg、Apache Hudi 和 Delta Lake 是当前数据湖领域中的三种主要表格式，它们都在努力成为数据湖的标准表格式，这种竞争有时被形象地称为"Table Format War"。这三种表格式都是开源的，拥有非常好的生态，背后都有一个商业公司在支持。云器认为重复再造一个新的表格式的轮子并不能让 Lakehouse 更加地开放，因此选择一个最合适的表格式，围绕它构建 Lakehouse 的内置表格式，打造一个开放的生态是对用户最负责任的方案。

为什么是 Apache Iceberg

来自 Tabular（Apache Iceberg 背后的商业公司）的 Brian Olsen 在 2023 年 7 月发表了一篇文章 Iceberg won the table format war，他认为 Apache Iceberg 已经在这场表格式的竞争中取得了胜利。其观点基本符合我们的看法，也是云器科技选择使用 Apache Iceberg 作为开放存储底座的原因：

• 从技术角度来说，Apache Iceberg 是第一个跳出了 Hive 标准（比如 Hive 分区）限制的表格式，相对于 Apache Hudi 来说没有主键约束，通过 Hidden Partition 的设计支持 Partition Evolution 这种高级功能。这种设计使得使用方有更大的定制空间，支持更丰富的场景。
• 从标准角度来说，Apache Iceberg 首先就制定了一套简单、清晰的标准，然后才提供各种引擎下的实现。Apache Hudi 实现太过复杂，并且非常依赖 JVM 生态。Delta Lake 开源版本相比 Databricks 内部版本有很多滞后性，与 Apache Spark 框架绑定也比较深。有了一个简洁的标准，用户和厂商既可以选择使用官方开源实现，也可以根据自己的需求开发一套完全兼容的实现，这正是一个开放的标准所带来的好处。
• 从生态角度来说，Dremio 很早就选择了 Apache Iceberg 作为其完全开源的 Open Lakehouse 底座。像 Snowflake 这种起初期望用其私有格式抢占市场的大玩家，也支持了 Apache Iceberg 作为可选的内置存储格式，并且性能与内置格式相差无几。甚至像 Databricks 和 Onehouse（Apache Hudi 背后的商业公司）这样的直接竞争对手，也分别通过 Delta Uniserval Format 和 Hudi OneTable 的机制，输出 Apache Iceberg 兼容格式。选择 Apache Iceberg 能更好地避免被运营商绑定的风险，保护用户的数据。

如何基于 Apache Iceberg 构建通用的增量存储

云器 Lakehouse 使用 Apache Iceberg 表格式，以及 Apache Parquet 文件格式，打造了一个能够实时兼容 Apache Iceberg 标准的存储文件布局，其元数据通过完全兼容 Iceberg 的 catalog 进行输出，天然兼容所有支持消费 Apache Iceberg 的开源框架，如 Apache Spark 和 Trino 等。由于所有云器 Lakehouse 内表输出的数据文件都是以 Apache Parquet 格式存放在云对象存储上，元数据完全兼容 Apache Iceberg，用户真正拥有自己的数据资产，无需担心 Lock-in 的风险。

前面提到过增量计算模式依赖增量存储，这也是通过 Apache Iceberg 实现的。具体来说，基于 Snapshot Isolation 使用 Apache Iceberg V2 标准引入的 Position Delete File 来表示增量数据。由于 Position Delete File 只能表示数据的删除，我们需要把 Update 拆分成经典的 Delete+Insert 模式，这样的设计对数据有三个挑战：

• Freshness：代表数据进入 Lakehouse 的新鲜度，即数据写入湖仓之后多久可见。为了让数据尽快可见，我们设计了单独的 Ingestion Service 服务，根据不同的表类型，兼顾性能和成本使用最优的方式把数据灌入湖仓。
• Latency：代表数据的查询性能，也就是查询湖仓中的数据要多久才能出结果。由于数据文件都保存在云对象存储上，我们设计了 Shared-Everything 的分层 Cache 服务，根据数据的冷热以及访问模式，自动将文件中的数据放到最合适的 Cache 中，加快查询速度。
• Performance：增量计算的间隔越短，就会以增量存储的方式引入越多的小文件，这对后续查询的性能会带来影响。同时，用户的数据和访问模式后续都可能会动态变化，我们需要能够识别并给出存储文件排布的最佳方案。因此，写入增量存储的时候，我们可以根据需要，自动选择以 Copy-on-Write 或者 Merge-on-Read 的方式产生数据文件。同时，在后台使用单独的 Compaction 服务，根据 Lakehouse 搜集到的信息进行文件的重排布，以节省成本，优化查询性能。

围绕 Apache Parquet 锤炼极致性能

对于 Lakehouse 的引擎来说，一个 SQL 查询始于读（TableScan）终于写（TableSink）。如果说开放的表格式决定了 Lakehouse 的能力下限，那合适的文件格式则可以决定 Lakehouse 的性能上限。在大数据领域，Apache Parquet 和 Apache Orc 基本就是列存格式的实施标准。两者曾一度各占半壁江山，但现在就像 DuckDB 作者 Hannes 回答社区问题时说的，似乎 Apache Orc 已经被用得越来越少了。那在 Apache Parquet 越来越独领风骚的今天，是不是无脑选择它就能高枕无忧了？

事实并非如此，Parquet 标准其实是一个基于 Thrift 协议定义的文件格式，其中包含很多可选的字段，这为后面的问题埋下了伏笔：

• 由于早期 Parquet 开源代码的糟糕实现，各个引擎和框架都开始从头写自己的 Parquet Reader/Writer，它们都根据自己的需要，只使用了 Parquet 标准中一部分字段，这对不同引擎之间 Parquet 文件的互操作性带来了问题，系统 A 因为用了某个更高级的字段，系统 B 没有实现它，导致 B 无法直接消费 A 产生的文件。
• 不同的 Parquet 实现有不同的 bug，而用户持久化的文件无法重写，这进一步导致不同引擎需要打上各种补丁，从有问题的历史 Parquet 文件中读出正确的数据。
• 再就是臭名昭著的 Parquet V2 争论。Apache Parquet 社区先是引入了一个 Data Page V2 的概念，用来支持对某一列的某个 Page 进行更细粒度的压缩和编码控制，这没有问题。但后续又引入了一个 Feature V2 的概念，把所有新加入的功能如 Page Index、Bloom Filter、Delta Encoding、Byte Stream Split Encoding 等，都称做 V2 功能。这样一来，有的实现认为 Data Page V2 才是 V2，其他则认为只要用了某个 V2 功能也叫 V2，导致对如何判断一个 Parquet 文件是不是 V2 版本没有一个共识。所以很多企业为了规避这个问题，直接禁用 V2 的任何功能。

尽管 Parquet 有各种各样的问题，它仍然是当前大数据文件格式的事实标准，在开放存储这个大前提下，也没有什么好纠结的。既然 Parquet 是开源的，是不是挑一个开源实现拿来用就好了？很多引擎和框架都实现了自己的 Parquet 读写模块，但由于前面提到的问题，要么功能不全，要么性能不佳，基本没有能直接拿来用。早在云器 Lakehouse 选型文件格式的时候（2022 年初），C++ 的开源 Parquet 实现只有 Apache Arrow、Apache Impala 和 DuckDB 三家，其中后两者都只实现了 V1 的功能；而 Apache Arrow 中的 Parquet C++ 代码是 Parquet 社区捐赠的，V2 的功能也实现了一部分，但仍然缺少 Predicate Pushdown、Page Index 和 Bloom Filter 等重要功能，并且内部测评的性能也不及预期，无法直接使用。

Community Over Code

纵观国外的一些友商，Velox 和 Databricks 开发了自己的 Native C++ Parquet 实现，而 Snowflake、BigQuery 和 ClickHouse 则都是基于 Apache Arrow 中的 Parquet C++ 实现来完成 Parquet 的拼图。虽然从头开发一套 Parquet 实现的确能够获得最佳的定制和性能，但也需要付出大量重复劳动，也可能会掉进一些前人踩过的坑。既然 Apache Parquet 是一个开源的标准，没有任何秘密，而 Apache Arrow 已经被友商广泛使用，那直接基于 Apache Arrow 中的 Parquet 代码来实现云器 Lakehouse 的文件格式，也符合云器 Lakehouse 追求最佳开放性的设计理念。与此同时，云器科技也决定投入到社区当中，补全 Parquet 缺失的功能，并且深度优化性能，从而真正成为社区的一部分。

主要贡献

云器科技对 Parquet 社区的贡献，主要涉及了 Apache 软件基金会旗下两个顶级项目 Apache Parquet 和 Apache Arrow 的三个 GitHub 仓库：

• apache/parquet-format：Parquet 格式规范，所有的实现必须遵循此规范。参与该项目可以影响格式标准的后续发展，把对云器有益的格式演进推回社区，从而让更多用户受益。
• apache/parquet-mr：Parquet 的 Java 语言实现，是以 Java 生态为主的大数据开源生态圈依赖最广泛的 Parquet 实现。它也被认为是 Parquet 最权威的实现，其他语言的实现在拿不准的时候，都会参照它来统一行为。参与该社区，可以让云器 Lakehouse 写出的 Parquet 文件，能被所有 Java 生态的开源框架（如 Apache Spark、Apache Hive、Trino）直接消费，达到最大的开放性。
• apache/arrow：Apache Arrow 项目的核心是一种基于内存的列式数据结构，这是一种与语言无关的标准化规范，使得数据可以在不同的编程语言和计算引擎之间以零复制（zero-copy）的方式进行共享和交换，同时提供了一套比较干净和功能最多的 Parquet C++ 实现。云器 Lakehouse 的 Parquet 正是基于这套代码进行功能开发和性能优化，使其达到一个比较理想的状态。

上面两张图基本涵盖了云器科技在 Parquet 社区中最主要的贡献，团队两名成员也因此被 Apache Parquet 和 Apache Arrow 社区提名为 Committer。云器科技对开源社区的投入不会停止，团队成员在 2023 年 8 月北京举行的“Apache Software Foundation 旗下大会 - Community Over Code Asia 2023”上分享了参与开源项目的心得，后续仍会深耕社区，把我们认为有价值的功能贡献回社区，让更多的用户受益。

总 结

本文回顾和分析了数据湖仓的历史和大数据平台的演进趋势，提出了基于增量计算的一体化趋势，以及该架构必然需要一个开放式的增量存储支撑。基于 Single Engine · All Data 理念云器发布了一体化数据平台——云器 Lakehouse，并分享了如何围绕 Apache Iceberg 和 Apache Parquet，来构建开放湖仓之上的增量存储，获得最佳开放性和极致性能。同时云器科技也大力投入开源社区，以合作共赢的姿态践行构建 Open Lakehouse 的设计理念。

作者简介：

吴刚，云器科技，Lakehouse 技术专家。目前是 Apache ORC 的 PMC，也是 Apache Arrow 和 Apache Parquet 的 committer。在此之前，曾是阿里巴巴的高级技术专家，负责 MaxCompute 的存储系统，也曾在 Uber 负责 Apache Spark 平台。

选择哪种编程语言已经不重要了，只提倡程序员下班后“多看看书”提升竞争力是误人子弟｜独家专访亚马逊 CTO

一代更比一代强，AI 时代的至强如何为云服务保驾护航？

寻找增长，SaaS 企业选择上飞书

离开云转战 AI？23 岁写了百万人用的开源软件，这个 IT 奇才 11 年后离开了自己的上市公司