Kafka 分层存储（Tiered Storage）是什么？什么场景值得开？
面试怎么回答
Kafka 原来数据全在 Broker 本地盘，长期保留成本高，加节点做分区迁移要搬全部历史数据，换节点恢复也慢，为了存储加 Broker 又浪费计算资源。分层存储把数据分成本地层和远程层：Segment 关闭后由 Leader 异步上传到 S3、HDFS 这类远程存储，本地只保留最近一段，用 local.retention 控制，整体保留仍由 retention.ms 控制，消费者读老数据时自动从远程拉，对客户端透明。适合要长期保留、偶尔回放，以及分区大、扩缩容频繁的场景。要注意 Compact Topic 不支持，读历史会变慢，远程存储和插件成了新依赖，要监控上传积压；不同版本限制不同，3.9 才算生产可用，上线前要充分测试。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
Kafka 的分层存储（KIP-405）从 3.6 开始提供早期版本，3.9 宣布可以用于生产。面试官问这题，想看你理不理解 Kafka 存储和计算绑定带来的问题，以及新特性的边界。
为什么需要分层存储
Kafka 原来所有数据都存在 Broker 的本地盘上，带来几个问题：
- 保留时间受限于磁盘：想把数据保留 30 天、90 天做回放，就得买大量磁盘，成本很高；
- 扩容和迁移慢：增加 Broker 后做分区重分配，要把整个分区的历史数据拷过去，几 TB 的分区要搬好几个小时；
- 故障恢复慢：Broker 换盘或替换节点，副本要从头同步全部历史数据；
- 存储和计算绑死：为了存储而加 Broker，CPU 和网络却是闲着的。
分层存储怎么做
- 数据分成两层：本地层（Broker 磁盘）存最近的数据，远程层（S3、HDFS 等）存历史数据；
- 日志段（Segment）滚动关闭后，由 Leader 异步上传到远程存储，活跃段始终在本地；
- 本地只保留一小段时间（由
local.retention.ms/local.retention.bytes控制），整体保留时间仍由retention.ms控制； - 消费者读取时如果 Offset 在本地就直接读，已经不在本地的就从远程层拉取，对客户端透明，不用改代码。
开启方式：Broker 端打开 remote.log.storage.system.enable，并配置远程存储的插件实现（Kafka 只定义了接口，对接 S3 等存储需要用社区或厂商的插件）；Topic 级别再打开 remote.storage.enable。
什么场景值得开
- 需要长期保留、偶尔回放：比如保留 30 天以上用于故障回放、重算、审计；
- 单分区数据量大、扩缩容频繁：本地数据少了，分区迁移和节点替换快很多；
- 想用更少的 Broker：Broker 按吞吐配，不再按存储量配。
不适合或要注意的地方
- Compact Topic 不支持分层存储；
- 读历史数据会变慢：从对象存储拉取的延迟明显高于本地盘，大量消费者同时回放历史时要评估远程存储的带宽和请求费用；
- 插件和远程存储成为新依赖：远程存储不可用时上传会积压，本地盘可能被撑满，要监控上传延迟和本地数据量；
- 版本差异：早期版本有不少限制（比如开启后不能关闭），要以所用版本的文档为准，充分测试后再上生产。