隨着新版本的推出，RAPIDS 迎來了其推出一週年紀念日。回顧所經歷的一年，RAPIDS團隊就社區對該項目的關心和支持表示衷心的感謝。此前，RAPIDS獲得了其首個BOSSIE獎。非常感謝各位的支持！RAPIDS團隊將繼續推動端對端數據科學加快發展，達到新高度。
關聯文章：
nvidia-rapids︱cuDF與pandas一樣的DataFrame庫
NVIDIA的python-GPU算法生態 ︱ RAPIDS 0.10
nvidia-rapids︱cuML機器學習加速庫
nvidia-rapids︱cuGraph(NetworkX-like)關係圖模型
文章目錄
RAPIDS
RAPIDS定義
RAPIDS，全稱Real-time Acceleration Platform for Integrated Data Science，是NVIDIA針對數據科學和機器學習推出的一套開源GPU加速庫，基於CUDA-X AI打造，可加速數據準備、模型訓練和圖分析。
使用RAPIDS加速庫可以實現從數據準備、模型訓練到預測整個端到端流程得到GPU的加速支持，大大提升任務的執行效率，在模型精度方面實現突破的同時降低基礎架構TCO。
CUDNN已經成爲GPU加速深度學習框架的標準加速庫。RAPIDS（如下圖）提供的cuDF、cuML和CuGraph則提供了對數據準備、機器學習算法以及圖分析的GPU加速庫。
RAPIDS支持輕量級大數據框架DASK，使得任務可以獲得多GPU、多節點的GPU加速支持。
RAPIDS以數據準備爲起點，引入新型 GPU 數據框架 (cuDF)，進而能實現並行化數據加載和數據操作，充分利用 NVIDIA GPU 上的大型高帶寬顯存。 cuDF 爲數據科學家提供了簡單易用且基於 Python 的工具集，可以替換其已十分熟悉的pandas 工具集。數據科學家無需從頭學習 NVIDIA CUDA 技術，只需要對現有代碼做出極少量更改，便能夠大幅提速數據準備，使其不再受限於 CPU 或 CPU 與內存之間的輸入輸出。
RAPIDS 還引入了不斷髮展壯大的全新 GPU 加速 ML 算法(cuML) 庫，當中包括 XGBoost 等時下熱門算法，以及 Kalman、K-means、 KNN、 DBScan、 PCA、 TSVD、 OLS 線性迴歸、Kalman Filtering 等算法。 ML 算法可產生大量數據傳輸，至今仍難以實現並行化。隨着 GPU 加速的 ML 和 NVIDIA NVLink™ 以及NVSwitch 架構陸續應用於服務器系統，模型訓練現可輕鬆分佈於多個 GPU 和多個節點（系統）之間，幾乎不會產生延遲，且能避過 CPU 與內存之間的輸入輸出瓶頸。
rapids背景資料
RAPIDS團隊在討論0.10版本時思考了之前Wes Mckinney所寫的一篇博客《Apache Arrow和“我最討厭Pandas的10個問題”》。
簡單回顧一下數據科學的歷史。十年前，組成今天大數據的許多要素相繼出現 。在數據世界的一角，Hadoop生態誕生， Hadoop、Hive、Cassandra、Mahout等都在快速發展。
另一方面，數據科學家口中的PyData堆棧正在興起。NetworkX（2005）、Numpy（2006）、Scikit-Learn（2007）和Pandas（2008）掀起了一波可用性浪潮；Hadoop、Hive、Cassandra、Flume、Pig和Spark將數據科學擴展到前所未有的水平。它們都在數據科學生態中加入了大量新的庫、供應商以及幾乎無數種構建數據管道方法，以解決數據科學的問題。
雖然新工具和工作流程的出現激動人心，但很少有人反過來思考在Apache Arrow之前，這些庫和框架如何進行有效協作。因此，大多數數據科學家/工程師將大部分時間用於庫之間的序列化和反序列化數據（大量副本和轉換）。
RAPIDS結合了人們喜愛的衆多庫.、社區和框架的諸多優點，以及人們在大規模使用這些工具時經歷過的困苦和煩惱。這些正面情緒與負面情緒引導RAPIDS生態解決了Wes討厭的關於Pandas的10個問題（實際上是11個問題）等。
“我最討厭Pandas的10個問題”列表
- 1、內部構件離“metal”太遠；
- 2、不支持內存映射數據集；
- 3、數據庫和文件攝取/導出性能不佳；
- 4、Warty缺少數據支持；
- 5、缺乏內存使用的透明度和RAM管理；
- 6、對分類數據的支持弱；
- 7、複雜的分組功能操作既笨拙又緩慢；
- 8、將數據附加到DataFrame很繁瑣且成本高昂；
- 9、類型元數據有限且不可擴展；
- 10、急切的評估模式，無查詢規劃；
- 11、“慢”，多核算法處理較大數據集的能力有限。
RAPIDS並非獨自解決這些問題；人們非常重視“生態”。沒有加速發展的數據科學生態，就不可能有RAPIDS。首先，RAPIDS是基於 Apache Arrow構建的。Apache Arrow是一個用於內存中數據的跨語言開發平臺。如果不是Apache項目及其貢獻者，那麼RAPIDS的構建將變得更加困難。然後，不要忘了Anaconda、Peter Wang和Travis Oliphant（爲我們帶來了許多促進其發展的PyData庫）以及他們爲了鼓勵和突出PyData生態性能所做的一切。Numba（2012）爲Python生態提供了一個JIT編譯器。該編譯器還可以針對RAPIDS在我們所有庫中都大量使用的GPU。由於能夠任意擴展功能並使用純Python編寫用戶定義函數（UDF），因此Python生態系統具有許多其他語言所沒有的優勢。
另外還有Python原生調度程序Dask（2014）。該程序可在整個Python生態中使用，並幾乎與所有調度程序（包括Slurm、Kubernetes和Yarn）存在關聯。GoAi（2017）聚集了多位GPU分析領域的開拓者構建RAPIDS基礎的原型並制定GPU庫之間的通信和互操作標準。最後，在互操作性方面，許多CUDA Python數組和深度學習庫（PyTorch、 MxNet、 Chainer、 CuPy和即將推出的 PaddlePaddle）採用DLPack和CUDA_Array_Interface（希望能夠有更多）。所有這些在RAPIDS生態中連接的庫一起實現了新庫的快速創建，例如cuSpatial、pyBlazing、cuXFilter和GFD（下文將作進一步的介紹），並且這種趨勢還將繼續。
就我個人而言，這也是我最喜歡RAPIDS的地方 —— 實現了Python生態GPU的民主化，使其他人能夠以前所未有的速度構建具有多種功能的高性能庫。爲了湊滿一張“10大”列表，我還要求每個RAPIDS庫的領導者說出他們對RAPIDS的喜愛之處（您會發現他們之前一定花了很多時間互相串通回答，因爲他們許多人的回答都相同）。
RAPIDS庫十大領先之處
Keith Kraus：
---- 速度 —— 核心功能“靠近metal”；
---- GPU生態互操作性；
---- PyData生態互操作性；
---- 強大的內存佈局語義；
---- 低級別訪問和控制（用戶可以在需要時獲取指向其數據的裸指針）；
---- 開源；
---- 深度學習框架集成；
---- 遵循已知的PyData 應用編程接口（API）；
---- 通過BlazingSQL實現的結構化查詢語言（SQL）。
John Zedlewski：
---- 我記得以前每天要 花好幾個小時等待大型集羣上的機器學習工作批量完成，所以每次看到臺式機能夠在幾秒鐘內完成如此大型的工作我都很高興！
Bartley Richardson：
---- 對於專門研究某個領域 （例如網絡安全和信息安全）的數據科學家而言，其他Python工具之間的互操作性至關重要。我們不但受益於更快的數據分析（通常是網絡安全中的TB+級數據集），同時還能與安全分析人員所依賴的域專屬下游Python軟件包和API保持互操作性，這真的是太棒了。
Mark Harris：
---- 我們的團隊太出色了。RAPIDS團隊是一個由充滿熱情、能力出衆的人組成的一支多元化分佈式團隊。儘管我們分佈在世界各地，我們中的許多人在家工作，但我們的團隊可以通過公開交流和合作建立新的功能並以驚人的速度解決問題。每個人都積極地提供幫助，而經常逼迫自己接觸自己專業領域以外的東西以學習新的技能。我們覺得做這件事情十分快樂。
Brad Rees：
---- ETL、數據工程、機器學習和圖表分析之間實現了無縫過渡。RAPIDS讓數據科學家只需要考慮分析即可，而無需考慮如何在工具之間移動數據。
Matt Rocklin：
---- 我喜歡RAPIDS符合標準的Python API，這樣就可以輕鬆地與現有的Python生態系統集成；
---- 我喜歡RAPIDS爲許多其他Python軟件包做出了貢獻，而不是隻管自己；
---- 我喜歡RAPIDS讓用戶可以輕鬆、快速地嘗試各種硬件，而不必學習新系統；
---- 我喜歡RAPIDS使新科學領域的發展速度加快，而不僅僅是增加深度學習功能。
RAPIDS核心庫更新
cuDF
cuDF在過去一年中的發展速度非常之快。每個版本都加入了令人興奮的新功能、優化和錯誤修復。0.10版本也不例外。cuDF 0.10版本的一些新功能包括 groupby.quantile()、Series.isin()、從遠程/雲文件系統（例如hdfs、gcs、s3）讀取、Series和DataFrame isna()、按分組功能中的任意長度Series分組 、Series 協方差和Pearson相關性以及從DataFrame / Series .values 屬性返回 CuPy數組。此外，apply UDF函數API經過了優化，並且加入了通過.iloc訪問器的收集和散播方法。
除了提供所有上述出色的功能、優化和錯誤修復之外，cuDF 0.10版本還花費大量的精力構建未來。該版本將cuStrings存儲庫合併到cuDF中，併爲合併兩個代碼庫做好了準備，使字符串功能能夠被更緊密地集成到cuDF中，以此提供更快的加速和更多的功能。此外，RAPIDS添加了cuStreamz元數據包，因此可以使用cuDF和Streamz庫簡化GPU加速流處理。cuDF繼續改進其Pandas API兼容性和Dask DataFrame互操作性，使我們的用戶可以最大程度地無縫使用cuDF。
在幕後，libcudf的內部架構正在經歷一次重大的重新設計。0.10版本加入了最新的cudf :: column和cudf :: table類，這些類大大提高了內存所有權控制的強健性，併爲將來支持可變大小數據類型（包括字符串列、數組和結構）奠定了基礎。由於已構建對整個libcudf API中的新類的支持，這項工作將在下一個版本週期中繼續進行。此外，libcudf 0.10添加了許多新的API和算法，包括基於排序、支持空數據的分組功能、分組功能分位數和中位數、cudf :: unique_count，cudf :: repeat、cudf :: scatter_to_tables等。與以往一樣，此版本還包括許多其他改進和修復。
RAPIDS內存管理器庫RMM也正在進行一系列重組。這次重組包括一個基於內存資源的新架構，該架構與C ++ 17 std :: pmr :: memory_resource大多兼容。這使該庫更容易在公共接口之後添加新類型的內存分配器。0.10還用Cython取代了CFFI Python綁定，從而使C ++異常可以傳播到Python異常，使更多可調整的錯誤被傳遞給應用程序。下一個版本將繼續提高RMM中的異常支持。
最後，你會注意到cuDF在這個版本中速度有了顯著提升，包括join（最多11倍）、gather和scatter on tables（速度也快2-3倍）的大幅性能改進，以及更多如圖5所示的內容。
圖5：單個NVIDIA Tesla V100（立即免費試用） GPU與雙路Intel Xeon E5–2698 v4 CPU（20核）上的cuDF vs Pandas加速
cuML 和 XGBoost
RAPIDS團隊開始爲GPU加速XGBoost（最流行的梯度漸變決策樹庫之一）做出貢獻時承諾將所有改進上游移至主存儲庫而不是創建長期運行的fork。RAPIDS團隊高興地宣佈，0.10版本隨附一個完全基於XGBoost主分支的XGBoost conda軟件包。這是一個快照版本，該版本包含即將發佈的1.0.0 XGBoost版本中的許多功能。它支持將數據從cuDF DataFrames加載到XGBoost時的透明性，並且提供更加簡潔的全新Dask API選項（詳細信息請參見XGBoost存儲庫）。目前已棄用較舊的Dask-XGBoost API，但它仍可以與RAPIDS 0.10配合使用。爲了簡化下載，目前XGBoost的conda軟件包（rapids-xgboost）已被包含在主要的Rapidsai conda通道中，如果你安裝了RAPIDS conda元軟件包，就會自動安裝 conda軟件包（詳細信息請參見入門頁面）。
對比：Intel Xeon E5–2698 v4 CPU（20核）與NVIDIA V100
RAPIDS機器學習庫cuML 擴展後支持多種流行的機器學習算法。cuML現在包含一個支持向量機分類器（SVC）模型，其速度比同等CPU版本快300倍。它在CannyLabs的GPU加速工作基礎上建立一個加速TSNE模型，該模型提供最受歡迎的高性能降維方法，同時其運行速度比基於CPU的模型快1000倍。我們隨機森林模型的每個版本都在不斷改進，並且現在包含了一個分層算法，其速度比scikit-learn的隨機森林訓練快30倍。
從cuML 訓練到推理
不僅是訓練，要想真正在GPU上擴展數據科學，也需要加速端到端的應用程序。cuML 0.9 爲我們帶來了基於GPU的樹模型支持的下一個發展，包括新的森林推理庫（FIL）。FIL是一個輕量級的GPU加速引擎，它對基於樹形模型進行推理，包括梯度增強決策樹和隨機森林。使用單個V100 GPU和兩行Python代碼，用戶就可以加載一個已保存的XGBoost或LightGBM模型，並對新數據執行推理，速度比雙20核CPU節點快36倍。在開源Treelite軟件包的基礎上，下一個版本的FIL還將添加對scikit-learn和cuML隨機森林模型的支持。
圖3：推理速度對比，XGBoost CPU vs 森林推理庫 (FIL) GPU
圖4：XGBoost CPU和FIL推理時間隨批處理大小的增加而擴展（越低越好）
將來，cuML還將支持GPU上其他算法的推理。
Dask
Dask在HPC和Kubernetes系統上實現了標準化部署，包括支持與客戶端分開運行調度程序，從而使用戶可以在本地筆記本計算機上輕鬆地啓動遠程集羣上的計算。Dask還爲使用雲但無法採用Kubernetes的機構添加了AWS ECS原生支持。
UCX上的高性能通信開發仍在繼續，包括使用NVLINK的單個節點中的GPU以及使用InfiniBand的集羣中的多個節點。RAPIDS團隊已將ucx-py綁定重寫，使其變得更簡潔，並解決了跨Python-GPU庫（如Numba、RAPIDS和UCX）共享內存管理方面的多個問題。
cuGraph
cuGraph已在將領先的圖形框架集成到一個簡單易用的接口方面邁出了新的一步。幾個月前，RAPIDS收到了來自佐治亞理工學院的Hornet副本，並將其重構和重命名爲cuHornet。這一名稱更改表明，源代碼已偏離Georgia Tech基準並體現了代碼API和數據結構與RAPIDS cuGraph的匹配。cuHornet的加入提供了基於邊界的編程模型、動態數據結構以及現有分析的列表。除了核心數函數之外，可用的前兩個cuHornet算法是Katz centrality 和K-Cores。
cuGraph是RAPIDS的圖形分析庫，針對cuGraph我們推出了一個由兩個新原語支持的多GPU PageRank算法：這是一個COO到CSR的多GPU數據轉換器，和一個計算頂點度的函數。這些原語會被用於將源和目標邊緣列從Dask Dataframe轉換爲圖形格式，並使PageRank能夠跨越多個GPU進行縮放。
下圖顯示了新的多GPU PageRank算法的性能。與之前的PageRank基準運行時刻不同，這些運行時刻只是測量PageRank解算器的性能。這組運行時刻包括Dask DataFrame到CSR的轉換、PageRank執行以及從CSR返回到DataFrame的結果轉換。平均結果顯示，新的多GPU PageRank分析比100節點Spark集羣快10倍以上。
圖1：cuGraph PageRank在不同數量的邊緣和NVIDIA Tesla V 100上計算所用的時間
下圖僅查看Bigdata數據集、5000萬個頂點和19.8億條邊，並運行HiBench端到端測試。HiBench基準運行時刻包括數據讀取、運行PageRank，然後得到所有頂點的得分。此前，HiBench分別在10、20、50和100個節點的Google GCP上進行了測試。
圖2：5千萬邊緣端到端PageRank運行時刻，cuGraph PageRank vs Spark Graph（越低越好）
cuGraph 0.9還包括了一個新的單GPU強連接組件功能。
cuSpatial
RAPIDS 0.10還包括cuSpatial的初始版本。cuSpatial是一個高效C ++庫，它被用於使用CUDA和cuDF的GPU加速地理空間分析。該庫包含供數據科學家使用的python綁定。cuSpatial比現有算法實現的速度提高了50倍以上並且還在開發中。cuSpatial的初始版本包括用於計算軌跡聚類、距離和速度、hausdorff和hasrsine距離、空間窗口投影、多邊形中的點以及窗口相交的GPU加速算法。在未來版本中，將有計劃地添加shapefile支持和四叉樹索引。
cuDataShader
發佈該RAPIDS版本的同時，RAPIDS還發布了cuDataShader GPU加速和cuDF支持端口。該端口用於高性能的Datashader。憑藉快速、大規模的數據可視化功能及其圍繞python的設計，Datashader非常適合與GPU驅動的viz一起使用。我們的第一個版本實現了大約50倍的速度。基於這些結果，將在下一個版本中將GPU功能加入到Datashader本身 ！因此請繼續關注該產品。如果您想嘗試，最簡單的方法就是在我們的另一個Viz庫cuXfilter中使用它。
cuXfilter
cuXfilter被用於支持我們的按揭虛擬化演示（新的鏈接位於此處），在經過完全重構後，其交叉過濾儀表板的安裝和創建變得更加簡單，而所有這些工作都可以通過python筆記本計算機完成！由於網絡上有許多出色的可視化庫，因此我們一般不創建自己的圖表庫，而是通過更快的加速、更大的數據集和更好的開發用戶體驗來增強其他圖表庫，這是爲了消除將多個圖表互連到GPU後端的麻煩，使你可以更快地以可視化方式瀏覽數據。
RAPIDS社區
用戶對生態的貢獻是最大的。BlazingSQL剛剛發佈了V0.4.5，該版本在GPU上的運行速度更快，並且加入了新的基準測試。和GCP上的TPC-H查詢從本地NVME和GCS提取數據的情況相比，該基準測試能夠查詢600M行。ensemblecap.ai的Ritchie Ng發佈了使用RAPIDS cuDF的分數差分（GFD）GPU 實現方法，該實現方法的速度比CPU高出100倍以上。
在接下來的幾個月時間，RAPIDS工程團隊將在全球各地的活動、會議和編程馬拉松上進行演示並提供教程。加入我們的GTC DC、PyData NYC和PyData LA。RAPIDS團隊希望與你共同努力，不斷完善RAPIDS。
阿里雲GPU雲服務器現已支持NVIDIA RAPIDS加速庫
支持實例
阿里雲目前支持RAPIDS的實例規格有GN6i（Tesla T4（立即免費試用））、GN6v（Tesla V100（立即免費試用））、GN5（Tesla P100）和GN5i（Tesla P4）。
如何在GPU實例上使用RAPIDS加速庫
關於如何在阿里雲GPU實例上基於NGC環境使用RAPIDS加速庫，請參考文檔：《在GPU實例上使用RAPIDS加速機器學習任務》。
按照上述文檔，可以運行一個單機的GPU加速的數據預處理+訓練的XGBoost Demo，並對比GPU與CPU的訓練時間。
用戶也可以通過選擇更多的數據量和GPU個數來驗證多GPU的支持。
後續阿里雲還會繼續提供更多的RAPIDS加速的最佳實踐。
參考文獻
RAPIDS 0.10現已推出！數據科學數十載的成果，人見人愛
超級公開課第17講 | 開源軟件平臺RAPIDS如何加速數據科學
RAPIDS 0.9 現已推出：構建了許多新的算法