導讀：隨著網易游戲品類及產品的快速發展，游戲數據分析場景面臨著越來越多的挑戰，為了保證系統性能和 SLA，要求引入新的組件來解決特定業務場景問題。為此，網易游戲引入 Apache Doris 構建了全新的湖倉一體架構。經過不斷地擴張，目前已發展至十余集群、為內部上百個項目提供了穩定可靠的數據服務、日均查詢量數百萬次，整體查詢性能得到 10-20 倍提升。
網易游戲數據與平臺服務部旨在通過數據科技為網易旗下眾多游戲提供運營及決策支持，是推動游戲商業成功、品質提升以及渠道優化的重要支撐。近年來，隨著網易游戲品類及產品的快速增加，數據規模呈爆炸性增長，每日新增數據達百 TB 級別，不僅需要對玩家基本行為指標（活躍度、付費情況、用戶新增等）進行分析，還需深入游戲內部復雜數據，對譬如游戲行為、游戲性能等詳細信息進行分析。面對如此大規模的數據增長，如何高效實時的提供數據支持成為必須面對的一大挑戰。
為了滿足各大業務場景對實時分析時效性的要求，同時保證數據快速寫入和極速查詢，網易游戲數據與平臺服務部亟需一個合適的 OLAP 引擎補充原有的離線數倉架構體系。經過大量的產品調研，Apache Doris 與網易游戲技術中心的整體要求高度契合。因此在 2021 年引入了 Apache Doris，并經過不斷地發展，目前已發展至十余集群，為內部上百個項目提供穩定可靠的服務。
本文將分享網易游戲在選型數據倉庫架構升級過程中的思考以及基于 Apache Doris 構建湖倉一體全新架構的解決方案，并分享 Apache Doris 在關鍵業務場景中的落地實踐。此外，本文也將分享網易游戲在 Apache Doris 集群運維上的建設及管理經驗，以供讀者思考或借鑒。
早期架構及挑戰
早期數據架構如上圖所示，數據主要來源于業務數據庫、游戲日志及接口數據，通過實時與離線兩條鏈路對數據進行加工。在查詢入口層面，我們自研了統一查詢引擎 SmartSQL，可基于 RBO、CBO 和 HBO 實現對 Trino、Spark 和 Hive 的智能查詢路由。如果用戶想要進一步加速查詢，數據將通過 ETL 計算成結果數據寫入至 HBase 中供點查訪問。此外，日志數據還將額外寫入一份至 Elasticsearch 中，為日志分析場景提供數據支持。
然而，這一架構在使用過程中也暴露出了許多問題：
- 運維成本高：涉及組件較多，包括 Apache Hive、Spark、Trino、HBase、Elasticsearch 等，運維復雜度相對較高，需要投入較多的人力。
- 研發成本高：過多的組件也帶來較高的研發成本。面對新增的需求，不僅要開發 Spark、Trino 作業，也要開發 HBase 作業，這要求分析師理解并學習不同組件的使用方法及數據模型，研發成本及難度較高、開發流程長。
- 數據時效性差：該架構數據處理鏈路長，需要經過多次流轉，時效性和查詢效率均無法滿足業務需求。
為了應對早期架構的局限性和挑戰，我們在選擇新的 OLAP 解決方案時，重點考慮了以下幾個核心需求：
- 具備簡潔的架構設計，能夠滿足多種業務場景的同時降低系統組件的復雜度，進而降低運維成本、提高系統的穩定性。
- 提供統一易用的能力，可由單一組件替代之前架構中的多個組件，降低用戶的學習和使用成本，提高研發效率。
- 具備實時高效的數據處理能力，能夠支持實時數據的高并發寫入和亞秒級查詢響應，滿足業務對高時效性的要求。同時希望新引擎符合實時數倉及湖倉一體發展趨勢。
基于以上需求，經過深入評估，我們最終選擇了 Apache Doris 作為 OLAP 解決方案，以下是具體的選型依據：
基于 Apache Doris 構建全新的湖倉一體架構
隨著 Apache Doris 湖倉一體的能力日趨成熟，我們基于 Apache Doris 構建了全新的湖倉一體架構，并針對不同應用場景設計了不同的數據解決方案：
- 數倉分層存儲： 將數據實時寫入 Apache Doris 中，所有熱數據的查詢均在 Apache Doris 數據倉庫中進行，根據 TTL 策略將熱數據轉冷至數據湖中；
- 數據湖查詢加速： 將 ODS 層數據寫入數據湖中，DWD、DWS、ADS 層則存儲在 Apache Doris 中。上層數據應用在執行查詢時，對于高 QPS 和低延遲要求的 SQL 直接走 Doris 內表，明細數據則通過 Apache Doris 提供的 Hive Catalog 以及 Iceberg Catalog 查詢湖中數據，同時還可通過外表物化視圖將外部數據經過物化視圖寫入內表。
全新的湖倉一體架構充分結合了倉和湖的能力，實現存儲和查詢的統一，并基于 Apache Doris 物化視圖等能力可以進一步簡化數據建模加工、實現數據湖查詢加速等能力。
Apache Doris 在網易游戲質量保障中心場景下的應用
QData 是網易游戲質量保障中心下屬的大數據團隊，團隊職責是從質量角度出發，針對游戲產品生命周期中的支付、獎勵、性能、登錄等主題，為游戲提供實時監控、離線分析、報表等服務，以提升游戲性能、優化設備表現。
該業務場景的特點以及對 OLAP 引擎選型時的要求如下：
- 日實時流數據量近百億，寫入作業并發數超 200，要求 OLAP 引擎能夠支持高并發寫入；
- 在某些分析場景下，需要用到 Hive 歷史數據，要求支持從 Hive 中快速同步大量歷史數據；
- 需要完整支持行為分析類型的函數，且要求 P95 指標查詢不超過 3s；
- 日常會有變更字段和更新數據的需求，要求引擎支持數據更新且不影響正常寫入和查詢；
而這些需求與 Doris 功能特性十分契合，因此數據與平臺服務部與 QData配合將 QData 的數倉從其他引擎遷移到了 Doris 中。
全新數倉架構如上圖所示，我們將 Doris 數倉分為 ODS、DWD、DWS 層：
- 對于超大表，ODS 層數據仍然保存在 Hive 中，進一步 ETL 之后再將聚合后的數據導入到 Doris 中實現查詢加速。
- 對于規模適中的表，Kafka 數據直接導入 Doris 中，通過倉內 ETL 和物化視圖的方式實現數據聚合、查詢加速。
01 Bitmap 查詢提速
一般來說，游戲產品會在版本發布當天公告更新及優化信息。為精準監控游戲運營的各個環節、為玩家提供良好的游戲體驗，數據團隊需監控玩家打開游戲時，從 Patch（游戲補丁）更新到最后登錄過程中轉化情況，量化各環節的轉化數據。這就要求對玩家設備 ID 進行精確去重，而去重的數據量高達 10 億級別。
如果直接使用COUNT(DISTINCT)往往會占用大量內存和 IO，并且查詢時間 >20s，特別是當表中有大量不同的值時，查詢性能受到的影響更大，無法滿足性能要求，因此我們提供以下兩種方式進行優化：
- 方式一：首先在 Hive 中構建玩家設備 ID 全局字典表，接著將該表導入到 Doris 表對應的 Bitmap 列；
- 方式二：針對明細表創建物化視圖，通過
bitmap_hash64函數將字符串轉化為 Bitmap 類型。使用bitmap_hash64而不使用bitmap_hash的原因是bitmap_hash在數據量大于 2000 萬時碰撞較為嚴重，導致結果不準確。
針對不同的使用場景，我們可選擇不同 Bitmap 優化方案。優化后，在 14 億數據的場景下，Bitmap 查詢峰值所占用的 Doris 內存 從 54GB 下降到了 4.2GB，查詢時間從 20 秒下降到了 2 秒以內，提升效果頗為顯著。
02 物化視圖提速查詢
游戲性能是玩家游戲時最直觀的體驗，良好的性能可以確保游戲流暢度、響應速度和畫面質量。性能問題可能導致卡頓、延遲或崩潰，嚴重影響玩家滿意度和游戲口碑和留存。因此需要對玩家游戲時的性能數據進行進行監控和分析。
衡量游戲性能相關的數據指標有很多，例如：FPS、卡頓次數、內存峰值等 8 種，單一指標相關的維度多達 10 余 個。而游戲策劃等部門希望在網頁端可針對多種指標和多個維度進行自定義聚合查詢，查詢響應時延需要控制在 2s 內。
對于該需求，我們可以基于常用的數據維度設計物化視圖，來滿足用戶絕大部分自定義聚合查詢的需求。 Doris 的一大優勢在于能夠自動識別并匹配最優物化視圖進行查詢，因此建議可設計 2-3 個物化視圖，過多的物化視圖可能會對數據導入速度造成影響。相較于之前基于 Presto 進行多維分析時查詢耗時長達 20-40 秒的情況，使用 Doris 后的查詢時間已經提速至 1-2 秒。這不僅提升了用戶體驗，也為數據分析工作帶來了極大的便利和效率。
03 多種寫入方式配置式作業生成
在數據寫入方面，考慮到不同業務方的寫入方式不同，我們在部門層面提供了多樣化的寫入方式。對于 Kafka 流，提供了一鍵映射 Doris 表的功能實現快速開發 Flink 作業；對于離線 Hive 數據的同步，提供了 Broker Load、Hive Catalog、Seatunnel 三種方式寫入；對于其他數據源數據的同步，基于 Seatunnel 可實現各類型數據源的集成寫入。
04 基于自研大模型問答和拖拽式生成查詢
我們研發了大模型問答系統，提供基于大模型問答的查詢模式和拖拽式生成查詢。用戶可以通過自然問答的方式便捷地生成 Doris SQL 查詢語句，也可通過界面化拖拽式操作生成 SQL 查詢語句，并迅速獲取到 SQL 執行結果以及對應的圖表顯示。在大模型生成查詢方面，成功率高達 92%。同時，為了滿足不同用戶的需求和習慣，我們仍然支持用戶通過 JDBC 接口對接自己的報表系統，旨在為用戶提供更靈活、高效的數據查詢體驗。
05 QData 場景下的問題整理
在 QData Doris 集群的使用過程中，我們遇到了一些問題，借此機會將這些問題及其相應的解決方案整理如下，以供大家參考。
- Hadoop 上的數據經過一段時間會被 EC 化處理、節約存儲成本，但 EC 化后的數據無法通過 Broker Load 導入，因此將 Broker Load 依賴的 Hadoop Client 版本升級至 3.0，解決了部分沖突、實現正常導入。
- 用戶在查詢 TB 級大表分區時，在完成分區過濾的情況下，仍會出現 IO 打滿情況，這是因為使用 Unique 模型查詢的時候，進行了兩次聚合操作，第一次是把數據進行 Compaction，第二次才實際用到過濾條件。臨時的解決辦法是跟用戶溝通是否可以修改模型，根本的解決方法是升級集群版本，借助 1.2 版本的 Merge On Write 特性，使得查詢能夠應用索引。
- 在 1.2.4 版本中， 用戶把 Java UDF Hive UDF 遷移到 Doris 中后發現 Doris 不支持 Hive UDF 的重載，所以我們把源碼做了改造，使其能夠支持 Hive UDF 的重載。
大規模集群的運維管理
自網易互娛內部引入 Apache Doris 后，經過兩年多的發展，集群已形成了非常可觀的規模：
- 總集群十余個，國內/海外均有布局，總節點數達上百個；
- 內部項目對接數達到上百個，日均查詢量超過 500 萬；
- 最大單集群存儲數據總量達到 PB 級，日均通過實時作業以及離線導入的數據量達到數十 TB。
面對如此龐大的集群規模，如何高效管理成為重點關注的問題。以下是我們對于 Apache Doris 集群管理運維的思考：
- 基礎建設：在確定 Apache Doris 選型后，首先需要制定部署規范、運維規范；其次需做好業務接入規范，提前與業務溝通、明確不同業務場景下適用的機型規格；同時需完善各類基準測試，建設完備的元數據元信息，以確保提供標準統一、性能可靠的數據服務。
- 監控報警：首先需梳理集群監控的分級指標，將 Doris 報警級別分為 P0、P1、P2 三個等級，并根據不同的等級設定報警規則和升級機制，部分指標提供用戶側的報警功能。然后統一監控入口，設定好監控大屏，能夠通過大屏快速獲取到所有集群節點的狀態信息（可基于官方提供的 Prometheus 模板迭代建設）。
- 安全性的保障：制定備份規范、及時進行數據備份，進行周期性故障演練，確保出現故障時能夠穩定快速的恢復。不僅如此，還需要配置集群巡檢規則、巡檢機器環境，如 Doris BE 部署時要求設置文件句柄數、關閉 Swap 等，確保機器環境處于健康狀態。
- 平臺化及可視化：將上述規范平臺化、可視化，通過自動化工具和腳本進行集群運維管理，避免人工操作失誤帶來的風險。同時平臺還可為業務方提供數據報表、分析和審計等功能，幫助業務方了解集群狀況及發展趨勢。
01 自研 Doris Manager 系統
基于上述集群運維目標及方向思考，我們內部自研了一套 Doris Manager 系統，實現對 Doris 集群的可視化管理，架構圖如下：
基礎服務層的 Galaxy 和 Aladdin 都是網易游戲內部的系統， Galaxy 是內部配置管理中心，Aladdin 是流程管理平臺，這兩個平臺結合可以實現集群運維部署的標準化。以 Doris 集群服務注冊啟動的流程為例，第一步啟動 FE Master，第二步注冊 FE FOLLOWER，第三步啟動 FE FOLLOWER，第四步注冊 BE，第五步啟動 BE，這些固定的步驟可以在 Aladdin 平臺創建為流程。當 Aladdin 將上述流程定義好之后，通過接口形式提供給 Doris Manager 調用，進而實現集群一鍵部署和擴縮容等運維操作。
- 在平臺安全方面：在認證上，使用了內部的 OPENID 打通內部權限，基于 RBAC 的權限模型能夠較好的劃分權限層級，區分不同角色的平臺視角。在審計追蹤上，記錄管理平臺上發生的任何行為，便于追蹤操作歷史；
- 在集群服務功能方面：針對用戶最關心的內容設計了集群狀態、綜合功能、查詢導入這幾個模塊，幫助用戶監控集群狀態、分析各類資源的使用情況；
- 在集群運維方面：設計了集群部署及托管、進程守護、數據備份、服務擴縮容等功能，以確保集群的穩定運行及高效管理；
- 在用戶接入方面：通過 Gateway 網關實現白名單管控，通過負載均衡實現服務的高可用。
02 Doris Manager 數據流轉
Doris Manager 平臺的各類分析模塊主要有以下 5 個數據來源：
- Doris 審計日志：雖然官方提供的 Audio Log 插件，可以將審計日志寫回到相應的 Doris 集群，但這種方式不便管理多集群場景。因此，我們將所有集群的審計日志統一采集到 Kafka 中（考慮到不同版本 Doris 的審計日志格式存在差異，因此進入 Kafka 流后，將對審計日志標準化處理，確保從多個 Doris 版本采集到的審計日志指標統一），然后對清洗后的審計日志進行雙寫，其一接入 Hadoop 集群，滿足內部對審計日志永久保存的需求，其二接入獨立的 Doris 集群，該集群將保留近 3 個月審計日志，以供 Doris Manager 進行用量分析、成本計算，并滿足用戶查看歷史 Query 的需求。
- FE/BE 日志：日志是觀測性的重要指標之一，由于早期的 Doris 版本沒有倒排索引功能，因此我們將 FE/BE 日志采集到 Elasticsearch 中，通過在 Doris Manager 平臺調用 Elasticsearch 提供的接口，實現問題日志的快速檢索。同時借助 Elasticsearch 配置集群日志級別的報警，比如 WARN 日志閾值報警、 Error 日志報警、關鍵字報警等。
- Cluster API 數據：Doris 提供了豐富的 API，Doris Manager 可通過調用集群 API 獲取到各種類型的信息，并將所需信息參與到模塊計算中。需要注意的是，某些 API 會隨著 Doris 的迭代發生變化，因此多個 Doris 版本間的接口兼容也是引入新版本時要著重測試的地方。
- Fe Meta：在
information_schema庫下存放了大量的元數據信息，可以直接獲取庫、表、分區等各類信息。 - 集群 Metrics：Metrics 最直接體現集群運行的健康度等信息、FE/BE Metrics 是分析集群狀態最佳的數據來源。
將這些數據采集到 Doris Manager 之后，我們通過內部規則、行業規范、配置約束和集群現狀等現狀設計了一系列分析模塊，獲取到分析結論可供管理員和用戶進行查詢分析、存儲分析以及成本計算等行為。
集群服務狀態管理的設計實現
為幫助用戶側掌控集群各類運行狀態，減少管理側的運維人力成本，我們主要聚焦存儲、導入和查詢這三方面進行模塊設計，設計目標如下：
- 查詢：幫助用戶全方位了解集群查詢情況，提速查詢。
- 導入：幫助用戶掌控實時和離線導入的數據增量情況，導入問題報錯輔助排查，減少人力運維。
- 存儲：幫助用戶減少冗余存儲，節約存儲成本，減輕元數據管理壓力。
01 查詢分析模塊
集群查詢消耗的總資源和各用戶消耗的資源都需要量化，以便開展用量預警、性能分析等工作。因此我們設計了 “查詢概覽” 模塊，該模塊主要有以下幾個功能，幫助用戶從全局概覽上了解集群的查詢性能變化情況。
- 支持查看集群近 3 個月各指標的走勢，包括數量、Cputime、Memory、P 系列指標；
- 統計集群內各用戶消耗查詢資源占比；
- 以表格的形式精確展示指標詳情，所有統計指標支持導出下載。
Doris 對于 Running Query 的可觀測支持度還在逐步完善中，而在某些場景下用戶需要了解實時 Running Query 的情況，便于 Kill 誤提交或者不合理的大查詢。因此 Doris Manager 設計了 “當前查詢” 的模塊，可自動刷新并獲取當前運行的查詢數量，幫助用戶查看正在運行的 SQL。
慢查詢治理對集群安全運行至關重要，不僅能及時釋放數據庫資源、降低安全風險，還能提高 SQL 質量和可維護性、提升用戶的使用體驗。為了幫助用戶感知集群的慢查詢，Doris Manager 設計了 “查詢分析” 模塊，支持按庫/按時間查看慢查詢匯總分布、查看慢查詢在時間軸上的分布，同時支持按照查詢時間、查詢語句、查詢用戶、Catalog 和閾值等維度來查看并導出慢查詢信息，以便更好的管理和優化數據庫性能。
在執行計劃上，Doris Manager 提供了兩種展示形式，一種是圖形化的、比較直觀，另一種是文字類型的，幫助用戶初步快速地定位慢查詢問題。每條慢查詢記錄后均設有便捷的操作按鈕，用戶只需點擊即可直接查看查詢計劃，從而對查詢速度慢的原因進行初步分析，無需再繁瑣地切換終端去執行EXPLAIN等語句。
對于一些無法通過執行計劃來定位的慢 SQL，官方提供了 Profile 功能，因此 Doris Manager 對其功能進行了集成—— “Profile 管理” 模塊。假設發現 Scan Node 耗時過長，很可能是 Bucket 參數設置不當所致，基于這些 Profile 信息，平臺側將提供針對性的診斷與優化建議，方便用戶調整并優化查詢性能。
在日常穩定使用集群服務時，用戶可能不會頻繁登錄平臺關注查詢情況，這可能會使用戶忽視掉某些查詢 SQL 速度的下降。因此 Doris Manager 開發了 “查詢報表” 模塊，可在每日上班前推送查詢報表，該報表包含前一日的慢查詢分布、明細數據以及各項查詢指標值，通過該方式及時讓業務洞察上一日的查詢情況、做出相應的優化調整。
02 導入分析模塊
在導入方面，Doris Manager 同樣也設計了 “導入概覽” 模塊，并將實時和離線的導入數據分開統計，讓管理員和用戶更清晰了解各類型導入指標的走勢，輔助用戶評估導入規模的變化。而對于導入具體的指標，則可以進入到 “集群監控” 頁面查看指標分鐘級別的走勢。
在導入報錯指南上，Doris Manager 設計了 “報錯分析” 模塊用于分析報錯返回的 URL， 這是因為如 Flink Doris Connector、Seatunnel、Spark Load 等寫入方式底層都是通過 Stream Load 寫入數據。當發生錯誤時，Doris 將返回一個報錯 URL，但由于公司內部網絡隔離，相關端口并未對用戶開啟，因此用戶無法訪問報錯鏈接，而且某些報錯內容對于剛接觸 Doris 的用戶理解起來較困難，因此我們基于 Stream Load 源碼梳理了日常常見的報錯信息，并整理到 Doris Manager 中形成知識庫，作為智能診斷的支撐。
03 存儲分析模塊
當用戶的集群投入運行一段時間后，表數量和數據量通常會持續增長，直到迫切需要治理，而用戶往往難以準確判斷哪些數據表仍具有使用價值。因此 Doris Manager 通過解析用戶的查詢語句，設計了 “熱度分析” 模塊。在頁面左上角通過計算匯總的每個庫、每張表的熱度信息來給集群打分，幫助用戶直觀地了解集群數據使用率。右上角則按照庫維度按照利用率評分升序展示信息，幫助用戶確認存儲治理的優先級。
頁面的下方則可以按照庫、表、分區粒度展示和導出對應粒度下資源的創建、時間、更新時間、表數據量、表行數、Tablet 數、最近 7 天/15 天/30 天的讀熱度、以及最后的查詢時間信息。該模塊幫助所有集群平均下降約 20% 的數據存儲量。
Tablet 是 Doris 中的重要概念，是數據移動、復制等操作的最小物理存儲單元。因此 Tablet 治理一直是 Doris 運維人員需要重點關注的內容。如果不規范設置 Bucket 數會帶來較嚴重的負面問題，影響集群的整體性能和穩定性。具體來說不規范分為兩種情況，一種是 Tablet 設置得過多，一種是 Tablet 設置得過少。
當 Tablet 數量過多時，主要分為三種情況：
- 可刪除表：通過向用戶提供表熱度信息，幫助用戶判斷可刪除的表；
- 非分區表：采用重刪重插的方式，通過優化表的存儲結構，進而減少 Bucket 的數量；
- 分區表：
- 動態分區：當 Bucket 出現異常時，借鑒 Doris Auto Bucket 思維，結合歷史數據進行分析和擬合，計算出最理想的 Bucket 數量，基于此來修改動態分區值。如果空分區過多時，可以提醒用戶調整參數，減少預創建分區數；
- 靜態分區：只能根據每個分區的推薦值來重建分區。
當 Tablet 數量過少時，與過多時的治理方式一致，區別僅為增大 Bucket 值。
雖然我們在業務接入階段會給用戶同步建表規范，但是仍然無法杜絕不遵守規范的行為，而用戶也無法感知當前集群 Tablet 的分布是否合理，管理員給集群業務方提出修改要求后，業務方也不知道用哪種方式去處理。因此 Doris Manager 結合上述治理思路開發了 “Tablet 分析” 模塊，該模塊會按庫、按表、按分區展示 Tablet 實際值和預期值，對于存在差異的行，提供了“點擊進入優化”的按鈕，按鈕背后的邏輯則是治理規則的應用。首先給用戶展示基礎信息，并評估等級，等級取決于預期值和實際值的差異，分為緊急、嚴重、提醒、健康四類，然后提供表熱度走勢圖，輔助用戶判斷這張表是否還在被使用中，最后是將優化方案及所需詳細的操作步驟和相關 SQL 展示給用戶，幫助用戶快速完成 Tablet 的治理。
結束語
自網易游戲內部最初引入 Apache Doris 至今， 已建成十余個集群、為內部上百個項目提供穩定可靠的服務、日均查詢量數百萬次，Apache Doris 已成為網易游戲內部數據服務體系中不可或缺的一部分。
后續我們也將繼續跟隨社區版本迭代節奏，截至發文前，Apache Doris 2.1 系列版本已經逐步穩定，該版本推出許多重磅功能是我們非常關注的，后續我們也會將工作重點聚焦于以下幾方面：
- 存算分離： 期望引入更廉價的存儲介質，同時希望在數據湖場景下更靈活的進行彈性部署。
- 倒排索引： 鑒于內部使用 Elasticsearch 的用戶對倒排索引比較感興趣，且 Apache Doris 倒排索引的能力已趨于成熟，后續將盡快測試并應用。
- 資源隔離：新版本的內置調度功能和 Workload Group 能更好地簡化架構和隔離資源，我們希望在業務場景上使用進而完善湖倉融合方案。
- 完善 Doris Manager：我們希望 Doris manager 能夠提供 On K8S 小實例部署模式，降低用戶在專屬集群需求上的接入門檻。另外計劃建設 Doris manager 對新版本特性的管理支持，比如推出跨集群數據同步等功能。
