加速R工作流磚
在磚,我們努力使我們的統一的分析平台Beplay体育安卓版本最好的地方運行大數據分析。對於大數據,Apache火花已成為事實上的計算引擎,而對於高級分析,R是其中一個最廣泛使用的語言和環境。R的包的生態係統擁有超過10 k包從簡單的統計函數的實現複雜的包等垂直基因組學和金融。
統一的分析平台,Beplay体育安卓版本磚運行時(DBR)在其核心,加速和統一的優勢Apache火花和r . DBR幫助客戶,在廣泛的行業和垂直,從大數據中提取價值效率。beplay体育app下载地址
許多磚R的用戶利用Apache火花和R豐富的生態係統的優勢與兩步工作流程。首先,他們對分布式執行所有大型數據操作SparkDataFrames使用SparkR API。這些通常包括加載數據從其來源、解析和轉換成需要的格式和形狀。在許多情況下,最後一個結構化的數據集的有趣的部分可以在單個機器的內存。在這個階段,用戶分布式數據集轉換為一個本地Rdata.frames並將它們傳遞給其他(單節點)為進一步分析R包或可視化。通常,R之間的轉換data.frames和火花DataFrames發生很多次了。例如,結果一個R包功能並行與分布式數據集。
在這篇文章中,我們介紹兩個新的改進磚3.3運行時(DBR)加速這些常見的工作流。首先,我們添加了對R的支持包磚圖書館管理的一部分。其次,作為我們的一部分DBIO加速器模塊,我們有加速的性能SparkR:收集()和SparkR: createDataFrame ()。這兩種api之間的橋梁是單節點R和分布式應用程序和火花SparkR最常用的功能之一。
在磚R包管理
磚的工作空間,用戶現在可以定義一個圖書館,指向他們期望的凹口庫和包。當這個庫被附加到一個集群時,所有工人和司機節點將自動安裝凹口包。這個功能可以通過REST API。
與R管理庫,將工作流與第三方R包將在磚容易得多。尤其是伸縮集群的情況,新員工可以動態地添加到集群。
高性能與DBIO SparkR
我們使用了航空公司的數據集為基準。數據集由超過1.2億29行和列的數字和字符類型CSV格式的,這是普遍和流行R用戶。我們逐步使用更大的數據集來評估分數與不同的數據吞吐量和延遲的大小和還發現極限之後,調用失敗。我們比較DBR 3.3與3.0 DBR集群組成四個i3。超大的工人。
測量SparkR::收集()性能
我們第一次加載數據使用火花的CSV數據來源與自動模式推理。我們緩存和實現的火花DataFrame然後收集當地Rdata.frame。我們測量的總運行時間收集的步驟。
測量SparkR: createDataFrame()的性能
我們從本地文件係統加載文件使用R的表格數據讀取功能默認配置,自動推斷模式。然後我們並行化data.frame與SparkR: createDataFrame ()和計數的行數。對於這個基準測試,我們測量時間的最後兩個步驟的總和。
基準測試結果
首先,我們比較並行R的平均吞吐量data.frames在DBR 3.3和3.0 DBR。DBIO可以達到300 x更高的平均吞吐量DBR 3.3 DBR相比3.0。當收集火花DataFrames24 x,我們觀察到更高的平均吞吐量磚比舊版本3.3運行時。
下麵的情節顯示的端到端延遲。這是用戶感知當調用SparkR API。在每個DBR版本,我們逐步增加輸入大小,直到調用會失敗。我們測量時間為每個成功運行。
DBR 3.0SparkR: createDataFrame ()失敗的數據大於750 k行(約70 mb)。在DBR 3.3 R的調用並沒有失敗data.frame。整體createDataFrame ()DBR 3.3 -快100倍,可以處理更大的數據。
的故障點
SparkR:收集()沒有改變。約為6 m行(550 mb) R過程不能處理單一的內存對象,收集火花時,我們觀察到失敗DataFrames。在這個實驗中,DBR 3.3是10倍的速度比舊版本在不同輸入的大小。
結論
我們不斷努力提高磚的不同R工作流。我們最近宣布與sparklyr集成;R包管理和改進SparkR性能是我們最近的步驟這一目標。
如上所示,DBIO磚3.3運行時顯著加速性能的最重要的兩個SparkR調用:SparkR:收集()和SparkR: createDataFrame ()。這些調用數據轉移引發的JVM R,反之亦然,是最受歡迎的SparkR api。
閱讀更多
閱讀更多關於我們的努力與SparkR磚,我們請您留意以下資產: