【原创】《大数据互联网大规模数据挖掘与分布式处理》阅读笔记(二)

【原创】《大数据互联网大规模数据挖掘与分布式处理》第二章大规模文件系统及MAP-Reduce

                                                       

       首先来看看这一章讲解的整体架构，分别介绍了分布式文件系统、Map-Reduce、使用Map-Reduce的算法，Map-Reduce扩展和集群计算算法的效率问题。

   

                                       

 一、分布式文件系统

 

1.1分布式文件系统起因

大规模WEB服务流行   在数千个计算节点完成大规模计算   这些计算节点都是普通的硬件构成，为了发挥并行化的优势，保证可靠性   开发专用的文件系统。

1.2分布式文件系统特点

本书写的特征是：1）存储单位比传统操作系统中的磁盘快大

                                           2）提供数据冗余机制来防止数据分布在上千块磁盘上是频发媒介故障

  联想：如果用户同时对一个文件进行写操作，如何同步，是不是采取加锁方案。

搜一搜：

如果文件的访问仅限于一个用户，那么分布式文件系统就很容易实现。可惜的是，在许多网络环境中这种限制是不现实的，必须采取并发控制来实现文件的多用户访问，表现为如下几个形式：

只读共享   任何客户机只能访问文件，而不能修改它，这实现起来很简单。HADOOP采取这种形式。

受控写操作采用这种方法，可有多个用户打开一个文件，但只有一个用户进行写修改。而该用户所作的修改并不一定出现在其它已打开此文件的用户的屏幕上。

并发写操作这种方法允许多个用户同时读写一个文件。但这需要操作系统作大量的监控工作以防止文件重写，并保证用户能够看到最新信息。这种方法即使实现得很好，许多环境中的处理要求和网络通信量也可能使它变得不可接受。

 

1.3计算节点的物理结构

集群计算：一种新的并行计算架构，其中计算节点位于机架，单节点之间网络互连，机架之间另一级网络或交换机互连。

主要故障模式：单节点故障；单机架故障

解决方案：文本需要多副本存储；计算过程需要分成多个任务完成。

 

         联想：文本过多，数据冗余过渡也是一种资源浪费，判定副本存储数量的阈值如何确定？

         联想：计算过程中多任务完成，其中某些任务突然因为外界原因宕机，怎么切换到其他机子上运行？

搜一搜：

l  例如在HADOOP的HDFS文件系统中，默认的副本个数是3，两个存放在一个机架，另一个放在其他机架上。在副本机制中，副本的数量值意味着对数据的存储空间的需求是原始数据的数倍，对于非重要的数据而言就是空间浪费，因此需要考虑如何基于数据的重要性来设置文本的副本数，搜到了一篇硕士论文讲述的是基于历史统计记录的动态副本策略，链接如下：http://cdmd.cnki.com.cn/Article/CDMD-10183-2010109806.htm

l  在HADOOP的HDFS中有一种心跳机制，可以掌握集群的工作状况。DataNode通过周期性地发送信条信息与NameNode联系，Namenode通过获取的心跳信息得知DataNode的存在，及其上的磁盘容量、已用空间、总负载等信息，可以参考这片博文讲解的比较详细：http://blog.youkuaiyun.com/fly542/article/details/6797139

l  通过一些负载管理工具进行分布式文件的管理，还可以通过快照定期存储某个时刻的数据复制，当数据损坏的时候，可以回滚到一个过去已知的正确的时间点。

                                                                                         

 二、Map-Reduce

2.1 Map任务

Map-reduce的思想就是“分而治之”, Mapper负责“分”，即把复杂的任务分解为若干个“简单的任务”执行.“简单的任务”有几个含义：

l  数据或计算规模相对于原任务要大大缩小；

l  就近计算，即会被分配到存放了所需数据的节点进行计算；

l  这些小任务可以并行计算，彼此间几乎没有依赖关系。

Map 任务的输入文件由多个元素组成，元素可以是任意类型。所有Map任务的输入和Reduce任务的输出都是