得物使用 AutoMQ 构建海量数据处理的新一代可观测性架构

作者：AutoMQ

2024-12-11
浙江
本文字数：2934 字
阅读完需：约 10 分钟

引言

得物作为全球领先的潮流网购社区，日益增长的用户和数据带来了巨大的技术挑战。当前，得物的可观测性平台每天生成数 PB 级 Trace 数据和数万亿条 Span 记录，要求平台具备高效的实时处理能力和低成本的数据存储解决方案。

传统的存算一体架构将计算与存储资源绑定，随着数据规模的扩大，暴露出了以下问题：

扩展性受限：存算资源无法独立扩展，导致计算和存储的扩容必须同步，进而提升了成本。
资源利用率低：计算与存储资源无法按需动态调整，造成闲置资源浪费。
运维复杂性高：集群扩展和缩容涉及复杂的资源迁移，增加了运维难度。

为了有效解决这些问题，得物可观测性平台采用了存算分离架构，结合 AutoMQ 和 Kafka 以及 ClickHouse 存储技术，实现了高效的资源管理和性能优化。

Apache Kafka 在大规模数据下的挑战

Apache Kafka 处于得物观测业务的核心数据链路中

在得物的可观测性平台中，Apache Kafka 被广泛用于数据收集、加工和分发。然而，随着业务数据量的不断增长，Kafka 的架构暴露出以下问题：

存储成本高：Kafka 的存储部分占据了大部分（计算与存储成本比例为 1:3）云资源开销，为了控制成本，得物调整了 Kafka 的数据 TTL 和副本配置，但存储成本仍居高不下。
冷读效率低：冷读场景下，磁盘吞吐量常达到上限，导致性能瓶颈。

得物 Kafka 磁盘高危报警

运维复杂性高：随着集群规模的扩大，Kafka 集群的扩缩容操作变得更加复杂，面临较高的运维风险。

这些问题源于 Kafka 原生架构的局限性，特别是其面向 IDC 环境的 Shared-Nothing 架构，难以充分发挥云计算时代对弹性和扩展性的要求。

为什么选择 AutoMQ

AutoMQ 云原生架构

为了解决 Kafka 在大规模数据处理中的问题，得物可观测性平台选择了 AutoMQ 作为替代方案。AutoMQ 的优势包括：

100%兼容 Kafka 协议：AutoMQ 完全兼容 Kafka 客户端和生态工具，迁移过程顺畅，避免了大规模改造。

存算分离架构：存储与计算解耦，AutoMQ 基于对象存储和 EBS 存储研发了共享流存储库 S3Stream[1]，并通过 S3Stream 替换了 Apache Kafka 的整个存储层，大幅降低存储成本，同时支持存储与计算的独立扩展。
弹性扩缩容能力：支持动态资源调整，无需数据迁移或停机，提升资源利用率。
未来扩展性：支持大规模数据量增长，能够与现代存储和计算工具无缝集成，满足长期需求。

AutoMQ 面向冷读场景的性能优化

在冷读场景下，Apache Kafka 的性能问题十分明显。KAFKA-7504[2]问题导致冷读操作影响实时写入，严重时会降低整个集群的吞吐量。AutoMQ 通过以下方式优化了这一问题：

对象存储与计算分离：存储与计算的彻底分离避免了冷读对写入性能的影响。
高效查询性能：AutoMQ 对查询操作进行了优化，即使在高并发场景下，冷读性能保持稳定。

Apache Kafka 的读写 IO 链路

Apache Kafka 的读写链路引入了两个关键的技术：Page Cache[3]和零拷贝 SendFile[4]系统调用。

Page Cache 极大地简化了 Kafka 内存管理的负担，完全由内核来负责。但存在冷热无法分离的问题，如果有业务持续在冷读，会跟热数据互相争抢内存资源，导致追尾读能力持续下降。
SendFile 是 Kafka 零拷贝的关键技术，但该调用行为发生在 Kafka 的网络线程池，如果执行 SendFile 时需要从磁盘上拷贝数据（冷读场景），会在一定程度上阻塞该线程池。又因为该线程池是处理 Kafka 请求的入口，包括写请求，SendFile 的阻塞行为将导致 Kafka 的写入受到巨大的影响。

在相同负载和机型下相比 Kafka，AutoMQ 冷读时可以保证不影响写入吞吐和延迟的情况下，拥有和 Kafka 相同水准的冷读性能[5]。

在冷读场景下，AutoMQ 显著提升了性能，与 Kafka 相比，冷读效率提升了约 5 倍，且对实时写入没有任何影响。

AutoMQ 基于共享存储架构的快速弹性能力

得物可观测性平台的业务流量呈现明显的峰谷波动，AutoMQ 通过存算分离架构实现了卓越的弹性扩缩容能力：

快速扩容：在业务高峰期，能够迅速扩展存储或计算资源，保障系统性能。
智能缩容：高峰过后，快速回收闲置资源，避免浪费并降低运维负担。

AutoMQ 的扩缩容依赖秒级分区迁移技术[6]。在扩容时，借助弹性伸缩组（ASG）[7]或 Kubernetes HPA，分区可以批量迁移到新节点，确保流量快速平衡，通常在十秒内完成。缩容时，待下线节点的分区会迅速迁移至其他节点，完成秒级下线。与 Apache Kafka 需要通过复制数据进行扩缩容不同，AutoMQ 利用共享存储架构避免了数据复制，显著提高了扩缩容效率，避免了数据重平衡[9]，跟 Apache Kafka 的实现有巨大的区别。

AutoMQ 自动流量重平衡 vs. Apache Kafka 手动迁移

AutoMQ 落地效果：千核资源替换，成本下降 50%

AutoMQ 在得物可观测性平台上线半年以来，逐步替换了整个可观测性架构对 Apache Kafka 的依赖，基于 AutoMQ 的整体可观测架构如下图所示，AutoMQ 集群承担了所有微服务业务的产生的观测数据，并基于 ClickHouse 进一步提供点查和观测数据分析的能力。

得物基于 AutoMQ 的可观测架构

AutoMQ 也为得物可观测性平台带来了以下显著的成效：

云账单成本同比下降 50%以上，同时运维效率大幅度提升。
完成近千核计算资源替换，总体吞吐高达数十 GiB/s。

AutoMQ 落地效果：平稳支撑得物双十一期间 100%流量

除了成本大幅度降低之外，今年通过 AutoMQ 的架构支撑得物双十一，避免了过往双十一前繁重的容量评估工作，以及提前扩容的运维成本。AutoMQ 集群上线以来，以及双十一期间全程保持高可用，零宕机，支撑了双十一期间 100%的流量，且高峰期负载平稳，无性能抖动。如下图是得物可观测性平台 AutoMQ 集群中其中一个 GiB 级吞吐的集群。

总结

得物其中的一个 AutoMQ GiB 级集群

得物通过引入 AutoMQ，成功解决了 Apache Kafka 在大规模数据处理中的诸多挑战。在实际应用中，AutoMQ 在得物可观测性平台表现出了显著的优势，不仅降低了系统的存储和计算成本，而且大幅度提升了资源利用率和运维效率。得物可观测性平台借助 AutoMQ 的存算分离架构，克服了 Kafka 在扩展性、存储成本和运维复杂性上的局限性，实现了动态资源调整和高效的冷读优化。在双十一高峰期，AutoMQ 的卓越性能和弹性扩缩容能力保证了系统的高可用性和稳定性，无需额外进行繁重的容量评估和提前扩容操作。这一技术实践为得物带来了显著的成本节约和性能提升，成为其面对未来数据爆发增长的坚实基础。同时也为其他企业在高效资源管理和性能优化方面提供了宝贵的经验与解决方案。