Kafka分层存储来袭！🚀 通过本地热存储+云对象存储，大幅降低成本，解锁海量历史数据分析。现有应用无需修改，即可享受“时间旅行”般的数据回溯，助力ML模型训练、A/B测试和灾难恢复。关注访问模式，优化配置，让你的Kafka集群更上一层楼！
译自：Store More, Pay Less: Welcome to Kafka Tiered Storage
作者：Anil Inamdar
长期 Kafka 用户都熟悉一个众所周知的难题：随着应用程序的扩展和数据的累积，数据会不断增加。数据存储并非免费，最终，当您必须决定是保留所有历史数据还是保持实际的存储成本时，关键时刻就到来了。
Kafka 的分层存储 的出现通过第三种选择消除了这种困境：为什么不两者兼得呢？
借助分层存储，这个流行的开源分布式事件流平台现在可以自动将数据拆分为两层：一层通过在本地存储最近的和关键的热数据来提供高性能，另一层将历史数据放置在低成本的云对象存储中。
分层存储改变了组织大规模利用 Kafka 的方式，从而支持新的用例，同时简化操作并确保更长期的数据一致性。以下是它的工作原理以及为什么它对每个数据密集型 Kafka 部署来说都是一个游戏规则改变者。
Kafka 分层存储保留了平台的核心语义和 API，允许现有的应用程序及其 Kafka 生产者和消费者无需修改即可运行。该架构用作直写缓存。数据最初会存储在本地存储上，然后在段关闭后异步复制到远程存储。消费者可以根据需要从本地或远程存储无缝读取，而底层复杂性已被完全抽象化。
随着组织的增长，他们的数据积累会加速，并最终达到仅仅扩展代理存储在财务上变得不可持续的地步。云对象存储 的成本仅为高性能 SSD 的一小部分，这使得分层存储的经济理由对财务利益相关者来说立即具有吸引力（换句话说，Kafka 分层存储会让您的 CFO 感到高兴）。与此同时，技术团队获得了强大的新功能，可以进行以前成本高昂的历史数据分析和重新处理。
虽然 Kafka 一直使企业能够通过其数据流“时间旅行”，从而释放关键的见解和能力，但历史数据保留的高成本严重限制了此功能的作用范围，直到现在。
Kafka 分层存储使跨越多年历史数据的扩展时间旅行在经济上可行，从而开创了变革性的机会。团队现在可以使用完整的历史数据集（而不是样本）来训练机器学习 (ML) 模型，执行到新接收器系统的无缝迁移，并对所有过去的交易执行全面的合规性审计。
此功能还有助于实现应用程序开发实践的现代化。工程团队可以通过恢复到引入之前的确切状态来解决错误，即使在事后几个月也是如此。应用程序可以使用针对历史数据的并行处理管道进行彻底的 A/B 测试。
时间转移操作（例如使用历史运营数据运行准确的假设情景模拟）现在已成为实际的用例。即使是灾难恢复策略也在不断发展，因为组织可以使用更经济的冷数据存储来替代昂贵的热基础设施副本，这种冷数据存储可以在需要时快速部署在新的 Kafka 集群上。
分层存储意味着保持对任务关键型数据的无缝高性能访问。也就是说，一些明智的调整也可以优化访问冷云存储中的历史数据时的性能。
保留策略应该是您的分层存储策略的一个缩影，将经常访问的数据保存在本地，并将远程存储用于不太常用的数据。远程复制是异步发生的，这意味着 Kafka 生产者将像往常一样运行。但是，您应该将集群 CPU 和网络资源增加大约 10%，以便更好地执行这些分层操作。
在规划要提供的容量时，Kafka 分层存储也改变了等式。根据 NetApp Instaclustr 的基准数据，从热本地存储读取通常比从远程云存储读取快两到三倍，而小段大小的降级高达 20 倍。为了保持正确的容量，请分离工作负载并确定您的生产者输入速率、消费者模式和要在本地存储的数据。 关注访问模式，而不是总的数据量，将有助于确定本地保留的最佳大小。调整主题大小，以最好地服务于高性能访问云存储数据所需的并行处理，同时请记住，分区计数会极大地影响读取性能。增加处理历史数据的主题的分区数，将通过允许更多消费者同时读取数据来提高冷存储吞吐量。如果您想深入了解 Kafka 分层存储的大小调整，我的 Instaclustr 同事 Paul Brebner 的文章可以满足您的需求。
Kafka 分层存储代表了 Kafka 向隐形基础设施演进的第一步，使开发团队从存储管理问题中解放出来，从而专注于业务逻辑和应用程序开发。通过自动执行有关数据保留和放置的复杂决策，分层存储使企业能够专注于从其数据中提取价值，而不是管理其底层基础设施。
未来的 Kafka 版本可能会继续沿着这个轨迹发展，进一步自动化运营，同时进行优化以满足组织日益复杂的数据管理需求和快速扩展的需求。