導(dǎo)讀：在云計(jì)算逐漸成熟的當(dāng)下，越來(lái)越多的企業(yè)開(kāi)始將業(yè)務(wù)遷移到云端，傳統(tǒng)的監(jiān)控和故障排查方法已經(jīng)無(wú)法滿足企業(yè)的需求。觀測(cè)云可以實(shí)現(xiàn)對(duì)云、云原生、應(yīng)用及業(yè)務(wù)的統(tǒng)一監(jiān)測(cè)，提供整體數(shù)據(jù)的分析、洞察、可視化、自動(dòng)化、監(jiān)測(cè)告警、智能巡查、安全巡查等服務(wù)。本文將分享 SelectDB 如何助力觀測(cè)云完成日志數(shù)據(jù)存儲(chǔ)和分析架構(gòu)升級(jí)，實(shí)現(xiàn)在存儲(chǔ)成本降低 70% 的同時(shí)、查詢性能提升 2-4 倍，最終實(shí)現(xiàn)整體性價(jià)比 10 倍提升，為日志存儲(chǔ)和分析場(chǎng)景服務(wù)提供強(qiáng)大動(dòng)力。

上海觀測(cè)未來(lái)信息技術(shù)有限公司是一家國(guó)內(nèi)領(lǐng)先的具備可觀測(cè)性實(shí)時(shí)數(shù)據(jù)檢測(cè)平臺(tái)的公司，其自研產(chǎn)品「觀測(cè)云」首批通過(guò)中國(guó)信通院頒發(fā)的「可觀測(cè)性平臺(tái)技術(shù)能力」先進(jìn)級(jí)認(rèn)證，可實(shí)現(xiàn)對(duì)云、云原生應(yīng)用及業(yè)務(wù)系統(tǒng)的統(tǒng)一觀測(cè)需求，為互聯(lián)網(wǎng)、零售、金融等行業(yè)用戶提供統(tǒng)一高效的數(shù)字化可觀測(cè)服務(wù)。

在云計(jì)算逐漸成熟的當(dāng)下，越來(lái)越多的企業(yè)開(kāi)始將業(yè)務(wù)遷移到云端，傳統(tǒng)的監(jiān)控和故障排查方法已經(jīng)無(wú)法滿足企業(yè)的需求。在可觀測(cè)理念逐漸深入人心的當(dāng)下，人們?cè)絹?lái)越意識(shí)到通過(guò)多層次、多維度、多視角的數(shù)據(jù)去觀測(cè)應(yīng)用系統(tǒng)來(lái)提升故障的定位效率以及業(yè)務(wù)分析能力。而觀測(cè)云本質(zhì)上是一個(gè)全面性的、可觀測(cè)性的解決方案，可提供整體數(shù)據(jù)的分析、洞察、可視化、自動(dòng)化、監(jiān)測(cè)告警、智能巡查、安全巡查等服務(wù)。

為更好提供上述服務(wù)，要求觀測(cè)云具備對(duì)基礎(chǔ)對(duì)象、網(wǎng)絡(luò)性能、日志、應(yīng)用性能、用戶體驗(yàn)、可用性甚至 CI 進(jìn)行觀測(cè)的能力。這些能力要求觀測(cè)云能夠統(tǒng)一整合來(lái)自多個(gè)場(chǎng)景和多種結(jié)構(gòu)的海量數(shù)據(jù)，并提供全面的日志檢索分析能力，快速實(shí)現(xiàn)數(shù)據(jù)查詢、篩選和分析。

為解決觀測(cè)云在日志存儲(chǔ)和分析場(chǎng)景所面臨的挑戰(zhàn)，飛輪科技與觀測(cè)云進(jìn)行了全面合作。通過(guò) SelectDB 的倒排索引能力、Variant 數(shù)據(jù)類型、冷熱數(shù)據(jù)分層存儲(chǔ)等特性，為觀測(cè)云日志存儲(chǔ)和分析場(chǎng)景服務(wù)注入強(qiáng)大的動(dòng)力，實(shí)現(xiàn)存儲(chǔ)成本降低 70% 的同時(shí)，查詢性能提升 2-4 倍，最終實(shí)現(xiàn)整體性價(jià)比 10 倍提升！

GuanceDB 原有架構(gòu)

觀測(cè)云具備強(qiáng)大的數(shù)據(jù)接入能力，通過(guò)自研的 All In One 采集工具 DataKit 可以從不同端側(cè)、業(yè)務(wù)層、中間件、基礎(chǔ)設(shè)施等不同層獲取數(shù)據(jù)，同時(shí)進(jìn)行預(yù)處理和元信息關(guān)聯(lián)。除了廣泛支持日志數(shù)據(jù)以外，Datakit 還支持采集和處理基礎(chǔ)設(shè)施的時(shí)序指標(biāo)、鏈路追蹤、安全事件以及在 APP 端或?yàn)g覽器端的用戶行為數(shù)據(jù)等。為了滿足多元化的多場(chǎng)景需求，DataKit 不僅對(duì)開(kāi)源探針和采集器進(jìn)行了全面兼容，還支持對(duì)自定義格式的數(shù)據(jù)源接入。

DataKit 采集的數(shù)據(jù)，經(jīng)過(guò)核心計(jì)算層處理后，會(huì)統(tǒng)一存儲(chǔ)到 GuanceDB 中。GuanceDB 是一個(gè)觀測(cè)云自主研發(fā)的由多種數(shù)據(jù)庫(kù)技術(shù)組成的多模態(tài)數(shù)據(jù)庫(kù)。

GuanceDB 的內(nèi)部架構(gòu)如上圖所示，主要包含查詢引擎 Query Engine 和存儲(chǔ)引擎 Storage Engine 兩層。在邏輯結(jié)構(gòu)上查詢引擎與存儲(chǔ)引擎通過(guò)抽象解耦，整體架構(gòu)上實(shí)現(xiàn)了可拔插可替換。

觀測(cè)云基于 VictoriaMetrics 存儲(chǔ)模塊研發(fā)了時(shí)序存儲(chǔ)引擎 Metric Store，同時(shí)在泛日志場(chǎng)景集成了 Elasticsearch/OpenSearch。這樣的設(shè)計(jì)使 GuanceDB 對(duì)外有統(tǒng)一的寫(xiě)入和查詢接口，能適應(yīng)不同類型的數(shù)據(jù)格式和業(yè)務(wù)需求。在當(dāng)前的實(shí)現(xiàn)中，MetricStore 已經(jīng)具備卓越的性能。然而，對(duì)于日志類和用戶行為類數(shù)據(jù)的處理來(lái)說(shuō)，Elasticsearch 卻有諸多不足，具體表現(xiàn)如下：

• 寫(xiě)入占用資源多：Elasticsearch 在處理高頻寫(xiě)入大量的數(shù)據(jù)時(shí)，會(huì)占用較高的 CPU 和內(nèi)存資源，這不僅會(huì)顯著增加集群成本，還會(huì)擠占查詢所占用的資源。
• 對(duì)無(wú)模式表支持差：Elasticsearch 對(duì)于 Schemaless 支持有限，當(dāng)前的 Dynamic Mapping 在面對(duì)大量的用戶自定義字段時(shí)，會(huì)頻繁造成字段類型沖突，導(dǎo)致數(shù)據(jù)丟失，需要人工介入進(jìn)行手動(dòng)處理。
• 聚合查詢性能差：Elasticsearch 在面對(duì)海量數(shù)據(jù)時(shí)，聚合性能表現(xiàn)較差。例如對(duì)億級(jí)數(shù)據(jù)計(jì)算分位數(shù)、錯(cuò)誤率時(shí)，極易出現(xiàn)超時(shí)，很難滿足大規(guī)模數(shù)據(jù)下的業(yè)務(wù)分析需求。

選型目標(biāo)及調(diào)研

原有架構(gòu)中 Elasticsearch 存在的問(wèn)題推動(dòng)我們對(duì)架構(gòu)進(jìn)行升級(jí)，在升級(jí)之前，我們調(diào)研了包括 SelectDB 在內(nèi)的多款數(shù)據(jù)庫(kù)。結(jié)合實(shí)際可觀測(cè)性場(chǎng)景，我們選型目標(biāo)如下：

• 高吞吐高性能：在可觀測(cè)場(chǎng)景下，業(yè)務(wù)數(shù)據(jù)的規(guī)模會(huì)隨著業(yè)務(wù)復(fù)雜度和業(yè)務(wù)規(guī)模線性遞增。為滿足這一需求，我們需要一種既能支持高吞吐實(shí)時(shí)寫(xiě)入，又能支持高性能數(shù)據(jù)分析，同時(shí)集群本身易于運(yùn)維、支持橫向拓展的存儲(chǔ)方案。
• 全文倒排索引：全文倒排索引能夠顯著提升檢索性能并降低查詢的資源開(kāi)銷，是實(shí)現(xiàn)高效日志分析的必備能力。在調(diào)研中，我們也注意到了像 Loki 這樣的無(wú)索引方案， 這類方案雖然簡(jiǎn)單，但當(dāng)請(qǐng)求 QPS 稍高時(shí)，全盤掃描時(shí)磁盤 IO 和 CPU 資源開(kāi)銷爭(zhēng)搶就會(huì)非常激烈，無(wú)法承載日志圖表展示、聚類篩選分析、實(shí)時(shí)告警等業(yè)務(wù)需求。
• 支持多種業(yè)務(wù)寫(xiě)入和查詢場(chǎng)景：觀測(cè)云采集的業(yè)務(wù)場(chǎng)景豐富多樣，包括海量吞吐的追加寫(xiě)、進(jìn)程和主機(jī)等對(duì)象數(shù)據(jù)的整體周期性更新、 RUM 場(chǎng)景下 Session 會(huì)話部分更新等，同時(shí)覆蓋高頻點(diǎn)查、列表查詢、大范圍聚合查詢等多種查詢場(chǎng)景，這就需要新方案能夠支持多種業(yè)務(wù)寫(xiě)入和多樣化場(chǎng)景查詢。
• 支持無(wú)模式表：可觀測(cè)業(yè)務(wù)場(chǎng)景中有大量的字段元信息是業(yè)務(wù)工程師根據(jù)業(yè)務(wù)需求手工維護(hù)的，為了更好的適配這種場(chǎng)景，存儲(chǔ)層就需要支持 SchemaLess，無(wú)需上層業(yè)務(wù)維護(hù)數(shù)據(jù)表的 Schema 信息，并且能夠自動(dòng)處理類型沖突。
• 支持大規(guī)模租戶隔離：在 SaaS 場(chǎng)景中，我們有大量的租戶和分表，這些元數(shù)據(jù)本身會(huì)給系統(tǒng)造成較大管理壓力。在使用 Elasticsearch 時(shí)，其單個(gè)集群能支持的索引數(shù)有限，一旦達(dá)到某個(gè)索引數(shù)量，性能就會(huì)急劇下降，因此需要將數(shù)據(jù)分散到不同的集群中，這給集群管理造成了諸多困擾
• 降低長(zhǎng)期存儲(chǔ)成本：可觀測(cè)類的數(shù)據(jù)價(jià)值會(huì)隨時(shí)間遷移而遞減，我們希望能通過(guò)冷熱分離、存算分離等技術(shù)手段，將長(zhǎng)期存儲(chǔ)的數(shù)據(jù)保存到對(duì)象存儲(chǔ)中，以降低數(shù)據(jù)的總體存儲(chǔ)成本。

綜合來(lái)看，SelectDB 能夠滿足觀測(cè)云的大部分需求，并且在與同類產(chǎn)品的對(duì)比中表現(xiàn)出色，我們也會(huì)在后面的章節(jié)中詳細(xì)介紹基于 SelectDB 的改造實(shí)踐。特別值得一提的是，在前期調(diào)研中，以下特性是吸引我們的重要特性：

• SelectDB 倒排索引可使得存儲(chǔ)空間節(jié)約超 80% 、寫(xiě)入速度是 Elasticsearch 的 5 倍、查詢性能是 Elasticsearch 的 2.3 倍。
• SelectDB 針對(duì) JSON 等半結(jié)構(gòu)化數(shù)據(jù)設(shè)計(jì)了 Variant 數(shù)據(jù)類型，可以將任意結(jié)構(gòu)的 JSON 存入 Variant 類型中，可以對(duì) JSON 內(nèi)部的字段和類型自動(dòng)分析、對(duì)頻繁出現(xiàn)的字段采用列式存儲(chǔ)，提升存儲(chǔ)和分析的效
• SelectDB 可以支持上千個(gè)數(shù)據(jù)庫(kù)和上萬(wàn)個(gè)數(shù)據(jù)表，能夠?qū)崿F(xiàn)一個(gè)租戶獨(dú)立使用一個(gè)數(shù)據(jù)庫(kù)，實(shí)現(xiàn)多租戶數(shù)據(jù)隔離的需求，滿足數(shù)據(jù)的隔離和安全性。

基于 SelectDB 的存儲(chǔ)架構(gòu)升級(jí)

因此我們引入 SelectDB 對(duì) GuanceDB 內(nèi)部架構(gòu)進(jìn)行升級(jí)，為了更好地介紹 SelectDB 如何在 GunaceDB 中作為存儲(chǔ)引擎發(fā)揮作用，我們首先介紹一下 DQL 查詢語(yǔ)言。

在可觀測(cè)性場(chǎng)景中，幾乎所有的查詢都涉及時(shí)間的篩選，同時(shí)大部分的聚合也需要按照時(shí)間窗口來(lái)進(jìn)行，并且針對(duì)時(shí)間序列，還需要支持按單個(gè)序列在時(shí)間窗口前后進(jìn)行 Rollup。在這些場(chǎng)景中，使用 SQL 來(lái)表達(dá)相同的語(yǔ)義就需要嵌套多層子查詢，導(dǎo)致表達(dá)過(guò)程和編寫(xiě)都異常復(fù)雜。

因此我們嘗試簡(jiǎn)化語(yǔ)法元素，在此基礎(chǔ)上設(shè)計(jì)出了新的查詢語(yǔ)言 DQL，并且增強(qiáng)了在可觀測(cè)場(chǎng)景下的常見(jiàn)計(jì)算函數(shù)，通過(guò) DQL 即可查詢指標(biāo)、日志、鏈路追蹤、對(duì)象等所有的可觀測(cè)數(shù)據(jù)。

從 GuanceDB 內(nèi)部結(jié)構(gòu)來(lái)看，本次升級(jí)我們使用 SelectDB 替換了 Elasticsearch/OpenSearch，原有的查詢架構(gòu)保持不變。

接下來(lái)我們介紹在引入 SelectDB 之后，DQL 查詢是如何工作的：

如上圖所示，Guance-Insert 是數(shù)據(jù)寫(xiě)入組件，Guance-Select 是 DQL 查詢引擎。

• 在 Guance-Insert 中，實(shí)現(xiàn)了分租戶的數(shù)據(jù)攢批邏輯，均衡了寫(xiě)入吞吐量和寫(xiě)入延遲兩大指標(biāo)，盡量高效地將數(shù)據(jù)通過(guò) Stream Load 接口寫(xiě)給 SelectDB Doris BE 組件。當(dāng)海量日志產(chǎn)生時(shí)，該方式攢批速度很快，平均日志入庫(kù)延遲在 2-3 秒。
• 在 Guance-Select 中， Guance-Select 會(huì)根據(jù)當(dāng)前查詢 SelectDB 的 SQL 支持情況，選擇是否將查詢下推給 FE 計(jì)算。通常情況下，常見(jiàn)的聚合查詢都可以下推給 FE 計(jì)算，但當(dāng)遇到 FE 不支持的 SQL 語(yǔ)義或函數(shù)時(shí)，我們就會(huì)選擇 Fallback 到僅下推謂詞到 BE，通過(guò) Thrift RPC 接口獲取 Arrow 格式的列存數(shù)據(jù)，再在 Guance-Select 中計(jì)算。由于此方案無(wú)法將計(jì)算邏輯下推 BE ，因此實(shí)際性能會(huì)略差于在 FE 中的查詢。不過(guò)在大部分場(chǎng)景下，這種方案是可以滿足需求的。

當(dāng)前的查詢架構(gòu)是綜合 FE 和 BE 能力的混合計(jì)算架構(gòu)，DQL 即可以利用 SelectDB 已經(jīng)充分優(yōu)化的查詢能力，也可以讓語(yǔ)法拓展不受 SelectDB 本身 SQL 能力的限制。

架構(gòu)升級(jí)的收益

01 存儲(chǔ)成本降低約 70%、查詢性能提升 3 倍

SelectDB 的引入，實(shí)現(xiàn)了綜合成本的大幅降低。之前我們?cè)谠粕夏晨捎脜^(qū)使用的是由 20 臺(tái) 16C 64G 云主機(jī)組成的 Elasticsearch 集群提供查詢服務(wù)，同時(shí)采用了獨(dú)立的索引寫(xiě)入服務(wù)（相當(dāng)于使用 20 臺(tái)云主機(jī)）。在替換成 SelectDB 之后，只需要 13 臺(tái)同配置的云主機(jī)，總成本下降了 67%。成本的大幅降低主要得益于兩個(gè)因素：

• SelectDB 寫(xiě)入性能高于 Elasticsearch ：在應(yīng)對(duì) 1GB/s 的持續(xù)高吞吐寫(xiě)入時(shí)，SelectDB 所占用 CPU 保持在 20% 以下，折合約占 2.6 臺(tái)云主機(jī)的成本，僅為 Elasticsearch 索引寫(xiě)入服務(wù)成本的 13%。這一優(yōu)勢(shì)可以在降低寫(xiě)入成本的同時(shí)應(yīng)對(duì)更大的突發(fā)流量，保障系統(tǒng)的穩(wěn)定性。

• SelectDB 數(shù)據(jù)和索引壓縮率高于 Elasticsearch：SelectDB 數(shù)據(jù)和索引采用列式存儲(chǔ)和 ZSTD 壓縮技術(shù)，使得線上集群整體壓縮比可達(dá) 1:8 ，而 Elasticsearch 壓縮比只有 1:1.5，因此使用 SelectDB 時(shí)，所占用存儲(chǔ)空間僅是 Elasticsearch 的 20% 左右。
• SelectDB 支持冷熱數(shù)據(jù)分層存儲(chǔ)：我們可以將近期較頻繁查詢的熱數(shù)據(jù)存儲(chǔ)在本地盤，長(zhǎng)時(shí)間不使用的冷數(shù)據(jù)自動(dòng)上傳至對(duì)象存儲(chǔ)中，這樣可大幅降低數(shù)據(jù)存儲(chǔ)成本。同時(shí)，SelectDB 支持根據(jù)存儲(chǔ)策略的配置自動(dòng)進(jìn)行冷熱數(shù)據(jù)遷移，并且數(shù)據(jù)生命周期管理和查詢對(duì)上層應(yīng)用透明，使用起來(lái)更加靈活方便。此外，SelectDB 還可通過(guò)本地 Cache 加速對(duì)冷數(shù)據(jù)的訪問(wèn)，從而提升用戶查詢冷數(shù)據(jù)的使用體驗(yàn)。

SelectDB 的引入，實(shí)現(xiàn)了查詢性能顯著提升。在減少機(jī)器數(shù)量以后，我們對(duì)比了相同的查詢?cè)趦蓚€(gè)集群下的性能，實(shí)踐表明 SelectDB 的點(diǎn)查和列表查詢速度比 Elasticsearch 快近 2 倍，在聚合查詢不進(jìn)行采樣的情況下，SelectDB 相比 Elasticsearch 快將近 4 倍。

綜上，采用 SelectDB 替換 Elasticsearch 后，僅使用 Elasticsearch 的 1/3 成本、獲得 2～4 倍的性能提升，整體性價(jià)比提升了近 10 倍！

02 倒排索引滿足日志場(chǎng)景全文檢索需求

倒排索引能夠顯著提升全文檢索的性能并降低查詢的資源開(kāi)銷，是實(shí)現(xiàn)高效日志分析的必備能力。SelectDB 支持倒排索引，以下是我們從 Elasticsearch 遷移到 SelectDB 過(guò)程中關(guān)鍵能力的介紹：

• 支持字符串全文檢索，包括可同時(shí)匹配多個(gè)關(guān)鍵字 MATCH_ALL、匹配任意一個(gè)關(guān)鍵字 MATCH_ANY 、匹配短語(yǔ)詞組 MATCH_PHRASE 的查詢方式。我們對(duì)日志文本內(nèi)容創(chuàng)建倒排索引時(shí)使用 MATCH_PHRASE 進(jìn)行查詢，能夠完整覆蓋原來(lái)在 Elasticsearch 上的功能。
• 支持英文、中文及 Unicode 多語(yǔ)言分詞，中文分詞還支持自定義詞庫(kù)、自定義停用詞。我們將原先在 Elasticsearch 上使用的中文詞庫(kù)和停用詞配置到 SelectDB 上，完成了用戶體驗(yàn)平滑遷移。

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條數(shù)據(jù)
SELECT * FROM httplog WHERE clientip = '8.8.8.8' ORDER BY ts DESC LIMIT 10;
-- 檢索request字段中有error或者404的最新10條數(shù)據(jù)
SELECT * FROM httplog WHERE request MATCH_ANY 'error 404' ORDER BY ts DESC LIMIT 10;
-- 檢索request字段中有image和faq的最新10條數(shù)據(jù)
SELECT * FROM httplog WHERE request MATCH_ALL 'image faq' ORDER BY ts DESC LIMIT 10;
-- 檢索request字段中有'查詢錯(cuò)誤'詞組的最新10條數(shù)據(jù)
SELECT * FROM httplog WHERE request MATCH_PHRASE '查詢錯(cuò)誤' ORDER BY ts DESC LIMIT 10;

除了在功能上能夠滿足日志全文檢索的需求，SelectDB 倒排索引還支持在線按需增減索引。Elasticsearch 索引在創(chuàng)建時(shí)是固定的，后續(xù)無(wú)法新增索引字段，這就需要提前規(guī)劃哪些字段需要建立索引，后續(xù)如需變更索引則需要重寫(xiě)，變更成本非常高。SelectDB 支持在運(yùn)行過(guò)程中按需增加索引，新寫(xiě)入的數(shù)據(jù)索引立即生效。同時(shí) SelectDB 可以控制對(duì)哪些分區(qū)創(chuàng)建索引，使用起來(lái)非常靈活。

03 Variant 數(shù)據(jù)類型，解決數(shù)據(jù) Schema 頻繁變化痛點(diǎn)

在可觀測(cè)場(chǎng)景中，數(shù)據(jù)的種類繁多且變化頻繁。例如我們?cè)谑占脩粼诰W(wǎng)頁(yè)上的每一次點(diǎn)擊、每一次導(dǎo)入等行為時(shí)，都可能會(huì)追加新的業(yè)務(wù)指標(biāo)，這樣的場(chǎng)景對(duì)數(shù)據(jù)庫(kù)的 Schema 變更實(shí)時(shí)性提出了更高的要求。

在常見(jiàn)的數(shù)據(jù)庫(kù)中，大部分?jǐn)?shù)據(jù)表的 Schema 是靜態(tài)的，也有一些數(shù)據(jù)庫(kù)如 Elasticsearch 可以通過(guò) Mapping 實(shí)現(xiàn)動(dòng)態(tài) Schema。然而，動(dòng)態(tài) Schema 可能會(huì)遇到字段類型沖突或因歷史字段不失效而導(dǎo)致字段數(shù)量達(dá)到上限的問(wèn)題。在引入 SelectDB 之后，我們使用最新特性 Variant 動(dòng)態(tài)數(shù)據(jù)類型（該特性將在 Apache Doris 2.1 版本中正式發(fā)布）可以很好地支持這類場(chǎng)景。

SelectDB 針對(duì)半結(jié)構(gòu)化數(shù)據(jù)設(shè)計(jì)了 Variant 數(shù)據(jù)類型，具備以下特色能力：

• 支持任何合法的 JSON 數(shù)據(jù)存儲(chǔ)在 Variant 類型的列中，并且能夠自動(dòng)識(shí)別 JSON 中的子字段和類型。
• Variant 數(shù)據(jù)類型可以避免字段過(guò)多導(dǎo)致的 Schema 爆炸問(wèn)題。對(duì)于頻繁出現(xiàn)的子字段，Variant 類型采用列式存儲(chǔ)方式，以提高數(shù)據(jù)存儲(chǔ)和分析的效率。而對(duì)于不頻繁出現(xiàn)的子字段，Variant 類型則會(huì)將其合并為一列進(jìn)行存儲(chǔ)，以避免列的數(shù)量過(guò)大。
• Variant 數(shù)據(jù)類型可以避免業(yè)務(wù)變更字段類型沖突無(wú)法寫(xiě)入的問(wèn)題。Variant 允許一個(gè)字段存在不同的類型，并采用不同的存儲(chǔ)方式，對(duì)新老數(shù)據(jù)采用不同的類型存儲(chǔ)，對(duì)于新老交替的混合部分采用最小公共類型存儲(chǔ)。

Variant 類型與 Elasticsearch Dynamic Mapping 最顯著區(qū)別在于，Dynamic Mapping 的作用域是當(dāng)前表的完整生命周期，而 Variant 的作用域只在當(dāng)前的動(dòng)態(tài)分區(qū)內(nèi)。這個(gè)差異化的設(shè)計(jì)使得 Variant 列可以隨著業(yè)務(wù)數(shù)據(jù)寫(xiě)入的變化而周期性失效，從而降低類型沖突的概率。例如，當(dāng)我們今天變更了業(yè)務(wù)邏輯代碼，并對(duì)部分業(yè)務(wù)字段進(jìn)行了重命名，那么舊的字段名將不會(huì)出現(xiàn)在明天的 Variant 列中。因此，我們可以認(rèn)為 Variant 只維護(hù)了最新數(shù)據(jù)的類型數(shù)據(jù)。

另外當(dāng)單個(gè)分區(qū)內(nèi)的字段類型沖突時(shí)會(huì)升級(jí)到 JSON 數(shù)據(jù)類型，從而避免出現(xiàn)數(shù)據(jù)錯(cuò)誤和數(shù)據(jù)丟失的問(wèn)題。例如業(yè)務(wù)系統(tǒng)中有兩處都用到了 status 字段，其中一處為字符串，一處為數(shù)字，那么我們?cè)诓樵儠r(shí)可以根據(jù)實(shí)際的語(yǔ)義來(lái)選擇當(dāng)前查詢需要的是字符串、數(shù)字或二者都要。（假設(shè)在篩選條件中寫(xiě) status = "ok"，此時(shí)就只會(huì)篩選 status 類型為字符串的數(shù)據(jù)。)

使用 Variant 數(shù)據(jù)類型后，在實(shí)際的寫(xiě)入和查詢中，用戶都無(wú)需感知 Variant 的存在。用戶可以根據(jù)自身的業(yè)務(wù)需求增刪字段，就如同使用普通列一樣。在進(jìn)行查詢時(shí)，也無(wú)需額外的語(yǔ)法或注解，只需要將其當(dāng)成普通列進(jìn)行運(yùn)算即可。

在當(dāng)前版本中，Variant 數(shù)據(jù)類型在使用時(shí)還需要額外的類型斷言，自動(dòng)的類型斷言將在后續(xù)版本中更新。而當(dāng)前在 DQL 的查詢中，我們已經(jīng)實(shí)現(xiàn) Variant 列的自動(dòng)類型斷言。大部分情況下可直接根據(jù) Variant 的實(shí)際數(shù)據(jù)類型來(lái)直接進(jìn)行斷言，只有極少數(shù)類型沖突的情況下 Variant 列會(huì)升級(jí)到 JSON 數(shù)據(jù)類型，此時(shí)我們會(huì)根據(jù) DQL 查詢中的聚合算子或操作符關(guān)聯(lián)語(yǔ)義來(lái)進(jìn)行實(shí)際斷言。

04 設(shè)計(jì)采樣邏輯，加速聚合查詢性能

在適配過(guò)程中我們發(fā)現(xiàn)，盡管 SelectDB 性能強(qiáng)大，但在需要對(duì)超大數(shù)據(jù)集進(jìn)行聚合計(jì)算時(shí)，仍然會(huì)占用較多的系統(tǒng)資源，計(jì)算的開(kāi)銷相對(duì)很高。而在可觀測(cè)場(chǎng)景中，大部分的計(jì)算都是定性分析，而不是定量的絕對(duì)值精確分析。

基于這樣的業(yè)務(wù)背景，我們?cè)?GunaceDB 中設(shè)計(jì)了如下的采樣邏輯：

• 估算查詢時(shí)間范圍內(nèi)的原始數(shù)據(jù)行數(shù)，當(dāng)需要查詢的原始數(shù)據(jù)行數(shù)大于 1000 萬(wàn)時(shí)開(kāi)啟采樣，并固定采樣行數(shù)為 1000 萬(wàn)反推計(jì)算采樣率。
• 在存儲(chǔ)層利用 SelectDB 的 TableSample 能力進(jìn)行實(shí)際數(shù)據(jù)采樣，配合一定的表寫(xiě)入均衡策略，保證聚合結(jié)果不產(chǎn)生嚴(yán)重偏差。
• 在查詢引擎層，根據(jù)不同的聚合算子適配采樣結(jié)果，大部分的分位數(shù)、平均值之類計(jì)算無(wú)需處理，僅需要處理 Sum 和 Count 函數(shù)等比例放大。
• 當(dāng) Count 聚合查詢?cè)诓蓸雍竺薪Y(jié)果過(guò)少時(shí)，我們會(huì)關(guān)閉采樣重新查詢，避免大的誤差出現(xiàn)。此外，我們會(huì)在響應(yīng)結(jié)果中標(biāo)注采樣率，當(dāng)用戶懷疑采樣結(jié)果有偏差時(shí)可以關(guān)閉采樣重新發(fā)起請(qǐng)求。

在這樣的采樣邏輯下，可以顯著減少超大規(guī)模計(jì)算所需的計(jì)算開(kāi)銷和用戶等待時(shí)間，相比之前有數(shù)十倍的性能提升，極大的提升了用戶的使用體驗(yàn)。

觀測(cè)云聯(lián)合飛輪科技打造新一代可觀測(cè)性解決方案

SelectDB 的引入滿足了我們 Schema Free 的要求，解決了數(shù)據(jù) Schema 頻繁變化痛點(diǎn)；提高了數(shù)據(jù)寫(xiě)入的性能，保證了數(shù)據(jù)寫(xiě)入的時(shí)效性和查詢的實(shí)時(shí)性；提升了全文檢索的性能并降低查詢的資源開(kāi)銷...... 總而言之，SelectDB 的應(yīng)用，使觀測(cè)云最終實(shí)現(xiàn)存儲(chǔ)成本降低 70% 的同時(shí)，查詢性能提升 2-4 倍，最終實(shí)現(xiàn)整體性價(jià)比 10 倍提升！

此外，觀測(cè)云與 SelectDB 聯(lián)合打造了新一代可觀測(cè)性解決方案，致力于為更多行業(yè)客戶提供實(shí)時(shí)數(shù)倉(cāng)與可觀測(cè)性平臺(tái)的全新選擇，這一聯(lián)合方案即將正式上線：

• 使用場(chǎng)景廣泛：我們將 SelectDB 實(shí)時(shí)數(shù)倉(cāng)的能力擴(kuò)展到了監(jiān)控日志及更廣泛的可觀測(cè)性場(chǎng)景，除監(jiān)控應(yīng)用開(kāi)發(fā)場(chǎng)景外，基于該方案可以構(gòu)建更多面向業(yè)務(wù)場(chǎng)景的實(shí)時(shí)觀測(cè)監(jiān)控場(chǎng)景。
• 降本提效：與傳統(tǒng)監(jiān)控方案相比，該方案存儲(chǔ)成本顯著降低，同時(shí)通過(guò)對(duì)采樣效率的提升和多租戶功能的優(yōu)化，整體性價(jià)比提高至少 20 倍，我們也強(qiáng)化了日志查看功能，使其效率提高了 100 倍甚至 1000 倍。值得一提的是，通過(guò)觀測(cè)云的產(chǎn)品力，用戶無(wú)需對(duì) SelectDB 二次開(kāi)發(fā)即可獲得完整的監(jiān)控觀測(cè)能力。
• 數(shù)據(jù)高效整合：SelectDB 可以將可觀測(cè)性數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)進(jìn)行整合，以發(fā)揮更大的價(jià)值。當(dāng)前底層大量數(shù)據(jù)已存儲(chǔ)在 SelectDB 中，當(dāng)引入新的業(yè)務(wù)數(shù)據(jù)后，利用 SelectDB Catalog 或 Join 能力對(duì)可觀測(cè)性數(shù)據(jù)與業(yè)務(wù)數(shù)據(jù)進(jìn)行高線整合，縮短了數(shù)據(jù)處理流程。
• 挖掘數(shù)據(jù)價(jià)值：借助于 SelectDB 的強(qiáng)大實(shí)時(shí)分析能力，使得 Metrics、Logs、Traces 等可觀測(cè)性數(shù)據(jù)的計(jì)算變得更加容易，用戶可以更充分地挖掘和利用這些數(shù)據(jù)。

未來(lái)，我們還將持續(xù)與飛輪科技協(xié)作，打造更受用戶歡迎的解決方案，同時(shí)也將共同推動(dòng) Apache Doris 社區(qū)的發(fā)展和壯大！