Uber 的技术博客发表了一篇文章，Introduction to Kafka Tiered Storage at Uber，旨在通过更少的 Kafka Broker 和更少的内存来最大限度地保留数据。这允许在各种业务应用程序中延长消息保留时间。
常见的解决方案是手动集成外部存储，定期将数据同步到外部系统。然而，这涉及大量的开发和维护工作，例如确定如何保存数据、设置同步频率、触发流程、获取数据和使用索引。
因此，Uber提出了一个解决方案，封装了外部存储的逻辑，通过简单的配置使其即插即用。此功能正在与 Apache 基金会合作开发，并将在未来版本中提供。
设想
重要的是要了解 Kafka 是一个具有非常高吞吐量能力的仅附加消息队列 (MQ) 组件。 Kafka将日志存储在broker的本地存储上，用户可以配置保留时间或日志大小。在我之前的公司（联想），我们使用Flink来持续消费数据。大数据量会导致Kafka超出磁盘存储限制，导致数据写入失败和业务错误。为了降低成本，我们只能调整保留时间，而不是部署更多机器。
此外，如果每个公司都开发自己的系统来将旧数据保存到外部存储，那么将涉及大量的开发工作。还有许多与同步和数据一致性相关的问题。
解决方案
本质就是对Broker进行改造，增加远程日志管理和存储管理
RemoteLogManager：管理远程日志段的生命周期，包括复制、清理和获取。
RemoteStorageManager：管理远程日志段的操作，包括复制、获取和删除。与远程日志段关联的元数据包括有关段的开始和结束偏移量、时间戳、生产者状态快照和领导者纪元检查点的信息。
RemoteLogMetadataManager 跟踪此元数据，以确保系统知道每个段的开始和结束位置，以及数据检索和管理所需的其他关键信息。
RemoteLogMetadataManager：管理远程日志段的元数据生命周期，具有强一致性。
其中RemoteLogManager作为控制组件，直接连接Broker中的磁盘来检索读取的数据。它还负责回调远程数据。 RemoteStorageManager是对数据进行操作的实体，RemoteLogMetadataManager负责管理元数据。
Kafka分层存储中的三个动作总结
将段复制到远程存储
如果日志段的结束偏移量（段中最后一条消息的偏移量）小于分区的last-stable-offset，则认为该日志段有资格复制到远程存储。（Last-Stable-Offset (LSO)：最高偏移量所有先前的消息都被所有同步副本完全确认，确保不会丢失数据。）RemoteStorageManager 处理日志段及其关联索引、时间戳、生产者快照和领导者纪元缓存的复制。清理远程段
通过专用线程池计算符合条件的段，定期清理远程数据。这与本地日志段的异步清理不同。删除主题时，远程日志段的清理是异步完成的，不会阻塞现有的删除操作或重新创建新主题。从远程存储中获取段
RemoteLogManager 通过使用 RemoteLogMetadataManager 查看元数据存储，根据所需的偏移量和领导纪元确定目标远程段。它使用 RemoteStorageManager 查找段内的位置并开始获取所需的数据。
