Apache Pulsar 分层存储帮你省钱

原作者：Jesse Anderson
翻译：StreamNative-Sijia

企业在考虑部署实时消息系统时，总体硬件成本是很重要的。通过预先规划，企业可以节省高达 85% 的总体存储成本。

在比较存储成本之前，我先简要介绍一下 Apache Kafka 和 Apache Pulsar 如何存储数据，它们之间有何差异，以及为什么这些差异很重要。

Kafka 中的数据存储

图 1 Kafka 存储简图

在 Kafka 中，Broker 进程负责移动并存储数据。Producer 将数据发送到 Broker 进程中。当 Consumer 轮询数据时，从 Broker 中检索数据。Broker 进程接收到数据时，会将数据存储在单独的本地目录中。

Kafka 集群支持同时运行多个不同的 Broker 进程，而每个 Broker 进程分别运行在物理上独立的计算机或容器上。

Pulsar 中的数据存储

可以通过几种不同的方式建立 Pulsar 集群。这种可扩展性正是优化存储成本的方式。

简单的 Pulsar 设置

图 2 Pulsar 存储简图

在 Pulsar 中，Broker 进程负责移动数据。Producer 将数据发送到 Broker 进程中。当 Consumer 推送数据时，数据来自 Broker。当 Broker 接收到数据时，会将数据存储在一个共置的 BookKeeper Bookie（BookKeeper 中存储数据的进程）中。

Pulsar 集群支持同时运行多个不同的 Broker 进程，而每个 Broker 进程分别运行在物理上独立的计算机或容器上。

具有独立 BookKeeper 集群的 Pulsar

图 3 Pulsar 与独立的 BookKeeper 集群

如图所示，Pulsar Broker 不直接存储数据，而是使用 Apache BookKeeper 来存储数据。数据发送/接收和存储的解耦使得 BookKeeper 可以在物理上独立的计算机或容器上运行。

在 Broker 保存消息时，只会将消息发送到 BookKeeper 进程中。这使 BookKeeper 集群和 Pulsar 集群可以相互独立地扩展。如果需要收发大量消息但只存储较短时间，则可以配置很多 Broker 和较少的 Bookie 节点；相反，如果收发消息速度慢但需要长时间存储，则可以配置少量的 Broker 和较多的 Bookie。

一个常见的问题是，将 Broker 和 Bookie 放在不同的计算机上是否会影响性能。Broker 会在内存中保留最新消息的缓存。但实际上，99.9% 的消息是缓存命中，因为大多数 consumer 只接收最新的消息。

卸载数据到 S3

图 4 Pulsar 与卸载数据到 S3 的独立 BookKeeper 集群

Pulsar 的解耦存储架构确实是 Pulsar 的一个新特点，即分层存储。BookKeeper 可以根据管理员配置的策略自动将存储在 Bookie 上的数据移动存储到 S3 中。

注意： 虽然我建议卸载数据到 S3，但这并不是唯一的选择。S3 支持 Google Cloud Storage，并且将会支持 Azure Blob Storage，因此可以将 S3 看作你将会选择的云存储的简称。

虽然数据存储在 S3 中，但是由于 Bookie 负责数据移动，Broker 仍然可以访问 S3 中的数据。另外，S3 的 IO 比本地存储的数据慢。

存储的主要区别

在存储方面，Kafka 和 Pulsar 的主要区别在于是否耦合。在 Kafka 中，存储耦合到 Broker 中；在 Pulsar 中，存储与 BookKeeper 分离。

图 5 Kafka 卸载

Kafka 确实能够将数据存储在 S3 中，可以通过手动设置 Kafka Connect 或编写自定义 Consumer 来实现。

图 6 Kafka 访问

图 6 展示了卸载数据到 S3 的注意事项。一旦数据卸载到 S3，就不能再通过 Kafka API 进行访问。必须使用支持 S3 的另一个计算引擎对数据进行后续处理或使用，否则需要将数据重新流回 Kafka 主题，再进行处理。

图 7 Pulsar 访问

使用 Pulsar 就可以与计算引擎共享数据，也就是说，Broker 和计算引擎都可以访问旧数据。

例如，Spark 可以处理 S3 中的旧消息，同时，Pulsar Consumer 能够请求这些旧消息。请注意，在其他计算引擎中读取 Pulsar 数据需要一种自定义输入格式，这种格式可以理解 Pulsar 的磁盘格式。在撰写本文时，Pulsar 支持用于 Spark、Flink 和 Presto 的连接器。

计算成本

我们已经分别介绍了 Kafka 和 Pulsar 如何存储数据，接下来可以开始计算成本了。为了使计算简单而具体，我们将采用 Amazon Web Service 2019 年 1 月在美国东部（俄亥俄州）地区的定价。S3 每 GB 每月的费用为 0.023 美元，Amazon EBS 通用 SSD 预配置存储每 GB 每月费用为 0.10 美元。

在这种情况下，假设每天存储 500 GB 的消息，需要存储 14 天，大约有 7000 GB 的原始事件消息。在 Kafka 和 Pulsar 中，为提高可用性，数据以三副本形式保存，这就需要 21,000 GB 的存储空间。不考虑 S3，Kafka 和 Pulsar 仅存储每年就要花费 25200 美元。

使用 Pulsar 和 S3，就不需要在 BookKeeper 上存储 14 天，可以只在 Pulsar 上存储 1 天，另外 13 天存储在 S3 上（大部分情况下，使用几分钟前的数据）。也就是说，需要 1,500 GB 的 EBS（500 GB x 3 份副本）和 6,500 GB 的 S3（S3 不直接对冗余收费）。EBS 每年的费用为 1,794 美元，S3 每年 1,800 美元，总共为 3,594 美元。显然，S3 请求的成本没有包含在内，但每年的费用应该在 50-300 美元之间。

在不损失数据可用性的条件下，这两种选择的费用相差了 85.7%。为了估算成本差异，我做了一个 Pulsar_Storage_Savings 文件。在表格中输入数据，就可以看到价格差异。

关于费用的补充

对于云用户而言，S3 中数据的归档存储已经纳入预算，这样可以节省费用。

还有一些更便宜的 S3 层，SLAs 更低，价格也更低，例如：Glacier。选用 Glacier，S3 每 GB 每月的费用将从 0.023 美元降至 0.004 美元。

可以根据用例和集群需要，选择合适数量的 Pulsar Brokers 与 BookKeeper Bookie 节点来优化成本。EC2 成本通常要比存储成本高得多。

了解 Kafka 和 Pulsar 在存储上的差异，的确可以优化存储支出。在灵活地交付业务所需的内容的同时，还可以降低 IT 开销。