共计 4732 个字符,预计需要花费 12 分钟才能阅读完成。
对于 Apache Pulsar
Apache Pulsar 是 Apache 软件基金会顶级我的项目,是下一代云原生分布式音讯流平台,集音讯、存储、轻量化函数式计算为一体,采纳计算与存储拆散架构设计,反对多租户、长久化存储、多机房跨区域数据复制,具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。
GitHub 地址:http://github.com/apache/pulsar/
当新生事物呈现时,人们总是有两种角度去察看它,要么把它看小,要么把它放大。
对于 Apache Pulsar 来说,把它看小的角度通常是“Apache Pulsar 只是一个新的音讯队列而已“,或者“Apache Pulsar 只是一个新的数据管道而已”,又或者是“队列零碎早就有了,只是 Apache Pulsar 更具扩展性也能解决某些场景问题而已,根本没啥本质区别”。
那么,事实果真如此吗?
带着这些问题,InfoQ 记者张浩在 QCon 2021 寰球软件开发大会(https://qcon.infoq.cn/2021/be…)上采访了 StreamNative 联结创始人、Apache Pulsar 和 Apache BookKeeper PMC 成员翟佳,和他聊了聊 Apache Pulsar 的历史、特点以及将来的趋势。
点击 链接 ,查看公众号视频采访的全部内容,为不便读者查看,视频下方也附上了文字内容。
InfoQ:翟老师,你好,欢送来到 QCon 大会并承受咱们的采访,请您先自我介绍一下吧。
翟佳:主持人好,我叫翟佳,来自 StreamNative,当初次要是做 Apache Pulsar、Apache BookKeeper 相干的设计和开发,也是这两个开源我的项目的项目管理委员会成员。更早之前,我还在 EMC 做过分布式文件系统的设计和开发。
InfoQ:我在 Pulsar 官网上看到它是这么定义的,它说 Pulsar 是一个云原生的分布式音讯和流平台。在中文媒体的很多宣传里,对于 Pulsar 的定义怎么说的都有,我权且就把它了解为是一个新一代的 Kafka。那么很多公司其实是把 Kafka 当成音讯零碎应用的,所以我想请你来聊一聊,这些年来开源音讯零碎都经验过怎么的迭代?
翟佳:你刚刚提到的音讯零碎的确是 Pulsar 诞生的一个初衷,因为在 2011 年、2012 年的时候,在雅虎外部须要解决的就是一个音讯零碎对立的问题。过后比拟风行的 ActiveMQ、RabbitMQ 在雅虎外部也都有应用,所以 Pulsar 诞生的一个场景也是做外部的一个对立,要替换 ActiveMQ、RabbitMQ 这样的音讯零碎。也就是你方才提到的 MQ 的场景需要。
你方才也提到 Pulsar 是云原生的,这跟它当初诞生时雅虎的环境无关。雅虎过后是 Hadoop 生态的一个次要缔造者,它是先有的底层的存储层,也就是 BookKeeper 这样一个我的项目。咱们之所以说它云原生也是因为 Pulsar 采纳了一个存储和计算拆散的这样一个架构,存储层就是咱们刚刚提到到 BookKeeper,BookKeeper 它在雅虎外部次要是解决 Hadoop 生态,也就是 HDFS、NameNode 这样的一层 HA。你能够认为它是做元数据的存储,所以它有很高的一致性。刚好它又是一种 Log 的形象,就是用 append-only 的模式,它跟咱们提到的 MQ 的场景很相似,新的音讯一直地追加,而后这个模式刚好能够利用在音讯这个畛域外面,所以它对云原生路线的抉择跟它的技术背景有关系。就是先有了很优良的、可能提供很好服务质量的存储系统,而后才有了 Pulsar 这样的存储和计算拆散的架构。
有了这样的零碎之后,它因为有存储和计算拆散的架构,有 Write-Ahead-Log(WAL)存储层的形象,它不仅能够撑持很多 MQ 的要害业务场景,不丢音讯,对一致性要求很高,又能够提供比拟高的带宽、比拟低的提早。所以这是很多用户把它用在原来 Kafka 的场景外面的起因。可能最开始的抉择是 MQ 的方向,然而因为架构、因为自身存储层的个性,也会用到一些 Kafka 的场景外面,这是它跟 Kafka 的关系。
InfoQ:方才你提到 Pulsar 是诞生于雅虎,你能更具体的介绍一下这个我的项目诞生的背景吗?这些年 Pulsar 倒退得怎么样?
翟佳:Pulsar 的诞生咱们刚刚提到过一点,开始做这个我的项目是在 2012 年,在过后,2011 年国内诞生了 RocketMQ,再往前一年,2010 年诞生了 Kafka,而后 Pulsar 在 2012 年诞生。
在 2012 年要抉择云原生的存储计算拆散的架构是一个很有挑战的事件。因为过后单个节点的网卡,单个节点的磁盘可能都不适宜云原生这样的架构。所以在 2012 年之前,也就是 2010 年下半年到 2011 年,雅虎外部做了一个 Pulsar 的原型零碎,它叫 HedWig。它次要是做这样的一个尝试:就是存储计算拆散这样的架构能不能服务于音讯这个场景。所以它诞生可能更早一些,先有 HedWig 这样一个原型零碎,而后再立项 Pulsar。Pulsar 开源之前在雅虎外部的代号叫 CMS(Cloud Message Service),所以说它最开始诞生的初衷就是要做一个云的音讯的服务。
有了后期原型零碎的铺垫,决定了云原生这个路线之后,再往后 2013 年次要是做性能开发,2014 年开始在雅虎外部大规模部署,在雅虎外部通过线上产品的测验,又稳固运行了一两年当前,在 2016 年开源进去,2017 年捐给 Apache 软件基金会,2018 年从 Apache 软件基金会毕业成为顶级我的项目。
捐给 Apache 软件基金会之后,这个我的项目就开始了一个疾速的发展期,很多国内外的互联网公司都开始应用 Pulsar,因为它的确解决了 MQ 场景里的问题,也解决了 Kafka 场景外面的一些问题。
特地是在 2019 年有了咱们商业化的公司 StreamNative 的成立,用户对这个我的项目就更有信念了。包含腾讯最开始上线的一个很要害的业务场景,就是腾讯计费平台,也都是基于 Pulsar 来做所有计费的业务。还有国外的 Splunk 以及雅虎外部也有很多的场景都应用了 Pulsar,这样 Pulsar 的生态也随着咱们国内外社区一直地成长,倒退得越来越好了。
在 2018 年成为顶级我的项目之前,GitHub 的 Star 数增长尽管还好,但不是那么显著,在 2018 年底变成顶级我的项目之后,2019 年公司(StreamNative)成立,Star 数的增长就更加迅速了。我感觉国内的开源土壤对咱们开源社区的构建,对咱们开源我的项目初期的成长有很大的帮忙。
InfoQ:我看到网上很多人比照 Kafka 和 Pulsar,包含方才咱们也做了一个比照,那你怎么去对待这两个技术呢?
翟佳:咱们刚刚也提到,Pulsar 我的项目诞生的背景就是要解决雅虎外部的需要。它要有大集群、多租户的能力,能让雅虎外部各个业务部门的数据买通,所以它诞生的初衷不是为了去做 Kafka 的事件,大家都在同一个时代。
而且在 2012 年 Kafka 也没有像当初这么火,Pulsar 还是从本身的角度登程,就是要解决雅虎外部的问题,而后就有了这样的产品。之后它又抉择了开源的路线,让产品变得更加稳固,可能借助社区给它增加更多的性能。所以说它最开始不是专门针对 Kafka 而设计的,然而诞生之初,它的设计为了解决本身的问题,会思考到更丰盛的利用场景,思考本身业务的一些需要,所以说它的确也可能撑持 Kafka 所对应的一些业务需要。自然而然地,在开源之后,可能它解决了 Kafka 用户的一些痛点,被一些用户所抉择,但这是一个自然而然的过程,并不是专门针对 Kafka 来做这个事。
InfoQ:郭斯杰之前说过,音讯、流、存储将会逐渐交融,你怎么了解这个观点呢?
翟佳:刚刚提到三个方向,音讯、流和存储。我发现音讯和流是很相干、模式也很相似的两个零碎,你的音讯也是须要一个载体来提供音讯的存储和服务,音讯进来的模式也是要依照工夫、用户的数据等等固定的程序,这样能力对外提供程序性和一致性的保障。
流的场景也是一样,所有的数据源源不断地流入,而后依照工夫程序来做一个生产,所以从这个角度来看,它们两个是很贴近、概念很相似的一个场景。只不过在之前可能因为技术架构的起因,咱们把音讯和流分成了两种模型。在很多企业外部要害的业务场景里用各种 MQ 来保障音讯的服务,在数据管道这种场景下用 Kafka 提供流的服务,然而实质上来说它们都是一样的,只是之前因为技术起因,把它们人造做了一个分隔。
Pulsar 的一个劣势是它有很好的底层贮存层 BookKeeper,它既能够保障很高的一致性,也能够通过 append-only Write-Ahead-Log(WAL)这种形象来保障比拟高的吞吐,它能够从技术上解决两个场景不同的需要,所以 Pulsar 从这个角度提供了很好的音讯和流的交融。
在存储这个方向,之前大家可能把音讯的存储这个事件看得有些太简略了,有很多用户认为我的音讯要做零碎解耦,在 MQ 的场景外面,可能有很多的音讯都是从内存里间接就把音讯生产完了,很少有须要把音讯落地、存储的场景,所以过后的实现都很简略,包含 Kafka 在内,大家都是把音讯间接落到文件系统外面,怎么简略怎么实现,这样对很多要害的业务场景,对很多须要数据沉积的场景来说,如果单单依附一个文件系统来做,你的服务质量,你的稳定性可能就不太容易保障,因为文件系统不是专门为这个场景设计的,比如说你在 MQ 场景,我须要实时地刷盘,我须要保障这个数据持久性,它的备份数以及一致性要足够高,这个场景下它的性能可能就会降下来了,这也是咱们说随着用户的利用数据场景不断丰富,随着你对音讯零碎的要求一直进步,它对底层音讯零碎的一些要求也会扭转。所以当初来看,随着大数据的倒退,随着用户数据量的进步,Pulsar 真正施展了它的价值,它有一个专门为音讯做的存储层,有了这样一个存储层,它能够跟咱们刚刚提到的音讯的服务、流的服务可能很好地联合起来。
所以说音讯、流和存储在 Pulsar 这边是一个交融的方向,是一个交融的架构,这是咱们从 Pulsar 这个角度来看这三个方向时一个很直观的感触。
InfoQ:Pulsar 之所以敢说它是新一代的音讯零碎,那它必定是适应了一些趋势,除了后面的音讯、流、存储的趋势外,你们还看到了什么样的趋势?
翟佳:咱们感觉这个趋势可能就是咱们在第一个问题中提到的,它和云原生比拟相干。因为云原生是一个很大的趋势。刚刚咱们也提到过,Pulsar 选的这套架构,过后也是一个很超前的架构,在 2012 年它就抉择了存储计算拆散这样的架构,它具备云原生这个劣势,同时再联合 Pulsar 自身每一层节点都是一个对等的架构,这样会对线上运维有很大的帮忙。包含咱们说在你的服务层,你所有的 Broker 都是一个对等的架构。而后你的存储层 BookKeeper 也是一个对等的架构。这样你扩缩容的时候,你的大集群不必保护每个节点 master/slave 的状态。它的保护更加简略。同时咱们在云上有一个很重要的初衷,就是我要做一个弹性的资源调度,从这个角度来说 Pulsar 也是刚好适应这个趋势,跟它诞生的代号 CMS(Cloud Message Service)是一脉相承的关系,就是要做一个音讯的云,要把云上的各种资源可能很容易地调度起来,可能为音讯零碎做一个服务。所以我感觉云原生是 Pulsar 很大的一个劣势,也是咱们适应的一个大趋势。
InfoQ:好的,谢谢翟老师。
翟佳:感激主持人。
相干浏览
- QCon 北京 2021:Pulsar PMC 成员翟佳缺席并演讲
- StreamNative CEO 郭斯杰带你深度解析“音讯、流、存储”三位一体交融趋势
点击链接,获取 Apache Pulsar 硬核干货材料!