簡介勉強算的上，但是高效談不上，在大數據時代，最高效的數據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的語法操作資料庫，能節約很多時間。

推薦閱讀：
相关文章