R+Hadoop方案为何成为企业学习业务的首选_数据分析师

众所周知，R在解决统计学问题方面无与伦比。但是R在数据量达到2G以上速度就很慢了，于是就催生出了与Hadoop相结合跑分布式算法这种解决方案，但是，python+Hadoop这样的解决方案有没有团队在使用？R这样起源于统计学的计算机包与Hadoop相结合会不会出问题？
因为他们在不懂R和Hadoop的特征应用场景的情况下，恰好抓到了一根免费，开源的稻草。　
R：
R的应用场景不在于无与伦比的统计学习能力，而在于结构化数据下无与伦比的单位代码产出量。神经网络，决策树等基于结构化数据的算法一行代码搞定，预测又只是一行代码。这样，商业数据库（如包括Oracle，Netezza，Teradata，SAPHANA等）提供了R接口供统计分析人员进行高效实施。同样的，SAS和IBM SPSS也做到了一部分高效实施能力，他们没有的是R独有的庞大cran packages群。但相似的一点是，R的package群也把它的用户惯坏了，惯坏到这些人只是觉得这是一个SAS或者SPSS的免费版，而不是去通过代码学习如何做机器学习哪怕一点点核心原理。你要做的，就是高效的最新结构化数据算法的实施。
最重要的是，从Hadoop上的数据加载到这些库，不仅保证了数据本身的正确性和结构化，也已经保证了数据模型的第二、第三范式化（CAErwin的第一课），想做任何一个分析，你手边的数据库简单的join就形成了你需要的分析宽表。想想SQL里sumover的设计含义：为什么它要制造数据的冗余？那一定是为了BI或者分析存在的。
Hadoop：
Hadoop的应用场景不在于给统计分析软件提供强力的支持，而只是提供了一个分布式数据的泛用免费框架，基于键值对（key value pair）高效的对原始非结构化数据进行存储。
结构化和非结构化数据库结合的R+Hadoop看起来很美，实则困难重重。我的看法是，任何一家在数据分析领域（Text Mining暂时除外，见后）决定以一个稳健的态度涉足的企业，都无一例外的基于数据强一致性的考虑，选择传统的结构化数据库作为后续结构化分析的依托——哪怕他们是收费的。如果习惯代码开发，Hadoop+python自己做初步的数据处理，而后使用基于java的Mahout是一个很自然的选择。
R+Hadoop的幻觉：
不管什么和Hadoop结合，都喜欢以word count这种典型的键值对开始。事实上R可以做这件事，但是觉得R做的无与伦比，就有点进入误区。还是那句R的美在于结构化数据下无与伦比的单位代码产出量。一旦你发现你作为专注于数据的分析师，同时也是一个并不骨灰的代码开发者，开始用R操作列表和数据结构，开始用R重写Mapper和Reducer，你就会产生一个疑问：
为嘛不学Java、Python？这种分析“不传统”，就算你不想学吧，为嘛不找懂它们的人来干？
Python基于键值对存储，也具有相当高的单位代码产出量，也有很多科学计算包。从这个意义上你可以做出一个白箱，单机缩水版的mahout，而且适合处理有增量算法的大数据学习（看看NumPy,SciPy,）。一样免费。
数据挖掘的幻觉：
数据挖掘是什么，很难吗？
广义的数据挖掘，包括数据分析和机器学习，只说最核心的数学概念的话，估计就几句话；恰好R的简洁性也是能用几句话做完这几句话的：
0数据清洗，标准化。和1-4，理解真实世界是相辅相成的
1最先学的数学技巧是空间分解：LL’，PCA，SVD，回归以及L2/L0惩罚变种
2再学最优化算法：L1惩罚回归，SVM（使用的Newton-Raphson/Gauss-Newton/Levenberg-Marquadt（还是1的内容）；MonteCarloMarkovChain
3数据结构：决策树（列表类），词频统计（键值对或者字典类），FP-growth（一个树的加强版）。学到这，所谓“贝叶斯”根本就不能叫算法，只能叫一个指导思想。
4模型集成：Adaboost，神经网络，bootstrap。对方法，对模型参数都能集成（大杂烩）
任何一个听起来很装逼的算法，逃不过被解析成这4类方法组合的命运。
可以看到，大数据分析的瓶颈在哪？
第0步，和曾经的大Boss讨论过，传统行业数据仓库实施起码还能打10年，而”实体-关系”概念和”键-值”概念这两种抽象起码还能打30年，数据的组织、过滤，元数据维护都是数据产生价值的必经之路，这方面的工作很枯燥但是很基础，大数据和传统数据都需要；
第1步是最基本最重要的分析手段，也最容易在大数据语境下导致单机无法分析的亿阶稀疏大矩阵产生：例1，用户User对商品SKU的购买记录；例2，在特定的经纬度，特定的时间，特定的用户发生了动作；这两个例子是典型的“汇总还不如不汇总”的情况，必须要有分布式稀疏矩阵处理技术；
第2步，序贯MCMC的串行性可以通过并行集成方法模拟，但是收敛性还仍然较低，需要暴力并行堆FLOPS；对应的，因为SVM/Lasso都有增量算法、分布式算法方案，核心思想在于“世界的真实，模型的本质，都是稀疏的”，锁少量资源，分布式地更新模型系数或者是梯度，这些算法在理论上得到突破后，往往依赖分析型数据库或者大数据平台灵活的并发调度，灵活的行列混合存储模式，这一点是单机、小集群、传统数据库难以企及的；
第3、4步，这里虽然举了很简单的例子，但这些是在数学模型和数据模型上是最没有开发压力的，需要关心的只是资深程序员的功底了。举例说明，文本挖掘（NLP）统计完词频你还是得会空间里做PCA（或者其他形式的大矩阵加工）；如果不然，只引入HMM模型和基础字典树的话，学习成本就只有学习贝叶斯理论了，并且仍然可以高效并行的解决NLP问题，有兴趣的可以参考Viterbi算法和CRF算法。
大数据的幻觉：存储和计算的冲突
大数据处理，多大算大？像我说的，在3、4步出来的数据，原始数据很大，加工汇总完了很小，或者处理起来是高度独立的。分布式存储不影响分析，说是大数据，其实和小数据处理没差别。
需要随时交换资源的聚类，回归，SVD，PCA，QR，LU等关系到矩阵分解的计算甚至是高效访问，这才是大数据真正的挑战。
那些有监督的分类树，把数据集切成1000份并且有冗余的给500台机器每台3-5份数据最后得到集成的分类结果，我很难称其为“大数据计算技术”，它的本质和挖矿机每秒能做无数个高度同质化的hash计算一样，不需要资源交换，不需要大量通信，它只是小数据的范围内打转。
内存内的分析和数据探索，展现（单节点）：
百万级，R的上限；千万级-亿级，SAS的上限；亿级，Python的上限。我的使用经验是，400M数据，Python加载内存500M，R加载占内存2G，SAS加载600M，经过表级压缩150M。而后续的原始处理（尤其是字符串操作这种数据清洗），R几乎不能做。这就需要你输入到R的数据几乎就能直接开始跑分析了。若不信邪，我推荐你用readLines加上strsplit来操作读入R的文件，看看他数据清洗的效率和read.delim，和SASprocimport以及Python的withas语法相差多少。
同时另一方面，只要数据量低于刚才提到的限度，R又提供了最好的展现方案，因为“展现方案是专用而非泛用”的。最著名的ggplot2，基于百度echarts产品的recharts（bytaiyunonGithub），还有YihuiXie的作品knitr（markdown语法动态将数据挖掘结果，图片，视频生成html），要比Python现有的可视化包（甚至是GUI包）更友好，易于操作，更适合小数据集快速展现。如果你恰好是SAS用户，还是不要说自己懂数据展现会比较好。来自:https://www.cda.cn/
我的理解是，R的产出类似html+js+CSS一样，适合轻量分析，轻量展现，更适合个人用户。
非结构化大数据处理：
你的算法已经走到了“万事俱备，只差跑全量”这样一个对手中的数据很了解的地步了。Wiki对Revolution Analytics的介绍讲：R didn’t natively handle datasets larger than main memory。非结构化大数据应用的场景只能是：
你很懂数据分布的细节（也许你花了很久在其他项目或者本项目的样本数据上研究过也在大数据集上稍微验证了一下）什么算法适合你了然于胸，已知增量算法是存在的，或者你觉得暴力并行没问你觉得把类似Mahout计算的步骤经过代码包装交付给R来做没问题
你完全不care交互式探索　　
这是你需要的R应用场景么？或者换一种说法，这种应用场景R有什么优势？要知道算法效率排名上R说下鄙team（一个不是专业做数据挖掘的数据部门）的经验：讲了半天R+Hadoop，不上Mahout，随便搞搞RSnow，准备买SAS。　
因为我会SAS（少量用Macro，没用过矩阵，因为没必要）和R（没有学习成本），Python的并行包pp使用中，考虑mahout。　　
更新：当大数据平台用户不满足于存储，简单加工以及成型算法实施，也开始关注最小查询、交互式探索效率了，诸如Spark的内存解决方案将会更合适。　　
结束语：　
顺便也给数据分析师，以及他们的领导们提醒一句：如果A有B没有的代码开发能力，R又完全替B把数学的事情做完了，形成了依赖，那B存在的意义是什么？国人强调数学理论这么一点点优势也都不复存在了。机器学习算法在不同的阶段适合使用不同的工具，研究和使用接不上也就算了，千万别连工具适合的环境都不懂，作为互联网从业人员，这就太难堪了。
在美国，精英的研究者是自己做开发的——这话也可以这么说，精英的开发者们自己做研究。每一个模型都不完美，现有的模型很可能不满足你的分析需要。所以才要以开放的心态接纳新技术，发展深入数据挖掘研究，从代码优化改造（山寨）走向技术原创。