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

“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/

原文发布于微信公众号 - MessageQueue(messagequeue)

原文发表时间:2019-02-27

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券