关于apache:译文-科普Pulsar-和-Kafka-架构对比

11次阅读

共计 2454 个字符，预计需要花费 7 分钟才能阅读完成。

本文作者是 David Kjerrumgaard，目前任职于 Splunk，Apache Pulsar 和 Apache NiFi 我的项目贡献者。译者为 Sijia@StreamNative。原文链接：https://searchdatamanagement….，翻译已获受权。

对于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。
GitHub 地址：http://github.com/apache/pulsar/

相比于 Kafka 等数据处理中间件，分布式音讯平台 Apache Pulsar 如何存储数据？本文基于架构，比照了 Apache Kafka 等传统数据处理中间件和分布式音讯平台 Apache Pulsar 的优劣势，供大家参考。

Apache Pulsar 的多层架构将音讯服务层与存储层齐全解耦，从而使各层能够独立扩大。传统的分布式数据处理中间件（如 Hadoop、Spark）则在同一集群节点 / 实例上解决和存储数据。这种设计能够升高通过网络进行传输的数据量，使得架构更简洁，性能也有所晋升，但同时扩展性、弹性、运维受到了影响。

Pulsar 的分层架构在云原生解决方案中自成一家。现在，大幅晋升的网络带宽为此架构提供了坚实基础，有利于计算和存储的拆散。Pulsar 的架构将服务层与存储层解耦：无状态 broker 节点负责数据服务；bookie 节点负责数据存储（如图 1）。

服务层与存储层解耦的架构有很多劣势。首先，各层都能够弹性扩大，彼此之间互不影响。借助云和容器等环境的弹性能力，各层能够主动扩缩容，动静适应流量顶峰。其次，通过显著升高集群扩大和降级复杂性，进步了零碎可用性和可管理性。再次，这种设计还属于容器敌对型设计，使 Pulsar 成为托管云原生流零碎的最佳计划。Apache Pulsar 应用高可扩大的 BookKeeper 作为存储层，实现了弱小的长久保障与分布式数据存储和复制，并原生反对跨地区复制。

多层设计能够轻松实现分层存储，从而能够将拜访频率较低的数据卸载到低成本的长久化存储（如 AWS S3、Azure 云）中。Pulsar 反对配置预约义的存储大小或时间段，主动将存储在本地磁盘的数据卸载至云存储平台，开释本地磁盘，同时平安备份事件数据。

Apache Pulsar 和 Apache Kafka 都具备相似的消息传递概念。客户端通过 topic（逻辑上分为多个分区）与二者进行交互。通常而言，写入 topic 的有限数据流会被分为分区（特定数量、大小相等的分组），从而使数据均匀分布在零碎中，并被多个客户端同时应用。

Apache Pulsar 和 Apache Kafka 之间的本质区别在于存储分区的基础架构。Apache Kafka 是基于分区的公布 / 订阅零碎，旨在作为整体架构运行，服务层和存储层位于同一节点上。

在 Kafka 中，分区数据作为 leader 节点上的单个间断数据存储，而后复制到正本节点上（正本节点可预配置），实现数据多正本。这种设计通过两种形式限度了分区的容量，并扩大了 topic。首先，因为分区只能存储在本地磁盘中，分区大小取决于主机上最大的单个磁盘大小（“新”装置用户的磁盘大小约为 4 TB）；其次，因为必须复制数据，所以分区的大小不能超过正本节点上最小磁盘空间的大小。

假如能够将 leader 存储在新节点上，磁盘大小为 4 TB 且只用于分区存储，两个正本节点的存储容量都为 1 TB。在向 topic 公布 1 TB 数据后，Kafka 将检测到正本节点无奈持续接收数据，并且在正本节点开释空间之前，不能持续向该 topic 公布音讯（如图 3）。如果 producer 在中断期间无奈缓冲音讯，则可能会造成数据失落。

面对这一问题，有两种解决方案：删除磁盘上的数据，存储现有正本节点，但因为来自其余 topic 的数据可能还没有被生产，可能会导致数据失落；或为 Kafka 集群增加新节点并“重均衡”分区，将新增节点用作正本节点。然而这须要从新复制整个 1 TB 的分区，耗时、易出错，对网络带宽和磁盘 IO 要求高，且代价昂扬。此外，对于具备严格 SLA 的程序而言，离线复制的计划并不可取。

应用 Kafka，不仅在扩大集群时须要从新复制分区数据，其余故障也可能须要从新复制分区数据，如正本故障、磁盘故障、计算机故障等。如果没有在生产环境中呈现故障，咱们通常会漠视 Kafka 的这一弊病。

在基于分片的存储架构（如 Apache Pulsar 应用的架构）中，分区被进一步分成分片，能够依据事后配置的工夫或大小进行滚动。分片均匀分布在存储层的 bookie 中，实现数据多正本和扩容。

当 bookie 磁盘空间用尽，不能持续向其中写入数据时，Kafka 须要从新复制数据，Pulsar 如何应答这种场景呢？因为分区被进一步分成分片，因而无需复制整个 bookie 的内容到新增 bookie 中。在增加新 bookie 前，Pulsar 能够持续接管新数据分片，并写入存储容量未满的 bookie 中。增加新 bookie 时，新节点和新分区上的流量立刻主动减少，无需从新复制旧数据。

如图 5 所示，在第 4 个 bookie 节点不再持续接管新音讯分片时，音讯分片 4-7 被路由到其余沉闷 bookie 上。新增 bookie 后，分片主动被路由到新 bookie 上。整个过程中，Pulsar 始终在运行，并且能够为 producer 和 consumer 提供服务。在这种状况下，Pulsar 的存储系统更加灵便，高可扩大。