Flink 生态:Pulsar Connector 机制剖析

本文涉及的产品
实时计算 Flink 版,5000CU*H 3个月
简介: 分片架构将消息流数据的存储粒度从分区拉低到了分片,以及相应的层级化存储,使 Pulsar 成为 unbounded streaming data storage 的不二之选。这使得 Pulsar 可以更完美地匹配和适配 Flink 的批流一体的计算模式。

整理:吕宴全(Flink 社区志愿者)
作者:申毅杰(StreamNative)

摘要:本文由 Apache Pulsar Committer,StreamNative 高级工程师申毅杰老师分享,社区志愿者吕宴全整理。本次分享将会分成以下四个内容展开:

  1. Pulsar 简介
  2. Pulsar 架构
  3. Pulsar Connector 内部机制
  4. 未来规划

Tips:点击「阅读原文」,可查看更多 Flink 生态直播~

Apache Pulsar 是 Yahoo 开源的下一代分布式消息系统,在2018年9月从 Apache 软件基金会毕业成为顶级项目。Pulsar 特有的分层分片的架构,在保证大数据消息流系统的性能和吞吐量的同时,也提供了高可用性、高可扩展性和易维护性。

分片架构将消息流数据的存储粒度从分区拉低到了分片,以及相应的层级化存储,使 Pulsar 成为 unbounded streaming data storage 的不二之选。这使得 Pulsar 可以更完美地匹配和适配 Flink 的批流一体的计算模式。

1. Pulsar 简介

1.1 特点

随着开源后,各行业企业可以根据不同需求,为 Pulsar 赋予更丰富的功能,所以目前它也不再只是中间件的功能,而是慢慢发展成为一个 Event Streaming Platform(事件流处理平台),具有 Connect(连接)、Store(存储)和 Process(处理)功能。

■ Connect

在连接方面,Pulsar 具有自己单独的 Pub/Sub 模型,可以同时满足 Kafka 和 RocketMQ 的应用场景。同时 Pulsar IO 的功能,其实就是 Connector,可以非常方便地将数据源导入到 Pulsar 或从 Pulsar 导出等。

另外,在Pulsar 2.5.0 中,我们新增了一个重要机制:Protocol handler。这个机制支持在 broker 自定义添加额外的协议支持,可以保证在不更改原数据库的基础上,也能享用 Pulsar 的一些高级功能。所以 Pulsar 也延展出比如:KoP、ActiveMQ、Rest 等。

■ Store

Pulsar 提供了可以让用户导入的途径后就必然需要考虑在 Pulsar 上进行存储。Pulsar 采用的是分布式存储,最开始是在 Apache BookKeeper 上进行。后来添加了更多的层级存储,通过 JCloud 和 HDFS 等多种模式进行存储的选择。当然,层级存储也受限于存储容量。

■ Process

Pulsar 提供了一个无限存储的抽象,方便第三方平台进行更好的批流融合的计算。即 Pulsar 的数据处理能力。Pulsar 的数据处理能力实际上是按照你数据计算的难易程度、实效性等进行了切分。

目前 Pulsar 包含以下几类集成融合处理方式:

  • Pulsar Function:Pulsar 自带的函数处理,通过不同系统端的函数编写,即可完成计算并运用到 Pulsar 中。
  • Pulsar-Flink connector 和 Pulsar-Spark connector:作为批流融合计算引擎,Flink 和 Spark 都提供流计算的机制。如果你已经在使用他们了,那恭喜你。因为 Pulsar 也全部支持这两种计算,无需你再进行多余的操作了。
  • Presto (Pulsar SQL):有的朋友会在应用场景中更多的使用 SQL,进行交互式查询等。Pulsar 与 Presto 有很好的集成处理,可以用 SQL 在 Pulsar 进行处理。

ͼƬ1.png

1.2 订阅模型

从使用来看,Pulsar 的用法与传统的消息系统类似,是基于发布-订阅模型的。使用者被分为生产者(Producer)和消费者(Consumer)两个角色,对于更具体的需求,还可以以 Reader 的角色来消费数据。用户可以以生产者的身份将数据发布在特定的主题之下,也可以以消费者的身份订阅(Subscription)特定的主题,从而获取数据。在这个过程中,Pulsar 实现了数据的持久化与数据分发,Pulsar 还提供了Schema 功能,能够对数据进行验证。

如下图所示,Pulsar 里面有几种订阅模式:

  1. 独占订阅(Exclusive)
  2. 故障转移订阅(Failover)
  3. 共享订阅(Shared)
  4. Key保序共享订阅(Key_shared)

ͼƬ2.png
ͼƬ3.png

Pulsar 里的主题分成两类,一类是分区主题(Partitioned Topic),一类是非分区主题(Not Partitioned Topic)。

分区主题实际上是由多个非分区主题组成的。主题和分区都是逻辑上的概念,我们可以把主题看作是一个大的无限的事件流,被分区切分成几条小的无限事件流。

而对应的,在物理上,Pulsar 采用分层结构。每一条事件流存储在一个 Segment 中,每个Segment 包括了许多个Entry,Entry 里面存放的才是用户发送过来的一条或多条消息实体。

Message 是 Entry 中存放的数据,也是 Pulsar 中消费者消费一次获得的数据。Message 中除了包括字节流数据,还有 Key 属性,两种时间属性和 MessageId 以及其他信息。MessageId 是消息的唯一标识,包括了ledger-id、entry-id、 batch-index、 partition-index 的信息,如下图,分别记录了消息在Pulsar 中的Segment、Entry、Message、Partition 存储位置, 因此也可以据此从物理上找到Message的信息内容。

ͼƬ4.png

2. Pulsar 架构

一个 Pulsar 集群由 Brokers 集群和 Bookies 集群组成。Brokers 之间是相互独立的,负责向生产者和消费者提供关于某个主题的服务。Bookies 之间也是相互独立的,负责存储 Segment 的数据,是消息持久化的地方。为了管理配置信息和代理信息,Pulsar 还借助了 Zookeeper 这个组件,Brokers 和 Bookies 都会在 zookeeper 上注册,下面从消息的具体读写路径(见下图)来介绍 Pulsar 的结构。

ͼƬ5.png
ͼƬ6.png

在写路径中,生产者创建并发送一条消息到主题中,该消息可能会以某种算法(比如Round robin)被路由到一个具体的分区上,Pulsar 会选择一个Broker 为这个分区服务,该分区的消息实际会被发送到这个 Broker上。当Broker 拿到一条消息,它会以 Write Quorum (Qw)的方式将消息写入到 Bookies 中。当成功写入到 Bookies 的数量达到设定时,Broker 会收到完成通知,并且 Broker 也会返回通知生产者写入成功。

在读路径中,消费者首先要发起一次订阅,之后才能与主题对应的 Broker 进行连接,Broker 从 Bookies 请求数据并发送给消费者。当数据接受成功,消费者可以选择向 Broker 发送确认信息,使得 Broker 能够更新消费者的访问位置信息。前面也提到,对于刚写入的数据,Pulsar 会存储在缓存中,那么就可以直接从 Brokers 的缓存中读取了,缩短了读取路径。

Pulsar 将存储与服务相分离,实现了很好的可拓展性,在平台层面,能够通过调整Bookies 的数量来满足不同的需求。在用户层面,只需要跟 Brokers 通信,而Brokers 本身被设计成没有状态的,当某个 Broker 因故障无法使用时,可以动态的生成一个新的 Broker 来替换。

3. Pulsar Connector 内部机制

首先,Pulsar Connector 在使用上是比较简单的,由一个 Source 和一个 Sink 组成,source 的功能就是将一个或多个主题下的消息传入到 Flink 的Source中,Sink的功能就是从 Flink 的 Sink 中获取数据并放入到某些主题下,在使用方式上,如下所示,与 Kafa Connector 很相似,使用时需要设置一些参数。

StreamExecutionEnvironment see = StreamExecutionEnvironment.getExecutionEnvironment(); Properties props = new Properties(); 
props.setProperty("topic", "test-source-topic") FlinkPulsarSource<String> source = new FlinkPulsarSource<>(
              serviceUrl, 
              adminUrl, 
              new SimpleStringSchema(), 
              props); 
DataStream<String> stream = see.addSource(source);

FlinkPulsarSink<Person> sink = 
      new FlinkPulsarSink(
              serviceUrl, 
              adminUrl, 
              Optional.of(topic), // mandatory target topic 
              props, 
              TopicKeyExtractor.NULL, // replace this to extract key or topic for each record
              Person.class); 
stream.addSink(sink);

现在介绍 Kulsar Connector 一些特性的实现机制。

3.1 精确一次

因为 Pulsar 中的 MessageId 是全局唯一且有序的,与消息在 Pulsar 中的物理存储也对应,因此为了实现 Exactly Once,Pulsar Connector 借助 Flink 的 Checkpoint 机制,将 MessageId 存储到 Checkpoint。

对于连接器的 Source 任务,在每次触发 Checkpoint 的时候,会将各个分区当前处理的 MessageId 保存到状态存储里面,这样在任务重启的时候,每个分区都可以通过 Pulsar 提供的 Reader seek 接口找到 MessageId 对应的消息位置,然后从这个位置之后读取消息数据。

通过 Checkpoint 机制,还能够向存储数据的节点发送数据使用完毕的通知,从而能准确删除过期的数据,做到存储的合理利用。

3.2 动态发现

考虑到Flink中的任务都是长时间运行的,在运行任务的过程中,用户也许会需要动态的增加部分主题或者分区,Pulsar Connector 提供了自动发现的解决方案。

Pulsar 的策略是另外启动一个线程,定期的去查询设定的主题是否改变,分区有没有增删,如果发生了新增分区的情况,那么就额外创建新的Reader 任务去完成主题下的数据的反序列化,当然如果是删除分区,也会相应的减少读取任务。

3.3 结构化数据

在读取主题下的数据的过程中,我们可以将数据转化成一条条结构化的记录来处理。Pulsar 支持 Avro schema and avro/json/protobuf Message 格式类型的数据转化成 Flink 中的 Row格式数据。对于用户关心的元数据,Pulsar 也在 Row 中提供了对应的元数据域。

另外,Pulsar 基于 Flink 1.9 版本进行了新的开发,支持 Table API 和 Catalog,Pulsar 做了一个简单的映射,如下图所示,将 Pulsar 的租户/命名空间对应到 Catalog 的数据库,将主题对应为库中的具体表。

ͼƬ7.png

4. 未来规划

首先,之前提到 Pulsar 将数据存储在 Bookeeper 中,还可以导入到 Hdfs 或者 S3 这样的文件系统中,但对于分析型应用来说,我们往往只关心所有数据中每条数据的部分属性,因此采用列存储的方式对 IO 和网络都会有性能提升,Pulsar 也在尝试在Segment 中以列的方式存储。

其次,在原来的读路径中,不管是 Reader 还是Comsumer,都需要通过 Brokers 来传递数据。如果采用新的 Bypass Broker方式,通过查询元数据,就能直接找到每条 Message 存储的 Bookie 位置,这样可以直接从 Bookie 读取数据,缩短读取路径,从而提升效率。

最后,Pulsar 相对 Kafka 来说,由于数据在物理上是存放在一个个 Segment 中的,那么在读取的过程中,通过提高并行化的方式,建立多线程同时读取多个 Segment,就能够提升整个作业的完成效率,不过这也需要你的任务自身对每个Topic 分区的访问顺序没有严格要求,并且对于新产生的数据,是不保存在 Segement 的,还是需要做缓存的访问来获取数据,因此,并行读取将成为一个可选项,为用户提供更多的选择方案。

相关实践学习
基于Hologres轻松玩转一站式实时仓库
本场景介绍如何利用阿里云MaxCompute、实时计算Flink和交互式分析服务Hologres开发离线、实时数据融合分析的数据大屏应用。
Linux入门到精通
本套课程是从入门开始的Linux学习课程,适合初学者阅读。由浅入深案例丰富,通俗易懂。主要涉及基础的系统操作以及工作中常用的各种服务软件的应用、部署和优化。即使是零基础的学员,只要能够坚持把所有章节都学完,也一定会受益匪浅。
相关文章
|
2月前
|
存储 缓存 算法
分布式锁服务深度解析:以Apache Flink的Checkpointing机制为例
【10月更文挑战第7天】在分布式系统中,多个进程或节点可能需要同时访问和操作共享资源。为了确保数据的一致性和系统的稳定性,我们需要一种机制来协调这些进程或节点的访问,避免并发冲突和竞态条件。分布式锁服务正是为此而生的一种解决方案。它通过在网络环境中实现锁机制,确保同一时间只有一个进程或节点能够访问和操作共享资源。
89 3
|
3月前
|
SQL 消息中间件 关系型数据库
Apache Doris Flink Connector 24.0.0 版本正式发布
该版本新增了对 Flink 1.20 的支持,并支持通过 Arrow Flight SQL 高速读取 Doris 中数据。
|
4月前
|
存储 数据处理 Apache
超越传统数据库:揭秘Flink状态机制,让你的数据处理效率飞升!
【8月更文挑战第26天】Apache Flink 在流处理领域以其高效实时的数据处理能力脱颖而出,其核心特色之一便是状态管理机制。不同于传统数据库依靠持久化存储及 ACID 事务确保数据一致性和可靠性,Flink 利用内存中的状态管理和分布式数据流模型实现了低延迟处理。Flink 的状态分为键控状态与非键控状态,前者依据数据键值进行状态维护,适用于键值对数据处理;后者与算子实例关联,用于所有输入数据共享的状态场景。通过 checkpointing 机制,Flink 在保障状态一致性的同时,提供了更适合流处理场景的轻量级解决方案。
67 0
|
4月前
|
SQL 关系型数据库 MySQL
实时计算 Flink版产品使用问题之如何配置Connector来保持与MySOL一致
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
4月前
|
消息中间件 存储 关系型数据库
实时计算 Flink版产品使用问题之如何使用Kafka Connector将数据写入到Kafka
实时计算Flink版作为一种强大的流处理和批处理统一的计算框架,广泛应用于各种需要实时数据处理和分析的场景。实时计算Flink版通常结合SQL接口、DataStream API、以及与上下游数据源和存储系统的丰富连接器,提供了一套全面的解决方案,以应对各种实时计算需求。其低延迟、高吞吐、容错性强的特点,使其成为众多企业和组织实时数据处理首选的技术平台。以下是实时计算Flink版的一些典型使用合集。
|
4月前
|
存储 Java 流计算
Flink 分布式快照,神秘机制背后究竟隐藏着怎样的惊人奥秘?快来一探究竟!
【8月更文挑战第26天】Flink是一款开源框架,支持有状态流处理与批处理任务。其核心功能之一为分布式快照,通过“检查点(Checkpoint)”机制确保系统能在故障发生时从最近的一致性状态恢复,实现可靠容错。Flink通过JobManager触发检查点,各节点暂停接收新数据并保存当前状态至稳定存储(如HDFS)。采用“异步屏障快照(Asynchronous Barrier Snapshotting)”技术,插入特殊标记“屏障(Barrier)”随数据流传播,在不影响整体流程的同时高效完成状态保存。例如可在Flink中设置每1000毫秒进行一次检查点并指定存储位置。
88 0
|
5月前
|
消息中间件 Kafka 数据处理
实时计算 Flink版操作报错合集之使用kafka connector时,报错:java.lang.ClassNotFoundException,是什么原因
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
|
5月前
|
存储 缓存 监控
Flink内存管理机制及其参数调优
Flink内存管理机制及其参数调优
|
4月前
|
消息中间件 安全 Kafka
Flink与Kafka的终极联盟:揭秘如何在一瞬间切换SASL机制,保护您的数据不受黑客侵袭!
【8月更文挑战第7天】Apache Flink作为高性能流处理框架,在与Kafka集成时确保数据安全至关重要。通过配置`KafkaConsumer`使用SASL机制如SCRAM-SHA-256或PLAIN,可有效防止未授权访问。SCRAM-SHA-256采用强化的身份验证流程提高安全性,而PLAIN机制则相对简单。配置涉及设置`properties`参数,包括指定`sasl.mechanism`、`security.protocol`及JAAS认证信息。合理选择和配置这些参数对于保护Flink应用与Kafka间的数据通信安全至关重要。
107 0
|
3月前
|
运维 数据处理 数据安全/隐私保护
阿里云实时计算Flink版测评报告
该测评报告详细介绍了阿里云实时计算Flink版在用户行为分析与标签画像中的应用实践,展示了其毫秒级的数据处理能力和高效的开发流程。报告还全面评测了该服务在稳定性、性能、开发运维及安全性方面的卓越表现,并对比自建Flink集群的优势。最后,报告评估了其成本效益,强调了其灵活扩展性和高投资回报率,适合各类实时数据处理需求。

相关产品

  • 实时计算 Flink版