導讀：數智時代的到來使網絡安全成為了不可忽視的重要領域。奇安信作為一家領先的網絡安全解決方案領軍者，致力于為企業提供先進全面的網絡安全保護，其日志分析系統在網絡安全中發揮著關鍵作用，通過對運行日志數據的深入分析，能夠對漏洞和異常行為生成關鍵見解，幫助企業建立有效的防御策略。本文將深入探討奇安信在網絡安全與日志分析解決方案的關鍵優勢，了解基于 Apache Doris 構建的全新一體化日志存儲分析平臺如何實時監測和分析日志事件，加強對可疑活動的追蹤與應對，提升系統安全性與快速響應能力。
奇安信是中國企業級網絡安全市場的領軍者，專注于為政府和企業用戶提供新一代網絡安全產品和服務。目前核心產品天擎終端安全系統在國內已有 4000 萬政企用戶部署、全國部署服務器超過 100 萬臺、服務超 40 萬大型機構。作為網絡安全國家隊，奇安信立志為國家構建安全的網絡空間，在終端安全、云安全、威脅情報、態勢感知等領域的技術研發持續領先。
隨著現代企業數字化轉型的不斷深化，大數據、物聯網、5G 等創新技術的廣泛應用加速了企業的數字化轉型步伐，這使得原先的網絡邊界被打破，多源多樣的終端設備成為了新的安全邊界。
網絡安全系統的防御性能與日志分析密不可分，當網絡設備、操作系統以及應用程序在運行時，會產生大量的運行日志，其中蘊涵了豐富的數據價值。最大化地利用運行日志數據能夠有效檢測內部系統的安全風險、還原攻擊路徑、回溯攻擊入口等，可以進一步提升系統安全性、保障企業網絡安全，因此日志分析系統在其中發揮著不可或缺的作用。
本文將介紹奇安信在網絡安全場景中，基于 Apache Doris 進行架構升級迭代并建設全新一體化日志存儲分析平臺的實踐經驗。
早期架構痛點與需求
安全日志平臺的架構如下圖所示，原始的設備、系統日志首先經過業務處理環節，包括歸一化和擴充維度等操作。這些處理步驟旨在將來自不同設備和系統日志轉化為半結構化 JSON 格式的安全日志，并將其寫入 Kafka 消息隊列中。
最新的日志會被寫入實時數倉，安全分析師可以通過分析平臺對實時數倉中的最新數據進行交互式查詢，從而進行攻擊研判和追蹤溯源等安全分析工作。另外，離線數倉用于保存歷史數據，以支持長周期數據挖掘的離線分析。
在以上日志數據平臺中，日志數據的寫入速度與查詢分析效率對上層業務人員進行實時安全事件監控和分析至關重要，這也是當前我們所面對的最主要痛點。
一方面，每天所生產的安全日志數據達到千億級，寫入壓力很大。最初我們選擇使用某 Apache Doris 的 Fork 版本來存儲日志數據，但在實際應用中，隨著每天新增日志量的不斷增長，入庫速度逐漸降低、集群寫入壓力過大、高峰期數據積壓嚴重，對集群穩定性造成很大影響，并且數據壓力較高時、查詢效率也達不到有效果的保證。隨后我們對集群進行多次擴容，從 3 節點逐步擴容到 13 節點，盡管機器成本已經大幅超過預期、但寫入效率并沒有發生本質的改善。
另一方面，業務人員在進行安全日志分析時，經常需要對文本字段（如 URL，payload 等）進行關鍵字匹配。在原系統中只能通過 SQL LIKE 進行全量掃描和暴力匹配，整體查詢性能不佳，千億級數量的數據表查詢耗時接近分鐘級甚至達到數百秒，即便按照時間區間過濾大量數據后、查詢耗時仍在數秒到數十秒。一旦遇到并發查詢性能還會進一步惡化，很難滿足日常安全分析的需求。
除寫入和查詢效率以外，運維監控也是我們的痛點之一，該廠商提供的可視化運維系統需要商業 License 授權，對于開源社區用戶不友好，集群維護處于原始手動狀態。
架構選型與升級的思考
為了解決過去版本的痛點、滿足更高效實時的日志分析訴求，我們亟需對早期系統升級改造。同時面向安全日志分析場景，我們也對新日志分析平臺的架構提出了更高的要求：
- 寫入性能：系統一方面需要支持海量病毒查殺事件等數據實時寫入與存儲，以滿足分析時效性的要求，另一方面需要基于日志數據 Schema Free 特點支持豐富數據類型的寫入與變更。
- 查詢性能：由于日志查詢分析會涉及對文本類型、JSON 數據進行全文檢索、日期或普通數值的范圍查詢，系統需要對字符串提供模糊查詢的能力，還需要支持能夠靈活創建且類型豐富的索引，以加速篩選過濾海量數據，提升查詢效率。
- 存儲成本：設備每天產生大量的日志數據，為了挖掘這些有價值的日志信息，業務人員還需要從數據中進行篩選和分析，并對異常日志回溯追蹤，這使得日志存儲的規模很大、存儲周期相對較長，因此高性價比的存儲成本也是系統構建的目標之一。
- 運維成本：系統自身的運維簡易程度以及是否具備合適的管控工具都能幫助我們進一步提效。
在持續關注業界 OLAP 數據庫的過程中，我們發現 Apache Doris 最近一年的發展非常迅猛，最新的 2.0 版本也把日志存儲和檢索分析作為新的發力點，推出了倒排索引、NGram BloomFilter 索引等特性，對關鍵詞檢索、LIKE 文本匹配的性能有大幅提升，與我們文本檢索慢的痛點需求非常契合，因此開啟了新架構的升級之旅。
架構升級之旅
上文中提到，在整體架構選型過程中我們主要關注的地方包括寫入性能、查詢性能、數據存儲成本以及運維成本等方面。在架構升級過程中，我們選擇了 Apache Doris 當時最新發布的 2.0 版本，具體升級收益如下。
01 寫入性能提升超 200%
為了評估 Apache Doris 寫入的極限性能，我們初期使用與線上系統相同配置的 3 臺服務器，從 Kafka 接入線上真實寫入流量，測試期間當 CPU 寫入效率跑滿至 100% 時寫入吞吐達到了 108 萬條/s、1.15 GB/s，寫入數據的可見性延遲保持在秒級。
而線上運行的原系統集群規模達 13 臺，在同樣的數據寫入情況下，CPU 利用率 30% 左右、寫入吞吐僅 30 萬條/s，并且存在高峰期 CPU Load 高、系統響應慢的問題。
根據測試結果，我們預估架構替換為 Apache Doris 后保持同樣 30% 的 CPU 占用，只需要 3 臺服務器即可滿足寫入需求，機器資源成本至少節約 70%。值得注意的是，在測試中對 Apache Doris 表中一半字段開啟了倒排索引，如果不開啟倒排索引的話，寫入性能在之前基礎上還能夠再提升 50% 左右。
02 存儲成本降低近 40%
在看到寫入性能的大幅提升后，Apache Doris 存儲空間占用也給我們帶來了驚喜。在開啟倒排索引的前提下，存儲空間比原系統不具備倒排索引還要略低，壓縮比從 1 : 4.3 提高至 1 : 5.7。
通過對比 Apache Doris 在磁盤上存儲的文件大小，同一份數據的索引文件(.idx)與數據文件(.dat) 大小相差無幾。換言而之，增加索引后 Doris 數據膨脹率大約在 1 倍左右，與許多數據庫和檢索引擎 3-5 倍的膨脹率相比，Doris 的數據存儲空間占用相對較低。經過研究發現，Apache Doris 采用了列式存儲和 ZSTD 壓縮算法來優化存儲空間占用。Doris 將原始數據和倒排索引都以列的形式存儲，使同一列的數據被存儲在相鄰位置，從而實現了更高的壓縮率。
ZSTD 是一個優秀的新型壓縮算法，使用了智能優化算法，相較于常見的 GZIP 算法， ZSTD 具有更高的壓縮率和更快的解壓速度，尤其在處理日志場景時表現非常出色。
03 查詢性能平均提升 690%
對于業務最關注的查詢性能，我們從線上查詢日志進行去重后分析出 79 條 SQL，在同一天總數據（1000 億條）、同樣規模的集群（10 BE 節點）上對比測試 Apache Doris 與原系統的查詢耗時。
我們發現，與原系統相比，所有的查詢語句均有明顯提升，整體查詢性能提升近 7 倍，有 26 條 SQL 查詢語句性能提升 10 倍以上，其中 8 條 SQL 查詢提升 10-20 倍、14 條 SQL 查詢提升 20-50 倍、還有 4 條 SQL 查詢提升 50 倍以上。最大差異的一條 SQL 查詢語句為 Q43，在原系統中執行時間接近一分鐘，在 Apache Doris 中僅需不到 1 秒，其性能差異高達到 88 倍。
針對性能提升幅度高的查詢，我們進行了對比分析并發現了其中幾個共同點：
倒排索引對關鍵詞查找的加速：Q23、Q24、Q30、Q31、Q42、Q43、Q50 等
1 -- 例如q43 提升88.2倍
2
3 SELECT count() from table2
4 WHERE ( event_time >= 1693065600000 and event_time < 1693152000000)
5 AND (rule_hit_big MATCH 'xxxx');
這種基于倒排索引進行關鍵詞檢索的技術，相較于基本的暴力掃描后進行文本匹配具有顯著的優勢，一方面極大地減少了需要讀取的數據量；另一方面，在查詢過程中無需進行文本匹配操作，因此查詢效率往往提升一個數量級甚至更高。
NGram BloomFilter索引對 LIKE 的加速：Q75、Q76、Q77、Q78 等
1 -- 例如q75 提升44.4倍
2
3 SELECT * FROM table1
4 WHERE ent_id = 'xxxxx'
5 AND event_date = '2023-08-27'
6 AND file_level = 70
7 AND rule_group_id LIKE 'adid:%'
8 ORDER BY event_time LIMIT 100；
對于要查找的非一個完整關鍵詞的場景，LIKE 仍然是有用的查詢方式，Apache Doris 的 NGram BloomFilter 索引能對常規的 LIKE 進行加速。
NGram BloomFilter 索引與普通 BloomFilter 索引不同，它不是將整個文本放入 BloomFilter ，而是將文本分成連續的子串，每個子串長度為 n ，并將他們放入 NGram BloomFilter 中。對于 cola LIKE '%pattern%' 的查詢，將'pattern'按照同樣的方式分成長度為 n 的子串，判斷每個子串在 BloomFilter 中是否存在，如果有一個子串不存在，則說明 BloomFilter 對應的數據塊中沒有跟'pattern'匹配的數據塊，因此通過跳過數據塊掃描的步驟，達到加速查詢的效果。
滿足條件的最新 TopN 條日志明細查詢優化：Q19-Q29 等
1 -- 例如q22，提升50.3倍
2
3 SELECT * FROM table1
4 where event_date = '2023-08-27' and file_level = 70
5 and ent_id = 'nnnnnnn' and file_name = 'xxx.exe'
6 order by event_time limit 100;
這種SELECT * FROM t WHERE xxx ORDER BY xx LIMIT n 的查詢，在查找滿足某種條件的最新 n 條日志時使用頻率非常高，Apache Doris 針對這種 SQL 查詢模式進行了專門的優化，根據查詢的中間狀態確定排序字段的動態范圍，并利用自動動態謂詞下推的方式，避免讀全部數據進行排序取 TopN，從而減少需要讀取的數據量（有時甚至可以減少一個數量級），進而提升了查詢效率。
04 可視化運維管控和可視化查詢 WebUI，最大化減少運維和探索分析成本
為了提高日常集群維護的效率，我們使用了飛輪科技免費開放的可視化集群管理工具 Cluster Manager for Apache Doris （以下簡稱 Doris Manager ）。Doris Manager 提供的功能可以滿足日常運維中集群監控、巡檢、修改配置、擴縮容、升級等操作，降低登陸機器手動操作的麻煩和誤操作風險。
除了管控 Apache Doris 集群之后，Doris Manager 還集成了類似 Kibana 的可視化日志探索分析 WebUI，對于習慣 ELK 日志分析的用戶非常友好，支持關鍵詞檢索、趨勢圖展示、趨勢圖拖拽日期范圍、明細日志平鋪和折疊展示、字段值過濾等交互方便的探索式分析，跟日志場景探索下鉆的分析需求很契合。
總結與規劃
在跟隨 Apache Doris 2.0-alpha，2.0-beta，2.0 正式版本發布的節奏，我們根據業務場景進行了詳細的評測，也為社區反饋了不少優化建議，得到社區的積極響應和解決。系統經歷試運行一個月之后，我們將 2.0.1 版本正式用于生產環境，替換了原系統集群，完成架構升級改造，實現了寫入性能、查詢性能、存儲成本、運維成本等多方面收益：
- 寫入性能提升 3 倍以上：目前，奇安信的日志分析平臺每日平均有數千億的新增安全日志數據，通過 Doris 的 Routine Load 能夠將數據實時穩定寫入庫，保障數據低延遲高吞吐寫入。
- 查詢性能平均提升 7 倍：查詢響應時間大幅減少，與之前的查詢效率相比達到平均 7 倍提升，其中業務特別關注的全文檢索速度達到 20 倍以上的提升，助力日志分析與網絡安全運營效率。
- 高效便捷的可視化管理：Cluster Manager for Apache Doris 工具提供了可視化集群監控告警平臺，滿足日常集群監控等一系列操作，同時 WebUI 多種功能為分析人員提供了操作簡單、使用便捷的交互式分析。總而言之，Doris 的易用性、靈活性大幅降低了開發、運維、分析人員的學習與使用成本。
后續我們還將在日志分析場景下探索更多 Apache Doris 的能力。我們將擴大 JSON 數據類型的相關應用，加強系統對于半結構化數據深度分析的能力。同時，我們也非常期待 Apache Doris 2.1 版本中新增的 Variant 可變數據類型，支持存儲任意結構的 JSON 數據，支持字段個數與類型的變化，讓業務人員靈活定義特殊字符，以更好地實現半結構數據 Schema Free 的分析需求。
非常感謝 SelectDB 團隊一直以來對我們的技術支持，助力奇安信走向“體系化防御、數字化運營”的網絡日志安全管理，幫助客戶準確識別、保護和監管網絡設備與各類系統，確保業務人員在任何時候都能夠安全、可信、穩定地訪問數據與業務。
最后，我們也將持續參與到 Apache Doris 社區建設中，將相關成果貢獻回饋社區，希望 Apache Doris 飛速發展，越來越好！
