劉敏 | 迅雷大數據平台負責人
尤帥 | 迅雷大數據平台資深工程師
陳照 | 阿里雲公共雲業務事業部解決方案架構師
潘錦棉 | 阿里雲公共雲業務事業部解決方案架構師
劉瑞偉 | 阿里雲公共雲業務事業部大數據解決方案架構師
一、背景介紹
企業簡介
迅雷（納斯達克股票代碼：XNET）作為全球分佈式技術領域的先行者，以技術構建商業，以服務創造共識，從而建立一個高效可信的存儲與傳輸網絡。
自2003年創立以來，公司通過持續深耕P2P傳輸、邊緣計算與區塊鏈技術，構建起覆蓋全球的高效可信數據網絡：這一網絡不僅承載着億級用户的日常數字生活，更成為Web3.0時代基礎設施的重要實踐者。
憑藉對極致用户體驗的追求，迅雷打造了多款行業標杆產品：革命性的迅雷下載引擎重新定義了文件傳輸效率，迅雷雲盤以去中心化存儲架構實現數據主權迴歸，玩客雲等智能硬件則開創了共享計算新生態。
截至2025年，迅雷產品矩陣已服務全球超4億註冊用户，形成極具價值的實時行為數據金礦。
技術底座決定商業邊界。迅雷深耕三大技術能力：
1. 海量數據實時治理能力：每秒處理PB級傳輸日誌與存儲元數據
2. 億級節點動態調度系統：通過智能算法實現全球分佈式節點毫秒級響應
3. 跨場景聯邦計算架構：在保障隱私安全前提下激活數據要素價值
這套經受高併發淬鍊的技術體系，不僅支撐着影視、遊戲、IoT等行業的關鍵業務場景，更沉澱出對數據流動規律的深度認知：這正是迅雷與阿里雲在大數據智能時代展開深度協同的底層邏輯。
核心業務痛點
隨着業務的發展，在大數據平台側遇到了一些痛點：
- 數據處理效率存在瓶頸：原 Hadoop 集羣難以充分利用業界領先的 Native 加速 與 Remote Shuffle Service 等技術，整體性能提升受限，進而影響降本增效。
- 計算資源彈性不足：原 Hadoop 集羣資源固定，當出現數據量突增、任務回溯等需要臨時擴容的場景時，容易發生資源緊張；且擴容週期較長，難以快速緩解問題。
- 運維複雜度較高：原集羣在資源層面需要較多人力介入；Spark 引擎升級、Python 環境管理等常見運維操作流程複雜且生產風險較高。同時，由於集羣版本偏低，在業務用量增長後更易觸發開源缺陷，導致穩定性下降，且難以原地升級。
- 成本管控壓力較大：調度任務呈現“夜間繁忙、日間空閒”的典型波峯波谷特徵，固定資源在日間存在較多閒置，造成不必要的成本浪費。
技術升級核心訴求
- 降本增效：在提升數據處理效率的同時，降低集羣運維成本與硬件投入成本；
- 極致彈性：實現計算資源“按需分配、秒級擴容”，精準匹配業務流量波動，避免資源閒置與短缺；
- 極簡運維：擺脱集羣管理負擔，讓技術團隊聚焦核心業務開發與優化；
- 穩定可靠：保障高併發場景下數據處理的穩定性與準確性，支持任務斷點續跑、故障自動恢復。
二、阿里雲 EMR Serverless Spark 技術賦能
1、Serverless 模式突破算力瓶頸，實現彈性敏捷的數據處理
原集羣是一個典型的服務器架構，困境是，資源要麼長期被打滿，要麼在空窗期大量閒置。圖中 yarn_cluster_totalMB 基本是一條平直的上沿線，代表集羣的總內存容量是固定不變的；而 yarn_cluster_allocatedMB 在大多數時間幾乎貼着這條上沿線運行，意味着集羣絕大部分時間都處在全分配的狀態。看上去利用率很高，但從架構與交付視角，這更像是在提示：集羣已經被當作一個“剛性資源池”使用，而不是一個能夠平滑承接業務波動的彈性資源底座。
當 allocatedMB 長時間接近 totalMB，系統幾乎沒有任何緩衝空間。只要業務側出現突發峯值、某個作業發生數據傾斜導致執行時間拉長、或者出現 shuffle 放大、重試增多，YARN 的調度就會立刻轉向排隊與擁塞。於是用户感知到的往往不是“高利用率”，而是更直觀的體驗問題：提交任務後排隊時間變長，交互式分析不再及時，批處理窗口被擠壓，甚至在極端情況下形成雪崩效應——任務變慢佔用資源更久，導致後續任務更排隊；排隊越多，超時與重試越多，反過來又進一步加劇擁塞。
在遷移到 EMR Serverless Spark 之後，從上述這張 Workspace memory consumption 曲線呈現出非常典型的“潮汐型負載”特徵：在業務高峯期內存用量可以快速拉昇到數十 TB；而在任務完成、負載回落後，資源佔用又能迅速下降，甚至迴歸到接近 0 的水平。對迅雷而言，這意味着計算資源不再被固定集羣容量所束縛，峯值時能夠按需獲得足夠的內存與併發能力去承接批處理窗口、突發任務或臨時分析，從而顯著降低排隊、擁塞與“頂格運行”的風險，讓作業完成時間與交付節奏更可控。
從系統能力角度看，這條曲線體現的是 Serverless Spark 把“容量規劃與資源池運維”從用户側徹底剝離：平台能夠基於作業生命週期自動拉起資源、按需擴展、在空閒時自動回收，實現真正的彈性伸縮與更強的資源隔離。最終帶來的直接收益是成本與使用量強綁定——高峯期用多少付多少，低谷期幾乎不產生資源佔用，也就不再為閒置容量長期買單；同時平台用自動化調度與回收機制保障資源供給的及時性與穩定性。
2、靈活訪問歸檔數據
迅雷數據團隊將大量OSS數據以歸檔、冷歸檔、深度冷歸檔類型存儲達到降低存儲費用的目的，這些歸檔數據無法直接訪問，需要提前執行解凍操作。
EMR Serverless Spark提供自動和手動兩種解凍方式便於作業靈活訪問歸檔數據，詳見解凍OSS歸檔文件
-
自動解凍，在作業生產plan階段識別出歸檔文件，自動提交解凍請求，使得作業執行時能夠正常讀取數據。但對於分區值需要動態計算得出的場景，自動解凍方式無法一次提交所有解凍請求，進而影響作業執行效率。
--conf spark.sql.emr.autoRestoreOssArchive.enabled=true - 手動解凍，提供restore sql語法顯示對錶、分區提前解凍，解凍過程對用户更友好。
藉助上述功能，我們能夠快速響應數據分析師對歷史歸檔數據的訪問需求，降低存儲成本的同時加速業務迭代。
-- 解凍整個表對應的OSS歸檔文件供後續查詢。
RESTORE TABLE table_name;
-- 指定分區解凍, 精細化控制解凍粒度，節省資源與時間。
RESTORE TABLE table_name PARTITION (pt1='a', pt2='b');3、基於Kyuubi的交互式開發
Serverless Spark內置了100%兼容開源的Kyuubi Gateway，並在雲原生穩定性和多租隔離性等方面進行了增強。一方面能複用Driver/Executor資源，避免容器啓動延遲，提供秒級查詢，另一方面利用Spark的動態資源伸縮，閒時及時釋放資源，避免浪費，從而提供高性價比的交互式分析能力。
迅雷自研的數據開發平台通過beeline和hue無縫對接Kyuubi Gateway，支持日常的數倉任務開發以及即席查詢，顯著提升開發分析效率，同時大幅降低了數據開發，數據分析和臨時查詢成本。
三、業務與技術價值雙重突破
遷移到 EMR Serverless Spark 之後，最直觀的感受是 TCO 明顯下降：不再需要為固定集羣按峯值長期備資源，平台按作業生命週期彈性拉起與回收，低谷期資源佔用可降到接近 0，只為實際消耗付費。同時，託管化帶來的穩定性與調度效率提升，減少了排隊、重試和資源爭搶等隱性成本，使同樣的業務產出用更少的資源與更少的運維投入就能完成。
更關鍵的是交付確定性提升：大作業整體可提速約 1 小時，報表鏈路從過去的長尾波動變成更可控的出數節奏，關鍵報表能穩定在 6:00 前產出。夜間人工干預大幅減少，基本無需運維人員深夜響應。本質上反映了失敗率與長尾顯著降低——平台通過彈性供給、隔離與自動化恢復，把原本需要人工兜底的容量與穩定性問題前移到系統能力中解決，讓生產鏈路更穩、更準點。
四、未來展望
在場景拓展上，將EMR Serverless Spark廣泛應用於臨時查詢、數據集成等更多業務場景，進一步釋放其彈性、免運維的優勢；另一方面，在技術深化上，積極探索AI與大數據的融合創新，充分發揮Serverless Spark在海量數據處理與AI協同方面的潛力，為業務創造更大價值。
