前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >Apache Pulsar 2.3 重磅发布,新特性独家解读

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

作者头像
林一
发布2019-03-14 15:51:22
1.9K0
发布2019-03-14 15:51:22
举报
文章被收录于专栏:MessageQueue

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

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-02-27,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 MessageQueue 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
云数据库 MySQL
腾讯云数据库 MySQL(TencentDB for MySQL)为用户提供安全可靠,性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性,包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL,可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理,不仅经济实惠,而且稳定可靠,易于运维。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档