導讀：隨著 360 企業安全瀏覽器使用者規模的不斷擴張，瀏覽器短時間內會產生大量的日誌資料。為了提供更好的日誌資料服務，360 企業安全瀏覽器設計了統一運維管理平臺，並引入 Apache Doris 替代了 Elasticsearch，實現日誌檢索與報表分析架構的統一，同時依賴 Doris 優異效能，聚合分析效率呈數量級提升、儲存成本下降 60%....為日誌資料的視覺化和價值發揮提供了堅實的基礎。
作者｜360 企業安全瀏覽器 劉子健
近年來，隨著網路攻擊和資料洩露事件的增加，使得瀏覽器安全問題變得更加緊迫和嚴峻。漏洞一旦被利用，一個簡單的連結就能達到資料滲透的目的，而傳統瀏覽器在安全性和隱私保護方面存在一些限制，無法滿足政企領域對於安全瀏覽的需求。在此背景下，360企業安全瀏覽器成為政企客戶的首選，以提供統一管理、降本增效、安全可控的解決方案。
在 360 企業安全瀏覽器強大安全防護能力的背後，對海量安全日誌進行深入分析和挖掘是及時發現潛在風險的重要手段。為了提供更好的日誌資料服務，360 企業安全瀏覽器設計了統一運維管理平臺，引入 Apache Doris 作為日誌分析架構的核心元件，實現資料匯入、計算和儲存的統一，保障了資料的準確性和一致性，實現了低成本、高效的實時查詢能力與同步能力，為日誌資料的視覺化和價值發揮提供了堅實的基礎。
業務需求
隨著 360 企業安全瀏覽器使用者規模的不斷擴張，瀏覽器短時間內會產生大量的日誌資料，這些資料具有格式多樣化、資訊維度豐富、時效要求高、資料體量大和隱私安全性高等特點。如果能夠對這些資料進行有效分析，可及時發現潛在威脅並提升網站使用體驗，因此我們設計了統一運維管理平臺。該平臺旨在對終端層、應用層和安全層進行監控和分析，並進行多維度分析和視覺化展示。
- 在應用層，提供應用總覽、訪問分析、效能分析、體驗分析以及異常分析等功能，可全面瞭解應用的執行狀況，及時發現並解決應用中存在的問題。
- 在終端層，提供終端導覽和終端活躍分析功能，及時掌握終端裝置狀況，從而更好地管理和最佳化終端效能。
- 在安全層，提供策略預警和策略建議等功能，可及時發現和預防安全風險，提高系統的安全性。
對於政企相關單位而言，瀏覽器受到攻擊可能導致大量隱私資料洩露，給單位和個人帶來難以預料的後果。因此，為保障客戶資訊的安全，統一運維管理平臺應具備以下幾個能力：
- 實時告警：部分客戶對查詢效能有較高的要求。比如：實時統計服務異常或系統崩潰的次數，並第一時間反饋給相關負責人解決。
- 匯入效能：在業務執行過程中，生成的日誌資料會被儲存在伺服器上。在高併發的情況下，日誌資料量非常龐大，因此對匯入效能有較高的要求。
- 資料一致性： 資料一致性對任何行業來說都是關鍵考慮因素，只有在資料一致的基礎上進行指標計算，才能確保統計結果的準確性。
- 部署簡單：因 360 企業安全瀏覽器主要為政企提供服務，通常採用私有化部署的方式，這意味著服務和客戶端將完全整合在客戶本地環境中。這就要求架構要足夠精簡，在確保在實現功能的同時，儘可能降低部署的複雜度。
架構 1.0 ：基於 Elasticsearch 的簡潔日誌處理架構
為滿足統一運維管理平臺的要求，我們首先設計了一個簡潔的日誌處理架構。在該架構中，瀏覽器客戶端發起請求後，經過業務層的服務 API 處理，日誌資料在服務應用層進行處理，並最終儲存於 MySQL、Elasticsearch 和 Redis 等資料儲存系統中。
MySQL 主要儲存業務相關資料以及少量計算完成的統計資料，用於管理平臺中隨查隨用，Elasticsearch 主要用於儲存日誌類資料，以支援資料實時分析和檢索需求。Redis 主要用於儲存熱資料和管理平臺的配置資訊，以提高介面效能。
在架構 1.0 使用過程中，我們發現幾個痛點問題：
- Elasticsearch 索引不支援變更：Elasticsearch 一旦建立索引，不再支援更改，分詞引數和欄位型別也無法修改。當提出新的業務需求時，就需要建立新的索引，並需要編寫指令碼將歷史資料遷移至新索引中，這就帶來較高的操作和開發成本。
- Elasticsearch 聚合效能差：當執行復雜的聚合查詢或存在大量聚合任務時，Elasticsearch 需要為聚合操作分配大量的記憶體，如果計算資源不足，會造成聚合操作執行時間過長，從而影響查詢效率。
架構 1.1：引入 Apache Doris 1.0 版本
據前文可知，Elasticsearch 聚合效能較差，而在實際的使用場景中存在大量需深度聚合的資料表，因此我們決定對架構進行升級改進。在正式升級之前，我們對多個資料分析元件進行調研，並發現 Apache Doris 具備許多特性符合我們的需求，有望解決當前存在的問題。以下列舉我們較為關注的特點：
- 支援多種資料模型：支援 Aggregate、Unique、Duplicate 三種資料型別，其中 Aggregate Key 模型能夠在快速且準確的寫入資料的同時進行資料聚合，即透過提前聚合大幅提升查詢效能。
- 採用列式儲存：Doris 按列進行資料編碼壓縮和讀取，從而實現極高壓縮比，該儲存方式也減少了大量非相關資料的掃描，提高 IO 和 CPU 資源的利用率。
- 支援物化檢視：既能對原始明細資料進行任意維度的分析，也能快速對固定維度進行分析查詢，對於查詢效能的提升有顯著的效果。
基於這些優勢，我們在架構 1.0 的基礎上先引入了 Apache Doris 1.0 版本，並將其作為資料儲存層。Apache Doris 在架構中主要替代 Elasticsearch 進行實時計算，並將相關統計報表的計算和儲存都遷移到 Doris 中來進行，由 Doris 提供統一資料服務。
不僅如此，Apache Doris 的引入也帶來了許多效能和效率提升：
- 開發效率提升：相比之前需要編寫複雜的 Elasticsearch 聚合程式碼，現在只需要建立聚合 Key，Doris Aggregate 模型即可完成聚合計算，極大提升了資料開發的效率。
- 資料一致性保證：Doris 提供了統一的數倉服務，資料的匯入、計算和儲存均可在 Doris 中實現，簡化了資料處理的鏈路和複雜度，對資料一致性的保障起關鍵作用。
- 查詢效能提升：當面對 4000 萬條資料的聚合查詢時，Elasticsearch 需要 6-7 秒才能返回查詢結果，而 Doris 在 1 秒內就能完成查詢並返回結果，查詢效能顯著提升。
除此之外，Apache Doris 在語法結構上也有明顯的優勢，這為客戶在排查問題時提供了極大的便利、縮短了排查時間。為更直觀體現其便捷性，我們對 Elasticsearch 和 Apache Doris 的語法結構進行對比。
在 Elasticsearch 中，聚合需要多層 group by，由於其語法與標準 MySQL 協議存在差異，因此語法結構相對複雜。
"aggregations": {
"group_day_time": {
"aggregations": {
"group_urltitle": {
"aggregations": {
"group_app_id": {
"aggregations": {
"group_url_host": {
"aggregations": {
"group_org_id": {
"terms": {
"field": "org_id",
"size": 200000
}
}
},
"terms": {
"field": "url_host",
"size": 200000
}
}
},
"terms": {
"field": "app_id",
"size": 10000
}
}
},
"terms": {
"field": "urltitle",
"size": 100000
}
}
},
"date_histogram": {
"calendar_interval": "day",
"field": "day_time"
}
}
}
當使用者遇到問題時，我們需要向客戶傳送大量的 Curl 命令來排查問題。然而，對於沒有 Elasticsearch 使用經驗的使用者來說，語法除錯難度非常高。
curl -u elastic:elastic 'http://127.0.0.1:9200/user_log*/_search?ignore_unavailable=true&pretty=true' -H 'Content-Type: application/json' -d '{"aggregations":{"group_day_time":{"aggregations":{"group_sysname":{"aggregations":{"group_app_id":{"aggregations":{"group_url_host":{"aggregations":{"group_org_id":{"terms":{"field":"org_id","size":200000}}},"terms":{"field":"url_host","size":200000}}},"terms":{"field":"app_id","size":10000}}},"terms":{"field":"sysname","size":100000}}},"date_histogram":{"calendar_interval":"day","field":"day_time"}}},"query":{"bool":{"filter":[{"range":{"day_time":{"from":"2022-06-02T00:00:00+08:00","include_lower":true,"include_upper":true,"to":null}}},{"range":{"day_time":{"from":null,"include_lower":true,"include_upper":false,"to":"2022-06-03T00:00:00+08:00"}}}]}}}'
引入 Apache Doris 後，在建立表時可以使用 Aggregate Key 模型來定義聚合條件。且 Apache Doris 支援標準 MySQL ，不僅語法更加簡潔、查詢也更加方便，如出現問題，只要熟悉 MySQL 的基本語法，便可以快速進行問題排查。
CREATE TABLE user_log
(
day_time datetime DEFAULT NULL COMMENT ‘時間',
org_id int(10) DEFAULT ‘0’ COMMENT ‘組織id',
app_id int(10) DEFAULT ‘0’ COMMENT ‘應用id',
url_host varchar(255) DEFAULT NULL COMMENT 'url地址‘,
urltitle varchar(255) DEFAULT '' COMMENT 'title',
pv_count BIGINT SUM DEFAULT "0" COMMENT "總數"
) Aggregate KEY(day_time,org_id,app_id, url_host, urltitle)
PARTITION BY RANGE (day_time) ()
DISTRIBUTED BY HASH(day_time) BUCKETS 10
SELECT day_time,org_id，app_id，url_host，urltitle，sum(pv_count) as pv
FROM user_log
WHERE day_time >= "2022-06-02" and day_time <= "2022-06-03"
GROUP BY day_time,org_id，app_id，url_host，urltitle
ORDER BY uv desc;
而在架構 1.1 版本中，我們仍然面臨一些挑戰和問題：
- Bitmap 問題：在處理大規模資料時，對於字串型別基數很高的資料，如果直接使用 Bitmap ，計算效能無法很好滿足。
- 資料準確性問題：當對 75 萬基礎資料測試時，Bitmap 雜湊衝突可能導致資料準確性問題。
- 儲存空間：由於 Elasticsearch 還未被 Apache Doris 全部替換，目前系統仍存在儲存資源消耗較大的問題。
架構 2.0 ：引入 Apache Doris 2.0，全面替代 Elasticsearch
針對上述問題，我們積極尋找下一步的解決方案。在與 Apache Doris 社群技術同學溝透過程中，我們得知 Apache Doris 2.0 版本在日誌分析場景上有了全面加強：
- 支援 JOSN 格式：Apache Doris 2.0 支援 JSON 格式，在我們的資料中有大量採用 JSON 格式的資料，該能力使我們能夠更方便地進行資料儲存。
- 支援部分列更新：2.0 版本支援了部分列更新功能，無需對整個資料集進行更新，這種精確的更新方式大大降低了計算資源的消耗，提高了資料更新效率。
- 支援倒排索引：2.0 版本支援倒排索引，可以滿足字串型別的全文檢索和普通數值/日期等型別的等值、範圍檢索，更加符合日誌資料分析的場景的查詢需求。
基於此，我們引入了 Apache Doris 2.0 版本，實現了從架構 1.1 到架構 2.0 的升級。在架構 2.0 中，我們對整體架構進行了調整， 以區分日誌服務、基礎服務與其他服務，這也使得系統更加清晰和易於管理。
在新架構中，我們使用 Apache Doris 完全替代了 Elasticsearch ，由 Apache Doris 統一提供日誌檢索和實時報表服務。此外，我們還對報表匯入方式進行了改進，早期的做法是透過 Insert Into 拼接 MySQL 的方式進行匯入，而新架構中引入了 FileBeat 工具，使報表資料的匯入和匯出更加高效便捷。
具體資料匯入流程為：當使用者在瀏覽器中訪問應用網址時，需要採集的資訊會被記錄在本地，當採集時間或數量達到設定閾值時，這些資訊將透過介面上報給日誌服務。日誌服務的主要任務是對資料進行清洗和填充，以補充瀏覽器空缺資料，並生成一條 JSON 存到伺服器的日誌檔案。當輪詢指令碼觸發時，將對日誌檔案進行讀取，資料透過 Stream Load 將資料同步到 Doris 中。
01 簡單易用，提升開發效率
Apache Doris 學習成本低、輕鬆上手。Apache Doris 相容 MySQL 協議，支援使用標準 SQL 語言進行資料查詢和操作，使得開發人員可以方便地進行復雜的資料查詢和聚合操作。相比之下，Elasticsearch 的 DSL 是一種基於 JSON 的查詢語言，對於不熟悉 DSL 開發人員來說，完全掌握該語法需要一定的學習曲線，具有較高的學習和使用門檻。
我們透過以下示例程式碼來展示使用 GOM 實現 Doris 查詢功能的程式碼實現。從程式碼示例可知，對於熟悉程式碼管理、程式碼規範、程式碼質量和後期維護等方面的人來說，這種寫法非常方便。對於新加入的同事來說，進行程式碼審查也變得非常容易，相較於以前的 Elasticsearch ，使用 Apache Doris 可以節省大量的開發時間。
02 合理進行表設計，滿足查詢秒級響應
在表設計中，我們主要使用了 Aggregate Key 聚合模型和 Duplicate Key 明細模型。 聚合模型用於統計瀏覽器相關指標，如使用者 PV（頁面訪問量）和 UV（獨立訪客數）以及應用訪問 PV 和 UV 等資料；明細模型主要用於儲存日誌資料，以便進行使用者或裝置的留存分析。
在實際的應用中，大部分報表選擇聚合模型進行實時計算，SUM 和 BITMAP 為常用的聚合計算，其中，SUM 約有 100+ 個聚合維度，BITMAP 約有 20-30 個維度，因涉及維度較多，我們將它們分佈在不同的表中。小部分報表採用明細模型，我們也在明細模型上建了 Rollup 來提高查詢速度。
具體欄位設定為：
- UV 採用 BITMAP 聚合模型，聚合函式
BITMAP_UNION - PV 採用 BIGINT 型別，聚合函式
SUM - 留存：
BITMAP_INTERSECT - 眾數：TOPN
SUM 效能評估
如上所述，我們在表建立過程中廣泛使用了 Bitmap 和 SUM 函式。為了評估 SUM 函式的效能，我們對一張約有 54 億行資料的表進行測試，並在建立 Rollup 後進行查詢，結果顯示查詢耗時為 0.32 秒，這表明 SUM 函式在處理大規模資料裡表現出良好的效能，滿足我們對查詢時延的要求。
select count(*) from testorg; # 5400179000
select org_id,sum(app_pv_count) from org_stats where os_type="windows" and day_time > "2023-07-01" and org_id >0 group by org_id; # 0.32s
Bitmap 效能評估
對於 Bitmap 而言，Bitmap 的長度相對於資料行數更為重要。隨著 Bitmap 資料量的增大，Bitmap Union Count 的執行速度可能變慢。
為驗證其效能，我們對一張包含 9 萬行資料的表進行 IP 測試，IP 數量始終保持在 75 萬以上，即每個 Bitmap 的長度大於等於 75 萬。在這個 9 萬*75 萬的資料集上，我們進行 Bitmap Union Count 計算，將 IP 轉換為整數型別，查詢時間約為 0.5 秒，總體而言查詢效能較好，符合效能要求。
select count(*) from testlog; # 90000
select app_id,day_time,bitmap_union_count(ip_pv_count) from test group by app_id,day_time ; #0.5s
03 相較 Elasticseach，儲存成本降低 60%
在引入 Apache Doris 之後，我們對 Doris 和 Elasticseach 的儲存空間佔用進行了對比。
我們以一天資料量為例進行測試，大約 606 GB 的 JSON 日誌資料。當我們將這些資料儲存到 Doris 中時，其所佔用儲存空間僅為 170 GB，壓縮比達到 1:3.6。
與此相比，相同規模的資料儲存到 Elasticsearch 中則需要 391 GB 的儲存空間，遠超過 Apache Doris 所需的空間，升級後儲存成本降低 60%。
收益總結
我們將系統架構從 Elasticsearch 升級為 Apache Doris 之後，具體取得的收益如下：
- 將日誌檢索和報表分析統一到一個系統中，Doris 2.0 版本在增加倒排索引後，能同時滿足這兩個場景，從而縮短了資料處理的鏈路和複雜度，顯著提高了資料處理的效率。
- 聚合分析效能得到數量級的提升，之前在 Elasticseach 中需要近 10 秒才能完成聚合查詢，而在 Doris 中不到 1 秒就能完成，聚合分析效率至少提升 100%。
- Doris 提供了高效的資料壓縮效率，相較於 Elasticseach，同一份資料的儲存資源成本降低了 60%。
- Doris SQL 相比 Elasticseach DSL 更加簡單易用，能夠大幅提升開發效率和問題排查的效率。
不僅如此，Apache Doris 的引入幫助我們實現了運營視覺化管理，提供了瀏覽器多種指標的實時監控，以指導業務部門下一步動作：
- 在安全方面，當崩潰次數達到設定閾值時，系統會透過郵件通知相關人員，以便排查瀏覽器崩潰的原因。還可對登入次數進行統計，有效監測是否存在外部人員試圖攻擊介面。
- 在績效統計方面，可對應用訪問資料進行統計，以幫助我們評估工作情況，從而更好地安排工作。
- 最佳化流量損耗和磁碟佔用：透過對頁面中 JS、CSS、Image 等資源的統計，可有效地發現訪問流量和資源大小並進行最佳化，以減少流量損耗和磁碟空間使用，從而實現降本提效。
- 提供業務系統健康報告：可準確監測應用 Web 頁面所引用的資源、資源載入時長以及異常情況等關鍵資訊，並根據這些資訊生成應用健康報告，基於報告能夠幫助企業完成業務系統的最佳化。
未來規劃
由於 360 企業安全瀏覽器面向企業提供服務，未來我們著重關注並探索以下方向，以更好地滿足客戶的需求。
- 冷熱資料分離：冷熱資料分離能夠在降低成本的同時提高效率，未來我們計劃將客戶的冷資料儲存到 S3 等儲存介質，將熱資料儲存在相應的資料磁碟，以提高儲存空間的利用率。
- Doris Manager 部署整合：未來我們計劃整合 Doris Manager ，以便客戶能夠直觀便捷地排查和發現問題，監控叢集的使用情況。