得物新一代可观测性架构：海量数据下的存算分离设计与实践 ...

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

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

• 存储成本高：Kafka的存储部分占据了大部分（计算与存储成本比例为1:3）云资源开销，为了控制成本，得物调整了Kafka的数据TTL和副本配置，但存储成本仍居高不下。

• 冷读效率低：冷读场景下，磁盘吞吐量常达到上限，导致性能瓶颈。

得物 Kafka 磁盘高危报警

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

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

AutoMQ云原生架构

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

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

• 存算分离架构：存储与计算解耦，AutoMQ基于对象存储和EBS存储研发了共享流存储库S3Stream[1]，并通过S3Stream替换了Apache Kafka的整个存储层，大幅降低存储成本，同时支持存储与计算的独立扩展。

• 弹性扩缩容能力：支持动态资源调整，无需数据迁移或停机，提升资源利用率。

• 未来扩展性：支持大规模数据量增长，能够与现代存储和计算工具无缝集成，满足长期需求。

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

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

案例

AutoMQ通过监控集群流量和CPU等指标，自动进行扩缩容。当流量达到扩容阈值时，系统会自动增加Broker节点；当流量下降至缩容阈值时，系统会优雅地将即将下线的Broker上的分区以Round-Robin方式秒级迁移至其他Broker，完成流量平衡。

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

得物基于AutoMQ的可观测架构

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

• 云账单成本同比下降50%以上，同时运维效率大幅度提升。

• 完成近千核计算资源替换，总体吞吐高达数十GiB/s。

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

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

得物可观测性平台在分布式链路追踪中，采用ClickHouse作为Trace索引数据的存储引擎，每天管理着数十万亿行追踪数据。随着数据量的持续增长，平台不仅需要保障实时查询的高效性能，还面临着存储成本优化和集群维护复杂度提升的双重挑战。

ClickHouse凭借卓越的性能，在面对大规模数据时依然能够提供极快的查询响应，为可观测性平台的实时分析和监控提供了坚实保障。然而，随着业务扩展和数据量激增，原有的基于云盘自建的开源分布式架构逐渐暴露出了一些问题：

• 成本高：得物的Trace平台从2022年至今，数据量从日增百TB级增长到数PB，膨胀了30倍。数据冷热存储的成本压力增加。

• 可扩展性差：作为一个电商平台，每年的双11和618等购物节，Trace平台都会迎来数倍的流量上涨，为了保证业务的稳定运行，每逢业务高峰都要进行集群的扩容，分布式架构下集群扩容麻烦、需要停写影响业务，再加上集群扩容中的协调难题都为平台的维护带来了额外的工作量和稳定性压力。

• 容灾能力较低：在实际应用中，考虑到海量数据产生的成本问题，得物并未采用多副本策略，而是通过单副本存储来优化资源利用率和降低存储开销，在更加追求系统稳定性和数据安全保障的今天，如何提高系统的容灾能力也成为了一个重要的课题。

• 集群写入负载平衡难：为了平衡集群节点的写入负载，每次扩容时需与上游服务协同进行rebalance，以合理分配数据至新节点。这一过程虽确保了扩展后的集群性能，但对运维效率提出了更高的要求，涉及数据分布调整和写入负载平衡的精细化管理。

因此，如何在保持ClickHouse性能优势的同时，优化扩容过程中的运维流程，解决集群写入负载平衡问题，进一步提升系统的稳定性，是得物平台在持续扩展中亟需解决的核心问题。

ClickHouse企业版是专为云环境下的存算分离架构设计，支持更高效的计算与存储资源管理。企业版与社区版的最大区别在于，它引入了更先进的存算分离架构和更多功能，能够在大规模数据处理、实时查询和存储管理方面提供更优的性能。

存算分离架构是ClickHouse企业版的核心创新，它通过将计算资源和存储资源分开，极大地提高了系统的弹性和扩展性。在这种架构下，计算节点和存储节点独立扩展，存储资源可以通过共享存储（如OSS、S3等）进行集中管理，而计算节点则能够根据负载情况进行自动伸缩，从而更好地应对流量高峰期的挑战。

企业版还引入了Serverless计算模型，允许平台根据实际负载自动调整计算资源的大小。相比于传统的基于固定资源分配的计算模式，Serverless架构能帮助平台实现弹性伸缩，只在需要时自动分配计算资源，极大地节省了资源开销，同时也能更好的应对业务流量的非预期增长，提高了系统的稳定性。

在ClickHouse企业版中，SharedMergeTree表引擎是实现存算分离架构的关键组件。SharedMergeTree优化了对共享存储（如Amazon S3、Google Cloud Storage、MinIO、阿里云OSS等）的支持，100%兼容社区版的MergeTree引擎的同时，内核还可以自动将社区版的建表语句转化为企业版专属引擎的建表语句（如下图所示），业务迁移无需DDL改造。

与传统的ClickHouse集群架构相比，SharedMergeTree引擎通过以下方式提升了数据存储和查询性能：

• 共享存储支持：所有数据都存储在共享存储中，而计算节点通过访问共享存储来执行查询和分析。这种设计使得数据的存储和计算完全分离，计算节点无需持有数据副本，从而降低了存储和计算资源的冗余。

• 无状态计算节点：计算节点不再存储数据副本，而是通过访问共享存储中的数据进行计算。这使得每个计算节点都是“无状态”的，具有更好的扩展性和容错能力。在面对流量高峰时，新的计算节点可以快速加入并开始工作，而不需要重新分配或迁移数据。

• 简化集群管理：用户无需管理传统的Shard或Distributed Table，SharedMergeTree引擎只需创建一张表即可，简化了集群管理流程，降低了维护复杂度。

在大规模电商平台的场景下，面对节假日等流量高峰时，系统需要具备快速扩展和高可用性的能力。ClickHouse企业版通过SharedMergeTree引擎，实现了分钟级水平扩展，并且在扩展过程中集群可正常执行读写任务，稳定性不受影响。

扩容流程：

1. 新节点（Server-3）加入：当需要增加计算节点时，新节点首先注册至集群的元数据管理服务（如Keeper），并开始监听数据元数据变化。

2. 元数据同步：新节点从Keeper同步当前有效的元数据，无需锁定集群，不会影响集群其他节点的操作。

3. 立即参与工作：新节点完成元数据同步后，立即可以处理查询请求，并按需访问共享存储中的数据。

通过这种方式，ClickHouse企业版能够在高负载下实现弹性扩展，确保集群的稳定性和业务的连续性。

最终，得物可观测性平台基于ClickHouse企业版的功能，在写入、查询、容灾能力及弹性能力方面进行了全面优化，实现了高性能和高效率的分布式链路追踪系统。

从自建ClickHouse社区版升级为企业版，因为企业版的存算分离架构不再有分片的概念，不再需要通过直连本地表进行写入的方式对不同分片间的数据和写入流量进行均衡，所以和原先直连节点做写入的方式不同，切换为企业版后业务写入操作的对象变为了集群本身，写入逻辑得到了简化，原有的写入流量和分片间数据不均衡带来的运维和管理的问题也从架构上得到了解决。

以下是具体的实践总结：

• 负载均衡：借助负载均衡（LB），将写入请求均匀分配到多个计算节点，避免单节点过载，提高系统稳定性。lb采用rr模式，当集群版本升级进行节点的分批重启、以及集群中某一节点进行故障重建时，会自动调整为wrr模式来保障集群的整体无感。

• 性能提升：利用ClickHouse企业版的Serverless架构，成功支持了分布式链路追踪场景下集群每秒高达2000万行的写入操作，单次请求40万行数据写入耗时优化至1s左右。

• 并行查询：通过Parallel Replica特性，将查询分发至多个节点并行处理，显著提高效率。在特定场景下，查询速度提升可达2.5倍。整体查询效率与自建ClickHouse不相上下。

• 索引优化：调整ORDER BY字段与查询顺序，最大化利用索引过滤及数据块优化，显著减少不必要的数据扫描，从而提升查询响应速度。

• 单节点故障容忍：集群默认3Keeper+至少双节点架构，每个计算节点都保存着一份完整的元数据，且计算节点仅管理元数据，核心业务数据存储于共享存储中。因此，单节点故障不会影响数据访问，其余节点可继续提供服务，确保业务稳定性。

• 高可用存储：通过采用如OSS等分布式对象存储，平台实现了高冗余的数据存储，进一步增强了系统在硬件故障情况下的恢复能力。

• 秒级弹性扩容：平台能够根据业务负载的实时变化，自动调整计算资源。通过监控CPU和内存使用，系统动态决策并热修改Pod配置，使扩容资源即时生效，无需重启服务。

• 按需付费：

  计算按需付费：每个节点的弹升和弹降都是独立进行，只和当前节点的实际业务负载有关的，因此无需再担心各节点间流量压力差异带来的成本冗余；同时节点的弹性扩容和缩容的最小单位均为1CCU（约1C4G），扩容事件同步至计费模块后，平台按秒计费，仅需为实际资源使用量付费。这一机制帮助得物大幅降低了资源浪费，同时确保了成本优化。

  
  

  存储按实际使用量付费：相比存算一体架构下需要预留至少20%的存储空间来保障集群的稳定性的资源预购模式，ClickHouse企业版的共享存储解决了自建社区版各分片数据不均衡、运维麻烦、成本冗余多的问题，同时仅按照实际使用量计费的模式结合对象存储本身价格低廉的特征，降低了得物大数据量场景下的存储成本70%+。

通过ClickHouse企业版，得物可观测性平台实现了从写入到查询、从容灾到弹性的全面优化。企业版的存算分离架构提升了系统可靠性，而秒级弹性能力结合秒级按需付费显著降低了计算资源的使用成本约20%和存储资源的采购成本70%+（总成本下降60%）。这种实践模式不仅满足了高并发、高性能的业务需求，同时也为系统的扩展性和运维效率提供了有力支持，成功应对了链路追踪数据管理中的各种挑战。

[1]AutoMQ基于S3的共享流存储库：https://docs.automq.com/zh/automq/architecture/s3stream-shared-streaming-storage/overview

[2]Kafka冷读性能问题来源：https://issues.apache.org/jira/browse/KAFKA-7504

[3]Linux Page Cache: https://en.wikipedia.org/wiki/Page_cache

[4]Linux SendFile: https://man7.org/linux/man-pages/man2/sendfile.2.html

[5]AutoMQ性能白皮书：https://docs.automq.com/zh/automq/benchmarks/benchmark-automq-vs-apache-kafka

[6]AutoMQ秒级分区迁移：https://docs.automq.com/zh/automq/architecture/technical-advantage/partition-reassignment-in-seconds

[7]AWS Auto Scaling Groups: https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html

[8]Kubernetes用于扩容的 HPA 组件：https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/

[9]AutoMQ持续数据自平衡：https://docs.automq.com/zh/automq/architecture/technical-advantage/continuous-self-balancing

[10]阿里云云数据库ClickHouse：https://help.aliyun.com/zh/clickhouse/?spm=a2c4g.11174283.0.0.61f5735a0zfJIS

路过

雷人

握手

鲜花

鸡蛋

版权声明：本文为 clickhouse 社区用户原创文章，遵循 CC BY-NC-SA 4.0 版权协议，转载请附上原文出处链接和本声明。

评论

评论