简介勉强算的上，但是高效谈不上，在大数据时代，最高效的数据manipulation语言只能是专业的etl语言，比如SQL、Spark等等~

谢谢邀请，

1.从工作角度来看，R dplyr 可以算是小数据探索领域高效简洁的数据处理方法，尤其对数据进行特殊处理的时候15万行以内吧，数据量大了后R dplyr运行速度就下降了。

2.若是遇到大数据，还是专门的ETL工具，或者SQL,我熟悉的是MYSQL，数据框结构的数据还是SQL最简洁高效，其他数据结构，尤其是知识库或者地理信息系统等可能就是SparkSQL或者postgreSQL之类的了，不过数据处理比较方便的还是python，运行效率比R要快。

如果此处的简洁指的是code有多短的话，那么data.table的语法比dplyr要简洁的多。毕竟 data.table::dt[i, j, by] 比 dplyr::filter(), mutate(), select(), group_by(), arrange()要短的多。

如果此处的高效指的是处理数据时的运行速度以及内存使用效率的话，那么data.table绝对比dplyr要来的高效，毕竟data.table对运行速度上的优化是dplyr无法企及的（data.table的modify by reference, multi-threading, setkey(); 而Hadley觉得dplyr不以运行效率为第一目的）；写代码的高效见仁见智，毕竟这个取决于对于工具的熟练程度。

但是如果你的简洁高效是指数据操纵代码的可读性与可扩展性的话，那么dplyr是一个不错的选择。dplyr最可取的地方（在我看来）在于她对于数据操作的抽象以及与tidyverse的结合。数据操作的抽象让她变成了一种操作数据的前端语言，不仅仅是一个操纵data.frame的package。而配合 %&>%，又提高了数据操纵代码的可读性（有时就跟读英语一样）。而与tidyverse（dbplyr, sparklyr）以及其他包的结合（比如DBI）让dplyr的扩展性大大提升。假设有一段用dplyr操作的运行在data.frame上的代码，现在数据形式从内存中的data.frame进入了关系型资料库（但是结构以及表名不变），借助dbplyr和DBI你只需要对你原有的dplyr代码做一些改变就可以让他跑在你的资料库上。如果你的数据现在在hdfs上，那么sparklyr又可以让dplyr的代码与sparkSQL连接。不管数据后端是R里的data.frame，还是R外的关系式型据库，hdfs，前端的dplyr代码都不会发生翻天覆地的变化。也许这也算是dplyr对于其他数据操纵工具的简洁高效之处吧。

dplyr语法简洁紧凑，非常符合直觉，易于学习，但是效率不如data.table以及pandas。dplyr在处理小数据(1G及以下)具有极大的优势，个人认为比SQL和pandas更好用。其次，dplyr背靠整个tidyverse生态链，具有得天独厚的优势。
反正在我看来r的tidyverse真是的神一样的数据处理库。真的太太太好用了。

R的data.table更灵活高效

data.table, 行筛选, 列操作, 能分组, 好用.

我觉得是反正不自觉的就用上了有念头了，一直想用

说实话我觉得Dylpr就是R里的SQL

待更

dplyr 的好处是直观，而且和tidyverse全家桶配合起来很流畅。高效不一定谈得上，data.table就比dplyr要快, pandas 也比dplyr快一些。但是用tidyverse全家桶的话，可以直接用dplyr的语法操作资料库，能节约很多时间。

推荐阅读：
相关文章