分层存储救不了Apache Kafka

Richard Artoul 所著

分层存储是数据流系统领域中的一个热门话题，这有充分的理由。云磁盘非常昂贵，对象存储则便宜得多，并且在大多数情况下，实时读取数据的应用程序仅读取最近写入的数据。将历史数据存储在昂贵的云磁盘上不经济，因此历史数据应移至对象存储。从理论上讲，这样做非常合理。

免费注册WarpStream试用(https://console.warpstream.com/signup/?utm_source=medium&utm_medium=blog&utm_campaign=smg)

但首先，分层存储在流处理系统中具体来说，意味着什么？基本思想是只将最近的数据保存到磁盘，并将历史数据异步移动到对象存储中，在那里可以廉价地存放。

分层存储运作。

此优化在Kafka的主要扩展维度是存储的场景中特别有用，比如您需要长时间保留主题时。在这些场景中，分层存储可以显著减少所需的EBS卷数量，从而显著降低您的成本。

从理论上讲，分层存储也应该通过减少每个代理本地磁盘上的数据存储量来减轻运营负担，这（与其他好处一起）应该使集群的扩展更快进出。有些特别热情的用户甚至乐观地认为，如果分层存储实施到位，它可以使Kafka成为一个现代的数据湖。

关于在Apache Kafka中添加分层存储功能的兴奋情绪是可以感受到的，这很可能是由于近年来Kafka领域几乎没有什么创新，但用户对现状的成本、复杂性和运营负担仍然感到不满。分层存储会是大家期待已久的银弹吗？

可惜的是，答案似乎是否定的。在去年，我与数百个使用Kafka（以及其他流处理系统的用户）进行了交谈，其中很多都是世界上最大和最先进的工程组织中的成员，但我还没有找到一个对分级存储感到满意的用户。

我发现很多人对其进行了评估，意识到它并不会显著减少他们的成本，于是就不再考虑了。我还发现了一些试图采用它的人，在遇到一系列操作问题和摩擦点之后，决定不继续使用。我还发现少数人设法将其投入生产，但他们为此增添了许多白发，显然很辛苦，几乎所有人都对最终结果感到失望。

我意识到我所说的一切与行业内的普遍看法不同，所以让我解释一下我为何会有此观点。

分层存储可以在某些工作负载上降低成本，但最终却在关键问题上表现得十分短视。具体来说，在讨论Apache Kafka时，分层存储的主要问题在于它没有解决目前用户在使用Kafka时遇到的两个主要问题：

1. 复杂性及运营负担
2. 成本（特别是一些跨区网络费用）

事实上，我认为它不但 没有解决 这些问题，实际上 让这些问题变得更严重。

层级存储的第一个问题是，它并没有让Kafka变得更简单易用，反而使它更难处理和更复杂。为了适应部分数据存储在完全不同且成本和性能特性也不同的存储介质中这一事实，对现有系统，如Apache Kafka进行改造是非常复杂的。最终结果是一个非常敏感且脆弱的系统，充满了各种限制、边缘情况和意外问题。

例如，关于性能的推理变得极其复杂。考虑一个 Kafka 消费者想要从开始读取一个主题。在正常情况下，从 Kafka 获取一批数据通常只需要几十毫秒或几百毫秒。但是，当分层存储启用时，读取第一批数据可能需要几十秒甚至几分钟的时间。

这主要是因为许多分层存储方案不支持从对象存储中按需读取数据。相反，这些实现要求必须先下载整个日志段，然后才能从中读取数据。这会产生问题，因为日志段可能达到数百MiB甚至几GB的大小。在下载这些大段时，消费者将被完全阻塞，无法进行任何操作。

一些分层存储的实现支持通过分块机制进行增量读取，但是日志段的分块仍然需要在从对象存储中分页读取后下载并缓存到磁盘上。将下载的分块写入磁盘会与实时工作负载竞争有限的IOPS（和磁盘空间），这意味着单个消费者少量历史数据的回放就可能轻易地扰乱所有为提供生产流量服务的实时消费者。这也意味着虽然分层存储确实减少了broker上的磁盘大小，但磁盘大小的缩减也是有限的。我们需要为实时和历史工作负载留出足够的空间来处理。

更进一步的是，这个问题变得更加严重，因为云硬盘的可用 IOPS 通常会随着配置的存储量而变化。但分层存储的主要目的就是减少需要预先配置的磁盘存储量！

像这样的问题可以通过非常谨慎的容量规划、基准测试和配置调整来解决，但这过程非常痛苦。此外，我迄今所描述的问题起初往往处于潜伏状态，然后在最糟糕的时候冒出来：当出现问题时，需要在不牺牲实时工作负载可靠性的前提下回放历史数据。

在过去的几个月里，我遇到了三个不同的组织，这些组织正在试图从分层存储数据流系统迁出，但因为无法在不影响实时流量的情况下读取分层存储中的数据，他们描述说无法迁移到新的解决方案中。读取历史数据的需求不仅仅发生在紧急情况下。

最后，可能最糟糕的是，分层存储带来的额外复杂性是累加的，除了你现在正面临的所有运营问题之外，

分区再平衡
挑剔的共识机制
性能瓶颈
缺乏弹性
热点
代理间的不平衡
等等问题

分层存储增加了新的故障模式和操作任务，同时保留了所有现有的。

保持不变的区网络

撇开运营不谈，分层存储还承诺降低Kafka的总成本。不幸的是，它通常也无法实现这一承诺，而原因可能让你意想不到：云网络的成本。

如果你认为云磁盘很贵，那么云网络的费用会让你大吃一惊。跨区域网络费用是数据流工作负载的隐形杀手，这会让你感到意外。具体来说，在标准高可用 三可用区设置下的Apache Kafka集群中，每GiB数据的写入成本为5.3美分。相比之下，将GiB的数据存储在S3一个月的成本仅为2美分。

运行在三个可用区的标准HA Kafka集群的数据流。

那么，分层存储是如何帮助减少跨区域网络成本的呢？不过，它完全做不到这一点。为了确保高可用性和数据持久性，你在启用了分层存储的集群中写入的所有数据仍然必须被复制到三个不同可用区的三个磁盘中，在被确认并被视为持久之前。分层操作则在之后进行。这确实是一个大麻烦，因为跨区域网络成本通常占流处理工作负载总成本的80%以上。

这意味着无论经纪人的本地磁盘有多大限制，或者分层存储实现将数据复制到对象存储的速度有多快，都不会影响，对于任何不是存储密集型的工作负载，使用分层存储架构的流处理系统通常花费几乎与传统的Kafka集群一样多，即使数据只在本地磁盘上存储一分钟。

好吧，也许分层存储并没有节省你预期那么多的钱，性能也不太稳定，但是你可以为EBS卷配置专用的IOPS，进行一些非常谨慎的演练，并测试一切是否按预期运行。这确实稍微复杂一些，但好处绝对是值得的，对吗？毕竟，分层存储不仅仅是为了降低成本，它还让你能够做一些新的事情。

例如，由于所有的数据都存储在对象存储中，理论上讲，你也可以直接对这些数据运行批处理作业/查询，完全绕过代理。看，现在你的数据流式变成了数据湖。

这当然有用，如果能做到的话，但在实际情况中却不行。对象存储中的数据正被代理主动“管理”（如合并、强制保留等），因此直接查询数据文件会导致异常：缺少和重复的记录，尤其是因为缺少快照隔离。除非你能找到一种方法，在代理磁盘和对象存储之间提供单一视图，否则你只能查询热数据集以外的数据，这意味着你只能查询已过时的数据。

你仍然可以使用Kafka API查询所有的数据，但实际上，你将受到托管你想要查询的主题分区（topic-partitions）的代理的最大吞吐量限制。例如，如果你只想查询一部分主题，并且这些主题只由一部分代理托管，你可能只能利用集群总容量的小部分来运行查询，因为其他代理都空闲着。

从理论上讲，当你需要扩展读取容量时，你可以暂时将一些broker标记为特定主题分区的“读取副本”，这样它们将拥有分层到对象存储的数据及其元数据，并处理读取请求，但不参与任何领导选举，并且你需要确保它们不会复制尚未将数据分层到对象存储中的内容，以避免浪费过多的磁盘空间，这听起来开始像是相当多的工作。

我并不是唯一一个对此感到失望的人。在流媒体领域，许多用户和专家对分层存储的虚假承诺感到失望。他们开始意识到，分层存储并非他们所期望的灵丹妙药。因此，许多系统和供应商选择了较为容易的道路：改头换面。

以下是一些短语需要留心：

1. “云优先的存储”（分级存储）
2. “接近无状态”（分级存储）
3. “将磁盘用作对象存储服务之前的缓存”（分级存储）

这些术语都只不过是分级存储的伪装。我在这篇文章中写过关于这一点，但这一点值得再次强调：对于现有玩家而言，对现有产品进行小幅改进，然后重新包装和重新定义品牌比真正为用户着想要容易得多：从零开始重新构建云服务。

希望现在你（们）已经确信，虽然分层存储确实有一些优点，比如可以降低特定工作负载的存储成本，但它并没有像承诺的那样带来革命性的改进。虽然它可能会减少一些成本，但它肯定不会让操作更简单或让生活更轻松。实际上，它会使你的Kafka工作负载变得更加不可预测和难以管理。

我将以这些话结束。分层存储主要就是使用 较少 的磁盘。但是，如果你能够从头开始构建流媒体，你将实现 零磁盘。从 有些 磁盘到 完全没有 磁盘的区别，就像白昼和黑夜。零磁盘，所有的内容都直接通过对象存储运转，没有中间磁盘，会更好。好很多。不过这些内容下次再详细讨论。

创建一个免费的WarpStream账户并享受$400的免费信用额度，开始流媒体。立即注册!

由于没有提供源文本或翻译内容，无法进行详细的分析和修改。请提供相关内容以便进一步处理。