導讀：隨著 360 企業安全瀏覽器用戶規模的不斷擴張，瀏覽器短時間內會產生大量的日志數據。為了提供更好的日志數據服務，360 企業安全瀏覽器設計了統一運維管理平臺，并引入 Apache Doris 替代了 Elasticsearch，實現日志檢索與報表分析架構的統一，同時依賴 Doris 優異性能，聚合分析效率呈數量級提升、存儲成本下降 60%....為日志數據的可視化和價值發揮提供了堅實的基礎。
近年來，隨著網絡攻擊和數據泄露事件的增加，使得瀏覽器安全問題變得更加緊迫和嚴峻。漏洞一旦被利用，一個簡單的鏈接就能達到數據滲透的目的，而傳統瀏覽器在安全性和隱私保護方面存在一些限制，無法滿足政企領域對于安全瀏覽的需求。在此背景下，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
2.1 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
2.2 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 ，以便客戶能夠直觀便捷地排查和發現問題，監控集群的使用情況。
