作者：黄天元，复旦大学博士在读，热爱数据科学与开源工具（R），致力于利用数据科学迅速积累行业经验优势和科学知识发现，涉猎内容包括但不限于信息计量、机器学习、数据可视化、应用统计建模、知识图谱等，著有《R语言高效数据处理指南》（《R语言数据高效处理指南》(黄天元)【摘要 书评 试读】- 京东图书）。知乎专栏：R语言数据挖掘。邮箱：huang.tian-yuan@qq.com.欢迎合作交流。

在我的新书《R语言高效数据处理指南》中，很重要的部分就是对基本二维表的操作进行诠释，其中包括了基本包、dplyr、data.table和sparklyr。其中sparklyr这种分布式计算对于个体来说还不算普遍，但是对于前三者的熟悉却是必要的。事实上我个人喜欢的是dplyr包，它富有灵性的动词通过组合能够自由地对数据进行操作，再看看现在SQL语句或者pandas的那些函数，我觉得dplyr目前足以甩其他工具好几条街。

但是，从速度上来看，data.table包已经登峰造极。只要数据上G，而且有很多分组操作，那么dplyr就会开始卡，而data.table就给用户很多惊喜。但是data.table的语法结构其实没有那么容易理解，也导致它变成了“方法”。其实一样的数据操作怎么可能data.table就了，只是牺牲了可读易写的特性来换取计算机的速度。但是两者真的不可兼得吗？我在自己的工作中需要加速的时候就经常混用两个包，而且我把相关的内容也写进了书中。

混用两个包，其实是可以加速的。加速效果的话，肯定不能比data.table快，但是还是要比dplyr本身快多了。之前Hadley就一直想推广dtplyr这个包，想用data.table作为后台，dplyr作为前端，然后做一个新的包，保证用户体验和操作性能一样好。但是这个包的开发是相当的慢，现在也还在0.0.3版本。这种想法其实很多人都有，近已经有很多包开发出来解决了这个问题。我筛选出两个供大家参考：

经过一些浏览学习，我个人目前是支持maditr这个包的，因为它只要在dplyr的函数前提下加上dt前缀，就转化为对应的函数，对于已经熟悉dplyr的用户非常友好。不过目前比较大的问题是，这种语法格式还不支持分组，而分组却是data.table大的优点之一（需要分组的操作data.table非常地快）。也就是说，分组计算一定是配合summarise一起用的，不过这样也没差，因为分组之后我们肯定要做点什么，光分组是没有用的。这里我就不介绍table.express这个包了，除却巫山不是云，但是其思想是大同小异的，这里对作者的努力和分箱的精神表示敬意。不过如果不懂原位更新等理念，可能使用上还是会出问题，所以对dplyr和data.table的了解还是很重要的，哈哈还是过来买我的书吧~

我觉得关于maditr的设计可以更dplyr一些，因此也提了一些建议，不知道会不会被采纳（let dt_* functions more like dplyr · Issue #5 · gdemin/maditr）。data.table和dplyr未来可能真的会变成一个包？会不会呢？It's interesting to ask and wait to see.