使用Apache Pulsar + Hudi构建Lakehouse方案了解下?

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介: 笔记

1. 动机


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

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

本提议尝试将Apache Pulsar作为Lakehouse,该提案仅提供顶层设计,详细设计和实现在后面的子提议中解决;


2. 分析


本部分将分析构建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。


3. 当前方案


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

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

1.png

当前的方案有一些缺点:

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


4. 新的Lakehouse存储方案


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

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


4.1 新的存储布局

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

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

2.png


4.2 支持高效Upserts

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

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

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

3.png

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

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

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


4.3 将Hudi表当做Pulsar Topic

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

4.png


4.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>/ <= ...
相关实践学习
基于MSE实现微服务的全链路灰度
通过本场景的实验操作,您将了解并实现在线业务的微服务全链路灰度能力。
目录
相关文章
|
13天前
|
应用服务中间件 网络安全 Apache
构建高性能Web服务器:Nginx vs Apache
【5月更文挑战第16天】Nginx与Apache是两种主流Web服务器,各具优势。Nginx以其轻量级、高并发处理能力和反向代理功能见长,适合大型网站和高并发场景;而Apache以功能丰富、稳定性强闻名,适合企业网站和需要多种Web服务功能的场景。在性能上,Nginx处理高并发更优,Apache则可能在高负载时遭遇瓶颈。在选择时,应根据实际需求权衡。
|
14天前
|
消息中间件 存储 Java
深度探索:使用Apache Kafka构建高效Java消息队列处理系统
【4月更文挑战第17天】本文介绍了在Java环境下使用Apache Kafka进行消息队列处理的方法。Kafka是一个分布式流处理平台,采用发布/订阅模型,支持高效的消息生产和消费。文章详细讲解了Kafka的核心概念,包括主题、生产者和消费者,以及消息的存储和消费流程。此外,还展示了Java代码示例,说明如何创建生产者和消费者。最后,讨论了在高并发场景下的优化策略,如分区、消息压缩和批处理。通过理解和应用这些策略,可以构建高性能的消息系统。
|
14天前
|
存储 SQL 分布式计算
使用Amazon EMR和Apache Hudi在S3上插入,更新,删除数据
使用Amazon EMR和Apache Hudi在S3上插入,更新,删除数据
151 0
|
14天前
|
存储 分布式计算 Hadoop
一文了解Apache Hudi架构、工具和最佳实践
一文了解Apache Hudi架构、工具和最佳实践
170 0
|
14天前
|
SQL 分布式计算 NoSQL
使用Apache Hudi和Debezium构建健壮的CDC管道
使用Apache Hudi和Debezium构建健壮的CDC管道
23 0
|
6天前
|
消息中间件 Java Kafka
实时计算 Flink版操作报错之Apache Flink中的SplitFetcher线程在读取数据时遇到了未预期的情况,该怎么解决
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
6天前
|
消息中间件 关系型数据库 MySQL
Apache Flink CDC 3.1.0 发布公告
Apache Flink 社区很高兴地宣布发布 Flink CDC 3.1.0!
300 1
Apache Flink CDC 3.1.0 发布公告
|
6天前
|
Java 关系型数据库 数据库连接
实时计算 Flink版操作报错之遇到错误org.apache.flink.table.api.ValidationException: Could not find any factory for identifier 'jdbc',该如何解决
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
10天前
|
Oracle 关系型数据库 数据库
实时计算 Flink版操作报错合集之执行Flink job,报错“Could not execute SQL statement. Reason:org.apache.flink.table.api.ValidationException: One or more required options are missing”,该怎么办
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
78 0
|
11天前
|
消息中间件 关系型数据库 MySQL
实时计算 Flink版操作报错合集之遇到报错:Apache Kafka Connect错误如何解决
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
75 5

热门文章

最新文章

推荐镜像

更多