深度解读Apache Kafka分层存储架构
Apache Kafka增加了分层存储来分离计算和存储。该功能支持更具可伸缩性、可靠性和成本效益的企业架构。本文探讨了Kafka的架构、用例、好处，以及在Kafka提交日志中存储pb级数据的案例研究。最后讨论了为什么分层存储不能取代其他数据库，以及Apache Iceberg如何进一步改变未来的Kafka架构。
让我们定义计算、存储和分层存储这三个术语，以便在数据流平台Apache Kafka的上下文中有相同的理解。
计算系统的两个基本组成部分是计算和存储。它们在信息处理中有不同的用途。
计算是指计算机系统执行任务、执行指令和进行计算的处理能力和能力。计算组件包括CPU (Central Processing Unit)和GPU (Graphics Processing Unit)。
存储是指长期存储和检索数据的组件和系统。它是持久维护数据以供以后使用的地方。存储包括硬盘驱动器(hdd)、固态驱动器(ssd)等设备，以及其他类型的非易失性存储器，例如即使在断电时也能保存数据的数据库。
分层存储是指一种基于访问模式、性能要求和成本考虑，使用不同的存储类或存储层(例如S3上的对象存储)来高效管理和存储数据的存储架构。
分层存储的目标是根据数据的特性和组织的策略，将数据放在最合适的存储介质上，从而优化存储资源的使用，平衡性能和成本。
可以根据分析使用模式、访问频率和其他因素的策略和算法，自动在这些层之间放置和移动数据。这确保了最关键和频繁访问的数据驻留在高性能存储中，而不太关键或不经常访问的数据被移动到成本更低、性能更低的存储中。
Apache Kafka是一个开源的分布式流平台，用于构建实时数据管道和流应用程序。Kafka是数据流的事实标准。事件流平台处理大量数据，提供可伸缩和容错的架构。
应用程序和数据存储使用Kafka来摄取、存储和处理实时数据流，使其成为构建事件驱动架构和需要处理连续数据流的系统的基本组件。此外，许多用例不仅利用Kafka来获取实时数据，还利用Kafka来确保实时、批处理和请求-响应api之间的数据一致性。
虽然大多数人认为Kafka是一个消息代理、实时分析平台或大数据摄取系统，但具有排序保证和时间戳的分布式提交日志支持大量用例，可以在数据创建很久之后访问数据或重放历史数据。
以下是一些在Kafka中利用数据长期存储的用例:
新使用者：部署新的应用程序/数据库/数据仓库、数据湖，并同步业务对象的状态。
卸载：通过不再一次又一次地从昂贵或不可扩展的系统(例如，大型机和MIPS)中消耗来显著降低成本。
错误处理：在修复业务逻辑中的问题后重新处理历史数据。
遵从性/法规处理：重播历史数据以分析事件。
查询和分析现有事件：使用笔记本中的数据进行数据工程、分析或报告。
分析平台中的模式更改：在更新数据契约后重新处理数据。
模型训练：批量摄取到AI框架中，以应用机器学习算法
灾难恢复：在发生故障时，操作数据存储持久性提交日志中的重播数据。
在Kafka中长期存储数据有一些缺点。以下论点是合理的担忧:
成本:在附加磁盘上存储大量数据比对象存储等外部存储系统要昂贵得多。
可伸缩性:操作具有大量数据(例如许多GB，甚至TB，甚至更多)的Kafka代理是具有挑战性的，特别是在需要重新平衡分区时出现故障的情况下。
风险:如果操作遇到大容量或需要迁移硬件时，会发生停机或数据不一致。
因此，你不应该在没有分层存储的Kafka中存储大数据集！考虑到这一点，让我们探索一下Kafka的分层存储是如何解决这些问题的。
Apache Kafka的后端是一个运行Kafka代理的分布式系统。每个Kafka代理都有处理和存储能力。
应用程序是事件的生产者和消费者。许多接口与Kafka代理通信：
用Java、Python、c++、Go或任何其他编程语言编写的应用程序；
Kafka Connect源连接器或接收连接器，连接到IBM MQ、Spark、Snowflake或任何其他数据存储或SaaS应用程序；
使用Kafka原生Kafka Streams、KSQL或外部基础设施(如Apache Flink)构建的流处理器；
任何其他端点，如HTTP接口或另一个中间件或数据平台的开箱即用集成。
Apache Kafka的分层存储是指根据Kafka代理中存储的数据的访问模式和需求，配置不同的存储层来优化存储基础设施的能力。
Kafka集群将数据存储在Kafka主题中。这些主题在重要性、访问频率和保留策略方面可能具有不同的特征。
这个概念类似于存储系统中分层存储的一般想法，但它适应了Kafka的特定需求。分层存储是使Kafka架构云原生的一个关键因素。
Kafka应用程序与逻辑Kafka主题通信，以产生消息到分区或从分区消费消息：
存储是连接到代理的磁盘。这可以是本地的HDD或SDD磁盘，也可以是AWS云上的EBS卷。
Kafka的分层存储不会改变应用程序与Kafka代理的通信方式。分级存储是一个实现细节：
除了连接到磁盘外，Kafka还将数据卸载到外部存储。大多数情况下，这是一个对象存储，如Amazon S3、Azure Blog storage、Google Cloud storage或Kubernetes的MinIO。
无服务器云产品为运营商处理卸载。自管理解决方案允许运营商为每个Kafka Topic配置冷热存储持续时间。
让我们回顾一下上面讨论的在Kafka中长期存储大数据集的反对意见，以及分层存储的帮助:
降低成本:大多数数据被卸载到外部存储。这大大降低了存储成本。
改进的可扩展性:只有连接到Kafka的磁盘上的数据必须重新平衡。由于大多数数据被卸载，重新平衡只需要几秒钟或几分钟，即使外部存储节省了数pb。
降低风险:更好的可伸缩性和计算与存储的分离使操作更容易，并显著降低停机或数据不一致的风险。
Apache Kafka的分级存储可用。但是，要注意不同的实现具有不同的特性、成熟度和支持级别。
开源Apache Kafka只提供分层存储的接口。您必须选择开源实现，将自己的集成构建到外部存储系统中，或者利用将分层存储嵌入到其产品中的商业产品或云服务。
请记住，界面本身是没有帮助的。实现需要经过实战测试，并保证代理上的热存储和外部存储中的冷存储之间的数据一致性，即使在出现故障、网络问题等情况下也是如此。
Kafka的消费者看不到Kafka分层存储的实现细节。他们只是消费，就好像没有分层存储实现一样(并且仍然期望相同的行为)。Kafka客户端应用程序不需要更改API或代码。因此，您可以轻松地将现有部署迁移到利用分层存储的Kafka集群。
很多人问Kafka分层存储对性能的影响。简短的回答是:对大多数场景没有性能影响。实时使用者像以前一样从内存/页面缓存中消费。重播事件日志中的历史数据与本地磁盘或远程对象存储没有太大区别
在撰写这篇博文时(2023年12月)，KIP-405: Kafka分层存储在Apache Kafka 3.6中作为早期访问可用。这个版本为Kafka引入了分层存储。此版本仅适用于非生产环境(有关更多信息，请参阅早期访问说明)。
这一功能的遗传只是一个可预见的时间问题。KIP-405的大部分是3.6版本早期访问的一部分。但是还有一些额外的特性将会在3.7中出现。GA可能在3.8+中紧随其后。
KIP-405提供可插拔的分级存储API
KIP-405在Kafka代理中分离计算和存储，在Kafka分层存储中本地实现可插拔存储分层，以最小的操作更改为远程对象带来无缝存储扩展。
Apache Kafka的LocalTieredStorage默认实现是一个基于本地文件的RemoteStorageManager。LocalTieredStorage有助于在测试期间在受控和隔离的环境中模拟远程存储行为。这并不适用于生产用例!企业需要编写自己的实现，嵌入开源替代方案，或者信任软件供应商或云服务。
KIP-405仅在Kafka 3.6的预览版中可用。然而，一些专有实现在生产中已经存在多年。这也有助于通过在生产环境中使用分层存储运行Kafka的经验教训来定义KIP。
Kafka分层存储的实现细节各不相同，可能有不同的方法或工具可以实现这一点，这取决于所使用的特定Kafka分布或存储基础设施。组织也可以使用外部系统或云存储解决方案来实现Kafka的分层存储策略。
Confluent率先为Kafka提供了分层存储，并且已经提供了几年的能力。它可用于自管理的Confluent平台和AWS、Azure和GCP中的完全管理的Confluent云。Confluent选择S3接口来实现对云提供商(AWS、Azure、GCP)和一些内部部署解决方案(如PureStorage Flash Blade、Nutanix Objects、Netapp对象存储、Dell EMC ECS、日立内容平台对象存储或Kubernetes的MinIO)的存储支持。
在开源Apache Kafka中率先实现KIP-405的Uber，在HDFS上运行它的分层存储。Confluent和AWS为重构、最佳实践和性能/集成测试做出了贡献。Uber数据和流媒体基础设施的技术主管Satish Duggana在Current 2023的一次演讲中介绍了这些技术的实施和部署细节。
其他供应商，如AWS的MSK和Aiven，现在也在采用KIP-405，并提供他们自己的分层存储实现。
KOR是一个云原生的全球贸易存储库和监管报告服务家族，采用了Confluent Cloud和数据流架构来改进合规流程。
监管报告显然是Kafka中分层存储重播历史数据的完美用例。由于Kafka日志提供了有保证的排序和时间戳，因此除了Kafka之外，不需要另一个数据库或数据湖。
KOR Financial首席数据官Daan Gerits在Diginomica上解释说:“在KOR Financial，我们有一个非常具体的问题，我们正在努力解决，那就是为监管机构收集交易信息。我们决定用一种与大多数人完全不同的方式来做这件事。当其他人使用数据存储或大数据技术时，我们决定全力投入Kafka。我们正在构建我们的系统，在Confluent cloud中存储160pb，然后在此基础上工作。我们没有其他的数据库。所以这是一个长期留存的用例。”
Apache Kafka是一个数据库。它提供ACID保证。数百家公司将Kafka部署在关键任务部署中，包括事务性工作负载。然而，大多数时候，Kafka与其他数据库没有竞争优势。
Kafka是一个事件流平台，用于实时大规模的消息传递、存储、处理和集成，零停机和零数据丢失。几乎所有的部署都将Kafka连接到数据库源和汇，以实现数据集成、解耦和数据一致性，其中云原生企业架构的核心是实时、可扩展和可靠的。
Apache Kafka是对数据库、数据仓库、数据湖和Lakehouse架构的补充。
Apache Kafka对分层存储的采用才刚刚开始。许多团队将在Kafka中存储(一些)数据更长时间，以便从昂贵的系统中卸载数据，或者在不需要另一个数据库的情况下重播历史数据。
然而，大多数分析平台并不使用Kafka协议来消费和查询数据。大多数数据平台的趋势是将Apache Iceberg作为一个标准化的抽象层，用于在对象存储或其他存储中存储和查询(非实时)数据。
Apache Iceberg是一个开源的大数据表格式和处理框架。它旨在提供两方面的最佳效果:传统表格式的性能和模式即读方法的灵活性。Iceberg提供分布式存储环境中管理大规模和不断发展的数据集的解决方案。
Apache Iceberg支持流行的数据处理框架，如Apache Spark、Apache Flink、Apache Hive、Presto等。有了Kafka的分层存储，特别是一些供应商对S3的支持，我可以看到它如何改变整个游戏规则，用Kafka协议或其他分析引擎和数据库以接近实时或批处理的方式实时存储和处理事件。
未来会告诉我们。现在，让我们为Kafka的分层存储如何成为数据流的下一个大事件而兴奋吧。
Apache Kafka的分层存储使事件驱动的架构更具可扩展性、成本效益和可靠性。它支持过去需要另一个数据库或数据湖的新用例。
然而，Kafka的目标仍然不是取代其他数据和分析平台。像微服务和数据网格这样的设计模式实现了应用程序和数据存储的真正解耦。Kafka提供了这种解耦。考虑到分层存储可用于各种用例(如卸载、新消费者或错误处理)，可以考虑针对云原生企业架构的新方法。