Overview of tiered storage

Pulsar 的分层存储 功能允许将历史 backlog 数据从 BookKeeper 中转移到更加低廉的存储介质中并且允许客户端访问无变化的 backlog 数据。

• Tiered storage uses Apache jclouds to support Amazon S3 and GCS (Google Cloud Storage) for long term storage.

  通过 jclouds，可以在未来便捷地去扩展对其他云存储的支持。

  提示

  更多关于如何在 Pulsar 中使用 AWS S3 offloader 的介绍，请查看这里。

  更多关于如何在 Pulsar 中使用 GCS offloader 的介绍，请查看这里。

• 分层存储通过Apache Hadoop 来实现在文件系统中进行归档存储。

  通过 Hadoop，可以在未来便捷地去扩展对其他文件系统的支持。

  提示

  更多关于如何在 Pulsar 中使用文件系统卸载器（offloader）的介绍，请查看这里。

何时使用分层存储？

分层存储应该在你有一个想长期保存 backlog 数据的 topic（主题）时使用。

举例来说，比如你的一个 topic 中包含了用户行为数据以此来训练自己推荐算法，那么你可能会希望将这部分数据做长期的存储。这样的话当你想要调整你的推荐算法模型时就可以获取完整历史数据并重新进行执行。

分层存储是如何工作的？

每个 Pulsar 的 topic 都包含了一个消息日志，我们称之为managed ledger。 日志由一系列有序分片（segment）组成。 Pulsar 只会向消息日志中最后的分片中写入数据。 All previous segments are sealed. The data within the segment is immutable. 这种方式我们称之为** 面向分片式架构（segment oriented architecture）**。

分层存储的卸载机制就充分利用了这种面向分片式架构（segment oriented architecture）。 当需要开始卸载数据时，消息日志中的分片就依次被同步至分层存储中， 直到消息日志中所有的分片（除了当前分片之外）都已被写入分层存储后。

默认情况下写入到 BookKeeper 的数据会复制三个物理机副本。 然而，一旦分片被封存在 BookKeeper 中后，该分片就不可更改并且可以复制到归档存储中去。 长期存储可以达到节省存储费用的目的。通过使用 Reed-Solomon error correction 机制，还可减少物理备份数量。

在将 ledger 卸载至长期存储系统中之前，你需要配置云存储的存储桶（bucket）、凭证以及其他属性。 此外，由于 Pulsar 会使用对象存储的分块上传功能来卸载 segment 数据，broker 可能会在上传数据时出现崩溃问题。 建议你在存储桶（bucket）中进行生命周期规则配置，在未完成的分块数据上传后一两天内进行自动清理以避免因上传不完整而被收取费用。 此外，你也可以手动触发卸载操作（通过 REST API 或者命令行）也可以自动触发（通过命令行）。

在将 ledger 卸载到归档存储系统后，你依旧可以使用 Pulsar SQL 来查询这些已归档的 ledger。

关于更多关于 Pulsar topic 分层存储的介绍，请查看这里。