为什么有些公司在机器学习业务方面倾向使用R+Hadoop方案.docxVIP

为什么有些公司在机器学习业务方面倾向使用 R + Hadoop 方案？众所周知,R 在解决统计学问题方面无与伦比。但是 R 在数据量达到 2G 以上速度就很慢了，于是就催生出了与 Hadoop 相结合跑分布式算法这种解决方案，但是，python+Hadoop 这样的解决方案有没有团队在使用？R 这样起源于统计学的计算机包与 Hadoop 相结合会不会出问题？5 条评论?分享按投票排序按时间排序11 个回答王威扬?，天赋大多点在数据上/搞业务/写代码收录于?编辑推荐??503?人赞同因为他们在不懂R和Hadoop的特征应用场景的情况下，恰好抓到了一根免费，开源的稻草。R：R的应用场景不在于无与伦比的统计学习能力，而在于结构化数据下无与伦比的单位代码产出量。神经网络，决策树等基于结构化数据的算法一行代码搞定，预测又只是一行代码。这样，商业数据库（如包括Oracle，Netezza，Teradata，SAP HANA等）提供了R接口供统计分析人员进行高效实施。 同样的，SAS和IBM SPSS也做到了一部分高效实施能力，他们没有的是R独有的庞大cran packages群。但相似的一点是，R的package群也把它的用户惯坏了，惯坏到这些人只是觉得这是一个SAS或者SPSS的免费版，而不是去通过代码学习如何做机器学习哪怕一点点核心原理。你要做的，就是高效的最新结构化数据算法的实施。最重要的是，从Hadoop上的数据加载到这些库，不仅保证了数据本身的正确性和结构化，也已经保证了数据模型的第二、第三范式化（CAErwin的第一课），想做任何一个分析，你手边的数据库简单的join就形成了你需要的分析宽表。想想SQL里sum over的设计含义：为什么它要制造数据的冗余？那一定是为了BI或者分析存在的。Hadoop：Hadoop的应用场景不在于给统计分析软件提供强力的支持，而只是提供了一个分布式数据的泛用免费框架，基于键值对（key value pair）高效的对原始非结构化数据进行存储。传统方式下目测可以做到对连续型数值、离散型数值、字符串、大型字符串BLOB、地理信息（二维点，多边形）的存储，Hadoop相当于直接把很多功能扩展：比如Hive作为一个基本工具，直接提供了更广泛的数据类型存储方案：数组(array)，结构体(struct)，键值对(map)等。业务场景：我存储一篇文章不再需要一坨文字灌进去，先做NLP解析，然后形成 (词,词性)的元组，再组成长数组(Array)即可方便的存储、分析，以及利用内置UDF、自写UDF对复杂结构行转列，提取信息。（当然，将NLP解析本身整合在UDF甚至算法中都是可行的，如PySpark）*2014.8改进说明：如果你至今觉得非结构化数据，键值对是一种卖弄概念，我就换一个至简的说法：一个只有两列的数据表。两列的mn*2和多列m*n数据表是可以在一定加工代价下互转的。这种数据结构被大量应用于Java，C++，Python甚至JavaScript中，当你看见类似Hashmap，Hashtable，dict，map等字眼，那就是这货没跑了：经过设计，用于存储的键(key)被散列后决定了它能够被均匀地分布式存储，值(value)是键的跟班，随着键被存储。对于非结构化数据而言，元数据和数据不像方表，极其容易抽象出来（无非就是列名和方表的内容）。初看一个半结构化的Json/XML，元数据出现在键(key)中，数据出现在值(value)中，容易理解。但在解析其他类型数据，(如网络日志Url)，键里的所谓元数据才是要分析的对象(一个用户反复的使用price=xxx做查询条件，说明价格敏感，有可能xxx取了好多值甚至所有可能值，key却很少，可能只有price和brand；此时用户行为模式出现在key里了。)结构化和非结构化数据库结合的R+Hadoop看起来很美，实则困难重重。我的看法是，任何一家在数据分析领域（文本挖掘暂时除外，理由在业务场景里描述过）决定以一个稳健的态度涉足的企业，都无一例外的基于数据强一致性的考虑，选择传统的结构化数据库作为后续结构化分析的依托—— 哪怕他们是收费的。如果习惯代码开发，Hadoop+python自己做初步的数据处理，而后使用基于java的Mahout是一个很自然的选择：其提供的矩阵计算（SVD），迭代式聚类算法(如Kmeans)，基于图的迭代模型（一个例子是PageRank算法，值中存的也是Key），以及集成决策树等模型，在分布式场景下是顺理成章完成的，而R则会像一个跟班，很难找到它的应用场景。一样具有较高编码效率的Python可以更加灵活、优美（缩进的意义上）的继承mrjob类完成相应功能，在数据尝试性探索这一步，matplotlib产出报告恐怕是不如R+knitr+ggpl