对于 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/pa…

[2] What is a Lakehouse? https://databricks.com/blog/2…

[3] Diving Deep into the inner workings of the Lakehouse and Delta Lake. https://databricks.com/blog/2…