可觀測性方案怎么選？SelectDB vs Elasticsearch vs ClickHouse

可觀測性（Observability）是指通過系統的外部輸出數據，推斷其內部狀態的能力。可觀測性平臺通過采集、存儲、可視化分析三大可觀測性數據：日志（Logging）、鏈路追蹤（Tracing）和指標（Metrics），幫助團隊全面洞察分布式系統的運行狀態，支撐資源優化、預警機制、故障分析等，提升系統可靠性與用戶體驗。

SelectDB 針對可觀測性場景進行倒排索引、全文檢索、寫入性能、存儲空間等多方面優化，助力企業構建高性能、低成本、開放的可觀測性平臺，相對于 Elasticsearch 和云上日志服務，性能提升的同時成本降低數倍。

高性能： 寫入性能是 Elasticsearch 的 5 倍，日志查詢性能是其 2 倍，聚合統計分析性能是其 6～21 倍。
低成本： 以日增 100TB、保存 30 天、熱數據 3 天的需求，SelectDB Cloud 成本大約 20 萬/月，Elasticsearch 大約 140 萬/月，云廠商日志服務大約 135 萬/月。
易用性： 兼容 MySQL 語法；架構簡潔，支持無停服自動升級、彈性擴縮容及自動負載均衡；并提供可視化集群管理 Cluster Manager。
開放性： 在全球主流云上（阿里云、騰訊云、華為云、AWS、Azure、GCP）提供服務，支持 OpenTelemetry、Grafana、 Kibana 等開源和商業生態，保持生態開放性和中立性。

可觀測數據的特征以及各種方案之間的對比.png

接下來，我們將從多個角度深入分析和介紹，包括可觀測性場景需求、可觀測數據的特征以及各種方案之間的對比。幫助讀者全面地理解可 SelectDB 可觀測性方案的優勢和適用性。

為什么可觀測性越來越重要

可觀測性平臺在提升系統穩定性、優化運維效率和支持業務創新方面發揮著關鍵作用，近年來，可觀測性的地位日益提升，主要源于以下兩方面因素：

業務和 IT 系統越來越復雜： 隨著云計算和微服務的發展，業務系統日益復雜。例如，一個 GenAI 應用的請求可能涉及到 App、服務網關、鑒權服務、計費服務、RAG 引擎、Agent 引擎、向量數據庫、業務數據庫、分布式緩存、消息隊列、大模型 API 等數十個服務。傳統依賴登錄服務器查詢運行狀態和分析故障的方式，在復雜系統中已經不再有效。而可觀測性平臺統一采集和存儲 Log、Trace、Metrics 數據，提供統一可視化分析，能夠有效快速發現問題。
業務可靠性要求顯著提高： 系統故障及其恢復效率直接影響用戶體驗。可觀測性通過全域數據打通和全景可視化分析，支持團隊快速定位問題根源，縮短業務中斷時間，保障服務可用性。同時，依托全局數據分析和預測，能夠提前發現系統資源瓶頸，預防故障發生。

如何選擇可觀測性解決方案

可觀測性數據的特征

可觀測性解決方案的核心在于如何高效應對海量數據的存儲與分析挑戰，而可觀測性數據本身具有以下顯著特征：

數據存儲量大且對成本敏感： 可觀測性數據特別是 Log 和 Trace 規模極為龐大且持續生成。對于中大型企業而言，每天產生的可觀測性數據高達 100 TB 甚至 PB 量級。為了滿足業務需求或監管要求，這些數據往往需要存儲半年甚至更長時間，存儲總量長期維持在 PB 甚至 EB 級別，帶來高昂的存儲成本。而隨著時間的推移，這些數據的價值也在逐漸下降，因此對于可觀測性平臺來說，存儲成本也變的更加敏感。
數據寫入吞吐高且需要實時： 面對每天 TB 甚至 PB 量級新增數據，要求平臺具備 1 ～ 10GB/s、百萬～千萬條/s 的高吞吐寫入能力；同時，考慮到可觀測性數據常用于故障排查、安全追蹤等時效要求很高的場景，還要求平臺保證秒級寫入延遲，確保數據的實時性和可用性。
需要實時分析且支持全文檢索： Log 和 Trace 數據中有大量的文本，如何在其中快速檢索關鍵詞和短語是該場景的核心需求。由于數據規模龐大，傳統的全量掃描和字符串匹配方式在性能和擴展性上往往無法達到實時響應的要求，特別是在上述高吞吐低延遲實時寫入的前提下，實時文本檢索更加困難。
數據模式不固定且經常擴展： Log 最初始形態為非結構化原始日志，以 Free Text 的形式存在，逐步演變為以 JSON 為主的半結構化 Log 和 Trace，可自主增減 JSON 內部的字段，其數據的 Schema 非常靈活。傳統嚴格的數據庫和數據倉庫已難以應對，數據湖系統雖然具備存儲靈活性，但在處理性能和實時性方面卻無法滿足分析需求。
需要對接多種數據源和分析工具： 可觀測性生態中包含眾多數據采集器和可視化分析工具，存儲與分析引擎需兼容多種生態工具，滿足與多樣化數據和工具的高效集成。

可觀測性方案的選擇

當前市場呈多元化競爭態勢，Elasticsearch 、Clickhouse、SelectDB 及各大云廠商均提供了可觀測性方案。如何選擇合適的方案，企業需從性能、成本、易用性、開發性等方面綜合評估：

性能：包括寫入性能和查詢性能。 可觀測性常用于故障排查等緊急情況，一方面要求查詢響應要快，特別是 Log、Trace 數據中的文本，需要實時全文檢索支撐用戶迭代式探索分析；另一方面要能查詢到最新產生的數據，至少需查詢到最近幾秒的新鮮數據。
1. Elasticsearch 以倒排索引和全文檢索著稱，提供秒級實時檢索的能力，但在高吞吐下寫入性能較低，高峰期容易出現寫入拒絕和延遲過高的問題。其次，它的聚合統計分析能力性能也不太理想。
2. SelectDB 采用列式存儲和向量化引擎，針對可觀測性分析場景對倒排索引進行了優化，其性能優于 Elasticsearch ，寫入性能是 Elasticsearch 的 5 倍，查詢性能是其 2 倍，聚合統計分析性能是 Elasticsearch 的 6～21 倍。
3. Clickhouse 通過列式存儲和向量化引擎，在寫入和聚合查詢上有顯著優勢，但全文檢索性能相較于 Elasticsearch 或 SelectDB 存在數倍至數十倍的差距，并且當前仍處于實驗階段。
4. 云廠商日志服務通過豐富的資源滿足寫入和查詢性能，同時也帶來下面的成本問題。
成本：包括存儲成本和計算成本。 相比于業務數據，可觀測性數據的存儲量龐大、價值密度更低，而且隨著時間的推移，這些數據的價值持續下降，迫使企業更關注存儲成本。同時，海量數據寫入和查詢帶來的計算成本也很高，GB/s 的數據寫入、TB 甚至 PB 級的數據檢索往往需要大量的計算資源。
1. Elasticsearch 成本問題眾所周知，它采用原始數據行存 + 倒排索引 + docvalue 列存的存儲模式，壓縮比只有 1.5：1。同時，JVM 性能開銷和構建倒排導致寫入時 CPU 占用很高，計算資源成本也較高。對于日增 100TB、保存 30 天、熱數據 3 天的需求，Elasticsearch 成本大約 140 萬/月。
2. SelectDB 在可觀測性場景進行性能和成本雙重優化，同等負載下成本較 Elasticsearch 縮減 50% ～ 80%。存儲上包括倒排索引、列式存儲、ZSTD 壓縮的優化，壓縮比可達 5:1 ～ 10:1，結合冷熱存儲分層可進一步壓縮成本。寫入上包括單副本寫入、時序 compaction 減少寫放大、向量化索引構建等優化。對于日增 100TB、保存 30 天、熱數據 3 天的需求，SelectDB Cloud 成本大約 20 萬/月。
3. Clickhouse 采用列式存儲和向量化引擎，存儲和寫入成本也較低。
4. 云廠商日志服務的成本也很高，對于日增 100TB、保存 30 天、熱數據 3 天的需求，成本大約 135 萬/月。
易用性：包括易用性和易維護性。 由于數據量龐大，可觀測性平臺通常采用分布式架構，其部署、擴容、縮容和升級等運維操作的便捷性直接影響平臺的擴展能力。同時，系統接口設計也至關重要，既決定了平臺調用底層存儲的開發效率，也關系到終端用戶的使用體驗。
1. 在 Elasticsearch 的 ELK 生態中，Kibana 提供了直觀易用的 Web 界面，且易于維護管理。然而，其提供的 DSL 查詢語言復雜，學習門檻很高，對于可觀測性平臺對接和應用開發帶來較大挑戰。
2. SelectDB 提供與 Kibana 類似的交互式分析界面，并將對接 Kibana 和 Grafana 原生界面，查詢語言采用標準 SQL 并兼容 MySQL 語法，可觀測性平臺開發的開發門檻和使用難度均較低。其次，SelectDB 架構簡潔，支持無停服自動升級、彈性擴縮容及自動負載均衡，同時提供可視化 Cluster Manager 高效管理集群。
3. Clickhouse 雖提供 SQL 接口，但語法采用獨立體系，存在一定學習成本。且 Clickhouse 在維護管理上也面臨很多挑戰，比如本地表 + 分布式表的概念、擴縮容無法自動均衡等等，通常需要開發一套運維系統來支撐。
4. 云廠商日志服務提供 SaaS 服務，用戶無需自行維護系統，使用也比較方便。
開放性：包括開源開放和多云中立。 可觀測性平臺的建設還需要考慮是否會被綁定，需重點評估開源程度、多云服務支持能力及生態開放性，這些因素直接影響平臺的靈活性和長期可用性。
1. Elasticsearch 提供開源和商業版本，在多個云上提供服務。它的 ELK 生態比較獨立，難以與其他生態打通，比如 Kibana 只支持 Elasticsearch 而且很難擴展到其他系統。
2. SelectDB 是基于 Apache Doris 開源項目的商業版本，也是 Doris 社區的最大的貢獻者，在全球主流云上（阿里云、騰訊云、華為云、AWS、Azure、GCP）提供服務。SelectDB 支持 OpenTelemetry、Grafana、 Kibana 等開源生態和商業生態，保持生態開放性和中立性。
3. Clickhouse 提供開源和商業版本，在多個云上提供服務。Clickhouse 支持 OpenTelemetry、Grafana 等開源生態，同時收購了一家可觀測性商業公司，在生態支持上將很難保持中立性。
4. 云廠商日志服務會和自己的云綁定，不提供開源的選項，不同云廠商之間的產品，很難保持一致的體驗或者便捷的遷移。

可觀測數據的特征以及各種方案之間的對比-2.png

基于上述分析，可知 SelectDB 可以實現高性能寫入和查詢的同時保持很低的成本，且其架構簡單、易于維護和擴展，提供簡單易用的標準 SQL 接口，支持開源版本、商業版本和云上服務，確保私有化和多云部署體驗一致，是構建可觀測性平臺的理想選擇。

基于 SelectDB 的可觀測性解決方案

SelectDB 針對可觀測性場景的特點，在 MPP 分布式架構，結合向量化執行引擎、CBO 優化器基礎增加了倒排索引以及極速全文檢索能力，實現了寫入性能和存儲空間極致優化，能夠很好的應對可觀測性數據提出的挑戰，使用戶可基于 SelectDB 構建高性能、低成本、開放的可觀測性平臺。

系統架構

基于 SelectDB 的可觀測性平臺主要由 3 大核心部分組成：

數據采集和預處理：支持多種可觀測性數據采集工具，包括開放的 OpenTelemetry 生態和 ELK 生態中的 Logstash、Filebeat，可通過 HTTP API 將 Log、Trace、 Metrics 數據寫入 SelectDB。
數據存儲和分析引擎：SelectDB 提供高性能、低成本的統一可觀測性數據存儲，并可通過 SQL 接口提供豐富的檢索和分析能力。
查詢分析和可視化：對接最常用的可觀測性可視化分析工具，包括廣泛使用的 Grafana 和 ELK 生態中的 Kibana，為用戶提供簡單易用的界面，以進行檢索、分析，并設置告警規則，實現實時監控和快速響應。

基于 SelectDB 的可觀測性解決方案.png

基于 SelectDB 的可觀測性解決方案有以下特點及優勢：

高性能
- 高吞吐、低延遲寫入：支持每天 PB 級 (10GB/s ） 的 Log、Trace、Metrics 數據持續穩定寫入，同時保持延遲在秒級甚至毫秒級。
- 高性能倒排索引和全文檢索：支持倒排索引、全文檢索、日志場景關鍵詞檢索，并能在秒級響應，實測性能是 Clickhouse 的 3～10 倍。
- 高性能聚合分析：基于 MPP 分布式架構和向量化 Pipeline 執行引擎，充分利用集群分布式和 CPU 多線程資源，在 ClickBench 測試中實現全球領先性能，可很好支撐可觀測性場景的趨勢分析、監控告警等常見查詢。
低成本
- 高壓縮率和低成本存儲：支持 PB 級海量存儲，壓縮率可達 5:1 ～ 10:1 甚至更高（包括索引），比 Elasticsearch 存儲成本節省 50% ～ 80%，支持冷數據存儲到 S3/HDFS，存儲成本再降 50%。
- 低成本寫入：同樣的寫入流量， SelectDB 的 CPU 資源消耗比 Elasticsearch 至少降低 70% 。
Flexible Schema
- 頂層字段變更：可以通過 Light Schema Change 發起 ADD / DROP COLUMN / INDEX 增加 / 刪除列 / 索引，并能夠在秒級完成 Schema 變更。用戶在規劃可觀測平臺時，只需關注當前需要哪些字段需要創建索引。
- 字段內部變更：專門為可擴展的 JSON 數據設計了半結構化數據類型 VARIANT，可以自動識別 JSON 中的字段名和類型，并自動拆分頻繁出現的字段進行列式存儲，提高壓縮率和分析性能。相對于 Elasticsearch 的 Dynamic Mapping，VARIANT 允許字段的類型發生變化。
易用性
- 標準易用的 SQL 接口：SelectDB 支持標準 SQL、兼容 MySQL 協議和語法，基于 SelectDB 構建的可觀測性平臺能夠使用 SQL 進行查詢，對工程師和數據分析師非常友好。
- 擁抱可觀測生態：兼容 OpenTelemetry 和 ELK 生態，無縫對接 Grafana 和 Kibana 等主流可視化工具，便于用戶采集數據以及可視化分析。
- 運維方便：無需停服即可在線擴縮容、自動均衡；私有化部署提供可視化 Cluster Manager 和 K8s Operator 工具；云上提供開箱即用的免運維服務。
開放性
- 開源開放：SelectDB 是基于 Apache Doris 開源項目的商業版本，也是開源社區最大的貢獻者，支持 OpenTelemetry Grafana 等開源生態和商業生態。
- 多云中立：SelectDB 已與主流云廠商（阿里云、騰訊云、華為云、AWS、Azure、GCP）合作，為用戶提供多云一致的體驗。

Demo & Screenshot

以下，我們通過 OpenTelemetry 社區的全方位演示 Demo ，來展示基于 SelectDB 構建的可觀測性平臺能力。

如下方視頻所示：被觀測的業務系統是一個十多個模塊組成的電商網站，壓力模擬程序 Load Generator 持續請求入口服務，在整個電商系統中產生大量的可觀測性數據（Log、Trace、Metrics），這些數據使用 OpenTelemetry 的各種語言 SDK 進行采集，發送給 OpenTelemetry Collector，Collector 中的 Processors 進行預處理，然后經過 OpenTelemetry Doris Exporter 寫入到 SelectDB，在通過 Grafana 進行可視化分析。

Grafana 通過 MySQL Datasource 連接到 SelectDB，提供統一的 Log、Trace、Metrics 可視化分析，還可以實現 Log 和 Trace 的聯動。

Log
Trace
Metrics

Grafana 的 Log 可視化和分析能力相對于 Kibana 來說是比較簡單的，因此在 SelectDB Studio 中實現了類似 Kibana Discover 的檢索分析能力，未來也會集成到 Grafana Doris datasource 中，提供更好的統一 Log Trace Metrics 可視化分析能力。

此外，在未來一個季度，SelectDB 將通過兼容 Elasticsearch 查詢協議，實現原生 Kibana 直接連接到 SelectDB。對于 ELK 用戶而言，如果將 Elasticsearch 替換為 SelectDB，可在不改變日志采集和可視化分析使用習慣的前提下，實現降本增效的目標、降低了原用戶的使用門檻。

Studio Discover.png

用戶聲音

案例 1：觀測云

觀測云使用 Doris 的商業化版本 SelectDB 替代了云上的 Elasticsearch。通過 SelectDB 的倒排索引能力、Variant 數據類型、冷熱數據存儲分層等特性，為觀測云日志存儲和分析場景服務注入強大的動力，實現存儲成本降低 70% 的同時，查詢性能提升 2-4 倍，最終實現整體性價比 10 倍提升。

觀測云.png

案例 2 ：中信銀行信用卡

為確保業務系統的穩定運行、提升運維效率和用戶體驗，中信銀行信用卡中心建立了大規模的日志云分析平臺。支持實時監控和故障排查、滿足金融監管對日志審計的嚴格要求。目前，平臺每日新增日志數據突破百 TB，全量歸檔日志量達 PB 級。

早期基于 Elasticsearch 構建的日志云平臺面臨存儲成本高、實時寫入性能差、文本檢索慢以及日志分析能力不足等問題。因此，卡中心引入 Apache Doris 替換 Elasticsearch，實現資源投入降低 50%、查詢速度提升 2～4 倍，同時顯著提高了運維效率。

中信銀行信用卡.png

案例 3：MiniMax

MiniMax 引入阿里云數據庫 SelectDB 版構建了覆蓋國內及海外業務的日志可觀測中臺，總體數據規模超過數 PB，日均新增日志寫入量達數百 TB。系統在 P95 分位查詢場景下的響應時間小于 3 秒，峰值時刻實現了超過 10GB/s 的讀寫吞吐。通過存算分離、高壓縮比算法和單副本熱緩存等技術手段，MiniMax 在優化性能的同時顯著降低了建設成本，計算資源用量降低 40%，熱數據存儲用量降低 50%，為未來業務的高速發展和技術演進奠定了堅實基礎。

結束語

基于 SelectDB 的高性能倒排索引、高吞吐量寫入和高壓縮存儲，用戶可以構建出性能高于Elasticsearch 10 倍的可觀測性平臺，并支持國內外多個云上便捷使用 SelectDB Cloud 的開箱即用服務。

SelectDB 將在可觀測性內核能力和生態支持上持續進化，未來幾個月將推出以下新功能：

通過 es2doris proxy 實現與原生 Kibana 的可視化分析對接，結合現有的 Logstash Doris Output Plugin，幫助 ELK 生態的用戶平滑遷移到 SelectDB。
通過 Grafana Doris Datasource 提供 Grafana Native Support，并將類似 Kibana Discover 的交互式檢索分析能力集成到 Grafana，讓 Grafana 用戶也能獲得更好的檢索分析體驗。
增強倒排索引和全文檢索能力，支持更多分詞器，如 ik、icu、edge ngram，同時允許自定義組合分詞器。
增強半結構化數據分析 VARIANT，支持不頻繁字段的合并存儲，并根據字段名指定類型和索引等。