博文推荐｜如何使用Apache Pulsar + Hudi 构建 Lakehouse

关于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。

GitHub 地址：http://github.com/apache/pulsar/

文章转自：ApacheHudi，作者：郭斯杰 StreamNative CEO，Apache Pulsar PMC 成员。

本期文章排版：StreamNative@Tango

动机

Lakehouse 最早由 Databricks 公司提出，其可作为低成本、直接访问云存储并提供传统 DBMS 管系统性能和 ACID 事务、版本、审计、索引、缓存、查询优化的数据管理系统，Lakehouse 结合数据湖和数据仓库的优点：包括数据湖的低成本存储和开放数据格式访问，数据仓库强大的管理和优化能力。Delta Lake，Apache Hudi 和 Apache Iceberg 是三种构建 Lakehouse 的技术。

与此同时，Pulsar 提供了一系列特性：包括分层存储、流式卸载、列式卸载等，让其成为一个可以统一批和事件流的存储层。特别是分层存储的特性，让 Pulsar 成为一个轻量级数据湖，但是 Pulsar 还是缺乏一些性能优化，比如索引，数据版本（在传统 DBMS 管理系统中非常常见），引入列式卸载程序的目的是为了缩小性能差距，但是还不够。

本提议尝试将 Apache Pulsar 作为 Lakehouse，该提案仅提供顶层设计，详细设计和实现在后面的子提议中解决（有兴趣的小伙伴可以持续关注）。

分析

本部分将分析构建 Lakehouse 需要的关键特性，然后分析 Pulsar 是否满足要求以及识别还有哪些差距。

Lakehouse 有如下关键特性：

• 事务支持：企业级 Lakehouse 中很多数据 pipeliine 会并发读写数据，支持 ACID 事务可以保证并发读写的一致性，特别是使用 SQL；Delta Lake、Iceberg、Hudi 三个数据湖框架都基于低成本的对象存储实现了事务层，都支持事务。Pulsar 在 2.7.0 版本后引入了事务支持，并且支持跨 topic 的事务；

• Schema 约束和治理：Lakehouse 需要支持 Schema 的约束和演进，支持数仓型 Schema 范式，如星型/雪花型 Schema，另外系统应该能够推理数据完整性，并且应该具有健壮的治理和审核机制，上述三个系统都有该能力。Pulsar 有内置的 Schema 注册服务，它满足 Schema 约束和治理的基本要求，但是可能仍有一些地方需要改进。

• BI 支持：Lakehouses 可以直接在源数据上使用 BI 工具，这样可以减少陈旧性，提高新鲜度，减少等待时间，并降低必须同时在数据湖和仓库中操作两个数据副本的成本。三个数据湖框架与 Apache Spark 的集成非常好，同时可以允许 Redshift，Presto/Athena 查询源数据，Hudi 社区也已经完成了对多引擎如 Flink 的支持。Pulsar 暴露了分层存储中的段以供直接访问，这样可以与流行的数据处理引擎紧密集成。但是 Pulsar 中的分层存储本身在服务 BI 工作负载方面仍然存在性能差距，我们将在该提案中解决这些差距。

• 存储与计算分离：这意味着存储和计算使用单独的集群，因此这些系统可以单独水平无限扩容。三个框均支持存储与计算分离。Pulsar 使用了存储与计算分离的多层体系结构部署。

• 开放性：使用开放和标准化的数据格式，如 Parquet，并且它们提供了 API，因此各种工具和引擎（包括机器学习和 Python / R 库）可以"直接"有效地访问数据，三个框架支持 Parquet 格式，Iceberg 还支持 ORC 格式，对于 ORC 格式 Hudi 社区正在支持中。Pulsar 还不支持任何开放格式，列存卸载支持 Parquet 格式。

• 支持从非结构化数据到结构化数据的多种数据类型：Lakehouse 可用于存储、优化，分析和访问许多新数据应用程序所需的数据类型，包括图像、视频、音频、半结构化数据和文本。尚不清楚 Delta、Iceberg、Hudi 如何支持这一点。Pulsar 支持各种类型数据。

• 支持各种工作负载：包括数据科学，机器学习以及 SQL 和分析。可能需要多种工具来支持所有这些工作负载，但它们都依赖于同一数据存储库。三个框架与 Spark 紧密结合，Spark 提供了广泛的工具选择。Pulsar 也与 Spark 有着紧密结合。

• 端到端流：实时报告是许多企业的常态，对流的支持消除了对专门用于服务实时数据应用程序的单独系统的需求，Delta Lake 和 Hudi 通过变更日志提供了流功能。但这不是真正的“流”。Pulsar 是一个真正的流系统。

可以看到 Pulsar 满足构建 Lakehouse 的所有条件。然而现在的分层存储有很大的性能差距，例如：

• Pulsar 并不以开放和标准的格式存储数据，如 Parquet；
• Pulsar 不会为卸载的数据部署任何索引机制；
• Plusar 不支持高效的 Upserts；

这里旨在解决 Pulsar 存储层的性能问题，使 Pulsar 能作为 Lakehouse。

当前方案

图 1 展示了当前 Pulsar 流的存储布局。

• Pulsar 在 ZooKeeper 中存储了段（segment）元数据；
• 最新的段存储在 Apache BookKeeper 中（更快地存储层）
• 旧的段从 Apache BookKeeper 卸载到分层存储（便宜的存储层）。卸载的段的元数据仍保留在 Zookeeper 中，引用的是分层存储中卸载的对象。

当前的方案有一些缺点：

1. 它不使用任何开放式存储格式来存储卸载的数据。这意味着很难与更广泛的生态系统整合。
2. 它将所有元数据信息保留在 ZooKeeper 中，这可能会限制可伸缩性。

新的 Lakehouse 存储方案

新方案建议在分层存储中使用 Lakehouse 存储卸载的数据。该提案建议使用 Apache Hudi 作为 Lakehouse 存储，原因如下：

• 云提供商在 Apache Hudi 上提供了很好的支持。
• Apache Hudi 已经作为顶级项目毕业。
• Apache Hudi 同时支持 Spark 和 Flink 多引擎。同时在中国有一个相当活跃的社区。

新的存储布局

图 2 展示了 Pulsar topic 新的布局。

• 最新片段（未卸载片段）的元数据存储在 ZooKeeper 中。
• 最新片段（未卸载片段）的数据存储在 BookKeeper 中。
• 卸载段的元数据和数据直接存储在分层存储中。因为它是仅追加流。我们不必使用像 Apache Hudi 这样的 Lakehouse 存储库。但是如果我们也将元数据存储在分层存储中，则使用 Lakehouse 存储库来确保 ACID 更有意义。

支持高效 Upserts

Pulsar 不直接支持 upsert。它通过主题（topic）压缩支持 upsert。但是当前的主题压缩方法既不可扩展，也不高效。

1. 主题压缩在代理内（broker）完成。它无法支持大量数据的插入，特别是在数据集很大的情况下。
2. 主题压缩不支持将数据存储在分层存储中。

为了支持高效且可扩展的 Upsert，该提案建议使用 Apache Hudi 将压缩后的数据存储在分层存储中。图 3 展示了使用 Apache Hudi 支持主题压缩中的有效 upserts 的方法。

该想法是实现主题压缩服务。主题压缩服务可以作为单独的服务（即 Pulsar 函数）运行以压缩主题。

1. 代理向压缩服务发出主题压缩请求。
2. 压缩服务接收压缩请求，并读取消息并将其向上插入到 Hudi 表中。
3. 完成 upsert 之后，将主题压缩游标前进到它压缩的最后一条消息。

主题压缩游标将引用位置的元数据存储在存储 Hudi 表的分层存储中。

将 Hudi 表当做 Pulsar Topic

Hudi 会在不同的即时时间维护对表执行的所有操作的时间轴，这有助于提供表的即时视图，同时还有效地支持按_arrival_顺序进行数据检索。Hudi 支持从表中增量拉取变更。我们可以支持通过 Hudi 表备份的_ReadOnly_主题。这允许应用程序从 Pulsar 代理流式传输 Hudi 表的变更。图 4 展示了这个想法。

可扩展的元数据管理

当我们开始将所有数据存储在分层存储中时，该提案建议不存储卸载或压缩数据的元数据，而只依赖分层存储来存储卸载或压缩数据的元数据。

该提案提议在以下目录布局中组织卸载和压缩的数据。

- <tenant>/
  - <namespace>/
    - <topics>/
      - segments/ <= Use Hudi to store the list of segments to guarantee ACID
        - segment_<segment-id>
        - ...
      - cursors/
        - <cursor A>/ <= Use Hudi to store the compacted table for cursor A.
        - <cursor B>/ <= ...

引用

[1] Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics. http://cidrdb.org/cidr2021/papers/cidr2021_paper17.pdf

[2] What is a Lakehouse? https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html

[3] Diving Deep into the inner workings of the Lakehouse and Delta Lake. https://databricks.com/blog/2020/09/10/diving-deep-into-the-inner-workings-of-the-lakehouse-and-delta-lake.html