導(dǎo)讀：科大訊飛星際日志中心經(jīng)歷了從 Elasticsearch 到 Loki，再到 Apache Doris 的可觀測性存儲分析底座升級，支持可觀測三大支柱 Log Trace Metrics 的存儲與分析，有效解決 Elasticsearch 成本高、Loki 查詢慢的問題。Doris 能夠在降低成本的同時提高查詢效率，實現(xiàn)了查詢性能提升 10 倍、存儲空間縮減至 Elasticsearch 1/6。此外，Doris 提供的半結(jié)構(gòu)化數(shù)據(jù)類型 VARIANT 能高效存儲可擴展的 JSON 數(shù)據(jù)，具備很高的靈活性，且其性能媲美普通寬表。

作者｜科大訊飛軟件研發(fā)工程師，曲慶偉

指標、日志、鏈路是服務(wù)可觀測性的三大支柱。 在保障服務(wù)穩(wěn)定性方面，指標主要用于發(fā)現(xiàn)故障和問題，而日志和鏈路分析則側(cè)重于定位和分析問題。其中，日志實際上在這三大維度中充當了重要橋梁。

訊飛星跡作為科大訊飛推出的一款全領(lǐng)域場景的可觀測產(chǎn)品，旨在滿足基礎(chǔ)設(shè)施、應(yīng)用及業(yè)務(wù)上的監(jiān)測需求，提供一體化的解決方案。以實際場景為例，當服務(wù)上線后，需要對中間件和操作系統(tǒng)的 CPU 、內(nèi)存等資源進行監(jiān)控，這些指標能夠?qū)崟r反映系統(tǒng)的健康狀態(tài)。當問題出現(xiàn)后，可以通過日志數(shù)據(jù)分析其來源，再利用日志鏈路分析迅速定位問題的位置。

為更好的處理及管理日志數(shù)據(jù)，訊飛星跡推出了星跡日志中心，經(jīng)過多個版本迭代后， 現(xiàn)已基于 Apache Doris 升級為可觀測存儲分析底座，實現(xiàn)查詢性能提升 10 倍，存儲空間縮減至原來 1/6。目前，在集團內(nèi)多個 BG BU 的項目上穩(wěn)定運行，幫助業(yè)務(wù)降本增效，同時通過業(yè)務(wù)指標分析和用戶畫像與行為分析助力業(yè)務(wù)增長。

星跡可觀測日志中心建設(shè)目標

科大訊飛對星跡可觀測日志中心建設(shè)目標可以總結(jié)為三點：寫的多、查的快、易于使用。

寫的多：

• 高吞吐、低延遲：日志數(shù)據(jù)增長迅猛，每天可產(chǎn)生 10 ～ 100 TB 數(shù)據(jù)、日志條數(shù)可達幾十億～幾百億條。同時，日志寫入并發(fā)量也在持續(xù)提升，可達到 50 萬 TPS，對日志平臺的寫入吞吐要求極高。

• 低成本存儲：日志數(shù)據(jù)總量龐大且保存時間較長，需實現(xiàn)高壓縮率的存儲方案，支持冷熱存儲和數(shù)據(jù)歸檔，避免占用過多存儲資源。

查的快：

• 秒級查詢響應(yīng)：即使面對海量數(shù)據(jù)，也需要提供穩(wěn)定高性能的查詢能力，以應(yīng)對故障排查等對響應(yīng)速度有較高要求的使用場景，分鐘級的數(shù)據(jù)延遲往往無法滿足業(yè)務(wù)要求。

易于使用：

• 運維簡單：要求架構(gòu)極簡易用，支持快速部署、擴容及運維，并能夠與其他子系統(tǒng)串聯(lián)打通，支持多云場景。

• 使用簡單：支持工程師熟悉的接口和語言比如 SQL，以及可視化的、便捷的管理界面。

可觀測性存儲底座架構(gòu)演進

01 ELK

早期訊飛基于 Elasticsearch 搭建了如圖所示的日志處理及分析架構(gòu)。具體來說，日志采集器將數(shù)據(jù)上報到 Kafka，接著通過 Logstash 進行 ETL 處理，處理后的數(shù)據(jù)存儲到 Elasticsearch 中，由 Elasticsearch 提供數(shù)據(jù)的查詢及分析服務(wù)。

存在的問題：

• 資源占用高：無論是寫入還是查詢，CPU 占用率普遍較高。這主要是由于高吞吐量寫入時，分詞操作和 Segment 合并會導(dǎo)致顯著的 CPU 消耗。

• 存儲成本高：受限于 Elasticsearch 的壓縮率，海量日志數(shù)據(jù)存儲成本相對較高。

• 穩(wěn)定性差：在進行跨天查詢或處理大數(shù)據(jù)量時，系統(tǒng)經(jīng)常出現(xiàn) OOM（內(nèi)存溢出）問題，且故障恢復(fù)時間較長。此外，index 加載耗時較長，可能導(dǎo)致寫入被拒絕。

02 Loki + Cassandra

第二代架構(gòu)采用了基于 Grafana Loki 的輕量化架構(gòu)，通過在各應(yīng)用物理機上部署采集器來實現(xiàn)日志數(shù)據(jù)的收集。日志數(shù)據(jù)通過 Kafka 進入 Logstash 進行 ETL 處理，最終存儲到 Loki 中。Loki 的后端存儲選用 Cassandra ，其采用 ZSTD 算法壓縮，相較于 Elasticsearch，存儲成本節(jié)約了 5 倍。具體而言，單條日志 300KB，每分鐘處理 1.8 萬次，經(jīng)過壓縮后，1 天的日志數(shù)據(jù)僅需 1.4 TB 的存儲空間。

存在的問題：

• CPU 使用率高、查詢分析效率低：Loki 的架構(gòu)與 Prometheus 原理相似。當以標簽進行數(shù)據(jù)查詢時，系統(tǒng)先根據(jù) index 定位到 chunk，然后加載 chunk 中的數(shù)據(jù)，解壓后逐條暴力搜索。這種處理方式顯然會導(dǎo)致較高的 CPU 使用率，并且經(jīng)常出現(xiàn) OOM（內(nèi)存溢出）問題，查詢和分析的效率也并不理想。

• 創(chuàng)建標簽的數(shù)量受限： 當標簽基數(shù)較少時，查詢速度尚可。而當標簽數(shù)量過多或搜索條件復(fù)雜時，無法對基數(shù)較大的值進行查詢加速，而日志場景中的字段基數(shù)通常較高。例如，在查詢每個鏈路的 trace ID 時，每條 trace ID 數(shù)據(jù)幾乎都是唯一的，這種高基數(shù)的數(shù)據(jù)不適合使用標簽來處理。

03 基于 Apache Doris 的可觀測性存儲底座

進一步的，為解決上述架構(gòu)存儲的問題，訊飛引入了 Apache Doris。使用 Apache Doris 替換了 Loki 服務(wù)。采集后的數(shù)據(jù)依舊流轉(zhuǎn)至 Kafka 中，消費到日志服務(wù)加工處理，按時間和數(shù)據(jù)大小攢批，設(shè)置攢批時長為 3 分鐘、數(shù)據(jù)大小為 200M，滿足任一條件則觸發(fā)數(shù)據(jù)發(fā)送，處理完的數(shù)據(jù)通過 Stream Load 寫入到 Doris 集群中。

Apache Doris 引入后，可以滿足文章最初提出的 3 個建設(shè)目標：

• 寫的多： 可支撐日均 600 億條、10TB 的寫入流量。與 Elasticsearch 相比，存儲成本不及其 1/6，相同的數(shù)據(jù) Elasticsearch 存儲需要 1T，而依賴于 Doris 的列式存儲和 ZSTD 壓縮，僅需要 170 G。

• 查的快： 查詢效率提升至少 10 倍，特別是在聚合分析、短語模糊匹配及 TOPN 命中前綴索引等場景下，性能提升效果顯著。Doris 即使在沒有命中索引的情況下，也可以在分鐘內(nèi)返回結(jié)果。與 Elasticsearch 頻繁出現(xiàn)的 OOM 相比，效率提升尤為突出。

• 易于使用： Doris manager 可便捷管理所有 Doris 集群?？拼笥嶏w在交付私有化項目時，通常需要管理至少數(shù)十套集群，而 Doris Manager 使這一過程變得便捷輕松。此外，系統(tǒng)還提供 Grafana 和自研的 Web 查詢界面，方便用戶進行日志檢索和分析。

新架構(gòu)的應(yīng)用及優(yōu)化經(jīng)驗

01 Log Trace Metric 選擇合適的數(shù)據(jù)模型

Doris 數(shù)據(jù)模型分為主鍵模型、明細模型和聚合模型，這三個模型在可觀測日志中心都有不同程度的應(yīng)用。

主鍵模型： 主要應(yīng)用于調(diào)用鏈數(shù)據(jù) Trace、配置數(shù)據(jù)的處理。主鍵模型能夠保證 Key（主鍵）的唯一性，當用戶更新一條數(shù)據(jù)時，新寫入的數(shù)據(jù)會覆蓋具有相同 Key（主鍵）的舊數(shù)據(jù)。

CREATE TABLE config (app_code varchar(50) NOT NULL COMMENT '業(yè)務(wù)唯一編碼',app_name varchar(50) NOT NULL ,table_name varchar(200) NOT NULL COMMENT '數(shù)據(jù)表名',create_time datetime NOT NULL COMMENT '創(chuàng)建時間',update_time datetime NOT NULL COMMENT '更新時間'
) 
ENGINE = OLAP 
UNIQUE KEY(app_code) 
DISTRIBUTED BY HASH(app_code) BUCKETS AUTO
PROPERTIES ("enable_unique_key_merge_on_write" = "true","light_schema_change" = "true"
);

**明細模型：**主要用于日志數(shù)據(jù) Log 的處理。數(shù)據(jù)將按照導(dǎo)入文件中的內(nèi)容進行存儲，且不進行任何聚合，即使 Key 列完全相同的數(shù)據(jù)也會被保留。在建表語句中指定的 Duplicate Key 僅用于指明數(shù)據(jù)存儲時按哪些列進行排序，以適應(yīng)業(yè)務(wù)不斷產(chǎn)生的數(shù)據(jù)。一旦數(shù)據(jù)產(chǎn)生，就不會再發(fā)生變化。

CREATE TABLE log_record
(`log_date` DATETIMEV2(3) COMMENT "日志打印時間",`source` VARCHAR(100) COMMENT "日志來源",`level` VARCHAR(10) COMMENT "日志級別",`host_name` VARCHAR(100) COMMENT "主機名",`msg` STRING COMMENT "日志內(nèi)容",INDEX idx_msg (`msg`) USING INVERTED
)
ENGINE = OLAP
DUPLICATE KEY(`log_date`)
PARTITION BY RANGE (`log_date`)
(
)
DISTRIBUTED BY RANDOM BUCKETS 50
PROPERTIES ("compaction_policy" = "time_series","dynamic_partition.enable" = "true","dynamic_partition.time_unit" = "DAY","dynamic_partition.create_history_partition" = "true","dynamic_partition.start" = "-30","dynamic_partition.end" = "7","dynamic_partition.prefix" = "p","compression"="zstd"
);

聚合模型： 主要用于告警指標 Metrics 的聚合。根據(jù) Key 列聚合數(shù)據(jù)，通過提前聚合大幅提升性能，極大降低聚合查詢時所需掃描的數(shù)據(jù)量和查詢的計算量，適合有固定模式的報表類查詢場景。

CREATE TABLE alarm_agg
(`id` LARGEINT,`first_trigger_time` DATETIME MIN COMMENT "第一次觸發(fā)時間",`level` TINYINT MAX COMMENT "告警級別",`msg` STRING REPALCE COMMENT "告警內(nèi)容",`num` INT SUM COMMENT "總數(shù)量"
)
AGGREGATE KEY(`id`)
DISTRIBUTED BY HASH(`id`) BUCKETS 10;

當相同的 ID 進入時，將根據(jù)聚合函數(shù)進行處理。例如，對于觸發(fā)時間，將提取最小值作為第一次觸發(fā)時間。此外，還會對某些級別和內(nèi)容進行替換，并對數(shù)量進行求和。這一過程可以提前對原始數(shù)據(jù)進行聚合，從而方便后續(xù)查詢。通過這種方式，后續(xù)查詢時能夠掃描更少的數(shù)據(jù)。

• 數(shù)據(jù)聚合發(fā)生的時段分為三個：

  • 每一批次數(shù)據(jù)導(dǎo)入的 ETL 階段。每一批次導(dǎo)入的數(shù)據(jù)內(nèi)部進行聚合，聚合后寫入 Doris 集群。
  • BE 進行數(shù)據(jù) Compaction 階段。BE 會對已導(dǎo)入的不同批次的數(shù)據(jù)進行進一步的聚合。
  • 數(shù)據(jù)查詢階段。對于查詢涉及到的數(shù)據(jù)，進行對應(yīng)的聚合。

• 聚合模型的局限性

  • 對 count(*) 查詢不友好， Doris 必須掃描所有的 AGGREGATE KEY 列，并且聚合后，才能得到語意正確的結(jié)果。 當聚合列非常多時，count(*) 查詢需要掃描大量的數(shù)據(jù)。

02 可擴展 JSON 數(shù)據(jù)使用半結(jié)構(gòu)化數(shù)據(jù)類型 VARIANT

{"source":"PC","time":1722562556534,"userId":"d3079d82","properties": {"duration":8979,"mark":"標識","title":"標題","url":"/statistic/analysis"}
}

上述示例展示了一個典型的行為分析日志，其中 properties 是 JSON 格式的可擴展字段，存儲了運行時長、標題和 URL 等子字段。然而，不同業(yè)務(wù)線在 properties 字段中的具體數(shù)據(jù)可能有所差異。例如，某業(yè)務(wù)線可能僅依據(jù)其標識來記錄數(shù)據(jù)，如果該業(yè)務(wù)線涉及啟動參數(shù)或啟動狀態(tài)，字段數(shù)量可能會減少，僅包含用戶信息，如用戶 ID。根據(jù)不同的事件類型，整個 properties 字段的內(nèi)容也會有所不同。因此，在日志場景中，經(jīng)常需要存儲一些動態(tài)字段，如 Kubernetes 下的標簽以及采集指標數(shù)據(jù)的標簽等。

2-1 基于導(dǎo)入手動指定 json_path 靜態(tài) Schema 方案：

對于 properties 這種可擴展的 JSON 字段，最初在使用 Doris 導(dǎo)入時，手動配置 json_path 參數(shù)以映射到表的字段。為提供用戶體驗，我們還在頁面上添加了可視化配置映射功能。該方案的優(yōu)缺點都很明顯。

• 優(yōu)點：能夠確保存儲和查詢的效率，所有字段都映射到 Doris 表中的普通列。相較于 JSON 文本數(shù)據(jù)，列式存儲在存儲和查詢方面的優(yōu)勢非常明顯。
• 缺點：不夠靈活，無法動態(tài)擴展字段。每次修改都需手動調(diào)整表結(jié)構(gòu)和映射關(guān)系，上下游系統(tǒng)需協(xié)同處理，這一過程繁瑣且低效，容易出錯。

2-2 基于 Doris Variant 動態(tài) Schema 方案：

后來，我們將 Apache Doris 升級到了 2.1 版本，該版本提供了 VARIANT 數(shù)據(jù)類型，支持嵌套的不固定 Schema。VARIANT 數(shù)據(jù)類型可以存儲任何合法的 JSON，可自動從 JSON 中抽取字段并推斷其類型，并將這些字段存儲為 VARIANT 列的子列。

使用 VARIANT 類型的表結(jié)構(gòu)和查詢語句如下所示：

CREATE TABLE log_variant (time BIGINT,source STRING,userId STRING,properties VARIANT
)
SELECT * FROM log_variant
WHERE time BETWEEN t1 AND t2AND source = 'PC'AND properties['duration'] > 100000;

拆分成子列并采用列式存儲的方式，使得 VARIANT 具備良好的存儲和分析性能。在進行聚合/過濾/排序等查詢時，只需讀取 VARIANT 子列數(shù)據(jù)（比如 properties['duration']） 即可，不會產(chǎn)生額外的數(shù)據(jù)讀取和解析的開銷（比如mark， title， url 等字段）。這種方案的性能與靜態(tài)列相當，而相較于 JSON 字符串，性能提升存在數(shù)量級的差異。

在使用 VARIANT 類型的過程中，也遇到一些局限性并已找到解決方法。

• 早期版本 VARIANT 不能應(yīng)用在聚合模型中， 升級到 2.1.3 以上的版本可以解決。

• 當 VARIANT 與 Group Commit 一起使用時，會出現(xiàn)過早反壓影響寫入性能的問題，升級到 2.1.5 以上的版本可以解決。

• 在 VARIANT 列上創(chuàng)建索引時，會對所有子列同時創(chuàng)建索引。如果子列數(shù)量過多，可能導(dǎo)致索引數(shù)量過多，從而影響寫入性能。此外，同一 VARIANT 列的分詞屬性是一致的。例如，如果某列包含十個字段，并使用中文分詞，那么這十個字段都將應(yīng)用相同的中文分詞規(guī)則。

• 日期、Decimal 等非標準 JSON 類型，會被默認推斷成字符串類型，應(yīng)盡可能從 VARIANT 中提取出來，用靜態(tài)類型性能更好。

綜合來看，建議需要 VARIANT 的用戶使用最新的 2.1.x 版本，目前最新版本為 2.1.6。針對問題 3 和 4，社區(qū)已經(jīng)開發(fā)了 VARIANT 內(nèi)部 Schema 允許用戶自定義的功能，預(yù)計將在后續(xù)版本中正式發(fā)布。

03 建表分區(qū)分桶優(yōu)化

Doris 支持以表進行邏輯分區(qū)，一個 Table 下面有多個 Partition，每個 Partition 下有多個 Tablet。

如上圖所示，Partition 是按照時間進行分區(qū)的，假設(shè)今天是 8 月 15 日，那么今天寫入的數(shù)據(jù)將寫入到右邊分區(qū)中。該分區(qū)的意義在于，將總體數(shù)據(jù)量進一步拆分，查詢時只查符合條件的分區(qū)，以此來提升查詢的效率。

Tablet 分桶一般有 Hash 和 Random 這兩種方式：

Hash： 數(shù)據(jù)寫入時將指定 Key 進行 Hash 計算，以確定該分配到哪個 Tablet。這種方法的優(yōu)勢在于，當根據(jù) ID 進行 Hash 時，查詢時可以精準地定位到相應(yīng)的 Tablet。具體來說，先根據(jù)時間進行過濾，篩選到特定的數(shù)據(jù)位置，由于數(shù)據(jù)是基于 Hash 進行分桶的，這樣可以輕松地命中相應(yīng)的 Tablet。

Random： 在數(shù)據(jù)寫入時，系統(tǒng)會隨機選擇一個 Tablet，并結(jié)合 Single Tablet Load 實現(xiàn)將整個 Batch 數(shù)據(jù)寫入同一個 Tablet 的單個文件。這種方式不僅增加了 IO 批處理的規(guī)模、提高了寫入的性能，還使得時間相近的數(shù)據(jù)能夠存儲在一起，從而優(yōu)化了存儲效率。

分桶數(shù)一般設(shè)置為磁盤數(shù)量的三倍，以確保每個 Tablet 的大小保持在 1-10GB 范圍內(nèi)。

CREATE TABLE log_record (log_date DATETIMEV2(3),  level VARCHAR(10),host VARCHAR(100),message string,INDEX idx_host (host) USING INVERTED),INDEX idx_message (message) USING INVERTED PROPERTIES("parser" = "chinese", "support_phrase" = "true")
)
ENGINE = OLAP
DUPLICATE KEY(log_date)
PARTITION BY RANGE (log_date)()
DISTRIBUTED BY RANDOM BUCKETS 50
PROPERTIES ("compaction_policy" = "time_series","compression"="zstd“,"dynamic_partition.enable" = "true", "dynamic_partition.time_unit" = "DAY", "dynamic_partition.create_history_partition" = "true", "dynamic_partition.start" = "-30", "dynamic_partition.end" = “3", "dynamic_partition.prefix" = "p"
);

分區(qū)分桶優(yōu)化前后的效果對比非常明顯。 例如，下面的根據(jù)時間查詢前 20 條數(shù)據(jù)。

SELECT * FROM log_record
WHERE log_date >= '2024-08-10 00:00:00.000' AND log_date <= '2024-08-11 00:00:00.000' 
ORDER BY log_date DESC LIMIT 0, 20

優(yōu)化前（左）雖然成功返回了 20 條數(shù)據(jù)，但其掃描的行數(shù)和數(shù)據(jù)量（ScanRowsRead， ScanBytesRead）遠大于優(yōu)化后（右）。優(yōu)化后的查詢以時間為分區(qū)，并以時間作為前綴索引，該方式適用于分頁場景下，能夠更好的提高查詢的性能，如紅色圈注處，只需在每個節(jié)點掃描前 20 行數(shù)據(jù)，即可完成查詢。

04 寫入優(yōu)化

• FE 參數(shù)優(yōu)化：盡量讓每個節(jié)點的 Tablet 均勻

  • enable_round_robin_create_tablet = true
  • tablet_rebalancer_type = partition

• BE 參數(shù)優(yōu)化：增加寫入 Buffer Size 的大小，write_buffer_size = 1073741824

• Stream Load 參數(shù)優(yōu)化：設(shè)置單 Tablet 寫入，load_to_single_tablet=true

我們會在寫入前攢批，壓力分攤到寫入模塊：

寫入前攢批與 Group Commit 原理相似（為什么不使用 Group Commit？最初在使用時， Group Commit 還未發(fā)布），將 Kafka 消費的數(shù)據(jù)進行本地存儲，也就是說相當于在寫入 Doris 之前，數(shù)據(jù)已經(jīng)被處理完成。通過這樣的方式將寫入壓力分攤至寫入模塊，可有效減輕 BE 的壓力。

此外，Doris 提供了兩種 compaction 策略：size_based 及 time_series，其中 time_series 適用于時序場景。

時序數(shù)據(jù)指每批導(dǎo)入的數(shù)據(jù)具有時間上的順序性。由于數(shù)據(jù)寫入到 Tablet 中是有序的，因此在合并時，我們可以直接對 Segment 文件進行合并。然而，在實際應(yīng)用場景需要注意，可能會出現(xiàn)新的數(shù)據(jù)插入到原本有序的數(shù)據(jù)中。比如，第一次寫入 10-12 點數(shù)據(jù)，第二次寫入 13-14 點數(shù)據(jù)，第三次又寫入 8-9 點數(shù)據(jù)。在這種情況下，我們通常會默認采用基于 size 的 Compaction 策略。

優(yōu)化完成后，在三節(jié)點集群測試下，每分鐘可寫入 600 萬條數(shù)據(jù)，數(shù)據(jù)流量約 4.5G。整個過程中，磁盤 IO 均值不超過 9%，BE 內(nèi)存占用均值為 4G，CPU 占用均值 9%。相對于其他系統(tǒng)，Doris 在寫入優(yōu)化方面是非常優(yōu)秀的，寫入吞吐高延遲低，而且資源占用率低。

收益總結(jié)

可觀測性存儲分析底座從 ELK 到 Loki 再到 Apache Doris 的架構(gòu)升級，帶來了多個方面的提升，總結(jié)起來還是最初提到的 3 個點：寫的多，查的快，易于使用，具體表現(xiàn)在：

• 寫的多： 可支撐日均 10TB，600 億條日志的寫入流量。與 Elasticsearch 相比，存儲成本不到其 1/6。

• 查的快： 查詢效率提升至少 10 倍，特別是在聚合分析、短語模糊匹配及 TOPN 命中前綴索引等場景下，性能提升效果顯著。

• 易于使用： Doris Manager 使得管理多個集群變得簡單，同時提供 Grafana 和自研的 Web 查詢界面，方便用戶進行日志檢索和分析。

未來展望

未來，還將在 Doris 的基礎(chǔ)上進行以下規(guī)劃：

• 基于訊飛星火大模型的 AIOps：持續(xù)探索智能運維的最佳實踐，包括日志異常監(jiān)測、故障預(yù)測和故障診斷等。

• 用戶行為分析：目前采用手動創(chuàng)建物化視圖，未來探索如何利用 Doris 的物化視圖能力實現(xiàn)自動物化。

• 存算分離：計劃基于 3.0 版本的存算分離，實現(xiàn)中心化的讀寫分離以及租戶的物理隔離。