Spark or R

前天下班浏览朋友圈， 雪晴数据网 转发了一篇译文， 大数据工具比较：R 语言和 Spark 谁更胜一筹？ ，原作者测试了在限定为单机环境下，使用Kaggle提供的手写识别的数据在R和Spark平台 运行不同算法的对比速度，结论有一下几个：

• 主成分分析R要4小时，Spark要10秒
• 逻辑回归：R运行7小时，Spark约5分钟
• 朴素贝叶斯，因为算法太简单，差异不那么巨大（45s和9s）
• 决策树：R完全跑不起来，Spark花20秒

在整篇文章作者的测试非常武断，有很多误导观众的信息。R再怎么样也不会如此不济，下面会逐条针对原文做补充。 当然，这里面我还想强调：在使用算法解决问题的过程中，以下几大行为必须纠正（或者叫做流氓法则）：

1. 不贴源代码，是耍流氓
2. 张冠李戴，完全复制，不做任何优化就对比，更是耍流氓
3. 不考虑业务场景乱用算法，就是耍流氓
4. 不考虑数据形态以及精度要求，拿算法的帽子乱盖，还是耍流氓

我们也来玩玩测试

首先提供一下我的环境，11年购入的Thinkpad T420，i7-2640M，4核心，8G内存；R版本Windows 64位原生编译版本，未做Blas库的任何优化。在这台玩魔兽现在都有点卡的老爷机上， 以上几个算法在单机版的R平台上测试速度为：

• 主成分分析为 1.64s
• 二分类逻辑回归 5s，多分类逻辑回归为58s
• 决策树使用更高级的GBDT，3s

同时为了表明不是流氓，给出代码

library(data.table) library(irlba) library(LiblineaR) library(SparseM) library(xgboost)  setwd("E:/Dropbox/data/handwriting") train <- fread('train.csv')  train <- as(train, 'Matrix') Y <- train[,1] A <- train[,-1]  ## Principal Components Analysis system.time(P <- irlba(A, nv=9, center=colMeans(A)))  ## Logistic Regression id <- Y == 1 Y1 <- as.numeric(id) ## single label system.time(m1 <- LiblineaR(data = as(A, 'matrix.csr'), target = Y1, type = 5))  ## multi label system.time(m2 <- LiblineaR(data = as(A, 'matrix.csr'), target = Y, type = 5))  ## Confusion Matrix dd <- data.frame(predict(m2, as(A, 'matrix.csr')), Y) table(dd)  ## eXtreme Gradient Boosting (Tree) system.time(bst <- xgboost(data = A, label = Y1, nrounds=10, objective = "binary:logistic")) 

深层次的原因

写到这里，有看官肯定会有疑问了：为什么同样的平台怎么就差异这么大了呢？在解释之前，首先需要明确的一点：

但R从最初设计就不是干这个的！R语言基本继承了S语言的设计理念，我们先了解一下当时S诞生的理由(Yihui Xie,2008)。

简要说：需要高性能计算的部分使用C和Fortran，需要处理逻辑以及快速分析部分使用R。这一直都是R存在的理念。 直至今日，R的源码50%是C，30%是Fortran，仅有20%的R代码。大量通用化计算模块均以R包的方式存在。 R单机版性能不济十之八九是用户采用了不恰当的方式。

比如Regression问题，当数据量小的时候一般用QR分解，亦可以直接用标准最小二乘方式，这时候就需要计算X的内积以及内积的求逆。 当维度很大时，这种做法完全就是个灾难。如果我们改用梯度下降或坐标下降方法之后，虽然牺牲了精度，但计算效率可以得到极大改观。

同样上个世纪Friedman提出了Gradient Boosting Machine，该方法每一代辛勤的科研工作者均站在前人的肩膀上做了更多的优化， 拿早期版本和最新的成果进行对比，（比如用Python的sklearn库中的GBM和R中的xgboost比，然后说R快），这本身是 赤裸裸地耍流氓 。

对于像SVD分解这类问题，如果进行全矩阵分解，计算量暴大不说，单单存储就不太容易搞定。Lancozs算法可以只求解我们关注的最大的几个 奇异值，忽略尾部的奇异值，有这么方便的方法还去做全矩阵分解，请参见流氓法则 4。

写在最后

如果过于迷信工具，而忽视了要解决问题的本质，就需要参见流氓做法 3 和 4了。当我们碰到一个问题，首先判断是否能够转化为数学问题， 然后判断用什么方法解决它，再然后判断适用的工具以及工具对应的特定方法。突然记起Python社区Zoom.Q大妈T恤上有句话， 叫做人生苦短，Python是岸。天天争论哪个工具好用，舍本逐末，那真是人生苦短了~