Base R vs. Tidyverse: BT 擂台赛启动

dapengde

前些天有感而发：

cosx 快成了 Base R vs. TidyVerse 的擂台了。

昨天突发奇想：

建议以后对 cosx 所有的提问都给出 Base R 版和 Tidyverse 版。做做大脑体操。简称 B 版和 T 版。我自告奋勇整理成书。书名我都想好了：BT 擂台赛。

今天建了个 bookdown 项目：

预览：<https://pzhaonet.github.io/btcookbook>
Repo: <https://github.com/pzhaonet/btcookbook>

欢迎有志之士加入一起完成。

Cloud2016

dapengde 一个 PR 已经提交 <https://github.com/pzhaonet/book-bt/pull/2> 此外，建议项目名称叫 BvsT-cookbook 似乎更好哇！

此外，最近一段时间，关于数据操作方面的讨论，也有很多，应该也可以收藏

Liechi

dapengde 预览里”后记“链接失效了。可以从"title"部分点下一章进入”后记“，但目录处的”后记“超链接不工作。我克隆了这库，但是没有找到链接失效的原因，所以无法提出修改建议。

dapengde

Cloud2016 谢谢！已合并。坟嘛，慢慢挖。项目名称，我倾向于让 BT 两个字母挨着，因为很 BT。cookbook 这个名字很好。就先叫 btcookbook 吧！

HarryZhu-7harryprince

有的操作 base R 实现不出来，因为 tidyverse 实际上实现了一个 db 层的封装，很多算子实际是透传到 db 里面的。这种比较感觉不太公平

dapengde

HarryZhu-7harryprince 嗯，有的操作用 tidyverse 也实现不出来。可能“擂台赛”这个词有些误导，然而其实并不是要他们分输赢，而是通过比较来强化我们对他们的理解和消化，所以，公平不公平，无所谓啦。

Cloud2016

dapengde HarryZhu-7harryprince 同志们，要是看到这样的互不实现的例子，一定要分享出来！！光说不练即为钓鱼嫌疑！

tctcab

HarryZhu-7harryprince

我是暂时木有碰到baseR做不了tidyverse可以做的操作，感觉有意思，跟楼上一样求个例子研究一下！

dapengde

Cloud2016 tctcab 你们这就是挑衅，挑战，挑逗。真成擂台赛了。

Liechi

dapengde 数据整理要不要考虑加一个 data.table 版？比如：

library(data.table) dt <- as.data.table(mtcars) dt[1 : .N %in% 2:5 & cyl < 6, cyl := 2] head(dt)

我觉得 data.table 值得拥有更多的曝光度。只是这样一来，书名就难取了：）

Cloud2016

tidyverse 主要是 dplyr 实现一系列操作， dbplyr (Database (DBI) backend for dplyr) 和 dtplyr (Data table backend for dplyr) 包等只是转化数据操作，适应不同的后端，实际是翻译工作，真正的封装是 DBI ，实现 R 与数据库的连接，实现一系列的交互操作。没有 tidyverse, Base R 通过 DBI 也可以与数据库交互，方式是传递 SQL 语句，dplyr 与数据库交互，本质也是传递 SQL 语句，但它做了大量 SQL 操作的翻译工作，所以用户写 dplyr 定义的操作即可，从而摆脱了直面 SQL 的麻烦，但是也不要指望它能完全替代 SQL，因为它也存在一些局限 <https://dbi.r-dbi.org/articles/dbi-proposal#sec:limitations> 。

dapengde

Liechi 这个例子里我本来是加上了 data.table 的，就是觉得无论放在 B 栏还是 T 栏均不妥，就割爱给删了。data.table 仅涉及数据处理吧？这样就无法贯穿 BT 全书，因为我觉得重头戏可能是 graphics vs ggplot2，还有字符串操作什么的。你要是有兴趣，可以添加个附录，给出数据处理部分每道题的 data.table 方案。一起做起来！

Cloud2016

Liechi dapengde 不要担心 data.table 属不属于 Base R？它绝对属于 Base R 阵营，因为人家的描述文件写的很清楚， Title: Extension of data.frame

yusong

Liechi 以前用Tidyverse，现在用data.table. data.table虽然可能易读性差一点，但是简洁高效，写起来神清气爽！

tctcab

dapengde
你这是对datatable的歧视！

Liechi

dapengde 如果不新开一个分栏的话，我建议放 data.table 放在 B 栏，因为:

data.table inherits from data.frame. ... It is inspired by A[B] syntax in R where A is a matrix and B is a 2-column matrix.

这样就不必担心“无法贯穿 BT 全书”这个问题了。加到附录太委屈这个皮薄馅大的包了。

dapengde

tctcab 歧视言重了，顶多是误解。
Liechi Cloud2016 活活把技术问题搞成了政治站队问题。

Cloud2016

dapengde 我看了HarryZhu-7harryprince 的两条回复之后，我觉得讨论 BT 首先要定义好什么是 Base R（B）什么是 Tidyverse（T）？只有把这个定义好了才有后续的比较。我不想引发一些不必要的争论，我认为<https://github.com/tidyverse/> 和 <https://github.com/r-dbi> 是不同层面的两个东西，前者是 tidyverse 后者是和 tidyverse 无关的 R与数据库的接口集合。至于接口之上，用户层面写 SQL 语句（Base R 风格）还是写 tidyverse 风格的数据操作都无所谓，分布式，集群这些，甚至实时、高并发这些都不是 R 社区做的，是你说的Hadoop Spark PostGIS Redis Nginx 等数据处理、缓存、代理引擎做的， geospark, RPostGIS 都是其上的接口，这些接口需要解决如何与 Spark PostGIS 等的引擎交互，因为你想啊，传个 SQL 语句用的着 Nignx 代理 Redis 缓存 Hadoop 存储 Spark 处理吗？是用户请求和 SQL 语句的执行才需要。

我对 ClickHouse 略有了解，它提供了 JDBC 和 ODBC 两种驱动，所以如果是传递 SQL，那么简单的就只需要根据 DBI 包，将其抽象封装的接口实例化即可，这样就实现了 clickhouse-r，如果需要 tidyverse 风的数据操作，就需要进一步翻译 SQL 为 dplyr 式的操作，这个翻译的过程需要写 C++/C 代码（走 ODBC 驱动）或者 Java 代码（走 JDBC 驱动）。

应该把 geospark sparklyr 看成一个前端，定义 dplyr 风格的操作，如果是直接基于 dplyr 就像你说的容易内存泄漏，这是显然的，因为一般人根本不知道它内部是什么？我也不知道，所以我很菜，当年在渣浪用的是 DBI 连接 ClickHouse 分布式集群，传递 SQL，报错了比较好调。

这是我以前整理的一堆临时笔记，仅供参考 <https://bookdown.org/xiangyun/RGraphics/dm-import-export.html#import-data-from-database>

HarryZhu-7harryprince

我倒是觉得 local 模式如果 base R 和 tidyverse 性能没差异，大家怎么写都无所谓。
比较有建设性的是，在 cluster 模式如何处理 PB 级别数据。比如 base R 和 tidyverse 对比如何实现 word2vec之类的。
比如数据分析以前很少有人处理过 nginx日志，通过 tidyverse 就提供了批量处理nginx日志的一个通道。

HarryZhu-7harryprince

因为透过 db 层的封装， tidyverse 成为了强大的分布式处理工具，比如通过 geospark, RPostGIS 处理各种空间数据。
如果把 sf 归类到 base R ，在做大数据处理的时候差异还是蛮明显的。

其他的一些 db，比如 neo4j, elasticsearch, mongodb 等等也会有一些奇葩功能是 base R 不会考虑的，所以我说这么比较有些不公平。

Cloud2016

dapengde 我完全赞同你的BT之分的观点，tidyverse 是不含有 DBI 的，而 HarryZhu-7harryprince 可能长期泡在 tidyverse 和 sparklyr 的世界，已经有点模糊了，事实上， sparklyr 加载之后会自动从命名空间导入 DBI，因为 sparklyr 是面向 spark 的接口包，没有这一层是无法传递 SQL 语句的，tidyverse 加载之后不会加载或从命名空间导入 DBI 包

dapengde

Cloud2016 啊哈哈，这本”BT擂台赛“原本没打算涉及这么深入的探讨。本来只是想搜集整理一下这里的提问和解答，帮助学习和使用而已，没想到扯到了站队问题。”只有把这个定义好了才有后续的比较“，这个态度严格上来说是对的，然而从实用角度来讲，不是”BT擂台赛“这本书的目的。如果在这一步纠缠不清，那么可能没法往下做了。你看人家 Thanos，一心一意想着打个响指灭掉一半生命，就把事儿给办了，没想着先定义一下什么是生命，人变成灰了可是身上的衣服怎么也灰了，同时体内的细菌病毒寄生虫算怎么回事儿……

不过，既然牵出这个话题，聊一聊也挺有意思的。

网上有不少关于 Base R vs. Tidyverse 的讨论（如这里，这里，这里，这里），我看他们就直接讨论下去了，没见到先定义的，可见，二者应该是有约定俗成的范围的。你猛一看觉得是 Base R 那就是 Base R。就擂台赛来说，如果需要界定一下的话，我觉得可以这样简单界定：

B 方案：不需要require()或library()或foo::bar()就能实现的方案。
T 方案：需要且仅需要require('tidyverse')而不需要加载其他包就能实现的方案。

这样可能更具有操作性。这也是我为啥没让 data.table 卷入的原因。

我理解的 Base R，就是 R 默认安装包（参考这里）：

base
compiler
datasets
graphics
grDevices
grid
methods
parallel
splines
stats
stats4
tcltk
tools
translations
utils

Liechi

dapengde
既然开始了，那就讨论一下。

其实我提出在 BT 擂台里加入 data.table，和站队无关，而是因为想起了 @Cloud2016 转发的 Mattlof 的文章。对文中的观点我不全认同，但是认为 data.table 值得拥有更多人知道这点，我无保留地支持。既然 BT 擂台“不是要他们分输赢，而是通过比较来强化我们对他们的理解和消化”，我想，在这个精神的指导下，加入 data.table 于比较的行列是件两全其美的好事：一来丰富了比较的多样性，让各系统的优劣充分展现；二来可以让更多人的了解 data.table 这个有很多优点的包。我觉得在数据整理部分为 data.table 单开一栏并无不可，不必拘泥于比较的对称性，即同时考虑作图和数据整理。不过既然考虑了这点，我想按照 data.table 的设计精神，将其划入 Base R 是自然的。如同建立系统发生树，总有合理的算法将“物种”聚类的。这个提议的初衷和站队无关，如果我觉得 data.table 和极乐净土更接近，也会毫不犹豫地提议将其划入 T 方案。

定义是重要的，在你举的 Thanos 的例子里，就算默认生命这个概念是自明的，但“一半”如何处理？是一个细菌等价于一个人这样算一半，还是按照体积或重量算的一半？如果现在设计一个函数帮助 Thanos 完成任务，定义的不清楚或许会让程序设计出现问题。你提出了你对 B 和 T 方案的定义，我想这表明你也至少部分认同定义边界是重要的。

我认同你对 T 方案的定义（考虑到极乐净土在一直囊括新包，不断扩张，其实这定义对 B 方案来说是不公平的；另外，管道这样本来中性的函数为管道所独占也不合理，它本不是专为 T 设计的，不过这些暂且先忽略），但我觉得 B 方案的定义太狭窄。在极乐净土出来之前，大家对 Base R 的理解和现在是很不同的。我想现在大家对 Base R 的理解一般为 “非 Tidyverse”。不过如果按照非 T 来理解 B 方案的话，似乎使得 B 方案有了无限可能，这有点耍赖：）会引发很多的问题，比如 lattice 作图要不要放到 B 方案里？但是我觉得加上一个设计精神源于 Base R，且功能强大，值得推广的 data.table 到 B 方案里应该是合理且有益的事情。

哈哈，突然想起最近看《西游记》时的一个感慨，“或许在天上佛道已然一家亲了，只苦了“愚昧”的世人，还在下界痴痴地守着分别心。”不过想想，世上很多事情都是由分辨始，至融汇终的（取其优点，秉承“拿来主义”），这也算世事的一个常态吧。

dapengde

Liechi Cloud2016 data.table 我没用过，而且也没时间没兴趣试用—— Base R 已经解决了我所有的问题，额外学习 tidyverse 已经是很奢侈的事，我不想再花精力学别的可以完成同样工作的包了，DBI 更是用不着。BT 这事儿要是有意义，诸位一起做才行啊！PR 或当合作者都行。