Kafka 已死，Kafka 万岁

by Richard Artoul

WarpStream 是一个直接构建在 S3 之上的 Apache Kafka® 协议兼容的数据流平台。它作为一个单一的无状态 Go 二进制文件交付，因此无需管理本地磁盘，无需重新平衡代理，也无需操作 ZooKeeper。由于数据直接从 S3 读取和写入，而不是使用跨区域网络，因此 WarpStream 在云端比 Kafka 要便宜 5 到 10 倍，因为在大规模部署中，跨区域网络的成本可能超过 Kafka 部署基础设施成本的 80%。

如果你只想动手试试，可以在30秒内尝试我们的演示。

**$ curl https://console.warpstream.com/install.sh | bash** **$ warpstream demo**

注册免费的WarpStream试用

否则，请继续阅读！

很可能你对这篇帖子的标题有强烈的反应。根据我们的经验，Kafka 是数据领域中最具争议的技术之一。有些人讨厌它，有些人则对其赞不绝口，但几乎每一家科技公司都在使用它。

Apache Kafka® 于 2011 年首次开源，并迅速成为构建流处理架构的默认基础设施。Jay Kreps 的著名博客文章《The Log》（日志）至今仍是我最喜欢的博客文章之一，因为它详细解释了 Kafka 提供的分布式日志抽象为何如此强大。

但现在已经不是2011年了。我们构建现代软件的方式发生了很大变化，主要转向了云环境，而Kafka却基本上没有什么改变。许多组织已经成功地将Kafka迁移到了云环境中，但说实话，没有人对结果感到满意。Kafka成本高、难以管理，大多数使用它的组织都觉得运行起来很困难。

Kafka 本身并不是问题。它是一款非常适合其创建环境的优秀软件：2011年 LinkedIn 的数据中心。然而，由于两个原因，它对于现代工作负载来说是一个异常不合适的工具：

1. 云经济学 — 由于设计原因，Kafka 的复制策略会产生大量的跨可用区带宽成本。
2. 运维开销 — 运行自己的 Kafka 集群实际上需要一个专门的团队和复杂的自定义工具。

在这篇文章的剩余部分，我们将重点讨论Kafka，但请记住，我们对Kafka所说的一切同样适用于任何在本地磁盘上存储数据（即使只是短暂存储）的类似系统，无论它用哪种编程语言实现。

下面的图描绘了一个典型的具有3个可用区的Kafka集群：

每个GiB的数据必须有2/3的时间跨区写入1，然后由分区领导者将其复制到其他两个区域的跟随者中，以确保数据的持久性和可用性。每次GiB的数据跨区传输时，成本为$0.022，其中源区域的出站费用为$0.01，目标区域的入站费用为$0.01。

$0.01⅔ + $0.02 2 == $0.053，这是你在最佳情况下通过Kafka集群流式传输每GiB数据的成本。将GiB数据存储在S3中一个月的成本仅为$0.0214，因此以通过Kafka从生产者复制数据到消费者的价格，你可以将这些数据存储在S3中超过两个月。实际上，对于任何具有大量吞吐量的Kafka集群，硬件成本可以忽略不计，因为工作负载成本的70–90%只是跨区域带宽费用。Confluent对此问题也有很好的说明。

重要的是要强调，这种跨可用区带宽问题是由Kafka的工作原理决定的。Kafka最初是为LinkedIn的数据中心设计的，在那里网络工程师不会向应用程序开发人员收取移动数据的费用。但今天，大多数Kafka用户都在公共云上运行它，这是一个有着完全不同限制和成本模型的环境。不幸的是，除非你的组织每年能投入数千万甚至数亿美元用于云服务，否则你无法逃避这个问题的物理限制。

这不仅仅是吞吐量的问题，即使吞吐量较低的Kafka集群，如果数据保留时间较长，也可能有较大的存储需求。在这种情况下，Kafka通过在昂贵的本地SSD上三重复制数据，其成本大约是使用像S3这样的对象存储的10-20倍5，假设在最佳情况下磁盘利用率为100%。

大多数开发人员最初遇到 Apache Kafka® 是因为他们想要解决一个实际问题。然而，在他们开始解决问题之前，他们必须首先了解以下内容：

1. Kafka（代理、协调器、水印等）
2. ZooKeeper（或 KRaft）
3. 领导者选举
4. 分区（我需要多少个分区？不清楚，但最好设置正确，因为一旦设置就不能更改！）
5. 消费者组
6. 重新平衡
7. 代理调优
8. 客户端调优
9. 等等

Kafka的“数据平面”（代理）和基于共识的“控制平面”（控制器、ZooKeeper等）都直接运行在需要精心管理和维护的本地SSD上。实际上，自托管的Kafka集群需要一个专门的专家团队，并且需要大量的定制工具，才能安全可靠地执行基本操作，例如节点替换和集群扩展。例如，Apache Kafka内置的分区重新分配工具甚至无法生成在硬件故障（不可避免地发生）时退役代理的计划：

当前，分区重新分配工具尚不具备自动生成下线Broker的重新分配计划的能力。因此，管理员需要自己制定一个重新分配计划，将要在下线Broker上托管的所有分区的副本移动到其余的Broker上。这可能会相对繁琐，因为重新分配需要确保所有副本不会从下线的Broker移动到仅一个其他的Broker上。

在许多情况下，将集群管理委托给像AWS MSK这样的托管提供商甚至无法解决运营负担问题。例如，MSK关于如何平衡集群的文档（一个非常常规的操作）只是链接到了Akka Kafka文档，该文档涉及手动编辑JSON来指定哪些分区应该迁移到哪些代理，并包括了诸如以下这样的有用评论：

分区重新分配工具没有自动研究Kafka集群中的数据分布并将分区移动到达到均匀负载分布的能力。因此，管理员需要确定哪些主题或分区需要移动。

有一些开源解决方案，比如Cruise Control，可以帮助减轻这种负担，但这也意味着需要学习另一套概念，部署和监控另一组服务，并且会遇到一些棘手的问题。Cruise Control 本身是一个依赖于 Apache Kafka 和 ZooKeeper 的 JVM 应用程序。这绝对不是一个轻量级的解决方案。

不幸的是，在许多情况下，开发人员原本打算解决一个业务问题，结果却变成了Kafka SRE（站点可靠性工程师）。

使用 Apache Kafka® 的高昂成本（无论是金钱还是工程小时数）意味着今天企业只能负担得起将其用于像欺诈检测和 CDC 这样最有价值的用例。入门成本对于其他任何用途都太高了。

当我们还在 Datadog 时，我们构建了 Husky，一个专门为可观察性数据设计的列式数据库，可以直接运行在 S3 上。完成之后，我们拥有了一个（几乎）无状态且自动扩展的数据湖，非常经济高效，永远不会耗尽磁盘空间，并且非常容易操作。几乎一夜之间，我们的 Kafka 集群看起来与之相比变得 非常过时。

在Datadog，Kafka的带宽量以双位数GiB/s计算，而broker存储则以PiB的NVME计算。使用开源Kafka、自定义工具和裸VM来维护这种级别的基础设施绝非易事。幸运的是，Datadog的负责工程团队非常有能力，使这一切得以实现。但即使经过多年的投入，自动化仍然无法与投入数百万工时来使S3等系统变得极其稳健、可扩展、成本效益高以及弹性相比拟。

一般来说，在云环境中运行的大规模存储工作负载无法与对象存储的经济性、可靠性、可扩展性和弹性竞争。这就是为什么像Snowflake和Databricks这样的“大数据”技术甚至不尝试。相反，它们通过从底层设计围绕商品对象存储来充分利用云的经济性。

像 Uber、Datadog 等许多公司即使面对 Kafka 的所有缺点，也成功地利用了 Kafka。但是，如果现有的 Kafka 实现仍然是进入门槛，那么将会有 如此多 的有趣问题永远得不到解决。这就是我们关注这个领域的原因，也是我们致力于构建一个能让数据流基础设施像 S3 一样易于访问的东西的原因。

如果我们能够直接在 S3 上构建一个类似 Kafka 的系统，这将一举解决 Kafka 的两个主要问题；成本将大幅降低，大多数传统的 Kafka 运维难题也会瞬间消失。没有主要的云提供商会对虚拟机和对象存储之间的网络成本收费，而且 AWS 雇用了数百名工程师，他们的唯一工作就是确保 S3 可靠运行并无限扩展，因此你不必为此操心。

当然，说起来容易做起来难，而且没有人做到这一点是有充分理由的：在像 S3 这样的高延迟存储介质之上构建低延迟流处理基础设施，同时仍然提供完整的 Kafka 协议语义，并且不引入任何本地磁盘，这是一个非常棘手的问题！

所以我们问自己：“如果从头开始重新设计Kafka，让它今天能在现代云环境中运行，直接在对象存储之上运行，不需要管理本地磁盘，但仍需支持现有的Kafka协议，那它会是什么样子？”

WarpStream 是我们对这个问题的回答。

WarpStream 是一个与 Apache Kafka® 协议兼容的数据流平台，可以直接运行在任何商品对象存储（如 AWS S3、GCP GCS、Azure Blob Storage 等）之上。它不产生任何跨可用区带宽费用，无需管理本地磁盘，并且可以完全在您的 VPC 内运行。

这有很多内容需要消化，所以我们通过将WarpStream的架构与Kafka的架构进行比较来拆解它：

与 Kafka brokers 不同，WarpStream 有“代理”（Agents）。这些代理是无状态的 Go 二进制文件（没有 JVM！），它们支持 Kafka 协议。但是，与传统的 Kafka broker 不同，任何 WarpStream 代理都可以作为任何主题的“领导者”，为任何消费者组提交偏移量，或作为集群的协调者。没有哪个代理是特殊的，因此可以根据 CPU 使用率或网络带宽自动扩展它们非常简单。

如果我们使用 Apache Kafka，而 Apache Kafka 需要运行 Apache ZooKeeper（或 KRaft）以及一堆带有本地 SSD 和复制功能的状态化代理，我们是如何做到这一点的？

1. 我们将存储和计算分离（通过将数据卸载到S3）
2. 我们将数据和元数据分离（通过将元数据卸载到自定义元数据存储）

将所有存储卸载到像 S3 这样的对象存储，可以让用户在应对负载变化时轻松地扩展 WarpStream Agent 的数量，而无需进行 零数据重新平衡。它还支持更快地从故障中恢复，因为任何请求都可以立即在另一个 Agent 上重试。它还大大减少了热点问题，即由于每个分区中的数据量不均，某些 Kafka brokers 的负载会显著高于其他 brokers。这意味着你可以告别手动重新平衡分区，并且不需要了解像 Cruise Control 这样复杂的解决方案。

WarpStream 设计的另一个支柱是将数据与元数据分离，就像现代数据湖一样。我们将每个 WarpStream “虚拟集群”的元数据存储在一个自定义的元数据库中，该数据库从头开始编写，旨在以最高效和最具成本效益的方式解决这个问题。事实上，我们对元数据存储的效率非常有信心，因此我们将免费为您托管 WarpStream 虚拟集群 免费。

您可以在我们的文档中了解更多关于 WarpStream 的架构，但简单来说：WarpStream 将所有数据复制、持久性和可用性难题转移到一个对象存储桶中，因此您无需担心这些难题，但所有数据仍然保留在您的云账户内。使用 WarpStream 时，唯一离开您云账户的数据是达成共识所需的元数据，例如分区中的批次顺序。

如今希望在基础设施中引入大规模数据流处理管道的现代从业者并没有太多好的选择。他们要么需要花费大量资金 并且 组建一个专门的工程师团队，只为运行 Kafka 而工作，要么他们需要向供应商支付费用以使用托管解决方案，并且花费 甚至更多的钱 ，这使得许多流处理用例在经济上变得不可行。

我们认为 WarpStream 可以为我们提供一个更好的选择，利用云的优势而不是劣势，并在数据流领域解锁一整套新的可能性。

不过你也不必只相信我们的话，我们有收据！下面的图片显示了我们整个云账户的跨区域网络成本（使用优秀的vantage.sh进行测量），包括我们在测试环境中运行的持续流处理工作负载。这个工作负载持续产生140MiB/s的数据，并由三个专用消费者进行消费，总共实现了560MiB/s的持续数据传输。

你可以看到我们每天平均花费不到 $15 在跨区域网络费用上，而使用 Kafka 集群运行完全相同的任务，仅跨区域网络费用每天就要花费 0.14GiB $0.053/GiB 60 60 24 == $641。

我们也没有仅仅用硬件成本或S3 API成本来替代这些跨区域网络成本。同样的工作负载在S3 API操作成本上每天不到40美元：

它也只需要相当于27个vCPU的代理硬件/虚拟机。

在总拥有成本方面，WarpStream 将大多数 Kafka 工作负载的成本降低 5–10 倍。例如，这里是比较持续运行 1GiB/s Kafka 工作负载的成本与使用 WarpStream 的等效成本：

脚注7为自托管Kafka硬件成本，脚注8为自托管Kafka网络成本。请注意，此表假设最佳情况，即Kafka集群已正确配置为使用follower fetch功能来减少消费者之间的网络区域成本。如果未进行此配置，Kafka的成本会高得多。此表还忽略了自托管Kafka设置的工程师薪资成本。

上面的表格清楚地表明，对于高吞吐量的Kafka工作负载，硬件成本可以忽略不计，因为工作负载的成本主要由跨区域网络费用决定。WarpStream完全消除了这些网络费用。

当然，事情并非全是阳光和彩虹。工程设计就是权衡取舍，我们在 WarpStream 上做出了一个重要的权衡：延迟。当前实现中，Produce 请求的 P99 延迟约为 400 毫秒，因为我们从不承认数据直到它被持久化保存在 S3 并提交到我们的云控制平面。此外，我们当前从生产者到消费者的端到端数据 P99 延迟大约为 1 秒：

如果你的工作负载可以容忍大约1秒的生产者到消费者的延迟（P99），那么WarpStream可以将你的总数据流成本降低5到10倍每GiB，并且几乎没有任何操作开销。我们也没有专有的接口；它只是Kafka，所以没有供应商锁定。最后，WarpStream可以在任何具有对象存储实现的环境中运行，因此我们可以在AWS的S3、GCP的GCS和Azure的Azure Blob Storage中与你对接。

如果你已经看到了这里，你可能会注意到WarpStream主要解决了Kafka的两个主要问题：云经济学和运维开销。我们认为Kafka还有一个主要问题：开发者体验。在我们看来，分区作为抽象层次太低，不适合编写任何非简单的流处理应用程序，我们认为WarpStream的架构使我们处于一个独特的位置，能够帮助开发者以一种新颖的方式编写流处理应用程序，这种方式更接近他们习惯的传统应用程序的编写方式。

我们将在未来的博客文章中更详细地讨论这个问题，但首先我们想做的是在开发者熟悉的地方与他们见面，并为他们提供一个他们已经熟悉的工具的改进版本。

WarpStream 当前处于开发者预览阶段。这意味着你可以完全自助地注册，并遵循我们的文档开始尝试使用它。你可以在自己的笔记本电脑上本地运行 WarpStream，也可以将其部署到你的预发布环境中。WarpStream 尚未准备好用于生产环境，但如果你有兴趣在生产环境中使用它，我们非常愿意听到你的声音。你可以在discord、slack或直接通过电子邮件联系我们：founders@warpstreamlabs.com

如果你想直接上手操作，可以尝试一下我们提供的演示教程 我们的演示，只需30秒：

**$ curl https://console.warpstream.com/install.sh | bash** **$ warpstream demo**

（无内容需要翻译）

1. 因为分区领导者位于不同的区域。
2. 请参阅“AWS 区域内的数据传输”部分。
3. 最坏的情况是，您的 Kafka 集群没有配置跟随者抓取功能，并且您为每个消费者支付跨区域带宽费用。
4. https://aws.amazon.com/s3/pricing/
5. ($0.452/小时 (i3en.xlarge) 24 30)/(2500GiB) == $0.13/GiB 月。$0.13 * 3倍复制 == $0.39/GiB 月 vs $0.021/GiB 月在 S3 上
6. https://www.datadoghq.com/blog/engineering/introducing-kafka-kit-tools-for-scaling-kafka/
7. 9 * i3en.6xl + ZK
8. ($(0.04 + ((2/3) 0.02)) 60 60 24 * 365)+$223000

创建一个免费的WarpStream账户并开始使用$400的免费信用额度进行流媒体传输。开始使用!