在数据驱动决策的时代，企业数据管道正承载着前所未有的压力。作为事实标准的流处理平台，Apache Kafka面临着数据保留周期从数天向数月甚至数年延伸的挑战，这直接导致了本地SSD/HDD存储成本的指数级增长。Apache Kafka 4.1分层存储Tiered Storage 的推出，正是为了攻克这一核心痛点。其核心价值在于，它首次在Kafka架构中实现了计算（Broker）与存储的物理分离，允许将较旧的、访问频率低的日志段（Log Segments）透明地卸载到更廉价的对象存储（如AWS S3、Azure Blob、GCP GCS）中，而无需迁移数据或更改客户端应用，从而在不牺牲数据可访问性的前提下，实现存储成本的数量级下降。
一、 传统架构之痛：为什么我们需要分层存储？
在Kafka 4.1之前，所有数据（无论新旧热冷）都存储在Kafka Broker的本地文件系统中。为了实现长期数据保留，只有两种选择：一是纵向扩展，为每个Broker添加昂贵的本地磁盘，这导致成本高昂且运维复杂；二是使用“抽数据到数据湖”的Lambda架构，将Kafka数据定期复制到HDFS或S3，但这破坏了数据的统一视图，增加了链路复杂度和查询延迟，并使得Kafka的精确一次语义等核心优势无法贯穿整个数据生命周期。
Apache Kafka 4.1分层存储Tiered Storage 从根本上改变了这一范式。它引入了“本地层”（Local Tier）和“远程层”（Remote Tier，即对象存储）的概念。活跃的、正在写入和最近写入的数据（热数据）仍然保留在Broker本地的高性能存储上，以确保低延迟的生产和消费。一旦日志段满足特定条件（如基于时间或大小），它就会被密封，然后由后台线程异步、高效地上传到配置的对象存储中，并从本地磁盘安全删除。当消费者需要读取这些历史数据时，Kafka能自动、透明地从远程层获取，对客户端完全无感。这一设计完美平衡了性能与成本。
二、 核心机制解析：透明卸载与无缝获取如何实现？
这一看似魔法般的特性，背后是一套精密的工程实现，主要围绕三个核心组件：
1. 日志段生命周期管理与分层策略：Kafka的日志管理器被增强，为每个分区维护一个双层日志段清单。当本地层的日志段滚动（roll）并满足预设的“分层策略”（例如，日志段关闭后1小时）时，它会被标记为“待卸载”。此时，它不再接受新写入，但依然可以从本地服务读取请求。
2. 远程存储管理器与高效上传：这是一个新增的后台服务，负责将待卸载的日志段（包括其索引和时间索引文件）高效、可靠地上传到远程对象存储。它采用了分批和压缩上传等优化手段，并确保上传过程不影响Broker的核心I/O性能。上传成功后，远程存储管理器会更新元数据，将该日志段的物理位置指向对象存储的URI，然后删除本地副本，释放宝贵的本地磁盘空间。
3. 透明读取与缓存层：这是对客户端“无感知”的关键。当Fetch请求（来自消费者或Follower副本）的目标数据段已被卸载到远程层时，处理该请求的Broker（称为“读取代理”）会首先检查本地缓存（如果启用）。若未命中，则它会扮演一个“客户端”的角色，从对象存储中拉取所需的数据范围。这个过程对原始请求者是透明的，它仍然像从本地磁盘读取一样收到数据。在 鳄鱼java 社区的早期性能测试中，对于顺序读取历史数据的场景，这种透明获取带来的额外延迟在配置良好的网络下通常是可接受的，尤其考虑到它节省的巨大成本。
三、 成本与收益量化：从理论到实践的数字革命
让我们用具体的数字来感知其颠覆性。假设一个中等规模的Kafka集群，每日新增数据1TB，数据保留策略为90天。
传统模式：需要预留至少90 TB的本地高性能存储（通常采用SSD或高速HDD）。以每TB月度成本约100美元（云上SSD托管磁盘）计算，仅存储成本每月就高达9000美元。
启用分层存储后：假设将7天内的数据保留在本地层（热数据），其余83天的数据存储在对象存储（冷数据）。本地层存储成本约为700美元/月。对象存储成本极低，以AWS S3标准存储为例，每GB每月约0.023美元，83TB数据每月成本仅约1900美元。总存储成本降至约2600美元/月，成本降低超过70%。如果保留策略延长至1年，成本优势将更加惊人。此外，由于本地磁盘压力骤减，Broker故障恢复和集群再平衡的速度也会显著提升。
四、 核心应用场景：不止于降本
除了显著的降本，Apache Kafka 4.1分层存储Tiered Storage 还解锁了多个关键场景：
1. 真正的流批一体存储层：Kafka Tiered Storage使同一个Kafka主题可以同时服务于低延迟的实时流处理（处理热数据）和回溯历史的大规模批处理作业（直接消费存储在S3上的冷数据）。这简化了架构，避免了向数据湖的复杂ETL过程。
2. 无限数据保留与全球数据共享：企业可以以极低的成本将关键事件流数据永久保留在Kafka中，用于合规审计、模型再训练或历史事件回放。同时，存储在云对象存储中的数据可以被不同区域的Kafka集群（甚至是其他计算引擎）直接访问，促进了数据的全球可用性。
3. 更敏捷的集群运维与弹性伸缩：Broker本地磁盘不再成为制约集群扩展和数据保留的瓶颈。运维人员可以更自由地调整Broker数量、进行版本升级或硬件更换，而无需担忧海量数据迁移带来的停机时间。
五、 部署考量与最佳实践初探
尽管优势巨大，但在生产环境部署前需谨慎规划。根据 鳄鱼java 架构师团队的分析，以下几点至关重要：
1. 网络带宽与延迟：Broker与对象存储之间的网络必须足够可靠且带宽充裕，尤其是在数据回填（fetch）时。建议在相同云区域内部署Broker和对象存储桶，以最小化延迟和成本。
2. 分层策略调优：需要根据业务访问模式精细配置`log.segment.ms`和`local.retention.ms`等参数。例如，对延迟敏感且需要频繁回溯最近几个小时数据的消费者，应适当延长本地保留时间。
3. 监控与告警：需密切关注远程存储管理器的上传/下载队列积压、对象存储的API请求成本和速率限制，以及消费者在读取远程数据时的延迟百分位数（如P99）。
六、 总结与展望：数据基础设施的新范式
Apache Kafka 4.1分层存储Tiered Storage 不仅仅是一个新功能，它代表了现代数据基础设施向“存算分离”和“成本感知”演进的明确趋势。它巧妙地将Kafka的流处理核心能力与云原生对象存储的无限规模和低廉成本相结合，为解决长期数据保留这一经典难题提供了优雅的一站式方案。
对于所有依赖Kafka的企业而言，现在是时候重新评估数据保留策略和总体拥有成本（TCO）了。分层存储的引入，迫使我们去思考一个更根本的问题：当存储成本不再构成主要障碍时，我们是否应该更激进地保留所有原始数据流？这是否会进一步推动事件溯源架构的普及，并催生出基于完整历史数据的、全新的分析和应用模式？这项技术或许正在悄然拉开数据驱动业务下一个时代的序幕。你，准备好迎接这个存储近乎免费的数据流世界了吗？
版权声明
本文仅代表作者观点，不代表百度立场。
本文系作者授权百度百家发表，未经许可，不得转载。
