社交媒體應用的功能迭代速度極快。Snapchat 月活躍用戶數超過 9.4億，每一項新功能在發佈前都會經過嚴格的 A/B 測試。其母公司 Snap 每天早上在 3小時的窗口期內，使用 Apache Spark 分布式框架處理 超過10 PB 的資料，每月運行數千個實驗，測量近 6,000個 指標（用戶參與度、應用性能、變現情況）。
為了更高效地支撐這一規模，Snap 在谷歌雲服務上採用了 NVIDIA 的開放資料處理庫 cuDF，用於加速 Apache Spark 應用。
一、核心成果：更快、更省、更可持續
根據 Snap 內部資料（採集時間為1月1日至2月28日），從 CPU 遷移到 GPU 後：
| 指標 | 提升效果 |
|---|---|
| 處理速度 | 在相同機器數量下，運行速度提升 4倍 |
| 每日成本 | 在 Google Kubernetes Engine 上使用 NVIDIA GPU，節省 76% |
| GPU 需求 | 實際只需 2,100個 GPU 同時運行，低於最初預測的 5,500個 |
Snap 高級工程經理 Prudhvi Vatala 表示：
「將資料基礎設施從 CPU 遷移到 GPU，使我們能夠隨著時間的推移，讓實驗高效覆蓋更多功能、更多指標和更多用戶。我們能夠運行的實驗越多，就能夠為 Snapchat 用戶提供越多的創新體驗。」
他還指出：
「我們曾規劃了一個旨在擴大實驗規模的宏偉路線圖，但根據現有的基礎設施，這將導致計算成本急劇飆升。切換到使用 cuDF 的 GPU 加速管道，我們獲得了一種拉平擴展成本曲線的方式，結果非常驚人。」
二、技術方案：cuDF + Google Cloud + Kubernetes
Snap 採用的方案包含以下組件：
NVIDIA cuDF：GPU DataFrame 庫，用於加速資料處理
Apache Spark 加速器：讓開發者無需更改代碼即可在 NVIDIA GPU 上運行現有 Spark 應用
Google Kubernetes Engine (GKE)：基礎設施管理服務
NVIDIA L4 GPU：運行在谷歌雲 G2 虛擬機上
cuDF 微服務套件：自動對 Spark 工作負載進行資格認證、測試、配置和優化
A/B 測試團隊後端工程師 Joshua Sambasivam 表示：
「當我看到最初實驗的結果時，我感到非常驚訝，我們節省的成本遠高於預期。Spark 加速器非常適合我們的工作負載。」
三、未來計劃：擴展至更多生產工作負載
Snap 團隊目前已經遷移了兩個最大的管道，並計劃將 Spark 加速器集成到 A/B 測試團隊之外的更廣泛的生產工作負載中。
Vatala 總結道：
「我們沒有意識到自己會坐擁這塊金礦。到目前為止，我們已經遷移了兩個最大的管道，但未來還有很多機會。」
四、對企業客戶的啓示：為甚麼值得關注？
如果您所在的企業每天需要處理大量資料（10 PB 級別）、運行大規模 A/B 測試或使用 Apache Spark 進行資料分析，Snap 的案例提供了清晰的參考：
無需改代碼：現有 Spark 應用可直接在 GPU 上運行，降低遷移門檻
線性擴展成本：GPU 加速可以拉平擴展成本曲線，避免成本急劇飆升
實際驗證：在 Google Cloud + Kubernetes + NVIDIA L4 GPU 的生產環境中驗證
全棧優化：從硬體（L4 GPU）到軟體（cuDF、Spark加速器）再到編排（GKE）的完整方案
WeChat
Profile