從 Elasticsearch 到 SelectDB，觀測雲實現日誌儲存與分析的 10 倍價效比提升

導讀：在雲端計算逐漸成熟的當下，越來越多的企業開始將業務遷移到雲端，傳統的監控和故障排查方法已經無法滿足企業的需求。觀測雲可以實現對雲、雲原生、應用及業務的統一監測，提供整體資料的分析、洞察、視覺化、自動化、監測告警、智慧巡查、安全巡查等服務。本文將分享   如何助力觀測雲完成日誌資料儲存和分析架構升級，實現在儲存成本降低 70% 的同時、查詢效能提升 2-4 倍，最終實現整體價效比 10 倍提升，為日誌儲存和分析場景服務提供強大動力。

上海觀測未來資訊科技有限公司是一家國內領先的具備可觀測性實時資料檢測平臺的公司，其自研產品「觀測雲」首批透過中國信通院頒發的「可觀測性平臺技術能力」先進級認證，可實現對雲、雲原生應用及業務系統的統一觀測需求，為網際網路、零售、金融等行業使用者提供統一高效的數字化可觀測服務。

在雲端計算逐漸成熟的當下，越來越多的企業開始將業務遷移到雲端，傳統的監控和故障排查方法已經無法滿足企業的需求。在可觀測理念逐漸深入人心的當下，人們越來越意識到透過多層次、多維度、多視角的資料去觀測應用系統來提升故障的定位效率以及業務分析能力。而觀測雲本質上是一個全面性的、可觀測性的解決方案，可提供整體資料的分析、洞察、視覺化、自動化、監測告警、智慧巡查、安全巡查等服務。

為更好提供上述服務，要求觀測雲具備對基礎物件、網路效能、日誌、應用效能、使用者體驗、可用性甚至 CI 進行觀測的能力。這些能力要求觀測雲能夠統一整合來自多個場景和多種結構的海量資料，並提供全面的日誌檢索分析能力，快速實現資料查詢、篩選和分析。

為解決觀測雲在日誌儲存和分析場景所面臨的挑戰，飛輪科技與觀測雲進行了全面合作。 透過 SelectDB 的倒排索引能力、Variant 資料型別、冷熱資料分層儲存等特性，為觀測雲日誌儲存和分析場景服務注入強大的動力，實現儲存成本降低 70% 的同時，查詢效能提升 2-4 倍，最終實現整體價效比 10 倍提升！

GuanceDB 原有架構

觀測雲具備強大的資料接入能力，透過自研的 All In One 採集工具 DataKit 可以從不同端側、業務層、中介軟體、基礎設施等不同層獲取資料，同時進行預處理和元資訊關聯。除了廣泛支援日誌資料以外，Datakit 還支援採集和處理基礎設施的時序指標、鏈路追蹤、安全事件以及在 APP 端或瀏覽器端的使用者行為資料等。為了滿足多元化的多場景需求，DataKit 不僅對開源探針和採集器進行了全面相容，還支援對自定義格式的資料來源接入。

DataKit 採集的資料，經過核心計算層處理後，會統一儲存到 GuanceDB 中。GuanceDB 是一個觀測雲自主研發的由多種資料庫技術組成的多模態資料庫。

GuanceDB 的內部架構如上圖所示，主要包含查詢引擎 Query Engine 和儲存引擎 Storage Engine 兩層。在邏輯結構上查詢引擎與儲存引擎透過抽象解耦，整體架構上實現了可拔插可替換。

觀測雲基於 VictoriaMetrics 儲存模組研發了時序儲存引擎 Metric Store，同時在泛日誌場景整合了 Elasticsearch/OpenSearch。這樣的設計使 GuanceDB 對外有統一的寫入和查詢介面，能適應不同型別的資料格式和業務需求。在當前的實現中，MetricStore 已經具備卓越的效能。然而，對於日誌類和使用者行為類資料的處理來說，Elasticsearch 卻有諸多不足，具體表現如下：

• 寫入佔用資源多：Elasticsearch 在處理高頻寫入大量的資料時，會佔用較高的 CPU 和記憶體資源，這不僅會顯著增加叢集成本，還會擠佔查詢所佔用的資源。
• 對無模式表支援差：Elasticsearch 對於 Schemaless 支援有限，當前的 Dynamic Mapping 在面對大量的使用者自定義欄位時，會頻繁造成欄位型別衝突，導致資料丟失，需要人工介入進行手動處理。
• 聚合查詢效能差：Elasticsearch 在面對海量資料時，聚合效能表現較差。例如對億級資料計算分位數、錯誤率時，極易出現超時，很難滿足大規模資料下的業務分析需求。

選型目標及調研

原有架構中 Elasticsearch 存在的問題推動我們對架構進行升級，在升級之前，我們調研了包括 SelectDB 在內的多款資料庫。結合實際可觀測性場景，我們選型目標如下：

• 高吞吐高效能：在可觀測場景下，業務資料的規模會隨著業務複雜度和業務規模線性遞增。為滿足這一需求，我們需要一種既能支援高吞吐實時寫入，又能支援高效能資料分析，同時叢集本身易於運維、支援橫向擴充的儲存方案。
• 全文倒排索引：全文倒排索引能夠顯著提升檢索效能並降低查詢的資源開銷，是實現高效日誌分析的必備能力。在調研中，我們也注意到了像 Loki 這樣的無索引方案， 這類方案雖然簡單，但當請求 QPS 稍高時，全盤掃描時磁碟 IO 和 CPU 資源開銷爭搶就會非常激烈，無法承載日誌圖表展示、聚類篩選分析、實時告警等業務需求。
• 支援多種業務寫入和查詢場景：觀測雲採集的業務場景豐富多樣，包括海量吞吐的追加寫、程式和主機等物件資料的整體週期性更新、 RUM 場景下 Session 會話部分更新等，同時覆蓋高頻點查、列表查詢、大範圍聚合查詢等多種查詢場景，這就需要新方案能夠支援多種業務寫入和多樣化場景查詢。
• 支援無模式表：可觀測業務場景中有大量的欄位元資訊是業務工程師根據業務需求手工維護的，為了更好的適配這種場景，儲存層就需要支援 SchemaLess，無需上層業務維護資料表的 Schema 資訊，並且能夠自動處理型別衝突。
• 支援大規模租戶隔離：在 SaaS 場景中，我們有大量的租戶和分表，這些後設資料本身會給系統造成較大管理壓力。在使用 Elasticsearch 時，其單個叢集能支援的索引數有限，一旦達到某個索引數量，效能就會急劇下降，因此需要將資料分散到不同的叢集中，這給叢集管理造成了諸多困擾
• 降低長期儲存成本：可觀測類的資料價值會隨時間遷移而遞減，我們希望能透過冷熱分離、存算分離等技術手段，將長期儲存的資料儲存到物件儲存中，以降低資料的總體儲存成本。

綜合來看，SelectDB 能夠滿足觀測雲的大部分需求，並且在與同類產品的對比中表現出色，我們也會在後面的章節中詳細介紹基於 SelectDB 的改造實踐。特別值得一提的是，在前期調研中，以下特性是吸引我們的重要特性：

• SelectDB 倒排索引可使得儲存空間節約超 80% 、寫入速度是 Elasticsearch 的 5 倍、查詢效能是 Elasticsearch 的 2.3 倍。
• SelectDB 針對 JSON 等半結構化資料設計了 Variant 資料型別，可以將任意結構的 JSON 存入 Variant 型別中，可以對 JSON 內部的欄位和型別自動分析、對頻繁出現的欄位採用列式儲存，提升儲存和分析的效
• SelectDB 可以支援上千個資料庫和上萬個資料表，能夠實現一個租戶獨立使用一個資料庫，實現多租戶資料隔離的需求，滿足資料的隔離和安全性。

基於 SelectDB 的儲存架構升級

因此我們引入 SelectDB 對 GuanceDB 內部架構進行升級，為了更好地介紹 SelectDB 如何在 GunaceDB 中作為儲存引擎發揮作用，我們首先介紹一下 DQL 查詢語言。

在可觀測性場景中，幾乎所有的查詢都涉及時間的篩選，同時大部分的聚合也需要按照時間視窗來進行，並且針對時間序列，還需要支援按單個序列在時間視窗前後進行 Rollup。在這些場景中，使用 SQL 來表達相同的語義就需要巢狀多層子查詢，導致表達過程和編寫都異常複雜。

因此我們嘗試簡化語法元素，在此基礎上設計出了新的查詢語言 DQL，並且增強了在可觀測場景下的常見計算函式，透過 DQL 即可查詢指標、日誌、鏈路追蹤、物件等所有的可觀測資料。

從 GuanceDB 內部結構來看，本次升級我們使用 SelectDB 替換了 Elasticsearch/OpenSearch，原有的查詢架構保持不變。

接下來我們介紹在引入 SelectDB 之後，DQL 查詢是如何工作的：

如上圖所示，Guance-Insert 是資料寫入元件，Guance-Select 是 DQL 查詢引擎。

• 在 Guance-Insert 中，實現了分租戶的資料攢批邏輯，均衡了寫入吞吐量和寫入延遲兩大指標，儘量高效地將資料透過 Stream Load 介面寫給 SelectDB Doris BE 元件。當海量日誌產生時，該方式攢批速度很快，平均日誌入庫延遲在 2-3 秒。
• 在 Guance-Select 中， Guance-Select 會根據當前查詢 SelectDB 的 SQL 支援情況，選擇是否將查詢下推給 FE 計算。通常情況下，常見的聚合查詢都可以下推給 FE 計算，但當遇到 FE 不支援的 SQL 語義或函式時，我們就會選擇 Fallback 到僅下推謂詞到 BE，透過 Thrift RPC 介面獲取 Arrow 格式的列存資料，再在 Guance-Select 中計算。由於此方案無法將計算邏輯下推 BE ，因此實際效能會略差於在 FE 中的查詢。不過在大部分場景下，這種方案是可以滿足需求的。

當前的查詢架構是綜合 FE 和 BE 能力的混合計算架構，DQL 即可以利用 SelectDB 已經充分最佳化的查詢能力，也可以讓語法擴充不受 SelectDB 本身 SQL 能力的限制。

架構升級的收益

01 儲存成本降低約 70%、查詢效能提升 3 倍

SelectDB 的引入，實現了綜合成本的大幅降低。之前我們在雲上某可用區使用的是由 20 臺 16C 64G 雲主機組成的 Elasticsearch 叢集提供查詢服務，同時採用了獨立的索引寫入服務（相當於使用 20 臺雲主機）。在替換成 SelectDB 之後，只需要 13 臺同配置的雲主機， 總成本下降了 67%。成本的大幅降低主要得益於兩個因素：

• SelectDB 寫入效能高於 Elasticsearch ：在應對 1GB/s 的持續高吞吐寫入時，SelectDB 所佔用 CPU 保持在 20% 以下，摺合約佔 2.6 臺雲主機的成本，僅為 Elasticsearch 索引寫入服務成本的 13%。這一優勢可以在降低寫入成本的同時應對更大的突發流量，保障系統的穩定性。

• SelectDB 資料和索引壓縮率高於 Elasticsearch：SelectDB 資料和索引採用列式儲存和 ZSTD 壓縮技術，使得線上叢集整體壓縮比可達 1:8 ，而 Elasticsearch 壓縮比只有 1:1.5，因此使用 SelectDB 時，所佔用儲存空間僅是 Elasticsearch 的 20% 左右。
• SelectDB 支援冷熱資料分層儲存：我們可以將近期較頻繁查詢的熱資料儲存在本地盤，長時間不使用的冷資料自動上傳至物件儲存中，這樣可大幅降低資料儲存成本。同時，SelectDB 支援根據儲存策略的配置自動進行冷熱資料遷移，並且資料生命週期管理和查詢對上層應用透明，使用起來更加靈活方便。此外，SelectDB 還可透過本地 Cache 加速對冷資料的訪問，從而提升使用者查詢冷資料的使用體驗。

SelectDB 的引入，實現了查詢效能顯著提升。在減少機器數量以後，我們對比了相同的查詢在兩個叢集下的效能，實踐表明 SelectDB 的點查和列表查詢速度比 Elasticsearch 快近 2 倍，在聚合查詢不進行取樣的情況下，SelectDB 相比 Elasticsearch 快將近 4 倍。

綜上，採用 SelectDB 替換 Elasticsearch 後，僅使用 Elasticsearch 的 1/3 成本、獲得 2～4 倍的效能提升，整體價效比提升了近 10 倍！

02 倒排索引滿足日誌場景全文檢索需求

倒排索引能夠顯著提升全文檢索的效能並降低查詢的資源開銷，是實現高效日誌分析的必備能力。SelectDB 支援倒排索引，以下是我們從 Elasticsearch 遷移到 SelectDB 過程中關鍵能力的介紹：

• 支援字串全文檢索，包括可同時匹配多個關鍵字  MATCH_ALL、匹配任意一個關鍵字  MATCH_ANY 、匹配短語片語  MATCH_PHRASE 的查詢方式。我們對日誌文字內容建立倒排索引時使用  MATCH_PHRASE 進行查詢，能夠完整覆蓋原來在 Elasticsearch 上的功能。
• 支援英文、中文及 Unicode 多語言分詞，中文分詞還支援自定義詞庫、自定義停用詞。我們將原先在 Elasticsearch 上使用的中文詞庫和停用詞配置到 SelectDB 上，完成了使用者體驗平滑遷移。

CREATE TABLE httplog
(
  `ts` DATETIME,
  `clientip` VARCHAR(20),
  `request` TEXT,
  INDEX idx_ip (`clientip`) USING INVERTED, --不分詞
  INDEX idx_req (`request`) USING INVERTED PROPERTIES("parser" = "chinese") --中文分詞)
DUPLICATE KEY(`ts`)
...-- 查詢clientip為'8.8.8.8'的最新10條資料SELECT * FROM httplog WHERE clientip = '8.8.8.8' ORDER BY ts DESC LIMIT 10;-- 檢索request欄位中有error或者404的最新10條資料SELECT * FROM httplog WHERE request MATCH_ANY 'error 404' ORDER BY ts DESC LIMIT 10;-- 檢索request欄位中有image和faq的最新10條資料SELECT * FROM httplog WHERE request MATCH_ALL 'image faq' ORDER BY ts DESC LIMIT 10;-- 檢索request欄位中有'查詢錯誤'片語的最新10條資料SELECT * FROM httplog WHERE request MATCH_PHRASE '查詢錯誤' ORDER BY ts DESC LIMIT 10;

除了在功能上能夠滿足日誌全文檢索的需求，SelectDB 倒排索引還 支援線上按需增減索引。Elasticsearch 索引在建立時是固定的，後續無法新增索引欄位，這就需要提前規劃哪些欄位需要建立索引，後續如需變更索引則需要重寫，變更成本非常高。SelectDB 支援在執行過程中按需增加索引，新寫入的資料索引立即生效。同時 SelectDB 可以控制對哪些分割槽建立索引，使用起來非常靈活。

03 Variant 資料型別，解決資料 Schema 頻繁變化痛點

在可觀測場景中，資料的種類繁多且變化頻繁。例如我們在收集使用者在網頁上的每一次點選、每一次匯入等行為時，都可能會追加新的業務指標，這樣的場景對資料庫的 Schema 變更實時性提出了更高的要求。

在常見的資料庫中，大部分資料表的 Schema 是靜態的，也有一些資料庫如 Elasticsearch 可以透過 Mapping 實現動態 Schema。然而，動態 Schema 可能會遇到欄位型別衝突或因歷史欄位不失效而導致欄位數量達到上限的問題。在引入 SelectDB 之後，我們使用最新特性 Variant 動態資料型別（該特性將在 Apache Doris 2.1 版本中正式釋出）可以很好地支援這類場景。

SelectDB 針對半結構化資料設計了 Variant 資料型別，具備以下特色能力：

• 支援任何合法的 JSON 資料儲存在 Variant 型別的列中，並且能夠自動識別 JSON 中的子欄位和型別。
• Variant 資料型別可以避免欄位過多導致的 Schema 爆炸問題。對於頻繁出現的子欄位，Variant 型別採用列式儲存方式，以提高資料儲存和分析的效率。而對於不頻繁出現的子欄位，Variant 型別則會將其合併為一列進行儲存，以避免列的數量過大。
• Variant 資料型別可以避免業務變更欄位型別衝突無法寫入的問題。Variant 允許一個欄位存在不同的型別，並採用不同的儲存方式，對新老資料採用不同的型別儲存，對於新老交替的混合部分採用最小公共型別儲存。

Variant 型別與 Elasticsearch Dynamic Mapping 最顯著區別在於，Dynamic Mapping 的作用域是當前表的完整生命週期，而 Variant 的作用域只在當前的動態分割槽內。 這個差異化的設計使得 Variant 列可以隨著業務資料寫入的變化而週期性失效，從而降低型別衝突的機率。例如，當我們今天變更了業務邏輯程式碼，並對部分業務欄位進行了重新命名，那麼舊的欄位名將不會出現在明天的 Variant 列中。因此，我們可以認為 Variant 只維護了最新資料的型別資料。

另外 當單個分割槽內的欄位型別衝突時會升級到 JSON 資料型別，從而避免出現資料錯誤和資料丟失的問題。例如業務系統中有兩處都用到了  status 欄位，其中一處為字串，一處為數字，那麼我們在查詢時可以根據實際的語義來選擇當前查詢需要的是字串、數字或二者都要。（假設在篩選條件中寫  status = "ok"，此時就只會篩選  status 型別為字串的資料。)

使用 Variant 資料型別後，在實際的寫入和查詢中，使用者都無需感知 Variant 的存在。使用者可以根據自身的業務需求增刪欄位，就如同使用普通列一樣。在進行查詢時，也無需額外的語法或註解，只需要將其當成普通列進行運算即可。

在當前版本中，Variant 資料型別在使用時還需要額外的型別斷言，自動的型別斷言將在後續版本中更新。而當前在 DQL 的查詢中，我們已經實現 Variant 列的自動型別斷言。大部分情況下可直接根據 Variant 的實際資料型別來直接進行斷言，只有極少數型別衝突的情況下 Variant 列會升級到 JSON 資料型別，此時我們會根據 DQL 查詢中的聚合運算元或運算子關聯語義來進行實際斷言。

04 設計取樣邏輯，加速聚合查詢效能

在適配過程中我們發現，儘管 SelectDB 效能強大，但在需要對超大資料集進行聚合計算時，仍然會佔用較多的系統資源，計算的開銷相對很高。而在可觀測場景中，大部分的計算都是定性分析，而不是定量的絕對值精確分析。

基於這樣的業務背景，我們在 GunaceDB 中設計瞭如下的取樣邏輯：

• 估算查詢時間範圍內的原始資料行數，當需要查詢的原始資料行數大於 1000 萬時開啟取樣，並固定取樣行數為 1000 萬反推計算取樣率。
• 在儲存層利用 SelectDB 的 TableSample 能力進行實際資料取樣，配合一定的表寫入均衡策略，保證聚合結果不產生嚴重偏差。
• 在查詢引擎層，根據不同的聚合運算元適配取樣結果，大部分的分位數、平均值之類計算無需處理，僅需要處理 Sum 和 Count 函式等比例放大。
• 當 Count 聚合查詢在取樣後命中結果過少時，我們會關閉取樣重新查詢，避免大的誤差出現。此外，我們會在響應結果中標註取樣率，當使用者懷疑取樣結果有偏差時可以關閉取樣重新發起請求。

在這樣的取樣邏輯下，可以顯著減少超大規模計算所需的計算開銷和使用者等待時間，相比之前有數十倍的效能提升，極大的提升了使用者的使用體驗。

觀測雲聯合飛輪科技打造新一代可觀測性解決方案

SelectDB 的引入滿足了我們 Schema Free 的要求，解決了資料 Schema 頻繁變化痛點；提高了資料寫入的效能，保證了資料寫入的時效性和查詢的實時性；提升了全文檢索的效能並降低查詢的資源開銷… 總而言之，SelectDB 的應用，使觀測雲最終實現儲存成本降低 70% 的同時，查詢效能提升 2-4 倍，最終實現整體價效比 10 倍提升！

此外，觀測雲與 SelectDB 聯合打造了新一代可觀測性解決方案，致力於為更多行業客戶提供實時數倉與可觀測性平臺的全新選擇，這一聯合方案即將正式上線：

• 使用場景廣泛：我們將 SelectDB 實時數倉的能力擴充套件到了監控日誌及更廣泛的可觀測性場景，除監控應用開發場景外，基於該方案可以構建更多面向業務場景的實時觀測監控場景。
• 降本提效：與傳統監控方案相比，該方案儲存成本顯著降低，同時透過對取樣效率的提升和多租戶功能的最佳化，整體價效比提高至少 20 倍，我們也強化了日誌檢視功能，使其效率提高了 100 倍甚至 1000 倍。值得一提的是，透過觀測雲的產品力，使用者無需對 SelectDB 二次開發即可獲得完整的監控觀測能力。
• 資料高效整合：SelectDB 可以將可觀測性資料與業務資料進行整合，以發揮更大的價值。當前底層大量資料已儲存在 SelectDB 中，當引入新的業務資料後，利用 SelectDB Catalog 或 Join 能力對可觀測性資料與業務資料進行高線整合，縮短了資料處理流程。
• 挖掘資料價值：藉助於 SelectDB 的強大實時分析能力，使得 Metrics、Logs、Traces 等可觀測性資料的計算變得更加容易，使用者可以更充分地挖掘和利用這些資料。

未來，我們還將持續與 協作，打造更受使用者歡迎的解決方案，同時也將共同推動   社群的發展和壯大！