導讀：

1. 打破R慢的印象，ETL效率顯著優于Python，堪比spark，clickhouse
2. 對比python中的datatable、pandas、dask、cuDF、modin，R中data.table以及spark、clickhouse
3. 探討R中的ETL體系

ETL在數據工作中起著至關重要的作用，主要用途有兩個：（1）數據生產（2）為探索性數據分析與數據建模服務。

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

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

目前已有研究

H2O團隊一直在運行這個測試項目， 其中：

• Python用到了:(py)datatable, pandas, dask, cuDF（moding.pandas在下文作者親自測試了下）;
• R: data.table, dplyr;
• julia: DataFrames.jl;
• clickhouse;
• spark

測試內容有groupby、join、sort等。測試數據長這樣：

廢話不多說，先看部分結果的截圖吧。

5G數據

50G數據

詳細報告見：https://url.cn/5qTWlNQ

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

modin.pandas vs data.table

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

1.讀取

• data.table用時89秒，內存峰值消耗7G
• modin.pandas用時58秒，內存峰值消耗25G

本測試所用的是modin[ray]，似乎modin.pandas一直有內存管理的問題，參考：

1.1 Fundamental memory leak in Modin：https://url.cn/5HlosKF
1.2 modin read big csv failed：https://url.cn/5cOdpVJ

2.分類匯總

測試內容：對于id3, id4兩列分類匯總求v3的中位數與標準差

• data.table用時10.5秒

data[, .(median_v3 = median(v3), sd_v3 = sd(v3)), by = .(id4, id5)]

• modin用時174秒，由于modin暫不支持多列的groupby，實際上還是用的pandas的groupby

x.groupby([‘id4’,‘id5’]).agg({‘v3’: [‘median’,‘std’]})
UserWarning: DataFrame.groupby_on_multiple_columns defaulting to pandas implementation.

3.長寬表變換

測試內容：id1, id4不動，對id5橫向展開，值為對v3求均值

• data.table用時3.3秒

dcast.data.table(ans, id1 + id4 ~ id5, value.var = “v3”, fun.aggregate = mean)

R ETL開發框架

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

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

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

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

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

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

2020年1月14號更新：關于應用場景，再次說明下，

G級別數據或以下，頻率低（如們每天跑一次），涉及到模型計算

調度請用crontab，airflow；

涉及到消息隊列請用kafka；

實時性高但數據量又大請用flink流計算；

大量消息隊列，且每個都實時性要求高，且數據量大，請用kafka+flink，如實時推薦系統。

標*的部分為還沒有測試過。

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

對R和數據科學感興趣的小伙伴，歡迎關注公眾號：R語言工程化

總結

以上是生活随笔為你收集整理的kafka python框架_为什么选择R而不是Python做ETL的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。