超越卡夫卡：与卡夫卡风格相仿的替代品正在兴起

随着Confluent收购WarpStream，Kafka的世界再次处于十字路口。如果弗朗茨·卡夫卡还活着，他可能会写一篇关于Apache Kafka在2024年的“变形记”。Apache Kafka已经开源将近15年了。当然，Kafka一直在发展，但管理和它相关的成本一直很高。在这篇博客中，Estuary的市场部副总裁罗布·梅耶和桑杰夫·莫汉探讨了Kafka的现状和未来。

卡夫卡现在还重要吗？

Kafka仍然是处理实时数据的一个流行且有效的选择，因为企业生成了大量的数据，这些数据必须实时处理、存储和分析，以保持其竞争力。它的核心优势——可靠且高吞吐量的实时流处理——继续满足跨行业的实时数据需求。

Kafka 的庞大基础设施和运营成本导致许多人提出疑问：“如果我们开发一个支持 Kafka API 的替代品会怎么样？”

该行业已经见证了多个类似卡夫卡小说中的奇异经历的替代方案，竞争也促进了创新。这些替代方案已经改变了消息传递的格局：每个 Kafka 实现及其配套技术都支持各种不同的应用场景。

我们先来简短回顾一下卡夫卡的历史。

Jay Kreps、Neha Narkhede 和 Jun Rao 在 2010 年由 LinkedIn 创作了 Kafka，以应对他们平台内部不断增长的可靠、可扩展的数据流处理需求。Kafka 在 2011 年被开源，并于 2012 年成为 阿帕奇软件基金会 的一部分，因为它具有支持大规模实时事件流处理的分布式、高吞吐量架构，迅速获得采用。2014 年，Kafka 的关键贡献者创立了 Confluent，这是一家专注于 Kafka 开发和托管服务的公司。

其设计灵感来源于像Apache ActiveMQ和Oracle的AQ这样的消息系统，结合了消息队列和日志存储的最佳方面，使其成为实时数据处理的强大而高效的工具。多年来，Kafka从一个消息系统发展成为一个功能完善的流处理平台，使企业可以处理、存储和分析实时数据流。Kafka Streams 于2016年推出，用于实时数据流处理。分层存储功能 于2020年添加，通过将存储与计算解耦，实现了更好的可扩展性和成本效益，提高了系统的灵活性。Freight Clusters 是在2024年5月最新添加的功能，它直接写入云存储，实现了真正的存储与计算的解耦。

第一个类似 Kafka 的竞争对手是 Apache Pulsar ，它是由 Yahoo 开发并于 2016 年贡献给 Apache Pulsar 项目。它支持基于日志的消息传递（类似 Kafka）和基于队列的消息传递（如 IBM MQSeries 和许多其他传统消息传递产品）。Pulsar 2.0 在 2018 年增加了分层存储，这是它首次在存储与计算解耦方面的尝试。Pulsar 还将读取服务与写入存储解耦，从而可以独立扩展，这相比 Kafka 更高效。

在2019年，亚马逊推出了基于真实Kafka代码但支持在AWS云上的Amazon Managed Streaming for Apache Kafka（Amazon MSK）。其他大型云服务商也纷纷推出了类似的服务。

2019年，Redpanda 也发布了一个与 Kafka 兼容的 API、更简单、更轻量且更快的产品。它采用单二进制架构，没有像 ZooKeeper 这样的外部依赖，使部署和管理更加容易，并降低了运营成本。它使用 C++ 编写，而 Kafka 则是用 Java 和 Scala 编写。Redpanda 还有一些其他优化，有助于其出色的性能，例如，它使用 Seastar 框架，为每个 CPU 核心分配一个线程。

红熊猫成立后不久，StreamNative 和 OVHCloud 在 2020 年 3 月 将 KoP 贡献给开源社区。KoP 使 Pulsar 代理能够支持 Kafka 协议。

Confluent 首先通过分层存储来应对这些事件。这使得 Kafka 更容易伸缩，通过将每个代理的消息存储转变为类似远程存储中的虚拟内存。这是解耦存储和计算的第一步，使 Kafka 更接近云原生。然后在 2023 年，Confluent 发布了 Kora，Kora 是 Kafka 的一个作为托管云服务的云原生版本。

但还不够。RedPanda 提供了 Confluent 没有提供的另一样东西；将原生的 Kafka 技术部署到客户自己选择的云中的能力，也就是现在大多数人所说的“携带您自己的云”（BYOC）。在 BYOC 模式中，客户可以在自己的账户中维持数据平面，而控制平面则运行在供应商的账户里。

这显然就是市场想要的那种红熊猫。红熊猫在2024年的收入增长了300%，目前估值已超过5亿美元。Confluent公司，Confluent公司在IPO时估值超过110亿美元，年收入仅增长了约25%，并在12个月内接近10亿美元，目前市值约为65亿美元。

如果有人参加了Confluent举办的名为Current的行业活动，就会发现提供实时数据解决方案的公司数量呈指数级增长。不仅这个生态系统在迅速扩张，而且正在经历转型。今年就发生了不少事情。

• 3月：Confluent 发布了 TableFlow，将 Kafka 流式传输到 Iceberg 数据库，这使得 Confluent 更直接地与数据湖和数据管理业务相关。
• 5月：Confluent 推出了 Freight Clusters，这是一种完全解耦的存储和计算方案，可以将 Kafka 的网络传输成本降低高达 90%，但会导致显著更高的延迟。
• 5月：StreamNative 发布了 Ursa，这是一种与 Kafka 兼容的流处理，支持数据湖存储。
• 9月：Confluent 收购了 Warpstream，以提供 BYOC（自带计算）服务，并可能为了消除 Confluent 的 Freight Clusters 方案的竞争对手。
• 9月：Estuary 推出了 Dekaf，用于实时分析。

Kafka 已经演化成围绕 Kafka API 和客户端协议的多个 Kafka 变体组成的生态系统，这已经不仅仅局限于 Apache Kafka 代码。事实上，它很像 PostgreSQL 生态系统，你可以根据自己的需求选择最适合的变体。

你可能在想“像 Postgres 一样？有超过 50 个 Postgres 的变种，并且它是可以分解成模块的。”但是，Kafka 的变体数量已经超过了 10 个，很多变种都非常灵活。

图1展示了Kafka变体的部分列表，这些变体随着扩展不断增加，并且在Kafka之上增加了流处理、ETL和分析所需的技术。此列表不包括提供流处理、分析和ETL功能的更大规模的事件流平台(ESP)、流分析数据库或统一实时平台(URP)的列表。关于这些平台的详细信息，请参阅解开流媒体格局：统一实时平台的兴起。在许多情况下，这些Kafka变体被用来为URP、ESP和流/分析数据库提供数据。

请留意，此图仅作示意之用。

首先，有Confluent，它有三个版本：开源的Kafka版本，Kora是他们的云原生Kafka版本，以及最近收购的Warpstream，它允许自带云。

然后就有外部的 Kafka 替代方案，像 Kora 和 Warpstream 一样。它们的出现是因为开源 Kafka 维护困难且扩展成本高昂。每家公司都以各自的方式解决了 Kafka 的一些问题。它们都值得花时间深入了解。

• Azure EventHubs — 与微软其他技术集成的消息系统，包括 Kafka 和其他消息支持
• Apache Pulsar（兼容 Kafka），以及 StreamNative、Datastax 和 OVHCloud 等供应商提供的服务
• Redpanda — 定位为更快、更便宜、更简单的 Kafka 替代方案
• Upstash — 一个集成了无服务器 Redis、向量数据库、Kafka 和基于 HTTP 的消息传递的解决方案

也有托管的Kafka服务，通常作为更大解决方案的一部分，比如：

• Aiven
• Amazon 的 Kafka 托管服务（MSK）
• Datell
• DoubleCloud
• Google Cloud 的 Apache Kafka 托管服务
• Instaclustr（NetApp）
• Keen
• OVHcloud
• Temok

这些供应商中的任何一家都可以像康尼乌特那样发布他们自己的云原生版本的Kafka，并将客户迁移到自己的云原生版本。

最后，还有一些类似于 Kafka 的技术提供了 Kafka API 的兼容性，主要是为了连接 Kafka API 生态系统，同时也简化了某些特定用例。简而言之，Kafka API 已经开始成为一个任何人都能使用的协议，无论是使用 Kafka 还是不使用 Kafka。

有几个项目是基于 Kafka 构建的，用于流处理任务（即流处理任务）（请参考图 1）。

Apache Samza 也是早期的之一。不过，它的创新理念最终促成了 Kafka Connect（用于连接）和 Kafka Streams（用于处理）的出现。Apache Flink 也成为了另一个选择。Debezium 在 2019 年首次发布，为 Kafka 添加了 CDC 数据源。

但最近，一些较少围绕Kafka的技术也开始进入Kafka生态系统。Estuary Flow是一种现代的实时数据集成解决方案。但它的起源可以追溯到Kafka早期，甚至早于Pulsar的出现。Estuary的创始人在2014年首先构建了开源的云原生消息项目Gazette。它是最早将消息日志（它称之为集合）从代理中解耦并存储在云存储中的项目之一。这是一个直到最近才由Warpstream和Confluent Freight Clusters实现的最佳做法。之后，相同的创始人又构建了Estuary Flow，这是一款实时CDC和ETL云服务，并且是开源的，基于Gazette。

Estuary最近发布了Dekaf，它完全兼容Kafka消费者的API，使任何目的地都能像连接Kafka集群一样轻松地连接到Estuary。Dekaf就像不含咖啡因的咖啡；消息传递就像没有了Kafka一样。

Estuary实现了Kafka API，以便利用所有Kafka功能，而无需使用Kafka带来的额外负担。现在，Flow可以用一个单一的数据管道轻松替代Debezium、自定义代码以及ELT或ETL技术。但是，Dekaf也允许Flow作为Kafka部署与目标之间的最后一英里被使用，以处理实时分析所需的数据管道细节。

几家实时分析供应商，如 Bytewax、ClickHouse、Materialize、SingleStore、StarTree 和 Tinybird 等，正在与 Estuary 合作，因为 Flow 使他们能够通过现有的 Kafka API 访问 Estuary 提供的各类实时和批处理数据源及功能。

也许更恰当的问题是，对于已经事实上成为标准的Kafka API，接下来会是什么。

新的供应商正在将Kafka本身也商品化，使之变得更简单和更便宜。Confluent及其他Kafka供应商需要在Kafka之外寻求发展。这一趋势其实并不新鲜。应用集成曾经基于JMS消息，最终将其变成了后台架构。一些数据集成供应商也正在使用Kafka。最终，开发人员可能只会与Kafka API打交道。

在 Confluent Cloud 中，数据平面和控制平面分别运行在各自的独立账户中。然而，Confluent 收购了 WarpStream，从而获得了 WarpStream 的先进 BYOC（自带云）解决方案。此外，Confluent 正在开发其名为 Freight Clusters 的自己的 BYOC 选项。

问题就是为什么Confluent需要收购WarpStream？除了加速其BYOC市场增长外，这还可能帮助Confluent进入如管理数据湖等其他市场。这与通过添加数据管理，Databricks在Apache Spark之外实现的增长类似。在今天的市场上，没有公司愿意只被视为单一产品的供应商。

Confluent 正在推销 Tableflow，该工具可以将 Kafka 流写入 Iceberg 作为目标表。Confluent 在 Confluent Current ’24 上发布了许多 企业级功能，作为实时数据平台，Confluent 拥有巨大的机会。希望 Confluent 能成长为一个主要的流数据管理和 AI 提供商，因为他们打算在 Kafka 之外拓展业务。

Kafka API 的未来发展还不清楚。围绕Kafka API的新功能正在迅速发展。Kafka是否会将这些新功能整合进来，从而成为事实上的标准？Confluent是否会继续带领Kafka朝正确的方向前进？这些新功能是否会围绕Kafka API进行扩展，还是会形成全新的标准？

不像弗朗茨·卡夫卡的《变形记》那样，阿帕奇·卡夫卡的《变形记》会有续篇。