網易雲音樂機器學習平臺實踐

作者： burness

機器學習平臺基礎架構

在網易雲音樂內部，機器學習平臺早期主要承擔著包括音樂推薦、主站搜尋、創新演算法業務在內的核心業務，慢慢地也覆蓋包括音視訊、NLP等內容理解業務。機器學習平臺基礎架構如下，目前我按功能將其抽象為四層，本篇文章也會從這四個方面詳細描述我們在各個抽象層的具體工作。

資源層:平臺核心能力保障

主要為平臺提供資源保障與成本優化的能力，資源保障覆蓋了包括算力、儲存、通訊、租戶等各個方面，而成本優化目前我們採用虛擬化，提供資源池的動態分配，另外考慮到某些業務突發性的大算力需求，資源層能夠快速、有效地從其他團隊、平臺資源層調取到足夠的資源提供給業務使用。本章以VK與阿里雲ECI為例，簡述雲音樂機器學習平臺在資源這塊的工作：

Visual Kubelet資源

目前網易內部有很多資源屬於不同的叢集來管理，有很多的k8s叢集，杭研雲端計算團隊開發kubeMiner網易跨kubernetes叢集統一排程系統，能夠動態接入其他閒置叢集的資源使用。過去一段時間，雲音樂機器學習平臺和雲端計算合作，將大部分CPU分散式相關的如圖計算、大規模離散和分散式訓練，彈性排程至vk資源，在vk資源保障的同時，能夠大大增加同時迭代模型的並行度，提升業務迭代效率；
平臺使用VK資源可以簡單地理解為外部叢集被虛擬為k8s叢集中的虛擬節點，並在外部叢集變化時更新虛擬節點狀態，這樣就可以直接藉助k8s自身的排程能力，支援Pod排程到外部叢集的跨叢集排程。

雲音樂平臺的CPU算力任務主要包括圖計算、大規模離散和分散式訓練三類，涉及到 tfjob, mpijob， paddlepaddle幾種任務型別，任務副本之間均需要網路通訊，包括跨叢集執行Pod Exec，單副本規格大概在（4c~8c, 12G~20G）之間；但是因資源算力不足，任務的副本數以及同時可執行的任務並行度很低，所以各個訓練業務需忍受長時間的訓練和任務執行等待。接入VK後，能夠充分利用某些叢集的閒置算力，多副本、多工並行地完成訓練模型的迭代。

阿里雲ECI

CPU資源可以通過kubeMiner來跨叢集排程，但是GPU這塊，基本上整個集團都比較緊張，為了防止未來某些時候，需要一定的GPU資源沒辦法滿足。機器學習平臺支援了阿里雲ECI的排程，以類似VK的方式在我們自己的機器學習平臺上排程起對應的GPU資源，如下是雲音樂機器學習平臺呼叫阿里雲ECI資源，在雲音樂機器學習平臺上，使用者只需要在選擇對應的阿里雲ECI資源，即可完成對阿里雲ECI的彈性排程，目前已有突發性業務在相關能力上使用：
截圖2021-12-21 下午3.29.22
截圖2021-12-21 下午3.30.34

底層基座層：基礎能力賦能使用者

底層基座層是利用資源層轉換為基礎的能力，比如通過spark、hadoop支援大資料基礎能力、通過flink支援實時資料處理能力，通過k8s+docker支援海量任務的資源排程能力，這其中我們主要講下ceph在整個平臺的使用以及我們在實踐優化中的一些工作。

Ceph

Ceph作為業界所指的一套分散式儲存，在機器學習平臺的業務中很多使用，比如在開發任務與排程任務中提供同一套檔案系統，方便打通開發與排程環境，多讀讀寫能力方便在分散式任務中同用一套檔案系統。當然，從0到1的接入，很多時候是功能性的需求，開源的Ceph存在即滿足目標。但是，當越來越多的使用者開始使用時，覆蓋各種各樣的場景，會有不同的需求，這裡我們總結Ceph在機器學習平臺上的一些待優化點：

資料安全性是機器學習平臺重中之重功能，雖然CephFS支援多副本儲存，但當出現誤刪等行為時，CephFS就無能為力了；為防止此類事故發生，要求CephFS有回收站功能；
叢集有大量儲存伺服器，如果這些伺服器均採用純機械盤，那麼效能可能不太夠，如果均採用純SSD，那麼成本可能會比較高，因此期望使用SSD做日誌盤，機械盤做資料盤這一混部邏輯，並基於此做相應的效能優化；
作為統一開發環境，便隨著大量的程式碼編譯、日誌讀寫、樣本下載，這要求CephFS既能有較高的吞吐量，又能快速處理大量小檔案。

針對這些相關的問題，我們聯合集團的數帆儲存團隊，在Ceph上做了比較多的優化：

改進一：設計並實現基於CephFS的防誤刪系統

當前CephFS原生系統是沒有回收站這一功能的，這也就意味著一旦使用者刪除了檔案，那麼就再也無法找回該檔案了。眾所周知，資料是一個企業和團隊最有價值的無形核心資產，有價值的資料一旦遭到損壞，對一個企業和團隊來說很可能是滅頂之災。2020年，某上市公司的資料遭員工刪除，導致其股價大跌，市值蒸發幾十億港元，更嚴重的是，合作伙伴對其信任降到了冰點，其後續業績也遭到了巨大打擊。
因此，如何保障資料的可靠性是一個關鍵問題。但是，CephFS這一開源明星儲存產品恰恰缺少了這一環。防誤刪功能作為數帆儲存團隊與雲音樂共建專案中的重點被提上了日程。經過團隊的攻堅，最終實現了回收站這一防誤刪功能。

新開發的回收站在CephFS中初始化了trashbin目錄，並將使用者的unlink/rmdir請求通過後端轉換成了rename請求，rename的目的地就是trashbin目錄。保證了業務使用習慣的一致性和無感。回收站保持逾期定期清理的機制。恢復上，通過構建回收站內相關檔案的目錄樹，然後rename回收站內的檔案至目標位置來進行恢復。

改進二：混合儲存系統的效能優化

通過長時間觀察分析機器學習平臺io狀態，發現經常性存在短時間的壓力突增情況。對於使用者來說，其最關注的就是成本以及AI任務訓練時長（儲存IO時延敏感）。而目前：對於公司內外部使用者，如果是追求效能的使用者，數帆儲存團隊提供基於全快閃記憶體盤的儲存系統；如果是追求成本的使用者，數帆儲存團隊這邊提供基於全機械盤的儲存系統。這裡我們提供一種兼具成本與效能的儲存系統方案，

該架構也算是業界較常用的架構之一，但是有一個問題制約該混部架構的發展，即直接基於Ceph社群原生程式碼使用該架構，效能只比純機械盤的叢集好一倍不到。因此，數帆儲存團隊對Ceph程式碼進行了深度分析與改造，最終攻克了影響效能的兩個關鍵瓶頸點：重耗時模組影響上下文以及重耗時模組在IO核心路徑，如下圖示紅所示：

經過數帆儲存團隊的效能優化之後，該混部系統效能相較於社群原生版本有了顯著提升，在資源充足的情況下，IO時延以及IOPS等效能指標有七八倍的提升，當資源不足且達到限流後，效能也有一倍以上的提升。

改進三：設計並實現了基於CephFS的全方位效能優化

CephFS作為基本的分散式儲存，簡單易用是優勢，但是在很多場景下存在著效能問題：比如業務程式碼、資料管理、原始碼編譯造成的卡頓、延遲過高；比如使用者刪除海量資料目錄耗時非常久，有時候甚至要達到數天；比如因多使用者分散式寫模型導致的共享卡頓問題。這些問題嚴重影響著使用者的使用體驗。因此，數帆儲存團隊對效能問題進行了深入研究與改進，除了上面提到的在混合盤場景下的效能優化，我們在CephFS後設資料訪問以及大檔案刪除等多方面都進行了效能優化。

在大目錄刪除方面：我們開發了大目錄非同步刪除功能：使用者在日常業務中，經常會遇到需要刪除大目錄情況。這些目錄一般包含幾千萬個檔案，總容量在數個TB級別。現在使用者的常規方式是使用Linux下的rm -rf 命令，整個過程耗時非常久，有時甚至超過24小時，嚴重影響使用體驗。因此，使用者希望能提供一種快速刪除指定目錄的功能，且可以接受使用定製化介面。基於此，我們開發了大目錄非同步刪除功能，這樣使得大目錄的刪除對使用者來說可以秒級完成；
在大檔案IO方面：我們優化了大檔案寫效能，最終使得寫頻寬可以提升一倍以上，寫延時可以下降一倍以上，具體效能指標如下；
在優化使用者開發環境git和make編譯等都很慢方面：使用者在容器原始碼目錄中使用git status非常慢，耗時數十秒以上，同時，使用make編譯等操作也異常慢，基於該問題，杭州儲存組對該問題進行了細緻分析：通過strace跟蹤簡單的git status命令發現，流程中包含了大量的stat, lstat, fstat, getdents等後設資料操作，單個syscall的請求時延一般在百us級別，但是數千個（對於Ceph原始碼專案，大概有4K個）請求疊加之後，造成了達到秒級的時延，使用者感受明顯。橫向對比本地檔案系統（xfs，ext4），通常每個syscall的請求時延要低一個數量級（十us級別），因此整體速度快很多。進一步分析發現，延時主要消耗在FUSE的核心模組與使用者態互動上，即使在後設資料全快取的情況下，每個syscall耗時依然比核心態檔案系統高了一個數量級。接下來數帆儲存團隊通過把使用者態服務轉化為核心服務後，效能得到了數十倍的提升，解決了使用者卡頓的這一體驗；
後設資料請求時延方面：分析發現，使用者的很多請求時延較高原因是open，stat等後設資料請求時延較高，因此，基於該問題我們採用了多後設資料節點的方案，最終使得後設資料的平均訪問時延可以下降一倍以上；

應用框架層：覆蓋大部分機器學習業務的工具能力

應用框架層主要承擔業務落地業務時，使用的框架能力，比如眾所周知的TensorFlow框架、分散式訓練任務能力、大規模圖神經網路能力等等，本章將從TensorFlow資源遷移與大規模圖神經網路兩塊工作講述團隊這塊的工作：

TensorFlow與資源遷移

考慮到算力資源的不足，在2021年，我們採購了一批新的算力，A100的機器，也遇到了一些問題：

資源與社群：
- A100等新顯示卡僅支援CUDA11，官方不支援CUDA10，而官方TensorFlow只有最新版本2.4以上版本支援CUDA11，而現在音樂用的比較多的TF1.X，原始碼編譯無法解決跨版本問題，Nvidia社群僅貢獻Nvidia-TensorFlow支援CUDA11；
- TensorFlow版本間差異較大，TF1.X與TF2.X， TF2.4.0以下與TF2.4.0以上差異很大；
- TensorFlow1.X的社群相關問題，如環境、效能，Google官方不予支援；
音樂內部機器學習基礎架構：
- RTRS目前僅支援TF1.14，目前針對TF1.X，Google不支援CUDA11，Nvidia官方出了Nvidia-TensorFlow1.15來支援，但是這種並不屬於官方版本，內部程式碼更改太多，風險較大；
- 針對目前各個業務組內維護的Java jni 模型推理的情況，如果需要使用新硬體進行模型訓練，需要支援至少CUDA11的對應的TF版本（2.4以上）；
- 模型訓練側程式碼，目前版本為TF1.12-TF1.14之間；

基於這樣的背景，我們完成機器學習平臺TF2.6版本的全流程支援，從樣本讀寫、模型訓練、模型線上推理，全面支援TF2.6，具體的事項包括：

機器學習平臺支援TF2.6以及Nvidia TF1.15兩套框架來適配Cuda11；
考慮到單A100效能極強，在大部分業務的模型訓練中無法充分發揮其效能。因而，我們選擇將一張A100切分成更小的算力單元，需要詳細瞭解的可以關注nvidia mig 介紹，可以大大提升平臺整體的吞吐率；
mig的好處，能夠大大地提升平臺整體的吞吐率，但是A100經過虛擬化之後，顯示卡例項的排程以及相關的監控也是平臺比較複雜的工作；
離線訓練升級到較高版本之後，推理框架也需要升級，保證相容TF1.x與TF2.x的框架產生的模型；

通過完成上述事項，在完成A100 MIG能力的支援之後，整體從訓練速度、推理改造後的資料來看，大大超出預期，離線任務我們使用新顯示卡1/3的算力可以在常規的任務老版本算力上平均有40%以上的訓練速度提升，最高有170%以上的提升，而線上推理效能，通過適配2.6的TensorFlow版本，在保證完全相容TF1.X的線上版本的同時，獲得20%以上的推理效能提升。在A100切分例項上，我們目前提供2g-10gb、3g-20gb、4g-40gb三類顯示卡例項，覆蓋平臺日常的任務型別，其他指標如穩定性均大大超過老版本算力。

大規模圖神經網路

隨著從傳統音樂工具軟體到音樂內容社群的轉變，雲音樂依託音樂主站業務，衍生大量創新業務，如直播、播客、K歌等。創新業務既是機遇也為推薦演算法同學帶來了挑戰：使用者在創新業務中的行為稀疏，冷啟動現象明顯；即使是老業務也面臨著如下問題：

如何為新使用者有效分發內容；
將新內容有效分發給使用者；

我們基於飛槳圖學習框架PGL，使用全站使用者行為資料構建使用者的隱向量表徵，刻畫使用者之間的隱性關係，提供個性化召回、相似挖掘、lookalike 等功能；在實踐中，我們遇到了各種難點挑戰：

難點一：存在多種行為物件、行為型別，使用者行為資料量大，近五億節點（包含使用者、歌曲、mlog、播客等），數百億條邊的資料規模；
難點二：模型訓練難，模型本身引數量巨大，需要大量算力資源來保障模型的訓練；
難點三：在企業界，落地像圖神經網路這類技術時，需要綜合考慮成本與收益，其中成本主要包括兩個方面：架構改造成本與計算資源成本；

為解決這些難點，我們基於網易雲音樂機器學習平臺落地了以下具體的技術方案：

GraphService提供類似於圖資料庫，基於海量的弱終端資源，提供巨圖儲存與取樣的服務、通過巨圖資料載入優化策略，滿足不同規模模型以及不同取樣方法；
通過k8s MPI-Operator實現了超大規模圖儲存與取樣，是實現通用構圖方案可用易用必要的基礎元件；
整合k8s TF-Operator 與MPI-Operator解決模型分散式訓練中的圖儲存、取樣與分散式模型計算的問題；
通過k8s VK資源與cephfs實現計算儲存資源彈性擴容
訓練過程會消耗大量計算儲存資源，訓練結束，這些資源就會閒置，通過cephfs實現儲存資源動態擴縮容；通過virtual-kubelet等閒置計算資源引入機器學習平臺，實現彈性擴容，按需計費，大大減少大規模分散式任務的訓練成本；

功能層：化零為整與化整為零的藝術

功能層主要是機器學習平臺做為一處機器學習基礎設施，去支援整個機器學習過程的全生命週期，在雲音樂，一個標準的機器學習流，主要包括四個部分：

資料樣本服務；
特徵運算元開發與配置開發；
模型訓練與離線評估；
模型服務開發與部署、持續更新；

而通過整合機器學習流中覆蓋的各個部分的不同系統，端到端機器學習平臺目的是為了更高效、方便的為演算法開發以及相關的使用者提供各種能力的支援。而在核心任務之外，機器學習平臺也會抽離部分階段的能力，為包括通過模型服務、模型共享等相關工作提供部分元件的支援；接下來會分別從端到端機器學習平臺與ModelZoo兩個專案來分享我們在這塊的工作：

端到端機器學習平臺：化零為整

端對端機器學習平臺是通過機器學習平臺，抽象出一套能夠打通樣本處理、特徵存取、線上服務開發、程式碼/資料版本控制系統、線上服務系統推送、abtest系統標準化流程，抽象出相應地介面，為各個機器學習子系統整合至機器學習平臺，複用包括容器化、系統互聯、彈性資源、監控等核心能力。端對端機器學習平臺目的的願景是提供一種以模型為中心的機器學習開發正規化，通過後設資料中心，將整個生命週期的相關後設資料關聯至模型任務，以模型的視角去串聯整個機器學習生命週期的各個階段。為了達到這個目的，我們在以下幾個方面完成相應的工作：

樣本服務

資料樣本收集與預處理，主要涉及大資料系統的對接，早期而言，資料樣本的開發並沒有相關的系統支援，業務同學自己寫Spark、Flink任務，進行樣本收集、清洗、預處理等過程。因而，聯通系統，僅需要機器學習平臺本身支援使用者開發樣本任務的聯通，音樂內部業務上游主要使用兩部分的資料開發平臺：猛獁與自研的Pandora與Magina，在機器學習平臺上，支援任務級別的依賴，同時考慮到其他任務的多樣性，我們在每一個容器中，提供大資料框架的接入能力，支援Spark、Flink、Hadoop等基礎框架。
而通過一段時間的迭代之後，我們通過約束標準的特徵使用方式，基於網易雲音樂基礎的儲存套件Datahub，提供一套標準的FeatureStore。在此基礎上，標準化業務的樣本生成邏輯，使用者僅需修改少部分的樣本生成模板中的邏輯，即可完成一個標準化的業務樣本服務，為使用者提供實時、離線的樣本生成能力。

特徵運算元開發與配置開發

特徵運算元開發與配置開發，是一個標準的機器學習流程必須的過程，也是比較複雜的過程，是樣本服務的前置邏輯。在雲音樂，線上推理框架，簡稱RTRS，抽象出專門的特徵處理模組，提供給使用者開發特徵運算元、使用特徵運算元生成的邏輯。

使用者在原始資料處理時通過特徵計算DSL語音配置已有運算元或者自定義特徵處理邏輯，編譯成相應地feature_extractor包，線上上服務或者樣本服務裡使用，提供給模型引擎與訓練任務使用，具體詳情可關注雲音樂預估系統建設與實踐這篇文章。

模型服務開發與部署

目前網易雲音樂線上的核心業務，主要使用模型服務框架是RTRS，RTRS底層基於C++開發的，而C++的相關應用開發，存在兩個比較麻煩的地方：

開發環境：總所周知，機器學習相關離線與線上作業系統不匹配，如何以一種比較優雅的方式提供使用者模型開發同時也支援服務開發的能力？網易雲音樂機器學習平臺底層基於K8S+docker，提供定製化的作業系統；
依賴庫、框架的共享：在進行rtrs服務的開發時，環境中需要整合一些公共的依賴，比如框架程式碼、第三方依賴庫等等，通過機器學習提供的統一的分散式儲存，只需要掛載指定的公共pvc，即可滿足相關需求；

模型的部署可簡單區分為兩個過程：

首次模型的部署：首次模型的部分比較複雜，涉及到線上資源申請、環境安裝配置等流程，並且在首次模型部署時，需要統一拉取RTRS服務框架，通過載入業務自定義邏輯so包以及模型、配置、資料檔案，提供基礎的模型服務能力；
模型、配置、資料的更新：在首次模型部署之後，由於時間漂移、特徵漂移以及種種其他原因，我們會收集足夠多的訓練樣本重新訓練模型或者更新我們的配置、詞典等資料檔案，這個時候，我們通常不是重新發布模型推理服務，而且去動態更新模型、配置、包括詞典在內的資料檔案等等；

而機器學習平臺通過標準化的模型推送元件，適配RTRS的模型部署以及線上服務的更新。

端對端機器學習平臺的收益

減少使用者參與，提升效率
端對端機器學習平臺將核心業務的主要流程通過模型關聯在一起，以模型為中心視角，能夠有效地利用上下游的基本資訊，比如在樣本特徵，可以通過複用樣本服務中生成的特徵schema的資訊，減少在模型訓練、模型推理時的特徵輸入部分的開發，能大大減少相關的開發工作，通過我們在某些業務的實驗，能夠將業務從0開發的過程花費的時間從周級別到天級別。

機器學習流程視覺化與生命週期資料跟蹤
端對端機器學習平臺通過統一的後設資料中心，將各個階段的後設資料統一管理，提供機器學習流程視覺化能力：
並且通過各個階段標準化的後設資料接入，能夠有效蹤機器學習過程各個階段的生命週期資料以及資源使用情況，如樣本使用特徵、樣本拼接任務的資源使用情況、模型最終上線的各個特徵處理方式、模型訓練的超參等等：

ModelZoo：化整為零

業務背景

下圖是對各個公司的機器學習業務模型上線佔用時間的一個調查資料的說明，大部分的資料科學家、演算法工程師在模型上線上花費過多的時間：

ModelZoo功能分層

符合我們在雲音樂內部業務落地的認知，而除了前面我們討論的端到端的標準化的核心業務的解決方案，雲音樂內部一些演算法團隊也會對其中的某些功能元件，有很強的需求，比如我們的通用模型服務，使用者希望通過易用、高效地部署方式去構建可在實際場景中使用的通用模型，這個就是ModelZoo的由來，在這個之上，我們希望後續通用模型能在流程上打通再訓練、微調，將能公開的已部署的模型，直接提供給有需求的業務方，Model的基礎功能分層如下：

資源層：資源層覆蓋機器學習平臺所有任務資源，包括GPU、VK資源、阿里雲ECI資源；
演算法層：覆蓋包括CV、NLP、以及其他有通用能力需要的能力模組如faiss分散式能力；
交付層：主要包括SDK、介面兩種交付方式，其中SDK模組用於提供給演算法整合開發過程的場景使用，介面用於無演算法整合的場景下使用，提供使用者自定義模型介面構建、介面提供服務等核心功能；
任務層：提供包括推理、微調、重訓等核心功能，通過SDK功能、介面功能提供；

ModelZoo進展

ModelZoo到目前為止，我們的工作大概在這幾方面：

通過K8S支援Serveless的能力，使用合適的映象如TF Serving、TorchServe，即可對模型做通用的模型服務；
基於機器學習平臺開，整合在模型部署元件中，提供元件部署通用模型推理的服務；
通過我們交付的元件，使用者僅需要通過指定模型包（包括部署的一些基礎元資訊），來部署相應的服務。如果需要額外的前後處理，也支援在torchserve中自定義前後處理的邏輯；
在映象層通過引入mkl編譯的映象、調整session執行緒數等核心引數，在高qps場景上，rt減少30%；
調研openvino、triton，目前由於業務已滿足需求以及人力需求，暫無進一步投入，有相關經驗的歡迎分享；

總結

以上就是網易雲音樂機器學習平臺的過去的一些工作，回顧一下，我們分別從“資源層”、“底層框架層”、“應用框架層”、“功能層”來分享相關的部分工作以及進展，機器學習平臺因為覆蓋的面很廣泛，工作看起來比較雜亂，覆蓋各種不同的技術棧，並且各項工作的挑戰與目標都不一樣，還是很有意思的。

本文釋出自網易雲音樂技術團隊，文章未經授權禁止任何形式的轉載。我們常年招收各類技術崗位，如果你準備換工作，又恰好喜歡雲音樂，那就加入我們 staff.musicrecruit@service.ne... 。