得物新一代可觀測性架構：海量資料下的存算分離設計與實踐

一、引言

得物作為全球領先的潮流網購社群，日益增長的使用者和資料帶來了巨大的技術挑戰。當前，得物的可觀測性平臺每天生成數PB級Trace資料和數萬億條Span記錄，要求平臺具備高效的實時處理能力和低成本的資料儲存解決方案。

傳統的存算一體架構將計算與儲存資源繫結，隨著資料規模的擴大，暴露出了以下問題：

擴充套件性受限：存算資源無法獨立擴充套件，導致計算和儲存的擴容必須同步，進而提升了成本。
資源利用率低：計算與儲存資源無法按需動態調整，造成閒置資源浪費。
運維複雜性高：叢集擴充套件和縮容涉及複雜的資源遷移，增加了運維難度。

為了有效解決這些問題，得物可觀測性平臺採用了存算分離架構，結合AutoMQ和Kafka以及ClickHouse儲存技術，實現了高效的資源管理和效能最佳化。

二、Kafka的演進：AutoMQ存算分離的創新與實現

2.1 Apache Kafka在大規模資料下的挑戰

Apache Kafka處於得物觀測業務的核心資料鏈路中

在得物的可觀測性平臺中，Apache Kafka被廣泛用於資料收集、加工和分發。然而，隨著業務資料量的不斷增長，Kafka的架構暴露出以下問題：

儲存成本高：Kafka的儲存部分佔據了大部分（計算與儲存成本比例為1:3）雲資源開銷，為了控制成本，得物調整了Kafka的資料TTL和副本配置，但儲存成本仍居高不下。
冷讀效率低：冷讀場景下，磁碟吞吐量常達到上限，導致效能瓶頸。

得物 Kafka 磁碟高危報警

運維複雜性高：隨著叢集規模的擴大，Kafka叢集的擴縮容操作變得更加複雜，面臨較高的運維風險。

這些問題源於Kafka原生架構的侷限性，特別是其面向IDC環境的Shared-Nothing架構，難以充分發揮雲端計算時代對彈性和擴充套件性的要求。

2.2 為什麼選擇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透過監控叢集流量和CPU等指標，自動進行擴縮容。當流量達到擴容閾值時，系統會自動增加Broker節點；當流量下降至縮容閾值時，系統會優雅地將即將下線的Broker上的分割槽以Round-Robin方式秒級遷移至其他Broker，完成流量平衡。

叢集節點數跟隨流量上漲

叢集節點數跟隨流量下跌

2.3 AutoMQ落地效果：千核資源替換，成本下降50%

AutoMQ在得物可觀測性平臺上線半年以來，逐步替換了整個可觀測性架構對Apache Kafka的依賴，基於AutoMQ的整體可觀測架構如下圖所示，AutoMQ叢集承擔了所有微服務業務的產生的觀測資料，並基於ClickHouse進一步提供點查和觀測資料分析的能力。

得物基於AutoMQ的可觀測架構

AutoMQ也為得物可觀測性平臺帶來了以下顯著的成效：

雲賬單成本同比下降50%以上，同時運維效率大幅度提升。
完成近千核計算資源替換，總體吞吐高達數十GiB/s。

AutoMQ落地效果：平穩支撐得物雙十一期間100%流量

除了成本大幅度降低之外，今年透過AutoMQ的架構支撐得物雙十一，避免了過往雙十一前繁重的容量評估工作，以及提前擴容的運維成本。AutoMQ叢集上線以來，以及雙十一期間全程保持高可用，零當機，支撐了雙十一期間100%的流量，且高峰期負載平穩，無效能抖動。如下圖是得物可觀測性平臺AutoMQ叢集中其中一個GiB級吞吐的叢集。

得物其中的一個AutoMQ GiB級叢集

三、ClickHouse的進化：存算分離架構的實踐與應用

3.1 背景

得物可觀測性平臺在分散式鏈路追蹤中，採用ClickHouse作為Trace索引資料的儲存引擎，每天管理著數十萬億行追蹤資料。隨著資料量的持續增長，平臺不僅需要保障實時查詢的高效效能，還面臨著儲存成本最佳化和叢集維護複雜度提升的雙重挑戰。

面臨的挑戰

ClickHouse憑藉卓越的效能，在面對大規模資料時依然能夠提供極快的查詢響應，為可觀測性平臺的實時分析和監控提供了堅實保障。然而，隨著業務擴充套件和資料量激增，原有的基於雲盤自建的開源分散式架構逐漸暴露出了一些問題：

成本高：得物的Trace平臺從2022年至今，資料量從日增百TB級增長到數PB，膨脹了30倍。資料冷熱儲存的成本壓力增加。
可擴充套件性差：作為一個電商平臺，每年的雙11和618等購物節，Trace平臺都會迎來數倍的流量上漲，為了保證業務的穩定執行，每逢業務高峰都要進行叢集的擴容，分散式架構下叢集擴容麻煩、需要停寫影響業務，再加上叢集擴容中的協調難題都為平臺的維護帶來了額外的工作量和穩定性壓力。
容災能力較低：在實際應用中，考慮到海量資料產生的成本問題，得物並未採用多副本策略，而是透過單副本儲存來最佳化資源利用率和降低儲存開銷，在更加追求系統穩定性和資料安全保障的今天，如何提高系統的容災能力也成為了一個重要的課題。
叢集寫入負載平衡難：為了平衡叢集節點的寫入負載，每次擴容時需與上游服務協同進行rebalance，以合理分配資料至新節點。這一過程雖確保了擴充套件後的叢集效能，但對運維效率提出了更高的要求，涉及資料分佈調整和寫入負載平衡的精細化管理。

因此，如何在保持ClickHouse效能優勢的同時，最佳化擴容過程中的運維流程，解決叢集寫入負載平衡問題，進一步提升系統的穩定性，是得物平臺在持續擴充套件中亟需解決的核心問題。

3.2 ClickHouse企業版介紹

ClickHouse企業版是專為雲環境下的存算分離架構設計，支援更高效的計算與儲存資源管理。企業版與社群版的最大區別在於，它引入了更先進的存算分離架構和更多功能，能夠在大規模資料處理、實時查詢和儲存管理方面提供更優的效能。

存算分離架構是ClickHouse企業版的核心創新，它透過將計算資源和儲存資源分開，極大地提高了系統的彈性和擴充套件性。在這種架構下，計算節點和儲存節點獨立擴充套件，儲存資源可以透過共享儲存（如OSS、S3等）進行集中管理，而計算節點則能夠根據負載情況進行自動伸縮，從而更好地應對流量高峰期的挑戰。

企業版還引入了Serverless計算模型，允許平臺根據實際負載自動調整計算資源的大小。相比於傳統的基於固定資源分配的計算模式，Serverless架構能幫助平臺實現彈性伸縮，只在需要時自動分配計算資源，極大地節省了資源開銷，同時也能更好的應對業務流量的非預期增長，提高了系統的穩定性。

SharedMergeTree表引擎

在ClickHouse企業版中，SharedMergeTree表引擎是實現存算分離架構的關鍵元件。SharedMergeTree最佳化了對共享儲存（如Amazon S3、Google Cloud Storage、MinIO、阿里雲OSS等）的支援，100%相容社群版的MergeTree引擎的同時，核心還可以自動將社群版的建表語句轉化為企業版專屬引擎的建表語句（如下圖所示），業務遷移無需DDL改造。

與傳統的ClickHouse叢集架構相比，SharedMergeTree引擎透過以下方式提升了資料儲存和查詢效能：

共享儲存支援：所有資料都儲存在共享儲存中，而計算節點透過訪問共享儲存來執行查詢和分析。這種設計使得資料的儲存和計算完全分離，計算節點無需持有資料副本，從而降低了儲存和計算資源的冗餘。
無狀態計算節點：計算節點不再儲存資料副本，而是透過訪問共享儲存中的資料進行計算。這使得每個計算節點都是“無狀態”的，具有更好的擴充套件性和容錯能力。在面對流量高峰時，新的計算節點可以快速加入並開始工作，而不需要重新分配或遷移資料。
簡化叢集管理：使用者無需管理傳統的Shard或Distributed Table，SharedMergeTree引擎只需建立一張表即可，簡化了叢集管理流程，降低了維護複雜度。

水平擴充套件

在大規模電商平臺的場景下，面對節假日等流量高峰時，系統需要具備快速擴充套件和高可用性的能力。ClickHouse企業版透過SharedMergeTree引擎，實現了分鐘級水平擴充套件，並且在擴充套件過程中叢集可正常執行讀寫任務，穩定性不受影響。

擴容流程：

新節點（Server-3）加入：當需要增加計算節點時，新節點首先註冊至叢集的後設資料管理服務（如Keeper），並開始監聽資料後設資料變化。
後設資料同步：新節點從Keeper同步當前有效的後設資料，無需鎖定叢集，不會影響叢集其他節點的操作。
立即參與工作：新節點完成後設資料同步後，立即可以處理查詢請求，並按需訪問共享儲存中的資料。

透過這種方式，ClickHouse企業版能夠在高負載下實現彈性擴充套件，確保叢集的穩定性和業務的連續性。

3.3 落地實踐與最佳化

最終，得物可觀測性平臺基於ClickHouse企業版的功能，在寫入、查詢、容災能力及彈效能力方面進行了全面最佳化，實現了高效能和高效率的分散式鏈路追蹤系統。

從自建ClickHouse社群版升級為企業版，因為企業版的存算分離架構不再有分片的概念，不再需要透過直連本地表進行寫入的方式對不同分片間的資料和寫入流量進行均衡，所以和原先直連節點做寫入的方式不同，切換為企業版後業務寫入操作的物件變為了叢集本身，寫入邏輯得到了簡化，原有的寫入流量和分片間資料不均衡帶來的運維和管理的問題也從架構上得到了解決。

寫入最佳化

以下是具體的實踐總結：

負載均衡：藉助負載均衡（LB），將寫入請求均勻分配到多個計算節點，避免單節點過載，提高系統穩定性。lb採用rr模式，當叢集版本升級進行節點的分批重啟、以及叢集中某一節點進行故障重建時，會自動調整為wrr模式來保障叢集的整體無感。
效能提升：利用ClickHouse企業版的Serverless架構，成功支援了分散式鏈路追蹤場景下叢集每秒高達2000萬行的寫入操作，單次請求40萬行資料寫入耗時最佳化至1s左右。

查詢最佳化

並行查詢：透過Parallel Replica特性，將查詢分發至多個節點並行處理，顯著提高效率。在特定場景下，查詢速度提升可達2.5倍。整體查詢效率與自建ClickHouse不相上下。

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+至少雙節點架構，每個計算節點都儲存著一份完整的後設資料，且計算節點僅管理後設資料，核心業務資料儲存於共享儲存中。因此，單節點故障不會影響資料訪問，其餘節點可繼續提供服務，確保業務穩定性。
高可用儲存：透過採用如OSS等分散式物件儲存，平臺實現了高冗餘的資料儲存，進一步增強了系統在硬體故障情況下的恢復能力。

彈效能力

秒級彈性擴容：平臺能夠根據業務負載的實時變化，自動調整計算資源。透過監控CPU和記憶體使用，系統動態決策並熱修改Pod配置，使擴容資源即時生效，無需重啟服務。按需付費：
計算按需付費：
每個節點的彈升和彈降都是獨立進行，只和當前節點的實際業務負載有關的，因此無需再擔心各節點間流量壓力差異帶來的成本冗餘；同時節點的彈性擴容和縮容的最小單位均為1CCU（約1C4G），擴容事件同步至計費模組後，平臺按秒計費，僅需為實際資源使用量付費。這一機制幫助得物大幅降低了資源浪費，同時確保了成本最佳化。
儲存按實際使用量付費：相比存算一體架構下需要預留至少20%的儲存空間來保障叢集的穩定性的資源預購模式，ClickHouse企業版的共享儲存解決了自建社群版各分片資料不均衡、運維麻煩、成本冗餘多的問題，同時僅按照實際使用量計費的模式結合物件儲存本身價格低廉的特徵，降低了得物大資料量場景下的儲存成本70%+。

四、總結

透過ClickHouse企業版，得物可觀測性平臺實現了從寫入到查詢、從容災到彈性的全面最佳化。企業版的存算分離架構提升了系統可靠性，而秒級彈效能力結合秒級按需付費顯著降低了計算資源的使用成本約20%和儲存資源的採購成本70%+（總成本下降60%）。這種實踐模式不僅滿足了高併發、高效能的業務需求，同時也為系統的擴充套件性和運維效率提供了有力支援，成功應對了鏈路追蹤資料管理中的各種挑戰。

五、引用

[1]AutoMQ基於S3的共享流儲存庫：https://docs.automq.com/zh/automq/architecture/s3stream-share...[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...[6]AutoMQ秒級分割槽遷移：https://docs.automq.com/zh/automq/architecture/technical-adva...[7]AWS Auto Scaling Groups: https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-sc...[8]Kubernetes用於擴容的 HPA 元件：https://kubernetes.io/docs/tasks/run-application/horizontal-p...[9]AutoMQ持續資料自平衡：https://docs.automq.com/zh/automq/architecture/technical-adva...[10]阿里云云資料庫ClickHouse：https://help.aliyun.com/zh/clickhouse/?spm=a2c4g.11174283.0.0...

敬請期待本系列的下一篇文章：《得物可觀測性平臺基於RUST如何在生產環境構建萬億流量》。在這篇文章中，我們將深入探討如何利用RUST技術在生產環境中高效處理萬億級別的流量，以及我們在這一過程中積累的經驗和教訓。

往期回顧

1.StarRocks存算分離在得物的降本增效實踐
2.盤點這些年搭建器在使用者體驗最佳化的實踐｜得物技術
3.解析Go切片：為何按值傳遞時會發生改變？｜得物技術
4.Java效能測試利器：JMH入門與實踐｜得物技術
5.彩虹橋架構演進之路-負載均衡篇｜得物技術

文 / 南風

關注得物技術，每週更新技術乾貨要是覺得文章對你有幫助的話，歡迎評論轉發點贊～未經得物技術許可嚴禁轉載，否則依法追究法律責任。