對比Elasticsearch，使用Doris進行高效日誌分析（上）

來源：Java學研大本營

介紹對比使用Elasticsearch和Apache Doris進行日誌分析。

作為公司資料資產的重要組成部分，日誌在系統的可觀察性、網路安全和資料分析方面扮演著關鍵角色。日誌記錄是故障排除的首選工具，也是提升系統安全性的重要參考。日誌還是一個寶貴的資料來源，透過對其進行分析，可以獲取指導業務增長的有價值資訊。

日誌是計算機系統中事件的順序記錄。一個理想的日誌分析系統應該是：

• 具備無模式支援。 原始日誌是非結構化的自由文字，基本無法直接進行聚合和計算，因此，在將日誌用於資料庫或資料倉儲進行分析之前，需要將其轉化為結構化的表格形式（這個過程稱為“ETL”）。如果發生日誌模式更改，需要在ETL流程和結構化表中進行一系列複雜的調整。為了應對此情況，可以使用半結構化日誌，主要採用JSON格式進行記錄。在這種格式的日誌中，可以相對容易地新增或刪除欄位，而日誌儲存系統會相應地調整其模式。

• 低成本。 日誌資料龐大且持續不斷生成。一個相當大的公司每年會產生10~100 TB的日誌資料。基於業務或合規要求，應該保留半年或更長時間的日誌。這意味著需要儲存以PB為單位的日誌大小，成本相當可觀。

• 具備實時處理能力。 日誌應該實時寫入，否則工程師將無法及時捕捉故障排查和安全追蹤中的最新事件。此外，良好的日誌系統應該提供全文搜尋功能，並能快速響應互動式查詢。

1 基於Elasticsearch的日誌分析解決方案

資料行業內常用的日誌處理解決方案是ELK技術棧：Elasticsearch、Logstash和Kibana。該流程可分為五個模組：

• 日誌收集：Filebeat收集本地日誌檔案並將其寫入Kafka訊息佇列。
• 日誌傳輸：Kafka訊息佇列收集和快取日誌。
• 日誌轉換：Logstash過濾和轉換Kafka中的日誌資料。
• 日誌儲存：Logstash以JSON格式將日誌寫入Elasticsearch進行儲存。
• 日誌查詢：使用者透過Kibana視覺化搜尋日誌或透過Elasticsearch DSL API傳送查詢請求。

ELK堆疊具有優秀的實時處理能力，但也存在一些問題。

1.1 缺乏無模式支援

Elasticsearch中的索引對映定義了表的結構，包括欄位名稱、資料型別以及是否啟用索引建立。

Elasticsearch還擁有自動根據輸入的JSON資料新增欄位到對映的動態對映機制。這提供了某種程度的無模式支援，但這還不夠，因為：

• 動態對映在處理髒資料時經常會建立過多的欄位，從而中斷整個系統的執行。

• 欄位的資料型別是不可變的。為了確保相容性，使用者通常將資料型別配置為"文字"，但這會導致比二進位制資料型別（如整數）慢得多的查詢效能。

• 欄位的索引也是不可變的。使用者無法為特定欄位新增或刪除索引，因此經常為所有欄位建立索引，以便在查詢中方便地進行資料過濾。但是太多的索引需要額外的儲存空間，並減慢資料攝入速度。

1.2 分析能力不足

Elasticsearch擁有獨特的領域特定語言（DSL），與大多數資料工程師和分析師熟悉的技術棧非常不同，所以存在陡峭的學習曲線。此外，Elasticsearch相對封閉的生態系統，在與BI工具整合方面會遇到一些阻力。最重要的是，Elasticsearch僅支援單表分析，滯後於現代OLAP對多表連線、子查詢和檢視的需求。

1.3 高成本和低穩定性

Elasticsearch使用者一直在抱怨計算和儲存成本。根本原因在於Elasticsearch的工作方式。

• 計算成本：在資料寫入過程中，Elasticsearch還執行計算密集型操作，包括倒排索引的建立、分詞和倒排索引的排序。在這些情況下，資料以每個核心約2MB/s的速度寫入Elasticsearch。當CPU資源緊張時，資料寫入需求往往會在高峰時段被拒絕，進一步導致更高的延遲。

• 儲存成本：為了加快檢索速度，Elasticsearch儲存原始資料的正排索引、倒排索引和文件值，消耗了更多的儲存空間。單個資料副本的壓縮比僅為1.5:1，而大多數日誌解決方案的壓縮比為5:1。

隨著資料量和叢集規模的增長，保持穩定性會成為另一個問題：

• 在資料寫入高峰期：叢集在資料寫入高峰期容易超載。

• 在查詢期間：由於所有查詢都在記憶體中處理，大型查詢很容易導致JVM OOM（記憶體溢位）。

• 恢復緩慢：對於叢集故障，Elasticsearch需要重新載入索引，這對資源消耗很大，因此恢復過程可能需要幾分鐘。這對於服務可用性的保證是一個挑戰。

2 更具成本效益的方案

在反思基於Elasticsearch的解決方案的優點和侷限性後，Apache Doris開發人員對Apache Doris進行了日誌處理的最佳化。

• 增加寫入吞吐量： Elasticsearch的效能受到資料解析和倒排索引建立的限制，因此改進了Apache Doris在這些方面的效能：透過SIMD指令和CPU向量指令加快了資料解析和索引建立的速度；然後移除了在日誌分析場景中不必要的資料結構，例如正排索引，以簡化索引建立過程。

• 減少儲存成本： 移除了正排索引，這部分資料佔據了索引資料的30%。採用了列式儲存和ZSTD壓縮演算法，從而實現了5:1到10:1的壓縮比。考慮到大部分歷史日誌很少被訪問，引入了分層儲存來分離熱資料和冷資料。超過指定時間段的日誌將被移動到儲存成本更低的物件儲存中。這可以將儲存成本降低約70%。

Elasticsearch的官方測試工具ES Rally進行的基準測試顯示，Apache Doris在資料寫入方面比Elasticsearch快約5倍，在查詢方面快約2.3倍，並且僅消耗Elasticsearch使用儲存空間的1/5。在HTTP日誌的測試資料集上，它實現了550 MB/s的寫入速度和10:1的壓縮比。

下圖顯示了一個典型的基於Doris的日誌處理系統的樣貌。它更加全面，從資料攝取、分析到應用，都可以更靈活地使用：

• 資料匯入：Apache Doris支援多種日誌資料的攝入方式。可以透過使用Logstash的HTTP輸出將日誌推送到Doris，可以在將日誌寫入Doris之前使用Flink預處理日誌，或者可以透過常規載入和S3載入從Flink或物件儲存中載入日誌到Doris中。

• 資料分析：可以把日誌資料放入Doris，並在資料倉儲中進行跨日誌和其他資料的聯接查詢。

• 應用：Apache Doris相容MySQL協議，因此可以把各種資料分析工具和客戶端整合到Doris中，例如Grafana和Tableau。還可以透過JDBC和ODBC API將應用程式連線到Doris。這裡計劃構建一個類似於Kibana的系統來視覺化日誌。

此外，Apache Doris具有更好的無模式支援和更使用者友好的分析引擎。

2.1 原生支援半結構化資料

首先，在資料型別上進行最佳化。透過向量化最佳化了字串搜尋和正規表示式匹配的文字效能，效能提升了2~10倍。對於JSON字串，Apache Doris將其解析並儲存為更緊湊和高效的二進位制格式，可以加快查詢速度4倍。還為複雜資料新增了一種新的資料型別：Array Map。它可以將連線的字串進行結構化，以實現更高的壓縮率和更快的查詢速度。

其次，Apache Doris支援模式演化。這意味著可以根據業務變化調整模式。可以新增或刪除欄位和索引，並更改欄位的資料型別。

Apache Doris提供了輕量級的模式更改功能，因此開發人員可以在幾毫秒內新增或刪除欄位：

-- 新增列。結果會在毫秒級返回。
ALTER TABLE lineitem ADD COLUMN l_new_column INT;

還可以僅為目標欄位新增索引，以避免不必要的索引建立帶來的開銷。在新增索引後，預設情況下，系統將為所有增量資料生成索引，並且可以指定需要索引的歷史資料分割槽。

-- 新增倒排索引。Doris會為以後的所有新資料生成倒排索引。
ALTER TABLE table_name ADD INDEX index_name(column_name) USING INVERTED;

-- 為指定的歷史資料分割槽構建索引。
BUILD INDEX index_name ON table_name PARTITIONS(partition_name1, partition_name2);

2.2 基於SQL的分析引擎

基於SQL的分析引擎確保資料工程師和分析師能夠在短時間內輕鬆掌握Apache Doris，並將其在SQL方面的經驗應用到這個OLAP引擎中。藉助SQL的豐富功能，使用者可以執行資料檢索、聚合、多表連線、子查詢、UDF、邏輯檢視和物化檢視，以滿足自身需求。

Apache Doris具備MySQL相容性，可以與大資料生態系統中的大多數GUI和BI工具整合，使使用者能夠實現更復雜和多樣化的資料分析。