十分荣幸有机会和大家分享一下 Apache Pulsar 怎么为批流解决提供交融的存储。心愿明天的分享对做大数据处理的同学能有帮忙和启发。

这次分享，次要分为四个局部：

• 介绍与其余音讯零碎相比，Apache Pulsar 的独特劣势
• 剖析批流解决中的存储需要
• 讲述 Apache Pulsar 如何完满匹配批流解决中的存储需要
• 介绍怎么应用 Apache Pulsar 提供批流交融的存储

Apache Pulsar 简介

Apache Pulsar 是早先开源的一个大规模分布式音讯零碎，是 Apache 的顶级我的项目，在 Yahoo 寰球数十个机房大规模部署并线上稳固应用了 4 年多。Apache Pulsar 设计中学习和借鉴了其余优良的分布式系统，在保障一致性和高吞吐的同时，也提供了其余优良个性，比方反对上百万的 Topic、无缝的多核心互备、灵便的扩展性等。

这里咱们简略介绍一下，与其余音讯零碎相比，Apache Pulsar 领有的独特劣势，大抵有以下 3 点：

• 独特的软件架构（存储和计算拆散，分层分片的存储）
• 灵便的生产模型（Exclusive、Failover、Shared 和 KeyShared）
• 丰盛的企业个性（多租户）

在介绍 Apache Pulsar 时，通常会用这样一句话，“Flexible Pub-Sub Messaging backed by durable log Storage”。这句话表明了 Pulsar 和其余音讯零碎的基本不同，它采纳了存储和计算拆散的架构。

Pulsar 的服务层应用 Broker，存储层应用 BookKeeper，来提供高效和统一的存储。

从架构上来说，Apache Pulsar 采纳了分层和分片的架构。这是 Pulsar 满足批流解决中存储需要的根底。

在 Apache Pulsar 的分层架构中，服务层 Broker 和存储层 BookKeeper 的每个节点都是对等的。Broker 仅仅负责音讯的服务反对，不存储数据。这为服务层和存储层提供了刹时的节点扩大和无缝的失效恢复。

存储层 BookKeeper 为 WAL（Write Ahead Log）提供了存储，是一个分布式的 Log 存储系统。

WAL 和数据处理中的流有很多相似性，都是数据源源不断地追加，都对程序和一致性有严格要求。

BookKeeper 通过 Quorum Vote 的形式来实现数据的一致性，跟 Master/Slave 模式不同，BookKeeper 中每个节点也是对等的，对一份数据会并发地同时写入指定数目的存储节点。对等的存储节点，保障了多个备份能够被并发拜访；也保障了存储中即便只有一份数据可用，也能够对外提供服务。

Apache Pulsar 通过分层分片的架构，将逻辑的分区转化为分片来作为存储单元。这为数据的并发拜访提供了根底。

除了架构的不同，从用户接口来说，Apache Pulsar 通过订阅的形象，提供了灵便的生产模型。每一个订阅相似一个 Consumer Group，接管一个 topic 的所有的音讯。用户能够应用不同的订阅类型、以不同的模式来独特生产同一个 Topic 中的音讯。

如果对程序性有要求，能够应用 Exclusive 和 Failover 的订阅模式，这样同一个 Topic 只有一个 Consumer 在生产，能够保障程序性。

如果应用 Shared 订阅模式，多个 Consumer 能够并发生产同一个 Topic。通过动静减少 Consumer 的数量，能够减速 Topic 的生产，缩小音讯在服务端的沉积。

Pulsar 行将公布的 2.4.0 版本增加了一种新的订阅模式：KeyShared。KeyShared 模式保障在 Shared 模式下同一个 Key 的音讯也会发送到同一个 Consumer，在并发的同时也保障了程序性。

Apache Pulsar 灵便的生产模型，防止了因为不同的生产场景须要部署多套音讯零碎的场景，打消了数据生产端的数据拆散。

此外，Apache Pulsar 是以多租户为根底的丰盛的企业级个性。企业外部能够搭建一套 Pulsar 集群，在集群中给各个部门调配不同的租户，并设置租户的管理权限。租户的管理员再依据部门的不同业务和场景需要，创立不同的 Namespace。在 Namespace 中能够设置管理策略，比方流控，Quota，互备的集群，数据正本数等。这样为 Topic 的治理提供了一个层级的可控的视图。

Apache Pulsar 的企业级个性，为企业搭建对立大集群提供了根底，不便了集群的治理和数据的共享。

以上是对于 Apache Pulsar 的简略介绍，欢送参阅 Apache Pulsar 的官网和微信公众号理解更多内容。

批流解决中的存储现状

在大数据处理刚刚衰亡的时候，个别用户会采纳 λ 架构，保护批流两套零碎：批零碎次要解决历史数据；流零碎解决实时的数据，对批零碎的后果进行补充来进步时效。两套零碎造成数据冗余，减少保护老本。

在存储层，批处理常应用 HDFS 和网络对象存储等；流解决常应用 Kafka 或其余的音讯零碎。

为了解决 λ 架构的问题，逐步演化出 κ 架构，应用一套零碎来满足实时数据处理和历史数据处理的需要。

在 κ 架构中，数据的“可反复解决”是要害。一方面要求实时数据能及时获取最新数据，解决完立刻导出给其余零碎应用；另一方面要满足解决历史数据的需要，须要具备读大量历史数据的能力。实时数据的解决决定了必须应用音讯零碎，然而音讯零碎并不能齐全满足批处理的并发需要。

在后面的分享中，百度和阿里的专家分享了计算层的批流交融。咱们认为批流交融存储层的需要是一个交融的存储表征：音讯零碎 + 并发的存储拜访。

为什么 Apache Pulsar 能满足批流解决中的存储需要

上面咱们从“Apache Pulsar 提供的存储形象”、“批流解决中的 IO 模式”和“Apache Pulsar 提供的有限流存储”这三个方面来解释为什么 Apache Pulsar 能满足批流交融的存储需要。

Segmented Stream 存储表征

后面咱们介绍了 Apache Pulsar 首先是一个音讯零碎，它和其余音讯零碎相似，提供了简洁的以 Topic，Producer，Consumer 为根底的 Pub/Sub 模型。

Pulsar 灵便的订阅模式和高带宽、低提早个性，可能很好的满足流解决的需要。

Apache Pulsar 的 Topic 能够分为不同的分区。和其余音讯零碎不同的是 Apache Pulsar 利用分片的架构，每个逻辑分区又进行了分片。

在分层分片的架构中，分片是存储的单元，能够类比 HDFS 中的一个文件块，分片被平均地散布在存储层的 BookKeeper 节点中。

咱们再从批流解决的角度来看 Apache Pulsar 的这种分片（Segment）的架构：

• 对于流解决来说，Apache Pulsar 的每个 Partition 就是流解决的一个流，它通过 Pub/Sub 的接口来给流解决提供数据交互。
• 对于批处理来说，Apache Pulsar 以分片为粒度，能够为批处理提供数据的并发拜访。

一方面，Apache Pulsar 中每个 Partition 都能够看做是源源不断流入数据的载体，借助于分片和二级存储，Apache Pulsar 有能力将 Partition 所有流入的数据都保留下来。这样每个 Partition 都能够看作是 Stream 的存储形象。

另一方面，Apache Pulsar 的 Partition 是逻辑分区的概念，分区外部又被分成分片，作为存储和 IO 拜访的单元。

联合这两个概念，咱们把 Apache Pulsar 对每个 Partiton 的存储表征称为 Segmented Stream。

通过 Pulsar 的 Segmented Stream 形象，为批流解决提供了一个对立的存储表征。

匹配批流解决中的 IO 模式

介绍了 Apache Pulsar 的 Segmented Stream 的存储表征后，上面咱们联合批流解决中数据的三种罕用的拜访模式：Write，Tailing Read 和 Catchup Read，来看看 Apache Pulsar 这种架构的合理性。这里次要会探讨提早、IO 的并发和隔离，并用大家比拟相熟的 Kafka 零碎来比照阐明。

• Write：往 Stream 中增加新的数据。
• Tailing Read：读最新的数据。
• Catchup Read：读历史老数据。

对于 Write 这种模式，所有的写都间接追加在 Stream 的尾部。对于和 Kafka 相似的 Master/Slave 架构零碎来说，数据会先写入 Leader Broker，再发送给其余 Follower Broker。

Apache Pulsar 的写先发送到 broker，而后 broker 作为存储代理，并发将数据发送给存储层的多个 Bookie 节点。两种架构都会有两次网络跳跃。

对于 Write 模式，提早差异不大。

Tailing Read 是流解决中的罕用模式。它从 Stream 的尾部读取最新写入的数据。

对于和 Kafka 相似的零碎，Tailing Read 会从 Leader Broker 间接读取。对于 Apache Pulsar，在 Broker 中有一段自保护的 Cache 来缓存刚刚写入的最新数据，Tailing Read 间接从 Broker 获取数据并返回。

两种架构都只有 1 次网络跳跃。对 Tailing Read 模式，提早差异不大。

Catchup Read 是批处理中罕用的读取模式。它从 Stream 的指定地位，读取一定量的历史数据。这种场景个别对数据的读取量比拟大，重视读取的带宽。

对于 Kafka 相似的零碎，Catchup Read 个别还是会应用 Pub/Sub 的接口，从 Leader Broker 间接读取。对于 Apache Pulsar，咱们能够从 Broker 中读取元数据，获取 partition 中分片的起始地位和分片在 BookKeeper 中的存储信息，绕过 Pub/Sub 接口，利用 BookKeeper 的 Read 接口，间接从存储层并发拜访多个分片。BookKeeper 提供了多正本的高可用，晋升了读取历史数据的并发能力。

如果咱们把这三种 IO 模式放在一起看就更有意思了。这能够类比用户在某时间段，对 Stream 既有最新数据读写，也有历史数据读写的情景。这是在批流交融中常常遇到的场景。

对和 Kafka 相似的零碎，这三种 IO 模式都会产生在 Leader Broker。在 Leader Broker 中，零碎的数据都须要通过文件系统的 Pagecache，历史数据和最新的数据会争用 Pagecache 资源，造成读写响应不及时。

如果这时再遇到 Broker 磁盘空间写满，须要扩容的状况，那就须要期待数据的搬移和 rebalance 的操作。这时，IO 的提早和服务质量很难失去保障。

Apache Pulsar Segmented Stream 的存储表征，联合分层分片的架构，为新数据和历史数据做了人造的隔离。最新的数据 IO 产生在 Broker 层。

对历史数据的并发读写，间接产生在存储节点。冷热数据被人造隔离，用户齐全不必放心 IO 的抵触和争用。Apache Pulsar 在节点扩容和谬误复原的过程中，也不会有数据大量拷贝和 rebalance，因而晋升了零碎的高可用性。

通过这三种 IO 模式的阐明和比照，咱们发现 Pulsar Segmented Stream 的存储表征，再联合分层分片的架构，能够很好地满足批流解决中对存储系统的需要。

有限的流存储反对

Pulsar Segmented Stream 的存储表征，很好地模仿了事实中 Stream 数据。对于流存储的另一个需要是实践上有限的存储空间。这样能够满足对历史数据的存储和拜访需要。Apache Pulsar 从两个方面解决了这个问题。

一方面 Pulsar 的存储层中，分片会平衡地散布到所有的存储节点中，这防止了其余零碎中繁多 broker 存储容量的限度，进而能够利用整个集群的存储空间。

另一方面，Pulsar 的分片架构，为数据的二级存储扩大提供了很好的根底。对于 Segmented Stream，用户能够设置 Segment 在 BookKeeper 中保留的工夫或大小。如果超过设定的值，将旧的 Segment 迁徙到便宜的二级存储，比方 Aws S3，Google Cloud Storage，或者 HDFS 中。二级存储的带宽个别有保障，能够满足历史数据的批处理模式。通过二级存储能够加重有限存储的老本。

小结

Pulsar 利用自身的分层分片的架构，提供了 Segmented Stream 的存储表征，满足了批流交融的存储需要。

• 通过 Pulsar Pub/Sub 接口拜访 Segmented Stream，能够满足流解决的存储需要；
• 通过 Pulsar 存储层对 segment 的拜访接口（Segment Reader），能够满足批处理的并发拜访需要。

从批流解决的 IO 模式分析中能够发现，Pulsar 的架构能够很好地解决批流解决中的 IO 并发和隔离。并且 Pulsar 提供了实践上有限流存储的能力，可能满足批处理中，对海量历史数据的存储需要。

怎么应用 Pulsar 提供批流交融的存储

后面咱们介绍了为什么 Pulsar 的架构能满足批流交融的存储需要。接着咱们会介绍 Pulsar 是如何在工程上实现的。

基于 Segmented Stream 存储的表征，咱们很容易辨别和反对批处理和流解决。批处理所申请的数据能够看做是一个有边界的流（Bounded Stream）。流解决所申请的数据能够看做是一个没有边界的流（UnBounded Stream）。

上面咱们看在 Pulsar 外部，批处理和流解决会怎么拜访 Segmented Stream。

这里的代码是一个计算广告点击率的 SQL 语句。如果用户想要查问某个时间段内的点击率，会提供点击事件的起止工夫。起止工夫能够确定一个流的起止边界，进而确定一个 Bounded Stream。这是一个典型的批处理场景。

对 Pulsar 的解决来说，首先依据起止工夫来确定和获取所须要的 Segments 列表；而后抉择这些 Segments，绕过 pub/sub 接口，间接通过 Pulsar 的 Segment Reader 接口，来拜访 Pulsar 的存储层。

流解决是一系列不会进行的 Windows 拜访和查问。与批处理相比，流解决它没有截止的工夫点，即便查问到以后时刻，它依然持续对以后的 window 一直地查问，一个 window 解决完结，接着解决下一个 window。它的 SQL 查问语句不会变动，然而查问 window 中的数据会一直实时更新，它是一个源源不断的、不停解决最新数据的形式。

对于这种拜访模式，间接应用 Pulsar 的 pub/sub 接口就能够间接获取最新的音讯，满足流解决的需要。

对批流交融，在计算层，更多关注的是批流交融的计算模型、API 和运行时的对立。在存储层，通过 Segmented Stream 的存储表征，为批流数据提供了对立的数据存储和组织形式。

针对批流解决的不同拜访模式，Pulsar 提供了两套 API 接口。流解决应用 Pub/Sub 的接口；批处理应用 Parallel Segment Read（PSegment）的接口。

对于批处理的接口，咱们在 Pulsar SQL 外面做了一个尝试，Pulsar SQL 借助 Presto，对写入 Pulsar 中的数据进行交互式的查问。

如果你想体验 Pulsar SQL，能够查看 Pulsar 的 SQL 手册。

Pub/Sub 的接口曾经比较完善，咱们最近在丰盛和欠缺 PSegment 接口。

在 PSegment 中，咱们的次要工作是集成 Pulsar 和 Flink、Spark、Hive 及 Presto。这些工作次要集中在 API 的实现和 Schema 的整合。这些工作实现之后，咱们会开源这部分的代码。

总结

Pulsar 是下一代云原生的音讯和流存储的平台。咱们认为音讯和流是一份数据的两种不同表征形式。Pulsar 采纳了存储计算拆散的分层架构和分区内再分片的存储架构，这种架构可能提供基于 Segmented Stream 的存储表征，能为批和流解决提供交融的存储根底。

作者翟佳，StreamNative 联结创始人兼 CTO，本文为其 InfoQ 技术大会演讲的内容整顿。