作者 | AutoMQ

引 言

Coban 是 Grab 的实时数据流平台团队，一直致力于围绕 Kafka 构建生态系统，服务于 Grab 各个业务领域。平台作为 Grab 数据湖的入口，从不同服务中采集数据，进行存储与后续分析。它支持事件的实时处理和分析，这对于许多应用和服务至关重要。平台每小时可处理数 TB 级数据流，具备高吞吐、低延迟与高可用性。

图 1：Grab 的数据流平台

除了稳定性和性能，成本效率也是团队非常关注的重点事项。本文将介绍 Coban 团队是如何通过引入 AutoMQ，提升 Grab 数据流平台的效率并有效降低成本的。

痛点陈述

过去，在数据流平台上遇到的主要挑战包括以下四个方面：

• 计算资源扩容困难：其中一个主要挑战是计算资源的扩容问题，尤其是在分区迁移时，容易引发资源使用量激增，影响操作灵活性。

• 磁盘无法独立扩容，导致操作复杂性增加：各个代理节点的磁盘使用情况差异较大，增加存储空间时，需要集群扩容或者增加代理节点的磁盘，然而这两种方案并非理想选择。

• 基于峰值的过度配置，导致资源浪费：目前的资源配置是基于峰值需求，这导致非高峰时段的云资源未得到最优利用，从而增加成本并降低效率。

• 高风险的分区再平衡：在集群维护期间，分区再平衡往往会导致较长时间的延迟增加，进而影响系统的整体性能和用户体验。

面对这些挑战，需要一种能够有效解决上述问题的方案。基于此，团队提出了以下需求，并选择了 AutoMQ：

• 良好的弹性：希望能够动态调整计算资源，既能应对高峰期的需求，又能应对低谷期的变化，且不会造成系统中断。

• 存储和计算分离：需要具备独立扩展存储的能力，以高效应对业务的弹性需求和持续增长。

• 与 Kafka 的高度兼容：与 Grab 现有数据流平台的无缝集成至关重要，能够避免大规模的系统改造和中断。

• 快速稳定的分区迁移能力：在流量激增时，快速重新分配大分区的能力对于保证系统性能和可靠性是至关重要的。

• 低延迟：支持现有的延迟敏感型 Kafka 使用场景是优先考虑的事项，确保平稳的用户体验。

图 2：新数据流平台愿望清单

解决方案

为了解决前文提到的挑战并满足业务需求，团队引入了 AutoMQ，一款具备高弹性与卓越性能的云原生 Kafka 解决方案。

图 3：采用 AutoMQ 的新数据流架构

图 3 展示了引入 AutoMQ 之后，数据流平台的新架构。由于 AutoMQ 与 Apache Kafka® 100% 兼容，因此可以轻松地从原有架构平滑切换至基于 AutoMQ 的新架构。

AutoMQ 采用基于 EBS WAL 和 S3 的共享存储架构。通过使用固定大小的 EBS 作为 WAL，系统可以在不增加额外成本的情况下，提供极高性能和极低延迟的写入能力。同时，所有写入的数据都会存储在 S3 Bucket 中，从而充分利用 S3 所带来的高可靠性、弹性与成本优势。

为什么选择 AutoMQ?

集群可快速、高效扩容

在过去的架构中，Kafka 采用的是副本机制，然而这种方式下的计算弹性并不理想。当节点之间进行数据迁移时，数据需要在不同的 Broker 间传输，往往会带来性能波动和运维挑战。而在 AutoMQ 中，数据存储在跨 Broker 的共享存储层中。当集群需要扩容或缩容时，AutoMQ 无需在 Broker 之间迁移分区数据，只需几秒钟即可完成分区的重新分配，实现真正快速、平滑的集群扩展。

AutoMQ 采用按需扩展的 S3 共享存储

AutoMQ 通过对象存储（如 S3）来保存数据。S3 是一种按需扩展的存储服务，当需要更长的数据保留期时，无需再像以往那样手动扩展 Broker 或本地磁盘，从而显著降低了运维成本和操作复杂度。

快速的分区重新分配能力

使用 AutoMQ 重新分配大规模分区的过程非常迅速，仅需同步少量元数据即可完成切换。这一优势源自 AutoMQ 的云原生架构设计。与 Apache Kafka® 依赖 ISR 多副本机制来保障数据持久性不同，AutoMQ 将数据持久化托管给云存储服务。由于云存储本身具备多副本与纠删码机制，天然提供高可靠性和高可用性，因此 AutoMQ 无需在 Broker 层引入多副本结构。AutoMQ 遵循“ 云优先（Cloud-First）”的设计理念，将传统的硬件依赖型架构转向以云服务为核心的架构，充分释放云端的弹性与性能潜力。

低延迟

低延迟是 Grab 实时数据流平台提升用户体验的关键。尽管对象存储服务（如 S3）并非为低延迟写入而设计，AutoMQ 巧妙地利用固定大小（10GB）的 EBS 块存储，实现了毫秒级（个位数毫秒）写入延迟。它通过使用 Direct I/O 技术绕过文件系统的写入开销，并依托云原生架构避免内部分区副本带来的网络开销，从而实现了极高的写入性能与稳定性。

100% Kafka 兼容性

AutoMQ 复用了 Apache Kafka® 的计算层代码，并通过了所有官方测试用例，真正实现了完全兼容（100% Compatibility）。这意味着可以在不调整现有 Kafka 基础设施或重写客户端代码的情况下，平滑切换至 AutoMQ，从而大幅降低架构迁移的成本与风险。

评估与生产环境部署

为确保 AutoMQ 能够满足预期，团队从 性能、可靠性和成本效益三个维度对其进行了全面评估。

在 可靠性方面，同样设计了多种测试用例和基准测试场景，来验证系统在不同类型故障下的表现。例如，模拟计划内维护时的平滑切换（graceful failover）以及突发基础设施故障下的应急恢复，从而确保系统能够在各种情况下保持稳定运行。

最后，评估 成本效益。AutoMQ 在各项测试中表现出色，通过了所有基准测试和用例验证。基于这些结果，团队对其在生产环境中的可行性充满信心，并决定在 Grab 的实际业务场景中引入 AutoMQ 进行正式部署。

过去，团队主要使用开源社区的 Kafka Operator Strimzi 在 Kubernetes 上管理和运维 Kafka 集群。为了支持与 AutoMQ 的集成，扩展了该 Operator 的功能，新增了 WAL Volume 的创建、挂载与授权，并实现了 AutoMQ 与 Strimzi 的无缝对接。此外，团队还系统学习了 AutoMQ 相关知识，例如 S3 存储机制、WAL 相关指标等，以便在生产环境中更高效地使用和管理 AutoMQ 集群。

使用效果

引入 AutoMQ 后，数据流平台在以下多个方面取得了显著提升：

吞吐量大幅提升：随着数据复制从 Broker 之间迁移至云端存储复制，观察到单核 CPU 吞吐量提升了 3 倍。就吞吐量而言，该集群目前已成为 Grab 内部服务矩阵中规模最大的集群之一。

成本效益提升：初步统计显示，整体 成本效益提高了 3 倍。

分区重新分配效率提升：在过去，整个集群的分区重新分配的耗时可能需要长达 6 小时，而现在 不到 1 分钟即可完成。

图 4：过去设置下扩展 Broker 时的性能表现

图 5：新的 AutoMQ 设置下扩展 Broker 时的性能表现

图 4 和图 5 展示了新旧两种架构在执行 Broker 弹性伸缩时，关键性能指标的变化差异。采用 AutoMQ 的新架构不仅可以极快地完成扩容，同时带来的性能波动更小，集群整体更加稳定。

在引入 AutoMQ 的共享存储架构后，与过去的架构相比，实现了极快的分区重新分配——每次分配仅需数秒即可完成。得益于此，Broker 的稳定性也得到了增强，因为在分区迁移的过程中无需再在 Broker 之间复制数据。这意味着 I/O 和网络利用率都不会再出现激增，数据也无需在 Broker 之间移动，因此集群更加稳定，在运维操作中也不会出现性能尖峰了。

由于分区重新分配的速度非常快，这也显著减少了对客户端的影响，无论是生产者（Producer）还是消费者（Consumer），在扩容或迁移期间几乎不再出现延迟上升的现象。此外，得益于共享存储架构，现在可以独立扩展存储资源。在旧架构下，如果需要增加存储容量，必须新增 Broker 节点或为单个 Broker 扩容磁盘。这不仅导致了不必要的计算资源浪费（新增节点的计算能力往往被闲置），还会在扩容时触发集群再平衡。这一操作会造成生产者与消费者客户端的延迟上升和系统稳定性下降。

未来展望

在引入 AutoMQ 后，已经在多个方面获得了显著收益。接下来，团队还计划进一步优化整体效率。

首先，希望进一步 提高计算资源利用率。AutoMQ 内置了一项尚未启用的功能—— 自动均衡（Self-Balancing）。这一功能与 Apache Kafka® 常用的一款开源工具 Cruise Control 类似。“自动均衡”会根据需要定期自动触发分区再均衡，使集群的计算能力在高峰与低谷时段都能灵活应对，从而实现更高效的资源调度。

其次，将持续 优化成本效益。既然现在能够容忍更频繁的中断，并且执行分区重新分配的成本不再高昂或几乎可以忽略不计，因此可以着眼于自动扩缩容（auto scaling）与抢占式实例（spot instances），以实现成本节约。在业务高峰期，集群可以扩容应对；而在非高峰或低负载时段，能够自动缩容，这将进一步提高资源利用效率和成本效益。团队还在探索使用 AutoMQ 的 S3 WAL流式存储引擎，来减少客户端和 Broker 之间的跨可用区（cross AZ）流量。此外，AutoMQ 还提供了一个名为 Table Topic的功能，它允许 Topic 的流式数据以 Iceberg 表格式直接存储在 S3 上，并且可以充分利用 AWS 最新发布的 S3 Table 功能。团队正计划对此进行深入研究，以便在引入 Table Topic 后，能够减少一些不再需要的数据管道冗余。

最后，鉴于 AutoMQ 在 Grab 内部的出色表现，团队计划在更多业务场景中推广其应用，将更多数据流用例迁移到 AutoMQ 上，进一步释放其潜能。