導(dǎo)讀：1. 打破R慢的印象，ETL效率顯著優(yōu)于Python，堪比spark，clickhouse

2. 對比python中的datatable、pandas、dask、cuDF、modin，R中data.table以及spark、clickhouse

3. 探討R中的ETL體系

ETL在數(shù)據(jù)工作中起著至關(guān)重要的作用，主要用途有兩個：(1)數(shù)據(jù)生產(chǎn)(2)為探索性數(shù)據(jù)分析與數(shù)據(jù)建模服務(wù)。

做過建模的小伙伴都知道，70%甚至80%的工作都是在做數(shù)據(jù)清洗；又如，探索性數(shù)據(jù)分析中會涉及到各種轉(zhuǎn)置、分類匯總、長寬表轉(zhuǎn)換、連接等。因此，ETL效率在整個項目中起著舉足輕重的作用。

而日常數(shù)據(jù)生產(chǎn)中，有時會牽扯到模型計算，一般以R、python為主，且1~100G左右的數(shù)據(jù)是常態(tài)。基于此，于是想對比下R、Python中ETL的效率。

目前已有研究

H2O團隊一直在運行這個測試項目， 其中：Python用到了:(py)datatable, pandas, dask, cuDF(moding.pandas在下文作者親自測試了下);

R: data.table, dplyr;

julia: DataFrames.jl;

clickhouse;

spark

測試內(nèi)容有g(shù)roupby、join、sort等。測試數(shù)據(jù)長這樣：

廢話不多說，先看部分結(jié)果的截圖吧。5G數(shù)據(jù)50G數(shù)據(jù)

上圖截取的是復(fù)雜的groupby問題中對于5G與50G數(shù)據(jù)各ETL工具的用時情況，項目運行服務(wù)器的內(nèi)存為128G，核數(shù)40。可以看到，無論是5G還是50G的數(shù)據(jù)，data.table的性能都在python之上,堪比spark、clickhouse。

modin.pandas vs data.table

modin.pandas與data.table測試結(jié)果如下，所用數(shù)據(jù)5G，數(shù)據(jù)格式如上。服務(wù)器為32G、8核，拉取Python3.6、R3.6.2兩個docker分別測試。

1.讀取data.table用時89秒，內(nèi)存峰值消耗7G

modin.pandas用時58秒，內(nèi)存峰值消耗25G

本測試所用的是modin[ray]，似乎modin.pandas一直有內(nèi)存管理的問題，參考：1.1 Fundamental memory leak in Modin：https://url.cn/5HlosKF

1.2 modin read big csv failed：https://url.cn/5cOdpVJ

2.分類匯總

測試內(nèi)容：對于id3, id4兩列分類匯總求v3的中位數(shù)與標(biāo)準(zhǔn)差data.table用時10.5秒data[, .(median_v3 = median(v3), sd_v3 = sd(v3)), by = .(id4, id5)]modin用時174秒，由于modin暫不支持多列的groupby，實際上還是用的pandas的groupbyx.groupby([‘id4’,‘id5’]).agg({‘v3’: [‘median’,‘std’]})

UserWarning: DataFrame.groupby_on_multiple_columns defaulting to pandas implementation.

3.長寬表變換

測試內(nèi)容：id1, id4不動，對id5橫向展開，值為對v3求均值data.table用時3.3秒dcast.data.table(ans, id1 + id4 ~ id5, value.var = “v3”, fun.aggregate = mean)

R ETL開發(fā)框架

開發(fā)環(huán)境為docker版的Rstudio-server，rstudio本身為最好用的IDE之一，開發(fā)效率高，debug方便。

并且，rstudio-server為線上版本的rstudio，后臺就是linux環(huán)境，前端為rstudio的ui，因此無需為開發(fā)環(huán)境與生產(chǎn)環(huán)境不一致而苦惱，更不會因為某些包只能linux使用而無法在windows使用而苦惱。

目前本人工作中負責(zé)一個項目的數(shù)據(jù)生產(chǎn)，大致流程如下。首先，用presto從hive中讀取數(shù)據(jù)，從ADB讀取數(shù)據(jù)，數(shù)據(jù)量在5G左右。中間涉及到PCA以及其他計算，最后入庫mysql，該任務(wù)每天跑一次 。

一個可行的實施方案為Rpresto、RMysql提供I/O支持，data.table提供主體ETL，crontab提供調(diào)度服務(wù)。

下圖是個簡易版R的ETL框架，可處理G以下數(shù)據(jù)，

##################################################

2020年1月14號更新：關(guān)于應(yīng)用場景，再次說明下，G級別數(shù)據(jù)或以下，頻率低(如們每天跑一次)，涉及到模型計算調(diào)度請用crontab，airflow；

涉及到消息隊列請用kafka；

實時性高但數(shù)據(jù)量又大請用flink流計算；

大量消息隊列，且每個都實時性要求高，且數(shù)據(jù)量大，請用kafka+flink，如實時推薦系統(tǒng)。

標(biāo)*的部分為還沒有測試過。

##################################################

對R和數(shù)據(jù)科學(xué)感興趣的小伙伴，歡迎關(guān)注公眾號：R語言工程化

總結(jié)

以上是生活随笔為你收集整理的python实现etl_为什么选择R而不是Python做ETL的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。