黄陂区建设局网站,网站没有备案时,服装网络营销策划书,做网站编程有钱途么导读#xff1a;1. 打破R慢的印象#xff0c;ETL效率显著优于Python#xff0c;堪比spark#xff0c;clickhouse2. 对比python中的datatable、pandas、dask、cuDF、modin#xff0c;R中data.table以及spark、clickhouse3. 探讨R中的ETL体系ETL在数据工作中起着至关重要的作…导读1. 打破R慢的印象ETL效率显著优于Python堪比sparkclickhouse2. 对比python中的datatable、pandas、dask、cuDF、modinR中data.table以及spark、clickhouse3. 探讨R中的ETL体系ETL在数据工作中起着至关重要的作用主要用途有两个1数据生产2为探索性数据分析与数据建模服务。做过建模的小伙伴都知道70%甚至80%的工作都是在做数据清洗又如探索性数据分析中会涉及到各种转置、分类汇总、长宽表转换、连接等。因此ETL效率在整个项目中起着举足轻重的作用。而日常数据生产中有时会牵扯到模型计算一般以R、python为主且1~100G左右的数据是常态。基于此于是想对比下R、Python中ETL的效率。目前已有研究H2O团队一直在运行这个测试项目 其中Python用到了:(py)datatable, pandas, dask, cuDFmoding.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.tablemodin.pandas与data.table测试结果如下所用数据5G数据格式如上。服务器为32G、8核拉取Python3.6、R3.6.2两个docker分别测试。1.读取data.table用时89秒内存峰值消耗7Gmodin.pandas用时58秒内存峰值消耗25G本测试所用的是modin[ray]似乎modin.pandas一直有内存管理的问题参考1.1 Fundamental memory leak in Modinhttps://url.cn/5HlosKF1.2 modin read big csv failedhttps://url.cn/5cOdpVJ2.分类汇总测试内容对于id3, id4两列分类汇总求v3的中位数与标准差data.table用时10.5秒data[, .(median_v3 median(v3), sd_v3 sd(v3)), by .(id4, id5)]modin用时174秒由于modin暂不支持多列的groupby实际上还是用的pandas的groupbyx.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-serverrstudio本身为最好用的IDE之一开发效率高debug方便。并且rstudio-server为线上版本的rstudio后台就是linux环境前端为rstudio的ui因此无需为开发环境与生产环境不一致而苦恼更不会因为某些包只能linux使用而无法在windows使用而苦恼。目前本人工作中负责一个项目的数据生产大致流程如下。首先用presto从hive中读取数据从ADB读取数据数据量在5G左右。中间涉及到PCA以及其他计算最后入库mysql该任务每天跑一次 。一个可行的实施方案为Rpresto、RMysql提供I/O支持data.table提供主体ETLcrontab提供调度服务。下图是个简易版R的ETL框架可处理G以下数据##################################################2020年1月14号更新关于应用场景再次说明下G级别数据或以下频率低如们每天跑一次涉及到模型计算调度请用crontabairflow涉及到消息队列请用kafka实时性高但数据量又大请用flink流计算大量消息队列且每个都实时性要求高且数据量大请用kafkaflink如实时推荐系统。标*的部分为还没有测试过。##################################################对R和数据科学感兴趣的小伙伴欢迎关注公众号R语言工程化
