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等。测试数据长这样:
废话不多说,先看部分结果的截图吧。
上图截取的是复杂的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,如实时推荐系统。
标*的部分为还没有测试过。