“阿里云SelectDB作為MiniMax日志存儲服務的核心支撐,為在線和離線業務提供了高效、穩定的查詢與聚合分析能力。其支持實時物化視圖、租戶資源隔離、冷熱分離等企業級特性,不僅有效解決了日志場景下PB級別數據查詢的性能瓶頸,還通過智能化的資源調度與存儲優化,實現了成本與效率的最佳平衡,為業務的高效運轉提供了堅實保障。”
——MiniMax可觀測架構師?香克斯
可觀測日志系統的探索與挑戰
近年來,MiniMax在多模態與文本模型領域持續發力,憑借其技術突破和應用創新能力,迅速成為全球人工智能領域的焦點。25年1月,MiniMax發布了多項重磅成果:支持主體參考功能的視頻新模型S2V-01、基于大規模線性注意力機制的開源模型MiniMax-01系列,以及支持17種語言音頻合成的T2A-01系列語音模型。作為一家成立僅三年但估值已突破數十億美元的初創企業,MiniMax已然躋身人工智能領域最具潛力的獨角獸企業之列。
為了深入洞察模型訓練迭代和?AI應用的運行狀態,精準定位潛在問題以持續優化模型和業務系統的性能,可觀測系統的建設成為MiniMax底層基礎設施建設中不可或缺的關鍵環節。然而,隨著業務規模的快速擴張,海量日志數據的處理對系統的性能和成本提出了嚴峻挑戰。
Loki架構的嘗試與局限性
**在可觀測系統的建設初期,為降低業務系統復雜度和存儲成本,MiniMax采用輕量化的Grafana?Loki。**其中,Promtail負責采集日志并發送給Loki,Loki負責日志存儲和查詢,Grafana用于UI展示。Loki通過日志標簽和元數據索引顯著降低了存儲成本和索引復雜度。然而,因缺乏日志內容的索引,查詢依賴正則表達式匹配和逐行掃描,造成大規模日志查詢時資源消耗過高,查詢響應時間延長。此外,每個Kubernetes集群需獨立部署完整的日志采集與存儲服務,增加了運維復雜度和成本。
隨著業務規模的指數級增長,MiniMax日志數據量迅速攀升至PB級別,Apache?Loki在資源消耗、寫入性能和查詢易用性等方面暴露出瓶頸。為此,MiniMax對日志可觀測系統提出了更高要求:
-
更高的查詢性能:支持上億條數據的秒級查詢響應。
-
更低的存儲成本:在PB級日志數據規模下,實現更具性價比的日志采集與存儲方案。
Doris架構的升級與痛點
為滿足上述需求,MiniMax對日志可觀測系統進行了全面重構。新系統采用阿里云開源的iLogtail作為日志采集工具,將日志數據推送至Kafka消息隊列。隨后,數據通過兩種方式寫入Doris集群:一部分由Mlogs?Ingester從Kafka拉取并通過Stream?Load寫入Doris;另一部分由Doris通過Routine?Load直接訂閱Kafka消息流。Doris作為核心存儲與查詢引擎,實現了全量日志數據的統一管理,避免了多集群獨立部署的復雜性。
然而,隨著MiniMax旗下星野和Talkie等AI應用的日活躍用戶數迅速攀升至行業榜首,其日志數據量和查詢請求呈爆發式增長,日均新增日志數據量超過數百TiB,MiniMax日志可觀測系統逐漸面臨了諸多挑戰:
-
業務快速擴張導致數據和查詢量激增,頻繁的集群擴容需要進行數據遷移,因數據規模較大,遷移過程繁瑣且耗時,影響了業務連續性。
-
日志可觀測系統負責多個業務的數據分析,單實例多業務并發時,內部資源競爭和干擾導致實例穩定性和查詢性能下降,降低用戶體驗和決策及時性。
-
自建Doris的運維成本較高,參數調優和集群管理耗費了大量的人力物力。
-
在遇到Apache?Doris內核相關問題時,社區支持的效率和專業性不均衡,增加了企業解決問題的時間成本和風險。
這些問題制約了MiniMax日志可觀測系統的優化升級,亟待尋求更高效、穩定的解決方案。
DevOps日志系統最佳實踐:阿里云SelectDB
為了應對上述挑戰,MiniMax引入了阿里云企業級數據倉庫SelectDB。SelectDB沿用了Apache?Doris的技術架構,100%兼容Doris語法,并針對寫入吞吐和查詢性能等方面進行了深度優化。它不僅降低了使用成本,還簡化了運維流程,提高了服務等級協議(SLA)保障。通過采用存算分離的云原生架構,SelectDB為處理海量日志提供了近乎無限的擴展能力,從而為MiniMax的日志可觀測體系提供了更加穩定和健壯的日志數據處理能力。
阿里云SelectDB技術方案優勢
阿里云SelectDB以其實時彈性、簡單易用、開源開放等差異化優勢,能夠實時處理PB級別的日志數據,并且提供了萬級QPS實時報表查詢和亞秒級即席多維分析的體驗。與開源自建方案相比,SelectDB在性價比上有顯著提升,并通過深度優化OSS寫入方式,實現了超過10GB/s的讀寫吞吐能力。
優勢一:彈性伸縮,提高集群擴容效率
Apache?Doris采用MPP架構,基于分桶邏輯進行數據的物理水平拆分,這種架構在用戶數據量穩定階段能有效利用多分桶的并行處理能力解決大規模數據實時查詢問題。然而,隨著數據寫入量和單個分桶數據量的快速增長,單個數據分桶節點可能會達到資源瓶頸,此時集群必須進行水平擴展。Doris的水平擴展需要進行全量數據的Reblance,以避免各個節點間負載不均衡。對于MiniMax來說,單次擴容因涉及PB級數據的重分布,可能需要數小時甚至達到天級別,給運維帶來巨大負擔。此外,突發業務流量時,擴容效率低可能導致集群資源不足,進而引發實例宕機風險。
阿里云SelectDB采用存算分離的云原生架構,將計算與存儲分層解耦,支持獨立擴縮容。在擴容過程中無需遷移數據,PB級數據可以實現分鐘級擴縮容。業務低谷期可以根據實際情況動態縮減資源,避免了資源浪費,最大化提高資源利用效率。MiniMax在將日志可觀測系統遷移到SelectDB?后,整體集群擴容時間可達到分鐘級別,大大降低了運維成本,并且能夠通過彈性伸縮能力迅速應對突發業務流量。
優勢二:存算分離,?提升吞吐效率并降低存儲成本
MiniMax在使用Apache?Doris集群時,為了實現數據高可用,生產環境默認采用Doris的兩副本模式,導致存儲資源消耗和集群寫入壓力均增至單副本的兩倍。此外,考慮到過高的存儲成本,MiniMax在Doris數倉中僅保留15天的業務數據,其他數據通過冷歸檔的方式存儲;而需要對這部分歸檔數據進行查詢分析時,則臨時從歸檔庫中解壓加載后才能進行分析,極大降低了數據查詢的效率。
阿里云SelectDB采用存算分離的設計,存儲層基于阿里云對象存儲OSS提供存儲服務。MiniMax在使用SelectDB后,利用OSS的數據高可用能力,計算引擎僅需單份數據寫入,存儲資源需求減少至Doris的二分之一,實際業務寫入吞吐能力提升超20%。此外,由于整體存儲成本的降低,SelectDB支持對歷史全量數據的實時查詢分析,大大提高了數據查詢效率。
優勢三:資源隔離,提高并發讀寫效率
MiniMax在使用Apache?Doris時,存在多個業務團隊共享同一實例進行全量數據查詢分析的情況,可能導致因不規范或大規模查詢耗盡實例資源,進而引發查詢或數據導入任務超時。
**阿里云SelectDB支持云原生多集群硬隔離能力,用戶可以將單個實例的計算資源劃分為多個邏輯集群,不同集群之間的分配獨立的****計算資源,實現了不同集群的嚴格物理資源隔離和數據共享,很好的解決負載隔離問題。此外,SelectDB還支持讀寫分離能力,進一步提高了并發查詢效率。MiniMax在使用了SelectDB后,采用了SelectDB多集群隔離能力,并將讀寫集群分開,避免了讀寫資源搶占帶來的實例穩定性問題,大大提高了并發讀寫效率。
優勢四:緩存加速,提供高吞吐與低延遲
**阿里云SelectDB通過單副本本地讀寫緩存、智能數據淘汰策略、高效列式存儲格式和先進壓縮算法,顯著提升了海量數據的讀寫效率。**業務進行數據查詢時,依據LRU的讀緩存策略,保證業務對于實時寫入數據和高頻查詢熱數據的查詢性能。當發現緩存命中率低和查詢性能不及預期時,可以進行實時的緩存空間擴容,以提升緩存命中率,PB級數據P95查詢可以在3秒內響應,提高了數據查詢效率。
阿里云SelectDB還具備高SLA保障,持久化數據存儲提供同城冗余和12個9的數據可靠性保障。此外,SelectDB還提供了直觀的用戶界面和產品化的運維工具,支持擴縮容、版本升級、參數配置和監控告警等操作,顯著降低了運維復雜度。用戶僅需關注計算資源、緩存大小和數據存儲使用率等核心指標,減少了開發和運維團隊的負擔。
?????????????
業務價值
基于阿里云SelectDB,MiniMax構建了覆蓋國內及海外業務的日志可觀測中臺,總體數據規模超過數PB,日均新增日志寫入量達數百TB。系統在P95分位查詢場景下的響應時間小于3秒,峰值時刻實現了超過10GB/s的讀寫吞吐。通過存算分離、高壓縮比算法和單副本熱緩存等技術手段,MiniMax在優化性能的同時顯著降低了建設成本,計算資源用量降低40%,熱數據存儲用量降低50%,為未來業務的高速發展和技術演進奠定了堅實基礎。
總結與展望
回顧MiniMax可觀測系統的演進歷程,從初期的Loki架構到Apache?Doris的引入,再到SelectDB的全面升級,每一次技術迭代都體現了MiniMax對業務需求的深刻理解和對技術創新的不懈追求。阿里云SelectDB憑借其卓越的性能、靈活的架構和強大的生態能力,為MiniMax提供了高效、穩定的日志存儲與分析服務,助力其在大模型實踐中實現成本與效率的最佳平衡。
未來,隨著MiniMax業務的持續高速發展,日志可觀測系統將繼續作為洞察系統運行狀態和優化性能的核心工具。阿里云將與MiniMax攜手,進一步挖掘日志數據的潛在價值,為業務創新提供更強有力的支持。