Kafka替代方案对比: AutoMQ vs WarpStream

2024年8月14日

如果你非常关注流系统的延迟，那么可以毫无顾虑地选择 AutoMQ

流系统是重要的数据基础设施。AutoMQ[1] 和 WarpStream[2] 都是流系统领域近几年诞生的新力量。他们存在一些相似的地方，例如都将 S3 作为主存储来降低成本。但是在很多方面，他们仍然存在不小的差异。本篇文章将从性能、弹性、可用性、成本、生态和适用场景等多个维度对他们进行全面对比，以便于读者在选择流系统时可以快速掌握他们的区别，选择适合自己的流系统。

TD;LR

AutoMQ 和 WarpStream 的所有区别可以用以下一张图来表示。如果关心其中对比的细节，则可以继续阅读后续的内容。

Native Kafka vs Kafka API Compatible

Apache Kafka 在流系统领域已经发展了十多年。时至今日，其生态不仅没有衰弱反而随着 AI 和 LLM 的兴起而愈加繁荣。Kafka 凭借其强大的生态和其庞大的存量市场使得 Kafka API 俨然成为流系统领域的事实标准。

Kafka 兼容性极其重要

如果无法对 Kafka 有着足够好的兼容性，将会产生以下诸多问题：

迁移成本高 ：存量业务需要迁移至新的 Kafka Alternative 涉及大量改造和未知风险。例如某业务系统强依赖 Apache Kafka 的某个 API 的行为，采用新 Kafka Alternative 时如果没有考虑到，则将引发业务故障。如果没有足够好的 Kafka 兼容性，完整、正确的评估迁移风险以及实施迁移是非常有挑战的工作。
无法享受 Kafka 生态红利 ：时至今日，Apache Kafka 已经积累了庞大的周边生态，并且还在持续发展中。如果没有足够好的 Kafka 兼容性，则无法充分利用 Kafka 的生态价值。后续使用过程中则常常面临需要自己重新开发相关软件，产生大量额外的成本。
与 Kafka 社区主干脱节，脱离主流社区 ：在 Confluent 以及广大开源社区力量的影响下，Apache Kafka 社区仍然正在蓬勃发展。缺乏对 Kafka 足够的兼容性，将难以复用社区的力量。例如未来 KIP-932: Queues for Kafka[3] 这种重量级特性上线，如果仅仅是做 Kafka API Protocol 层面的兼容，将无法及时跟进这些重量级特性。即使自己重新实现了这部分能力，也将在初期缺乏足够的社区验证，需要漫长的时间才可以变得成熟。

Kafka API 兼容数量： 73（AutoMQ） vs 26（WarpStream）

Apache Kafka Protocol 官方文档中[4]定义的 Kafka API 个数合计为 74 个。WarpStream 截止当前，根据其官方文档描述[5]累计支持的的 Kafka API 数量为 26 个 ，而 AutoMQ 支持的 Kafka API 数量为 73 个 。AutoMQ 由于将持久性卸载至 EBS 和 S3，因此通过单个副本即可保证数据持久性。因此 Kafka API 当中的 StopReplica 对 AutoMQ 无效。在 Kafka API 兼容程度上面，AutoMQ 相比 WarpStream 具有绝对优势 。在这里，其实还有一个隐含的差异。AutoMQ 完整保留了 Apache Kafka 计算层的实现，因此这些 Kafka API 实现后的行为会和 Apache Kafka 完全保持一致；WarpStream 由于是自己重新实现了这些 Kafka API ，在其行为表现上较难和 Apache Kafka 社区保持一致。

WarpStream 的 Kafka 兼容性 ：WarpStream 是使用 golang 重新实现的流系统，对 Kafka API 进行了重新实现，在协议层面进行了兼容，只兼容了 35.13% 的 Kafka API。仅仅做 API 协议层面的兼容很难做到对 Apache Kafka API 的完全兼容。Apache Kafka 社区主干代码随着版本不断迭代和变更，仅做 API 协议层面的兼容很难及时跟进这些变更和修复，在 API 的最终表现层面或多或少会和官方 API 的实际行为产生差异。
AutoMQ 的 Kafka 兼容性 ：AutoMQ 作为 Apache Kafka 的社区分叉项目，对其存储层进行了重新设计与实现，但是完整保留了 Apache Kafka 计算层的代码。对于 Apache Kafka 具有 100% 的兼容性[6]，通过了 Kafka 的所有测试用例合计 387 个（不包含 Zookeeper 相关的测试用例，AutoMQ 只支持 KRaft 模式）。此外，AutoMQ 由于计算层对 Apache Kafka 的完全兼容，可以非常迅速地跟进 Apache Kafka 社区主干的更新与修复。例如，当前 AutoMQ 已经跟进 Apache Kafka 社区 3.8.x 的最新代码。后续，Apache Kafka 社区有新的特性和修复版本发布，AutoMQ 也都会及时更近，与 Kafka 社区主干计算层差异不超过 2 个月。

总体而言，AutoMQ 作为 Apache Kafka 的代码分叉，属于 Native Kafka[7]的范畴，而 WarpStream 属于 Kafka Protocol Compatible 的范畴（非完全兼容）。

-	AutoMQ	WarpStream
Kafka Compatibility	Native Kafka	Kafka Protocol Compatible

更好的 K8s 支持

WarpStream 当前仅支持将 Agent 部署至 K8s[8]，其元数据服务等都只能脱离 k8s 部署。WarpStream 对于 K8s 的支持当前仍然较弱，没法通过 helm chart 和 yaml 文件对集群从生命周期、权限、身份认证，网络、元数据进行全面的管理。

AutoMQ 得益于对 Apache Kafka 的完全兼容，其可以完全复用 Bitnami Kafka Chart [9]的完整能力，将整个 AutoMQ 数据面（包括元数据服务）全部部署到 K8s 上进行统一管理。此外，过去使用 Bitnami Kafka 时候由于 Apache Kafka 由于多副本分区数据复制导致的难以扩缩容问题，在 AutoMQ 身上也随之迎刃而解。AutoMQ 可以为用户在 K8s 上提供深度集成 K8s 的低成本、高弹性的 Kafka 服务。

存储架构

AutoMQ 和 WarpStream 在存储层的实现都将像 S3 这样的对象存储服务作为主数据的存储介质来取得比 Apache Kafka 高得多的成本效益。两者都践行了共享存储架构的理念，但是在设计和实现上则截然不同 。下面两张架构图清晰的展示了 AutoMQ 和 WarpStream 的差异：

元数据管理实现方式不同 ：AutoMQ 计算层的总体实现与 Apache Kafka 保持一致。因此除了提供了 100%的 Kafka 兼容能力以外还同时复用了 KRaft 来进行元数据的管理。WarpStream 的元数据管理强依赖其 WarpStream Cloud 下的自研组件 Cloud Service 以及 Virtual Cluster。
存储层实现方式不同 ：WarpStream 的实现方式比较简单直接，通过 Agent 来接受 Producer 的写入，然后将数据写入对象存储。采用这种方式，只有当数据真正在对象存储上完成持久化以后才可以给 Producer 返回成功，然后才可以继续写之后的数据。这种方式最大的问题即丧失延迟性能。WarpStream 官方的评测数据显示 P99 的发送延迟为 620ms [10]。AutoMQ 则巧妙地将一小块空间（10GB）的 EBS 卷作为 WAL，利用 EBS 低延迟、高性能、高持久性的特点保障了写入的性能。通过 EBS WAL，AutoMQ 可以提供个位数毫秒的 P99 发送延迟[11]，在延迟方面 AutoMQ 彻底领先 WarpStream 。同时，由于 EBS 内部本身通过多副本已经具备很高的持久性，AutoMQ 不必像 Apache Kafka 一样额外再使用多副本来保证数据持久性，相比 Apache Kafka 可以节约 2/3 的存储成本以及彻底避免 Broker 之间的数据复制。图[4]可以看到 AutoMQ 利用 NVME Reservation 和 EBS 卷多重挂载的能力可以在毫秒级完成 failover 从而可以将 EBS 当做共享存储来使用。

开放 vs 封闭：多模共享存储架构

AutoMQ 与 WarpStream 存储设计理念上另外一个重要区别是：AutoMQ 是开放的流存储架构。这种开放性体现在做个方面：

AutoMQ 核心流存储引擎源码是公开的 ：WarpStream 是完全闭源的商业化产品。闭源的产品相比开源/源码开放的产品在产品验证方面处于天然弱势。缺乏足够的使用者，使得其产品成熟度相比开源/源码开放的产品来说会慢得多。此外，对于初期感兴趣的用户来试用和体验产品也会产生较大的门槛，不利于使用者深度了解和学习产品。与之相反的是，AutoMQ 则将存储层最核心的流存储引擎 S3Stream 的所有源码[12]实现全部公开在 Github 上。使用 Github 源码公开版本的 AutoMQ 我们称之为社区版。用户可以自由通过社区版研究、学习、体验 AutoMQ，并且将社区版免费应用于生产环境。
AutoMQ 具备更加灵活开放的流存储引擎实现 ：最近我们看到 Databricks 收购了 Apache Iceberg 的创造者 Tabular[13]。 Icerberg 相比其他数据湖存储格式可以在众多数据湖格式中脱颖而出最终成为数据湖格式的事实标准与他更加灵活开放的设计初衷是息息相关的。更早一点的例子则是 Kubernetes 战胜了 Docker Swarm 成了容器编排领域的事实标准。历史告诉我们，一个更加开放、通用的设计将会更容易取得成功。相比 WarpStream，AutoMQ 的流存储引擎设计则更具灵活和通用性。AutoMQ 顶层对 WAL 进行了更加通用、灵活的抽象，称之为 Shared WAL[14]。Shared WAL 针对不同的存储介质可以有不同的实现，甚至可以将不同的实现进行组合。不同的存储介质具备不同的性能表现和使用方式，均有各自最适用的场景。像 WarpStream 这种直接写 S3 的方案，当前已经在 AutoMQ 中实现了，并且现在你就可以用我们已经开放源码的代码运行它[15]。

KRaft vs 自研元数据存储

AutoMQ 作为 Native Kafka 直接利用了 Apache Kafka 的 KRaft 来管理元数据，相比 WarpStream 主要带来以下好处：

更加成熟和稳定 ：KRaft 自首次发布以来已经经过市场 3 年多的考验，并被 Confluent、AWS MSK、Aiven、instaclustr 等众多 Kafka 服务供应商广泛应用于生产环境。元数据存储服务作为流系统最核心的设施之一，保证其稳定可靠显得尤为重要。
元数据服务无外部依赖 ：AutoMQ 使用 KRaft 来进行元数据管理，无需任何外部依赖。奥卡姆剃刀原理告诉我们，如无必要，勿增实体。使用 AutoMQ 使用 KRaft 则很好的贯彻了这种理念，简化了架构，缩短了元数据的传输路径，降低复杂度和出错概率。WarpStream 额外依赖 2 个独立的服务 Cloud Service 以及 Virtual Cluster，整个元数据传输路径很长。同时，为了保证元数据传输的可靠性，还需要同时保障 Cloud Service 和 Virtual Cluster 的高可用，在部署、工程实现层面都带来了更大的复杂性。
自建部署友好 ：AutoMQ 对自建部署非常友好。AutoMQ 对 Kafka 的启动流程做了优化，即使使用 AutoMQ 免费的源码开放社区版本，只需要在多台机器上一键启动 jar 即可完成一个分布式 AutoMQ 集群的创建，无任何外部依赖，部署十分简单。如果使用 WarpStream，你还需要部署高可用版本的 Cloud Service 和 Virtual Cluster 才可以保证整个 WarpStream 服务可用。

流系统延迟不可忽视：低延迟 vs 高延迟

WarpStream 在设计之初已经完全做好了放弃流系统延迟性能的计划。我们也相信，确实存在一些场景他们对延迟确实不敏感，但是 WarpStream 这种想法在我们看来更多来自于“被迫无奈”。想要将流系统构建于 S3 之上，但是又没有好的办法同时优雅地处理好延迟问题，只能被迫自己接受延迟性能的损失。从 AutoMQ 的视角来看，低延迟是流系统不可或缺的一部分。延迟是产品一致性、兼容性的强指标。

实时性是未来的技术趋势 ：整个技术的发展肯定是不断往前的。流领域本来就非常重视的数据实时性，因此才会诞生像 Apache Flink 这样的低延迟流处理引擎、RisingWave 这样面向实时低延迟事件流的流数据库。一个低延迟的流系统将不利于和现代化数据技术栈中的其他产品更好的协同工作。
实时性助力商业成功 ：在不断变得越加竞争激烈的全球化环境中，谁可以更快地将数据发挥出价值，谁将拥有更多的商业先机，更容易获得成功。
实时性场景在流领域仍然具有重要应用场景 ：在金融贸易、实时数据分析、实时监控、反欺诈、实时推荐等领域仍然具有重要应用。
切换高延迟系统带来额外迁移成本 ：如果用户的存量业务正在使用 Apache Kafka，使用 AutoMQ 的迁移成本更低。从低延迟切换到高延迟带来一系列的实施难度和成本例如性能测试、参数调整、AB 版本对比等。而使用 AutoMQ，则无需对你的客户端和上层应用的配置做任何调整。AutoMQ 支持了很多客户将生产环境的 Apache Kafka 迁移至 AutoMQ，都充分验证了这一点。

退一步讲，即使你当前所有的业务都不关心延迟，我们仍然推荐你使用 AutoMQ。AutoMQ 提供一体化的多模存储引擎。当你现在不关心延迟，希望简化架构，你可以使用 AutoMQ 的 Direct S3 Cluster；当你未来需要关心延迟时则可以使用 AutoMQ 的 EBS WAL 实现。如果着眼于更远的未来，如果市面上诞生了其他拥有独特优势的存储介质，AutoMQ 这套 Shared WAL 的统一抽象也将非常轻松地支持这些新型存储。这点可以参考之前的内容，我们如何通过 100 多行代码实现 Kafka directly on S3[16]。通过一个流系统产品，你将可以更好地适应未来各种变化，而不是当你关心流系统的延迟时再重新采购一套新的产品。