全文共3482字，預計學習時長7分鐘
如今，大家都在Python工具（pandas和Scikit-learn)的簡潔性、Spark和Hadoop的可擴展性以及Kubernetes的操作就緒之間做選擇。結果是，選擇應用了以上所有工具。主攻Python的數據科學家、精通Java和Scala Spark的大師和一批開發者，他們三批人馬保持獨立，分別管理解決辦法。
數據科學家們用pandas進行探索。然後，其他的數據工程師團隊重新編寫相同的邏輯代碼並使其大規模工作，或者使用Spark令其與實時流一同工作。當數據科學家需要更改邏輯或將一個不同的數據集用於他/她的模型時，則會進行一次次地迭代。
除了注意業務邏輯之外，還要分別或同時在Hadoop和Kubernetes構建集群，並應用整個CI / CD過程手動進行管理。最重要的是，大家都在努力工作，沒有足夠的業務影響來展示它......
如果你想在Python中編寫簡單代碼，並且用比Spark更快的速度運行，同時無需重新編碼、無需開發者解決部署、擴展和監控問題，可能嗎？
你可能會「說我是一個夢想家」。我是一個夢想家，但不是唯一的一個！本篇文章將證明如今可以使用Nuclio和RAPIDSlimg令以上設想成為現實，它們是由NVIDIA孵化的免費開源數據科學加速平臺。
過去幾個月，有人將RAPIDS與Nuclio開源無伺服器項目和Iguazio的PaaS集成在一起。現在，使用相同的Python代碼會擁有更快的數據處理速度和可擴展性，並且由於採用無伺服器方法，其操作開銷可達到最低水平。
本文將對同樣廣受歡迎的實時數據的用例進行演示，它們由基於Json的日誌組成。本文將根據以上數據完成分析任務，並將聚合結果轉儲為壓縮的Parquet格式，便於進一步的查詢或機器學習訓練。本文將研究批和實時流（是的，使用簡單Python代碼的實時流）。但開始之前，先進行總體概述。
是什麼導致Python既慢又無法擴展？
在小型數據集上使用pandas時，其性能表現不錯，但這隻發生在整個數據集適合內存且在pandas和NumPy層下使用已優化的C代碼進行處理的情況下。處理大量數據包含集中的的IO操作、數據轉換、數據拷貝等，拖慢了處理的速度。從本質上講，臭名昭著的GIL 給Python帶來了線程同步的困難，在處理複雜任務時非常低效，異步Python相對更好，但其開發複雜且無法解決固有的鎖定問題。
像Spark這樣的框架具有異步引擎(Akka) 和內存優化數據布局的優勢，它們可以將工作分配給不同機器中的多個工作人員，從而提高性能和可擴展性，並使其成為實際標準。
RAPIDS幫助Python開掛
英偉達想出了絕佳的點子：保留面向Python的API（接口）中受歡迎框架，如pandas、Scikit-learn和,而在GPU的高性能C代碼中處理數據。他們採用內存友好型的ApacheArrow 數據格式，以加速數據傳輸和操作。
RAPIDS支持數據IO (cuIO), 數據分析(cuDF)和機器學習(cuML).這些不同組成部分共享相同的內存結構，因此基本上可以在不將數據來回複製到CPU中的情況下完成數據攝取、分析和機器學習的過程。
以下示例演示了讀取大型Json文件（1.2GB）的實例，其使用pandas API聚合數據。可以看到，使用RAPIDS運行相同的代碼，速度如何增快30倍(完整Notebook：https://github.com/nuclio/rapids/blob/master/demo/benchmark_cudf_vs_pd.ipynb)，與沒有IO的計算相比，它快了100倍，這意味著還有對數據進行更為複雜計算的餘地。
本文使用單GPU (NVIDIA T4) 它可以使伺服器價格增加約30％，性能提升30多倍。只使用幾行Python代碼，每秒就可處理1千兆字節的複雜數據。哇！！
如果將此代碼打包在無伺服器函數中，它可以在每次用戶請求時或定期運行，並讀取或寫入動態附加的數據卷。
Python中可實現實時流嗎？
你是否嘗試使用Python執行實時流式傳輸？好吧，我們做到了。以下代碼選取自Kafka最佳實踐指南，此代碼從流中讀取，同時並未額外處理。
問題在於Python本質上是同步的，而其在實時或複雜的數據操作方面效率相當低。該程序每秒只生成幾千條消息，而且還沒做任何有意思的工作。當我們添加前文示例中使用的json和pandas處理(Notebook：https://github.com/nuclio/rapids/blob/master/demo/python-agg.ipynb)時，性能會進一步降低，處理速度僅為18MB / s。那麼，是否需要回到Spark進行流處理呢？
不，等等。
最快的無伺服器框架是Nuclio，現在它也是Kubeflow（Kubernetes機器學習框架）的一部分。Nuclio運行由實時和高度並發的執行引擎包裝的各種代碼語言。Nuclio無需額外編碼，可並行運行多個代碼實例（使用高效的微線程）。Nuclio處理流程內和多個流程/容器中的自動擴展(請參閱此技術報導博客：https://theburningmonk.com/2019/04/comparing-nuclio-and-aws-lambda/)。
Nuclio以高度優化的二進位代碼處理流處理和數據訪問，並通過簡單的函數處理程序調用函數。它支持14種不同的觸發或流協議(包括HTTP、Kafka, Kinesis、Cron和批)，這些協議通過配置指定（不更改代碼），並支持快速訪問外部數據卷。單個Nuclio函數每秒可處理數十萬條消息，吞吐量超過千兆字節/秒。
最重要的是，Nuclio是目前唯一一款具有優化NVIDIA GPU支持的無伺服器框架。它知道如何確保GPU利用率最大化，並在需要時擴展到更多流程和GPU。
筆者對Nuclio持保留意見，但它的功能的確很先進。
無需Devops的30倍速度流處理
結合使用Nuclio與RAPIDS，基於Python流處理獲得GPU加速，最終實現完美蛻變。以下代碼與批處理案例別無二異，本文只是將其置於一個函數處理程序中，並將傳入的消息收集到更大的批中以減少GPU調用。(請參閱完整筆記本：https://github.com/nuclio/rapids/blob/master/demo/nuclio-cudf-agg.ipynb)
可以使用HTTP或Kafka觸發器測試同一個函數：在兩種情況下，Nuclio都將處理並行性，並將流分區劃分給多個工作人員，無需任何額外開發工作。本文測試的設置是使用3節點Kafka集群和單個Nuclio函數進程（在具有一個NVIDIA T4的雙插槽Intel伺服器上)。本文設法處理638 MB / s，比編寫自己的Python Kafka客戶端快30倍，並且它可以自動擴展以處理任何數量的流量。值得一提的是，所使用Python代碼短小而簡單！
在測試中，筆者注意到GPU未充分利用，這意味著可以對數據進行更複雜的計算（連接、機器學習預測、轉換等），同時保持相同的性能水平。
那麼，也就是以更少的開發獲得更快的性能，但無伺服器解決方案的真正好處在於「無伺服器」。使用相同的代碼，在Notebook中進行開發 (請參閱此筆記本示例：https://github.com/nuclio/rapids/blob/master/demo/nuclio-cudf-agg.ipynb) 或選用你喜歡的IDE，並在一個命令中對其進行構建、貨櫃化並運送到有完整檢測功能、已安全加固的的Kubernetes集群（日誌、監控、自動縮放......）。
Nuclio與Kubeflow管道集成。構建多階段數據或機器學習管道，你可以輕鬆地實現數據科學工作流自動化，並收集執行和工件元數據，從而輕鬆地重現實驗結果。
下載Nuclio（https://nuclio.io/）並將其部署在你的Kubernetes上(請參閱RAPIDS示例：https://github.com/nuclio/rapids)。
留言 點讚 關注
我們一起分享AI學習與發展的乾貨
如需轉載，請後臺留言，遵守轉載規範