开发ETL为什么很多人用R不用Python

2020-07-13 14:14:20 浏览数 (1)

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数据5G数据
50G数据50G数据

上图截取的是复杂的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级别数据或以下,频率低(如们每天跑一次),涉及到模型计算

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

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

0 人点赞