ClickStack 六、七月更新：Trace 迷你地圖、指數直方圖分位數與文字索引加速篩選
ClickHouse 官方部落格 · 2026-08-10
ClickHouse 於 2026-08-10 發布 ClickStack（前身為 HyperDX 可觀測性堆疊）六、七月合併更新，涵蓋 trace 檢視、指標 schema 與儀表板告警三大區塊。對應的套件版本已在 GitHub 上釋出至 @hyperdx/app@2.34.0（2026-08-07），前一個里程碑為 2.33.0（2026-07-31）與 2.32.0（2026-07-27）。這批更新主要針對大規模 trace 除錯與 Prometheus 相容場景做加固。
Trace 檢視與跨追蹤導覽
Waterfall 視圖新增固定服務配色，同一個 service 在不同 trace 之間會維持一致顏色，降低視覺辨識成本。針對長 trace，新增了縮圖式迷你地圖（minimap）用於快速跳轉到特定時間區段。詳細面板現在會顯示 OpenTelemetry 的 span links，讓使用者可以直接跳轉到被連結的另一條 trace，取代先前只能手動複製 trace ID 再搜尋的流程。
指標 schema 與儲存優化
指標端新增了對指數直方圖（exponential histogram）的分位數查詢支援。指數直方圖是 OpenTelemetry 指標協定中的一種直方圖型態，其桶界以指數比例（而非固定寬度）分佈，能在有限桶數下同時涵蓋小數值的高精度與大數值的寬範圍，因此適合估算 p50、p95、p99 等分位數且記憶體開銷較低。ClickStack 同時開放外部相容 Prometheus 端點的連線方式，並將預設指標 schema 由「排序鍵中儲存完整屬性 map」改為「雜湊屬性後再排序」，藉此縮小排序鍵體積、加快寫入與合併效率。
儀表板與告警行為
儀表板篩選器現在會互相收斂：選定一個篩選條件後，其餘篩選器的可選值會依據既有條件動態縮限，類似 faceted search 的體驗。告警評估新增「連續視窗」模式，需連續多個評估週期都超過閾值才觸發，用來壓低單次尖峰造成的誤報。新增的 kiosk 模式則提供純唯讀、適合電視牆展示的介面。
影響範圍
- 新增分類長條圖（categorical bar chart）與事件模式（event pattern）作為儀表板小工具類型
- 篩選器自動完成改用 ClickHouse 文字索引（text index）加速，大幅縮短輸入時的候選值回應時間
- OpenTelemetry Collector 新增 Datadog receiver，可直接接收 Datadog agent 送出的資料
@hyperdx/otel-collector@2.34.0、@hyperdx/common-utils@0.25.0、@hyperdx/hdx-eval@0.3.1同步發布
這些改動不需要使用者手動遷移 schema，多數功能在升級套件版本後即自動生效，僅指標 schema 的雜湊化屬性對舊資料維持相容讀取。
原始來源：ClickHouse Blog：What's new in ClickStack - June + July、hyperdxio/hyperdx GitHub Releases
南韓時尚平台 Musinsa 遷移 ClickHouse Cloud：儲存成本降 86.5%、TCO 最高減 71.4%
ClickHouse 官方部落格 · 2026-08-09
韓國最大時尚電商平台 Musinsa 於 2026-08-09 公開的案例研究中，說明其客戶資料平台（CDP）與受眾引擎（Audience Engine）如何從自架 ClickHouse 遷移至 ClickHouse Cloud。Musinsa 目前擁有 1,640 萬會員與約 1,100 家合作品牌，服務橫跨 13 個國家，遷移後儲存成本降低 86.5%，整體總持有成本（TCO）最高減少 71.4%。
原本的問題
自架 ClickHouse 架構下，運算與儲存綁定在同一組節點，Musinsa 必須為尖峰容量預先配置固定的運算資源，導致閒置運算容量長期被浪費。受眾引擎需要同時執行即時查詢與批次計算兩種特性差異很大的工作負載，兩者共用叢集資源時彼此互相搶佔，造成延遲不穩定。即時資料寫入原本透過 Databricks Auto Loader 銜接，管線環節多、維運複雜度高。
採用的方法
ClickHouse Cloud 透過 SharedMergeTree 表引擎將運算與儲存拆分，資料實際落在共享的 S3 物件儲存層，運算節點僅作為無狀態的查詢與合併執行者。相較於自架環境需手動設定 S3BackedMergeTree 才能達到類似效果，Cloud 版本免除了這層設定負擔。Musinsa 進一步為即時查詢與批次工作負載分別配置獨立運算資源，兩者互不干擾，並啟用自動閒置（automatic idling）與垂直自動擴縮（vertical autoscaling），閒置的工作負載會自動降載甚至暫停計費。資料寫入則改用 ClickPipes 原生管線，取代原本的 Databricks Auto Loader，簡化了即時資料攝取的維運鏈路。
實際效果
| 指標 | 數值 |
|---|---|
| 會員數 | 1,640 萬 |
| 月活躍用戶（MAU） | 720 萬 |
| 合作品牌數 | 約 11,000 家 |
| 受眾（audience）數量 | 2,500 組 |
| cohort-to-user 映射筆數 | 約 11 億筆 |
| 儲存成本降幅 | 86.5% |
| TCO 降幅（最高） | 71.4% |
案例中強調，儲存與運算分離讓 Musinsa 不必再為「支付未使用的運算容量」付費，而按工作負載獨立擴縮的能力則直接反映在總持有成本的下降上。以約 11 億筆 cohort-to-user 映射的規模而言，這樣的成本結構調整對於持續成長的受眾清單尤其明顯。
原始來源：ClickHouse Blog：How Musinsa scaled its audience engine with ClickHouse Cloud、ClickHouse Docs：Storage and compute separation