本帖最后由 旧收音机 于 2015-5-30 22:43 编辑
问题导读
1、分布式计算有哪些？
2、怎么去分析分析维基百科数据集？
3、分布式计算有哪些优缺点？
6 分布式推荐计算 本章概述： 分析维基百科上的一个大数据集 利用Hadoop和分布式计算产生推荐结果 伪分布式上存在的非分布式推荐 本书着眼于持续增长的数据集，从10条到100,000再到1千万再到1.7千万。不过这依然是中等大小的推荐系统所处理的数据。本章依然放手一搏，处理了来自维基百科语料库中的1.3亿条数据，这些数据主要是以文章对文章的连接形式存在的。在这些数据集中，文章既充当了用户，也充当了项目。这也显示了Mahout在特定情形下十分灵活的应用。 为满足演示目的，1.3亿的数据还是可管理的。但是对于单机处理推荐过程还是有一些困难的。这就需要使用一种新的推荐算法，通过Mahout基于的Mapreduce范式与Hadoop来实现分布式计算。 我们首先要检测一下维基百科的数据来认识一下它对于分布式推荐计算意味着什么。你将会学习到如何在分布式的环境下设计一个推荐器，因为这与非分布式的推荐计算有很大的不同。你也将看到Mahout如何把之前的算法设计翻译成基于MapReduce和Hadoop的实现。最后，你将运行一个完整的基于Hadoop的推荐Job程序。 6.1 分析维基百科数据集我们从分析维基的数据开始，但是很快我们会发现由于问题规模而引起的问题。我们将很快退后几步去深入了解下分布式计算是如何执行的。 维基是一个由用户编写和维护的在线百科全书。据报道，在2010年它已经包含320万篇英文文章了。维基文章提取的开源项目( http://download.freebase.com/wex/)估计所有维基文章大概有42GB。基于互联网，维基文章可以相互链接。这些链接代表了某种兴趣。可以做个比方，一篇文章像是用户一样“喜欢”另一篇文章作为其偏好的项目。 在往下继续之前，先下载并解压links-simple-sorted.zip，其中包含5,706,070篇文档对3,773,865篇不同文档的130,160,392个链接。主要说明的是，这些数据中没有偏好值或者排名等级，这里只有文章与文章之间的关联关系。也就是说，这属于一种“布尔偏好”。文章A链接了文章B，不能代表B对A也有链接。在这里，用户和项目是一样多的，所以不论是基于用户的算法还是基于项目的算法无好坏之分。如果使用一个涉及相似度度量的算法并且不依赖于偏好值，那么LogLikelihoodSimilarity会比较合适。 直觉上这些数据具有什么意义？并且我们期望获得什么样的推荐结果？一条从A到B的链接表示了B向A提供了一些相关参照信息。一个基于这些信息的推荐信息将会一些和A指向相同或相似的文章。这些推荐出来的文章被解释成它们没有被A指向却应该被A指向。推荐系统将揭示一些对A感兴趣或者会偶然关联上的一些文章。 6.1.2 数据规模的考虑在处理这样大的数据时，一个非分布式的推荐引擎可能就搞不定了。单单这些数据就要消耗JVM堆空间2GB大小，再加上Mahout程序所需空间，可能需要2.5GB。这已经超过了某些32位的机器的堆空间大小。也就是说，你需要一台64位的机器，今儿不换明儿也得换。再由于推荐算法固有的时间复杂度，推荐系统需要超过一秒的时间去完成推荐任务，这对于现代Web实时应用来说已经是非常慢了。 如果我们有足够多的硬盘，那么我们可以搭建这样一个平台。但是总有一天，随着数据的日益增多，到了十亿或者更多，所需的堆空间也达到了上限32GB呢？对了，也许有人会开始琢磨如何对数据降噪去减少数据的量，提高数据的精度。但是这并不能从根本上回避数据增长所带来的问题。 如果你的系统在处理数据规模上有限制的话，那么只能说你Out了。计算资源可以无限的增加；那么我们要解决的问题是如果把这些计算资源整合在一起去协同的完成任务。你的收益和制作一个超级计算机（计算能力的提升）所需的成本是不成比例的，所以我们应该想办法利用多个普通机器的计算资源。对于那些单点无任何联系的机器，堆在一起只能是浪费电源，最有效利用他们的方式就是联合它们去为推荐系统效力。 这些维基数据的大小代表了一个基于Mahout的实时推荐系统所处理数据的上限。——这其实已经超过现代的标准了。对于这样的数据规模，我们需要一个新的方法。 6.1.2 分布式计算的优缺点评估根据上面说明的原因，我们不得以才使用多个普通机器与代替一个高性能机器。一个公司或学术组织可能拥有很多未充分利用的普通机器，这样这些机器额外的空闲资源就可以用来做推荐任务。另外有一些计算资源也可以通过云计算的提供商哪里得到，比如亚马逊EC2服务（ http://aws.amazon.com）。 图 6.1 分布式可以将一个数据规模很大的问题化简成很多小规模数据的问题，从而分配给较小的服务器上去计算。 分布式处理一个推荐问题从根本上改变了推荐引擎。到目前为止我们所见到的所有推荐算法都是一个具有一个偏好返回值的函数。为了给一篇文章推荐一个新的连接，我们需要去遍历所有的文章-文章的连接；因为推荐过程需要所有的这些数据。然而，如此大量的数据，我们要遍历全部或者大部分不可能一次性完成。我们之前所介绍的方法已经变得不再适用了，至少对于目前的问题形式。接下来分布式推荐引擎将为你我点亮一展明灯。 需要指出的是，分布式处理一个问题不能提搞计算的效率，相反，它相对于单机处理要消耗更多的资源。比如，在很多机器之前传输数据需要消耗网络带宽。这种计算往往要被结构化，包括中间结果的排序，它会占用一些时间去进行序列化、存储以及反序列化等过程。而且这些是非常占用内存和消耗电能的。 需要注意的是，这样的计算需要在线下执行，因为即使计算很少的数据也是秒级别的，而不是毫秒级别的。这样它就不能对用户的请求做出实时响应。一般地，这样的计算和存储会定期的进行，然后在运行时返回给用户。 然而，这种做法可以为推荐系统在处理大规模数据时提供一种途径，这是单机处理方案无法具备的。因为分布式计算可以从很多机器上利用计算资源，把那些未使用、零散的计算资源整合在一起，从而在计算能力上超越专用计算机。最后，分布式计算可以使用更少的时间完成任务，虽然它需要更多对原料处理的过程和时间。一般而言，对于同一个问题，分布式要比单机的计算多消耗一倍的CPU资源。如果我们用10CPU，那么速度将会是单机处理的5倍，而且对于机器的利用率也大大提高了。 （翻译 By 花考拉）
关注分布式存储技术以及分布式计算方法
相关导读：
| 
/2 
京ICP备2020039040号
简书网举报电话：021-34700000
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
千斤顶
显身卡
