得物可观测性平台存算分离实战：基于AutoMQ与ClickHouse企业版的海量数据处理

随着用户规模和数据的爆炸式增长，得物的可观测性平台面临着前所未有的挑战。每天产生的PB级Trace数据和万亿级Span记录，对平台的实时处理能力和存储成本控制提出了极高要求。

传统存算一体的架构将计算与存储资源强绑定，在大数据量下逐渐暴露出弊端：

• 扩展性受限：存算资源无法独立扩展，导致扩容时必须同步升级，推高了总体成本。
• 资源利用率低：计算与存储的配比难以动态调整，容易造成资源闲置与浪费。
• 运维复杂性高：集群的扩缩容涉及繁重的数据迁移，运维风险和难度直线上升。

为应对这些挑战，得物可观测性平台全面拥抱了存算分离架构，结合Kafka与ClickHouse存储，实现了高效的资源管理和性能优化。

Kafka的演进：AutoMQ存算分离的创新与实现

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

在得物观测业务的数据链路中，Apache Kafka承担着数据收集、加工与分发的核心角色。然而，随着业务数据量的急剧攀升，Kafka原生的架构开始显现出瓶颈：

• 存储成本高昂：Kafka的存储部分占据了云资源开销的大头。虽然通过调整TTL和副本配置来控制成本，但存储费用依然居高不下。
• 冷读效率低下：在数据冷读场景下，磁盘吞吐极易达到上限，成为性能瓶颈。

• 运维复杂度高：随着集群规模扩大，Kafka的扩缩容操作变得异常复杂，伴随着较高的运维风险。

这些问题的根源在于Kafka面向传统IDC设计的Shared-Nothing架构，难以充分发挥云时代对弹性和扩展性的需求。

为什么选择AutoMQ

为了解决上述难题，得物选择了AutoMQ作为新一代的数据流引擎。其核心优势在于：

• 100%兼容Kafka协议：客户端与生态工具无需改造，迁移过程平滑。
• 真正的存算分离：基于对象存储和EBS研发的S3Stream共享流存储库，彻底替代了Apache Kafka的存储层，大幅降低成本，并支持存储与计算独立扩展。
• 卓越的弹性能力：支持动态扩缩容，无需数据迁移或停机，资源利用率显著提升。

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

在冷读场景下，Apache Kafka的性能缺陷尤为突出。其读写链路依赖Page Cache和零拷贝SendFile系统调用，但这也带来了问题：

• Page Cache：虽然简化了内存管理，但无法分离冷热数据。持续的冷读会与热数据争抢内存，导致追尾读能力下降。
• SendFile：该调用发生在网络线程池中。当冷读需要从磁盘拷贝数据时，会阻塞线程池，进而严重影响Kafka的写入性能。

AutoMQ通过存算彻底分离的架构，从根源上规避了这一问题。在相同负载下，AutoMQ能在保证写入吞吐和延迟不受影响的同时，提供与Kafka相当的冷读性能。

对比项	AutoMQ	Apache Kafka
冷读过程中发送耗时	小于 3ms	大约 800ms
冷读过程中对发送流量影响	读写隔离，维持 800 MiB/s	相互影响，下跌到 150 MiB/s
冷读效率（冷读 4TiB 数据耗时）	42 分钟	215 分钟

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

得物观测业务的流量呈现出显著的峰谷特征。AutoMQ的存算分离架构，配合秒级分区迁移技术，实现了卓越的弹性扩缩容能力：

• 快速扩容：业务高峰期，借助ASG或Kubernetes HPA，新节点可在十秒内加入集群并承担流量，分区实现秒级迁移与平衡。
• 智能缩容：流量低谷时，待下线节点的分区可快速迁移至其他节点，实现资源的快速回收。

与Apache Kafka需要通过数据复制进行扩缩容不同，AutoMQ基于共享存储，避免了繁琐的数据重平衡过程，效率得到质的提升。

案例：智能弹性实践
AutoMQ能够监控集群流量和CPU指标，自动触发扩缩容。当流量达到阈值，系统自动增加Broker；流量回落时，则优雅地将分区迁移后下线节点。

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

上线半年以来，AutoMQ已逐步替换了得物可观测性架构中对Apache Kafka的全部依赖，整体架构如下图所示：

AutoMQ带来了显著的成效：

• 云账单成本同比下降50%以上，运维效率大幅提升。
• 完成了近千核计算资源的替换，整体吞吐高达数十GiB/s。
• 平稳支撑双十一100%流量：避免了以往繁重的容量评估和提前扩容，整个双十一期间保持高可用、零宕机，高峰期负载平稳无抖动。

ClickHouse的进化：存算分离架构的实践与应用

背景与挑战

在分布式链路追踪场景中，得物采用ClickHouse作为Trace索引数据的存储引擎，每日管理数十万亿行数据。随着数据量从百TB级暴增至PB级，原有的自建开源分布式架构面临挑战：

• 成本压力：数据冷热存储成本激增。
• 扩展性差：每逢大促需手动扩容，流程复杂，影响业务。
• 容灾能力弱：为控制成本采用单副本策略，数据安全性面临挑战。
• 负载均衡难：扩容后需与上游协同rebalance，运维复杂度高。

ClickHouse企业版：存算分离新架构

ClickHouse企业版专为云环境设计，其核心创新在于存算分离架构与Serverless计算模型。计算与存储资源解耦，计算节点可根据负载自动弹性伸缩，存储则依托于共享对象存储，实现了极致的弹性与成本优化。

SharedMergeTree表引擎

这是实现存算分离的关键。SharedMergeTree引擎100%兼容社区版MergeTree语法，业务迁移无需改造DDL。它带来三大提升：

1. 共享存储支持：数据统一存于对象存储，计算节点无状态，按需访问。
2. 简化集群管理：无需再管理分片（Shard）或分布式表（Distributed Table），一张表即可。
3. 内核自动转换：社区版建表语句可被自动转换为企业版引擎。

CREATE TABLE T (id UInt64, v String)
ENGINE = ReplacingMergeTree
ORDER BY (id);

SELECT engine
FROM system.tables
WHERE name = 'T';

-- 查询结果 engine 为：SharedReplacingMergeTree

分钟级水平扩展能力

面对流量高峰，ClickHouse企业版能实现分钟级水平扩展，且扩缩容期间集群读写不受影响。

扩容流程简述：

1. 新节点加入：新计算节点注册到元数据服务（ClickHouse Keeper）。
2. 元数据同步：新节点从Keeper同步数据元数据，过程无锁，不影响集群。
3. 立即工作：同步完成后，新节点即刻可处理查询，访问共享存储中的数据。

落地实践与全方位优化

迁移至ClickHouse企业版后，得物在多个维度进行了优化：

架构简化与写入优化
新架构下，业务直接写入集群，通过负载均衡（LB）自动分配请求，彻底解决了分片间数据与流量不均衡的难题。

• 负载均衡：LB采用RR模式，在节点重启或故障时自动切换为WRR，保障集群无感。
• 性能飞跃：依托Serverless架构，支撑了每秒高达2000万行的写入峰值，40万行数据写入耗时优化至1秒左右。

查询优化

• 并行查询：利用Parallel Replica特性，将查询分发至多个节点并行处理，特定场景查询速度提升2.5倍。

  select trace_id,span_id, duration
  from span_index
  where service = 'order-xxx'
  and startTime between '2024-11-23 16:00:00' and '2024-11-23 17:00:00'
  order by duration desc
  limit 0,30
  settings max_threads = 16, 
  allow_experimental_parallel_reading_from_replicas = 1;

• 索引优化：调整ORDER BY字段与查询顺序，最大化利用索引，减少不必要的数据扫描。

容灾与弹性能力

• 高可用架构：默认3Keeper+双节点起，计算节点仅管理元数据，核心数据在共享存储中。单节点故障不影响数据访问与服务。
• 秒级弹性与按需付费：
  • 计算：监控CPU/内存，动态热修改Pod配置，资源秒级生效。按实际使用的CCU（约1核4G）秒级计费。
  • 存储：使用对象存储，按实际使用量付费，无需预留缓冲空间，存储成本降低70%+。

总结

通过引入AutoMQ和ClickHouse企业版，得物可观测性平台成功构建了新一代的存算分离架构。这一实践不仅解决了海量数据下的存储成本、扩展性和运维复杂度难题，更实现了显著的降本增效：

• 成本大幅优化：整体云资源成本下降约60%，其中计算成本优化20%，存储成本优化70%以上。
• 运维效率革命：实现了资源的秒级弹性伸缩与智能平衡，运维工作从“繁重的手工操作”转变为“高效的策略管理”。
• 稳定性显著提升：平稳支撑了双十一等极端流量场景，实现了高可用与零宕机。

这套架构为处理超大规模可观测性数据提供了经过生产验证的可靠路径，其设计思路与实践经验，对于面临类似挑战的技术团队具有很高的参考价值。欢迎在云栈社区交流探讨更多关于架构演进与性能优化的实战经验。