在机器学习方面使用 R + Hadoop 方案真的有那么好2

第3、4步，这里虽然举了很简单的例子，但这些是在数学模型和数据模型上是最没有开发压力的，需要关心的只是资深程序员的功底了。举例说明，文本挖掘（NLP）统计完词频你还是得会空间里做PCA（或者其他形式的大矩阵加工）；如果不然，只引入HMM模型和基础字典树的话，学习成本就只有学习贝叶斯理论了，并且仍然可以高效并行的解决NLP问题，有兴趣的可以参考Viterbi算法和CRF算法。

大数据的幻觉：存储和计算的冲突

大数据处理，多大算大？像我说的，在3,4步出来的数据，原始数据很大，加工汇总完了很小，或者处理起来是高度独立的。分布式存储不影响分析，说是大数据，其实和小数据处理没差别。

需要随时交换资源的聚类，回归，SVD，PCA，QR，LU等关系到矩阵分解的计算甚至是高效访问，更进一步还有热数据在内存上而不是物理存储上的多次迭代，这才是大数据真正的挑战。

那些有监督的分类树，把数据集切成1000份并且有冗余的给500台机器每台3-5份数据最后得到集成的分类结果，我很难称其为“大数据计算技术”，它的本质和挖矿机每秒能做无数个高度同质化的hash计算一样，不需要资源交换，不需要大量通信，它只是“小数据+独立运算后直接能够整合结果”的范围内打转。

数据在物理存储、内存、甚至显存的原地迭代会带来数据重分布；在传统数仓领域数据，重分布其实是对未来效率提高预期的妥协，且里面含有比较多对传统业务稳定数据架构的理解。

大数据时代明显不存在什么数据仓库ER模型稳定性，不知道大家有没有这种体验：一个新需求，一个全新的不着边际的研究性问题的场景下，就能建个新库来进行探索与数据加工整理，数据挖掘。各自为政，实验容易，落地与整合困难。—— 这个情况下如果要频繁走物理存储的话，基于key的重新分布会让数据像煮沸的一锅粥大量占用网络与IO写入带宽，与传统数据库性能的巨大鸿沟是无法回避的问题。因此在这个场景下，Spark、Storm、GPU计算火起来，如Scala、Clojure、Python等含有FP概念的语言走得越来越靠近开发工程师的视线，较高级的封装工具如图模型计算的GraphSQL等组件也浮出水面。而且说句实话，Map（映射）和Reduce（规约）在这些语言中，已经是老的掉了好多年牙的概念了。（FP：Functional Programming我反对翻译成函数式编程，这明明是泛函编程）

大数据概念引入这件事儿是大炮打蚊子——内存内的分析和数据探索，展现（单节点）：

*从数据记录条数讲：

百万级，R的上限；

千万级-亿级，SAS的上限；

千万级，Python的上限；

*我的使用经验，从数据占用内存的效率讲：加载400M数据会使得

Python（Numpy列存）占用内存500M

R（我谨慎猜测是行存列存和二维表三样都存一份）加载占内存2G

SAS（行存）占用600M，经过表级压缩（依然是行存）150M

*后续的原始处理

尤其是字符串操作这种数据清洗，R几乎不能做，精通shell及regexp的人又做的太容易。

若想用R，这就需要你输入到R的数据几乎就能直接开始跑分析了。若不信邪，我推荐你用readLines加上strsplit来操作读入R的文件，看看他数据清洗的效率和read.delim，和SAS proc import 以及 Python的with as语法相差多少。

*展现方案：

只要数据量低于刚才提到的限度，R又提供了最好的展现方案，因为“展现方案是专用而非泛用”的：

a. Hadley最著名的R包之一ggplot2未来会引入SVG等可交互元素。一个具有d3.js可视化特性的绘图包还不让你震惊吗？

b. 百度echarts团队项目被taiyun包装成recharts放在了github上

c. 已经加入RStudio的R统计达人Yihui Xie的作品knitr，能够使用markdown语法动态将数据挖掘结果，图片，视频生成打包放进html或者pdf文档。

说说对手：

a. R要比Python现有的可视化包（以matplotlib和pygame为主）更友好，更易于操作。

b. 虽然让从来没接触过前端的人沉浸在用Chrome即可调试的JavaScript里面不太科学，但我爱不释手，而且其核心的展现方式确实未来会加入R。

c. Java风格的Processing，无缝调用java库，封装大量java图形函数、视频相关API、鼠标响应API，可以导出java applet或port成js代码；搞大数据的人必然熟悉java开发，可以几乎0成本又高效快速的使用它。

这几种工具确实各有所长，我个人无法取舍，但平心而论，R是学习门槛、编码效率和产出效果同时最出色的（个人经历原因无法对SAS VA，Tableau，Flex或更一般的BI展现工具置评，其受众因为软件成本，落地性不够等原因，我缺乏使用它们的经验，它们也缺乏对我的吸引力）

归纳下我的理解，R的产出报告类似html+javascript+CSS一样，是适合轻量分析，轻量展现的。

大数据干这件事儿是正道——非结构化大数据批量或者迭代处理：

你的算法已经走到了“万事俱备，只差跑全量” 这样一个对手中的数据很了解的地步了。Wiki 对Revolution Analytics的介绍讲：R didn’t natively handle datasets larger than main memory，这么灵活小巧的工具做个抽样数据分析明明是很好的。

非结构化大数据应用的场景只能是：

-你很懂数据分布的细节（也许是项目经验，也许是R上已经做过抽样探索）

-问题适合的算法你了然于胸；增量算法存在；暴力并行计算（矩阵计算，图迭代）没问题

-你觉得把类似Mahout计算的步骤经过代码包装交付给R来做没问题

-你完全不care交互式探索

这是你需要的R应用场景么？或者换一种说法，这种应用场景R有什么优势？调用编译好的cpp库，fortran库是R发挥优势的地方吗？要知道算法效率排名上R<java<C++。算法月内要上线，自己看着办。

说下前鄙team（一个不是专业做数据挖掘的数据部门）的经验：

讲了半天R+Hadoop，不上Mahout，随便搞搞RSnow，准备买SAS。

因为我会SAS（少量用Macro，没用过矩阵，因为没必要）和R（没有学习成本），Python的并行包pp使用中，考虑mahout。

更新：当大数据平台用户不满足于存储，简单加工以及成型算法实施，也开始关注最小查询、交互式探索效率了，诸如Spark的内存解决方案将会更合适。

现team是一个同事至少是硕士（统计/金融/计算机），专做金融行业数据挖掘的小团队。能力和业务场景可以供参考。

* SAS能力覆盖面95%（具备核心价值的数据在服务器上能够处理的量很少超过上亿，主推SAS）

* Python和R覆盖面都在70%+

* Hadoop/大数据概念淡：客户有足够的Teradata、Oracle、SAS服务器

* Hive/Spark：Hive做辅助、灵活仓储，PySpark作为一个可以预期、稳定的数据挖掘平台的接点

结束语：

顺便也给数学系、统计系的数据分析师，以及他们的领导们提醒一句：如果员工A有员工B没有的代码开发能力，R又完全替员工B把数学的事情做完了，形成了依赖，那员工B存在的意义是什么？强调数学理论这么一点点优势也都不复存在了。

机器学习算法在不同的阶段适合使用不同的工具，研究和使用接不上也就算了，千万别连工具适合的环境都不懂，作为互联网从业者，这就太盲从了。

精英的研究者是自己做开发的——这话也可以这么说，精英的开发者们自己做研究。每一个模型都不完美，何况新问题涌现的越来越快，现存的模型很可能不满足你的分析需要。所以才要一边扎实理论，以最少的尝试嗅到最适合问题的算法，一边以开放的心态接纳和理解新技术的应用场景，深入发展数据挖掘研究，从代码优化改造（山寨）走向技术原创。

一个不好的消息是，不管是从indeed.com职位Post、搜索还是行业生命周期研究看，大数据这几个字正在迅速退掉金色，其名字的价值泡沫正在逐步被挤出。抓住技术的重点与技术适合的场景，对个人以及对行业都是磨刀不误砍柴工的事情。