Base R vs. Tidyverse: BT 擂台赛启动
- 已编辑
dapengde 一个 PR 已经提交 <https://github.com/pzhaonet/book-bt/pull/2> 此外,建议项目名称叫 BvsT-cookbook
似乎更好哇!
此外,最近一段时间,关于数据操作方面的讨论,也有很多,应该也可以收藏
有的操作 base R 实现不出来,因为 tidyverse 实际上实现了一个 db 层的封装,很多算子实际是透传到 db 里面的。这种比较感觉不太公平
HarryZhu-7harryprince 嗯,有的操作用 tidyverse 也实现不出来。可能“擂台赛”这个词有些误导,然而其实并不是要他们分输赢,而是通过比较来强化我们对他们的理解和消化,所以,公平不公平,无所谓啦。
dapengde HarryZhu-7harryprince 同志们,要是看到这样的互不实现的例子,一定要分享出来!!光说不练即为钓鱼嫌疑!
我是暂时木有碰到baseR做不了tidyverse可以做的操作,感觉有意思,跟楼上一样求个例子研究一下!
- 已编辑
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> 。
- 已编辑
我倒是觉得 local 模式如果 base R 和 tidyverse 性能没差异,大家怎么写都无所谓。
比较有建设性的是,在 cluster 模式如何处理 PB 级别数据。比如 base R 和 tidyverse 对比如何实现 word2vec之类的。
比如数据分析以前很少有人处理过 nginx日志,通过 tidyverse 就提供了批量处理nginx日志的一个通道。
因为透过 db 层的封装, tidyverse 成为了强大的分布式处理工具,比如通过 geospark, RPostGIS 处理各种空间数据。
如果把 sf 归类到 base R ,在做大数据处理的时候差异还是蛮明显的。
其他的一些 db,比如 neo4j, elasticsearch, mongodb 等等也会有一些奇葩功能是 base R 不会考虑的,所以我说这么比较有些不公平。
- 已编辑
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>
- 已编辑
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
- 已编辑
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 方案里应该是合理且有益的事情。
哈哈,突然想起最近看《西游记》时的一个感慨,“或许在天上佛道已然一家亲了,只苦了“愚昧”的世人,还在下界痴痴地守着分别心。”不过想想,世上很多事情都是由分辨始,至融汇终的(取其优点,秉承“拿来主义”),这也算世事的一个常态吧。