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

导读：

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级别数据或以下，频率低（如们每天跑一次），涉及到模型计算

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

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

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

对R和数据科学感兴趣的小伙伴，欢迎关注公众号：R语言工程化