etl调度工具ctm_为什么选择R而不是Python做ETL

导读&＃xff1a;

1. 打破R慢的印象&＃xff0c;ETL效率显著优于Python&＃xff0c;堪比spark&＃xff0c;clickhouse
2. 对比python中的datatable、pandas、dask、cuDF、modin&＃xff0c;R中data.table以及spark、clickhouse
3. 探讨R中的ETL体系

ETL在数据工作中起着至关重要的作用&＃xff0c;主要用途有两个&＃xff1a;&＃xff08;1&＃xff09;数据生产&＃xff08;2&＃xff09;为探索性数据分析与数据建模服务。

做过建模的小伙伴都知道&＃xff0c;70%甚至80%的工作都是在做数据清洗&＃xff1b;又如&＃xff0c;探索性数据分析中会涉及到各种转置、分类汇总、长宽表转换、连接等。因此&＃xff0c;ETL效率在整个项目中起着举足轻重的作用。

而日常数据生产中&＃xff0c;有时会牵扯到模型计算&＃xff0c;一般以R、python为主&＃xff0c;且1~100G左右的数据是常态。基于此&＃xff0c;于是想对比下R、Python中ETL的效率。

目前已有研究

H2O团队一直在运行这个测试项目&＃xff0c; 其中&＃xff1a;

• Python用到了:(py)datatable, pandas, dask, cuDF&＃xff08;moding.pandas在下文作者亲自测试了下&＃xff09;;
• R: data.table, dplyr;
• julia: DataFrames.jl;
• clickhouse;
• spark

测试内容有groupby、join、sort等。测试数据长这样&＃xff1a;

废话不多说&＃xff0c;先看部分结果的截图吧。

详细报告见&＃xff1a;https://url.cn/5qTWlNQ

上图截取的是复杂的groupby问题中对于5G与50G数据各ETL工具的用时情况&＃xff0c;项目运行服务器的内存为128G&＃xff0c;核数40。可以看到&＃xff0c;无论是5G还是50G的数据&＃xff0c;data.table的性能都在python之上,堪比spark、clickhouse。

modin.pandas vs data.table

modin.pandas与data.table测试结果如下&＃xff0c;所用数据5G&＃xff0c;数据格式如上。服务器为32G、8核&＃xff0c;拉取Python3.6、R3.6.2两个docker分别测试。

1.读取

• data.table用时89秒&＃xff0c;内存峰值消耗7G
• modin.pandas用时58秒&＃xff0c;内存峰值消耗25G

本测试所用的是modin[ray]&＃xff0c;似乎modin.pandas一直有内存管理的问题&＃xff0c;参考&＃xff1a;

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

2.分类汇总

测试内容&＃xff1a;对于id3, id4两列分类汇总求v3的中位数与标准差

• data.table用时10.5秒

data[, .(median_v3 &＃61; median(v3), sd_v3 &＃61; sd(v3)), by &＃61; .(id4, id5)]

• modin用时174秒&＃xff0c;由于modin暂不支持多列的groupby&＃xff0c;实际上还是用的pandas的groupby

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

3.长宽表变换

测试内容&＃xff1a;id1, id4不动&＃xff0c;对id5横向展开&＃xff0c;值为对v3求均值

• data.table用时3.3秒

dcast.data.table(ans, id1 &＃43; id4 ~ id5, value.var &＃61; “v3”, fun.aggregate &＃61; mean)

R ETL开发框架

开发环境为docker版的Rstudio-server&＃xff0c;rstudio本身为最好用的IDE之一&＃xff0c;开发效率高&＃xff0c;debug方便。

并且&＃xff0c;rstudio-server为线上版本的rstudio&＃xff0c;后台就是linux环境&＃xff0c;前端为rstudio的ui&＃xff0c;因此无需为开发环境与生产环境不一致而苦恼&＃xff0c;更不会因为某些包只能linux使用而无法在windows使用而苦恼。

目前本人工作中负责一个项目的数据生产&＃xff0c;大致流程如下。首先&＃xff0c;用presto从hive中读取数据&＃xff0c;从ADB读取数据&＃xff0c;数据量在5G左右。中间涉及到PCA以及其他计算&＃xff0c;最后入库mysql&＃xff0c;该任务每天跑一次 。

一个可行的实施方案为Rpresto、RMysql提供I/O支持&＃xff0c;data.table提供主体ETL&＃xff0c;crontab提供调度服务。

下图是个简易版R的ETL框架&＃xff0c;可处理G以下数据&＃xff0c;

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

2020年1月14号更新&＃xff1a;关于应用场景&＃xff0c;再次说明下&＃xff0c;

G级别数据或以下&＃xff0c;频率低&＃xff08;如们每天跑一次&＃xff09;&＃xff0c;涉及到模型计算

1. 调度请用crontab&＃xff0c;airflow&＃xff1b;
2. 涉及到消息队列请用kafka&＃xff1b;
3. 实时性高但数据量又大请用flink流计算&＃xff1b;
4. 大量消息队列&＃xff0c;且每个都实时性要求高&＃xff0c;且数据量大&＃xff0c;请用kafka&＃43;flink&＃xff0c;如实时推荐系统。

标*的部分为还没有测试过。

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

对R和数据科学感兴趣的小伙伴&＃xff0c;欢迎关注公众号&＃xff1a;R语言工程化