Apache Pulsar 2.3 重磅发布，新特性独家解读

Apache Pulsar 2.3 重磅发布，新特性独家解读

原创： 郭斯杰 ApachePulsar 1周前

“Apache Pulsar 2.3.0 重磅发布！最新版本包含支持在Kubernetes中执行Pulsar Functions，基于JSON Web Tokens的认证方式，C++和Python客户端对Schema的支持，Python Functions对于状态函数的支持，以及一系列新增的IO Connectors（Debezium，Canal，MongoDB， Elastic Search，以及HBase）”

Apache Pulsar在上周正式发布了2.3.0版本！距离2.2.1版本的发布，相距不到三个月的时间。这个版本总共接受了来自社区近500个代码提交。在这500个代码提交中，越来越多的代码贡献来自于中国的开发者，中国力量越发迅猛。2.3.0版本包含很多新的特性，性能的改善，以及Bug的修复，这些改进继续丰富和完善了Apache Pulsar作为一个云原生流数据平台的能力。

这个版本的特性覆盖了从消息存储核心，多语言客户端，到Pulsar Functions/Connectors以及Pulsar Ecosystem的方方面面。在这篇文章中，我们将会为大家详细解读2.3.0中的特性。这其中包括：

Pulsar Functions in Kubernetes: Pulsar正式原生地支持在Kubernetes中执行Pulsar Functions
Token Authentication: 除了TLS以及Athenz的认证支持之外，Pulsar正式提供基于JSON Web Token的认证方式。
C++和Python客户端对于Schema的支持
状态函数（Stateful Function）在Pulsar Python Functions的支持
Pulsar与Debezium的集成

Bookie & Broker

—

Pulsar 2.3.0正式将BookKeeper的依赖从4.7.2升级到4.9.0. BookKeeper 4.9.0相比于4.7.2，包含了更多的特性和性能优化：

智能的内存管理：BookKeeper使用Direct Memory和Netty Buffer Pool进行内存管理。Direct Memory的好处是避免了GC带来的停顿以及避免栈内外内存的拷贝。但是如果用户没有设置正确的DirectMemory的大小，Bookie将会收到OutOfDirectMemory的异常。在4.9.0版本中，BookKeeper引入智能的内存管理，绝大部分时间使用DirectMemory，在DirectMemory不够用的情况下，BookKeeper会使用堆内的内存。
粘性读（Sticky Read）：默认情况下BookKeeper使用round-robin的方式从多个复本里面并发读取数据。这种方式可以最大化读带宽，非常适用于Tailing Read的应用场景。但是，当BookKeeper被使用在批处理负载的情况下，这种方式虽然可以最大化读带宽，但是每个Bookie由于都在进行预读取，磁盘的IO全局来看是被放大了。在4.9.0中，为了让BookKeeper更加高效地支持批处理负载，引入了粘性读（Sticky Read）的概念。用户可以在BookKeeper客户端开始粘性读 - BookKeeper客户端会优先选择一个复本进行读取，只有当这个复本不可读或者网络时延变高的情况下，BookKeeper才会更换其他复本进行读取。
针对超低延时的优化：大部分的BookKeeper部署是使用磁盘进行存储。但是对于一些超低延时（sub-millisecond）的应用场景支持，以及对于持久化内存的使用，BookKeeper也在探索这方面的改进。围绕这个领域，BookKeeper在4.9.0中引入了一些针对此类场景的优化，这些优化包括CPU-Affinity的支持，使用更好的无锁高并发的数据结构（比如JCTools）等。
Etcd元数据管理：很长时间内，BookKeeper默认的元数据管理是ZooKeeper。从4.9.0开始，BookKeeper正式支持Etcd作为其元数据管理的一种方案。

Pulsar 2.3.0在BookKeeper 4.9.0的基础上，进行以下的丰富和完善：

Pulsar在2.3.0里面开始在BookKeeper的ledger metadata中标记Topic、Subscription、Cursor等元数据信息。这样，未来Pulsar可以使用这些标记信息建立反向索引，用于更加智能和丰富的监控管理。
Pulsar SQL正式启用BookKeeper粘性读，来提供IO的有效性。
Pulsar Broker以及Java客户端正式启用BookKeeper提供的智能内存管理，并提供根据JVM堆栈大小，自动配置不同组件的内存使用大小，降低配置的复杂度。

除此之外，Pulsar 2.3.0提供了对于ZStandard压缩算法的支持。在指定使用ZStandard之前，需要确保所有的消费者已经升级到2.3.0。老版本的消费者没有办法消费ZStandard压缩过的消息。

Schema

—

原生的Schema支持是Pulsar作为流数据平台的核心特性。我们在2.3.0版本中围绕Schema开展了更多的工作。这些工作包括：

新引入的Schema类型：

KeyValue Schema：新的Schema类型，允许Pulsar同时对于Key和Value进行Schema验证。
AUTO_PRODUCE Schema：顾名思义，这是一个生产端使用的Schema，允许客户端在生产数据的时候自动按照Schema对于数据的进行验证，避免客户端往Topic中生产不兼容的脏数据。
AUTO_CONSUME Schema：一个新的消费端Schema。消费端不再需要制定相应的POJO类作为Schema类型。消费端会自动识别Schema，将消费到的数据自动识别成为通用记录（Generic Record）。这种消费方式适用于大部分不能提前预知Schema类型，但又需要Schema的场景，比如Change-Data-Capture (CDC)，以及跟各种数据库打交道的应用场景。

在Pulsar Admin，我们引入了兼容性管理机制，管理员可以配置每个命名空间的Schema兼容性级别。同时，管理员可以关闭生产端Schema的自动更新功能，由管理员在管理端统一管理Schema的更新。

此外，在2.3.0以前，只有Java客户端支持Schema。从2.3.0以后，Python客户端正式支持Schema。用户在使用Python客户端的时候，可以指定相应的Schema，用来创建Producer和Consumer。目前Python客户端仅支持Json，Avro，以及一些简单类型的Schema，比如 str 和 bytes。

Security

—

在2.3.0之前，Pulsar主要支持TLS，Athenz和密码文件这三种认证方式。TLS的认证方式需要在客户端和服务器端，使用多个Key文件，并不方便凭证的分配；同时凭证文件的管理也不方便。Athenz需要额外配置Athenz服务器。密码文件的认证太过于简单，对于大规模部署并不实用。

Pulsar 2.3.0 添加了基于 JSON Web Tokens (RFC-7519) 的鉴权和认证方式。Tokens用来标识一个客户端，并和Pulsar权限管理中作为权限管理对象的Role建立关联，来限制客户端的行为，比如对于Topic的发布或者消费的权限。通过JSON Web Token的认证方式，用户可以在创建客户端的时候指定相应的Token即可。

我们后续将会有一些文章来详细介绍Pulsar Token认证的原理和实践。

Functions

—

在2.3.0以前，Pulsar主要支持Thread和Process两种运行时来执行Pulsar Functions。这意味着，Pulsar Functions会以线程或者进程的方式运行在Pulsar Broker或者Pulsar Function Workers（如果单独部署）。这两种方式最大的问题是资源不隔离。因为Functions会与Broker或者Function Worker共用CPU、内存等系统资源。

从2.3.0开始，Pulsar Functions正式支持使用Kubernetes作为Pulsar Functions的调度器。启用Kubernetes作为Pulsar Functions的调度器也相当便捷，只需要在Function Worker配置中启用kubernetesContainerFactory，并配置相应的Kubernetes设置（比如k8Uri、jobNamespace等）。

如果你已经使用Kubernetes或者Helm来部署Pulsar，那么你只需要在Function Worker配置中启用kubernetesContainerFactory即可，无需其他Kubernetes设置。

这样，当你通过Pulsar-Admin CLI创建Function的时候，Pulsar Broker或者Function Worker会替你向Kubernetes提交相应的任务并以Kubernetes Pods的方式来执行Functions。你在提交Function时指定的CPU和内存等资源会自动变成向Kubernetes申请的实际资源，这样你可以将所有资源分配和隔离的工作全部交由Kubernetes来管理。

从2.3.0开始，Python Functions开始支持状态API。Python Functions的状态API包括简单的计数和KV操作。此外，在2.3.0之前，Python Function只支持提交单文件编写的Python Function。从2.3.0开始，Pulsar支持提交一个包含所有依赖的Zip包。这样，Python Function的用户可以将其编写的Python Function和它所需要的依赖打包在一起进行提交。

Connector

—

在Connector方面，Pulsar 2.3.0加入了对于数据库CDC （Change Data Capture）的支持。CDC的支持主要包括两块，一个是跟RedHat开源的通用CDC框架 - Debezium进行集成，另外一个是对于阿里开源的MySQL CDC框架 - Canal进行集成。

RedHat Debezium是一个功能完善的CDC工具，它支持多种常见的数据库 - MySQL、MongoDB、PostgresSQL，Oracle，SQL Server等。Debezium将数据库的Binlog转化成为可以被Pulsar读取和保存的数据格式写入Pulsar中，由于Binlog的抓取和记录是实时的，这样通过Debezium，就可以为下游的数据平台提供稳定可靠的实时数据源。下游应用可以立即获取并响应数据库中的每一行的改动，以实现对数据的实时流转和计算。

阿里开源的Canal是另一款针对MySQL进行CDC抓取的框架。Pulsar 2.3.0中也提供了集成Canal的CDC Connector。该Connector由来自中国社区的@tuteng同学贡献。

除了用于CDC的Connector之外，Pulsar在2.3.0中接入了对于MongoDB、HBase、Elastic Search以及Local Filesystem的支持。大部分的Connector贡献来自于中国开发者，特别鸣谢 @ambition119 和 @tuteng 的贡献和参与社区的讨论。

Clients

—

在2.3.0以前的release，非Java语言客户端的特性是远远落后于Java客户端的。我们在2.1和2.2的release中做了很多C++和Python方面的特性。在2.2的时候，Python和C++的特性基本上跟Java平齐的。Pulsar 2.3.0之后，CGO封装的Go客户端也完成了大部分的特性，实现跟Java客户端的平齐。大部分GO客户端的特性追赶工作，都是有中国开发者完成。其中特别鸣谢 @wolfstudy 童鞋！

2.3.0中客户端完善的特性包括：

Java
Pulsar 1.x的API默认从主API中移除。如果用户仍然需要使用1.x的API，可以引用pulsar-client-1x的依赖。
支持在Pulsar Service Url中指定多台Broker的地址。对于没有DNS或者无法使用Load Balancer的童鞋，可以通过这种方式来实现重连的高可用。
自动分区变更发现：2.3.0以前的客户端并不能自动发现分区的变更。如果管理端更改了分区数量，客户端需要手动重启来知晓分区数量的变更。在2.3.0之后，客户端会自动发现变更的分区数量，程序无需重新启动。
增加getPartitionsForTopic的API，方便客户端来获取指定topic的partitions列表。
Consumer增加pauseMessageListener和resumeMessageListener的API。如果使用MessageListener的方式消费消息，可以通过这两个方式暂停和重启消费。
C++：
Consumer可以指定SubscriptionInitialPosition
Producer增加了Flush方法来将所有pending的消息发送并进行持久化存储
TLS链接上进行hostname的验证
允许指定使用Avro格式的Schema信息
默认开启Batching
Consumer实现receiveAsync
Go：
Producer增加了Flush方法
使用go mod替代dep
Consumer支持Seek
Consumer支持指定SubscriptionInitialPosition
TLS链接进行hostname的验证
Producer支持LastSequenceID
Message支持获取SequenceID
Message支持获取Topic

结语

—

从2.0开始，Apache Pulsar已经从一个单纯的消息系统演进成为一个云原生的流数据平台。越来越多的企业开始接入和部署Apache Pulsar。2.3的发布从内核到周边强化了Pulsar作为流数据平台的诸多特性。在未来的一个月内，也就是2.4版本中，我们将会有更多强悍的特性发布。

此外，我们将于3月23日在杭州举办Apache Pulsar的第三次线下Meetup。这次Meetup由Apache Pulsar和Apache Flink两大社区联合举办。届时，来自Apache Pulsar的PMC成员和核心Committer将会齐聚杭州，为大家深度解析2.3版本的诸多特性，以及联合Apache Flink社区一起探讨Pulsar和Flink在批流融合方面的集成进展。活动议程将在近期上线，敬请大家关注。

Pulsar 2.3的下载链接：https://pulsar.incubator.apache.org/en/download/

Pulsar的项目链接：https://pulsar.incubator.apache.org/
Pulsar的Github代码库：https://github.com/apache/incubator-pulsar
Pulsar的Slack Channel：https://apache-pulsar.herokuapp.com/
Pulsar的邮件列表：https://pulsar.incubator.apache.org/contact/