Hadoop 学习小结(1)

云计算可以说最近是热得发紫，我呢也有幸在做一些相关的工作。先把自己的一些想法总结如下：
拿google的云计算平台来说吧，它涉及到数据存储、数据管理、编程模式等多方面具有自身独特的技术。同时涉及了众多其他技术如下表所示：

技术类型	具体技术
设备架设	数据中心节能技术、节点互联技术
改善服务技术	可用性技术、容错性技术
资源管理技术	数据存储技术、数据管理技术
任务管理技术	数据切分技术、任务调度技术、编程模型
其他相关技术	负载均衡技术、并行计算技术、虚拟机技术、系统监控技术

对于google云计算技术,大家比较熟悉的就是：数据存储技术--Google File System（GFS）,数据管

理技术--BigTable,编程模式--MapReduce。其中Map-Reduce 也是大多数云平台采用的编程模式。下面简单的介绍下这三种技术：

GFS是一个管理大型分布式数据密集型计算的可扩展的分布式文件系统。它使用廉价的商用硬件搭建系统并向大量用户提供容错的高性能的服务。GFS和普通的分布式文件系统主要有以下几点：

首先，节点失效将被看成是正常情况，而不再视为异常情况。

其次，按照传统标准来看，文件都是非常巨大的。

第三，大部分文件都是只会在文件尾新增加数据，而少见修改已有数据的。对一个文件的随机写操作在几乎是不存在的。一般的工作都是由两类读取组成：大的流式读取和小规模的随机读取。

GFS架构：

GFS集群由一个单个的master和好多个chunkserver（块服务器）组成，GFS集群会有很多客户端client访问（如下图）。每一个节点都是一个普通的Linux计算机，运行的是一个用户级别（user-level）的服务器进程。只要机器资源允许，并且允许不稳定的应用代码导致的低可靠性，我们就可以运chunkserver和client可以运行在同一个机器上。



引入一个单个master的设计可以大大简化了设计，并且也让master能够基于全局的角度来管理chunk的存放和作出复制决定。不过，必须尽量减少master的读和写操作，以避免它成为瓶颈。客户端永远不会通过master来做文件的数据读写。客户端只是问master它应当访问那一个chunkserver来访问数据。客户端在一定时间内cache这个信息，并且在后续的操作中都直接和chunkserver进行操作。如图所示的读操作的具体阐述如下：

首先，客户端把应用要读取的文件名和偏移量，根据固定的chunk大小，转换成为文件的chunk index。然后向master发送这个包含了文件名和chunkindex的请求。master返回相关的chunk handle以及对应的位置。客户端cache这些信息，把文件名和chunkindex作为cache的关键索引字。

于是这个客户端就像对应的位置的chunkserver发起请求，通常这个会是离这个客户端最近的一个。请求给定了chunk handle以及一个在这个chunk内需要读取得字节区间。在这个chunk内，再次操作数据将不用再通过客户端-master的交互，除非这个客户端本身的cache信息过期了，或者这个文件重新打开了。实际上，客户端通常都会在请求中附加向master询问多个chunk的信息，master于是接着会立刻给这个客户端回应这些chunk的信息。这个附加信息是通过几个几乎没有任何代价的客户端-master的交互完成的。

BigTable：
采用列存储的方式管理数据,如何提高数据的更新速率以及进一步提高随机读速率是未来的数据管理技术必须解决的问题。

BigTable对数据读操作进行优化,采用列存储的方式,提高数据读取效率。BigTable 管理的数据的存储结构为:< row: string, column: string, time: int64 >- > string。BigTable的基本元素是:行,列,记录板和时间戳。其中,记录板是一段行的集合体。其逻辑结构如下：



下面是一个是一个存储Web网页的范例列表片断。行名是一个反向URL｛即com.cnn.www｝。contents列族｛原文用 family，译为族，详见列族｝ 存放网页内容，anchor列族存放引用该网页的锚链接文本。CNN的主页被Sports Illustrater｛即所谓SI，CNN的王牌体育节目｝和MY-look的主页引用，因此该行包含了名叫“anchor:cnnsi.com”和 “anchhor:my.look.ca”的列。每个锚链接只有一个版本｛由时间戳标识，如t9，t8｝；而contents列则有三个版本，分别由时间 戳t3，t5，和t6标识。



BigTable在执行时需要三个主要的组件:链接到每个客户端的库,一个主服务器,多个记录板服务器。主服务器用于分配记录板到记录板服务器以及负载平衡,垃圾回收等。记录板服务器用于直接管理一组记录板,处理读写请求等。

为保证数据结构的高可扩展性, BigTable采用三级的层次化的方式来存储位置信息，如下图所示：



当客户端读取数据时,首先从Chubby file 中获取RootTablet的位置,并从中读取相应METADATA tablet的位置信息。接着从该METADATA tablet中读取包含目标数据位置信息的User Table的位置,然后从该User Table中读取目标数据的位置信息项。据此信息项到相应的服务器读取数据。

MapReduce是一个编程模式，它是与处理/产生海量数据集的实现相关。用户指定一个map函数，通过这个map函数处理key/value（键/值）对，并且产生一系列的中间key/value对，并且使用reduce函数来合并所有的具有相同key值的中间键值对中的值部分。

Mapreduce 的架构：
与分布式文件系统类似，Map/Reduce的集群，也由三类服务器构成。
•其中作业服务器即Master。后者告诉我们，它也是为各个作业分配任务的核心。
•具体的负责执行用户定义操作的是任务服务器Worker，每一个作业被拆分成很多的任务，包括Map任务和Reduce任务等，任务是具体执行的基本单元，它们都需要分配到合适任务服务器上去执行，任务服务器一边执行一边向作业服务器汇报各个任务的状态，以此来帮助作业服务器了解作业执行的整体情况，分配新的任务等等。
•除了作业的管理者执行者，还需要有一个任务的提交者，这就是客户端。与分布式文件系统一样，客户端也不是一个单独的进程，而是一组API，用户需要自定义好自己需要的内容，经由客户端相关的代码，将作业及其相关内容和配置，提交到作业服务器去，并时刻监控执行的状况。
具体流程示意如下：



具体相关操作为：

1． 用户程序中的MapReduce函数库首先把输入文件分成M块，每块大概16M到64M（可以通过参数决定）。接着在cluster的机器上执行处理程序。
2． 这些分排的执行程序中有一个程序比较特别，它是主控程序master。剩下的执行程序都是作为master分排工作的worker。总共有M个map任务和R个reduce任务需要分排。master选择空闲的worker并且分配这些map任务或者reduce任务
3． 一个分配了map任务的worker读取并处理相关的输入小块。他处理输入的数据，并且将分析出的key/value对传递给用户定义的map函数。map函数产生的中间结果key/value对暂时缓冲到内存。
4． 这些缓冲到内存的中间结果将被定时刷写到本地硬盘，这些数据通过分区函数分成R个区。这些中间结果在本地硬盘的位置信息将被发送回master，然后这个master负责把这些位置信息传送给reduce的worker。
5． 当master通知reduce的worker关于中间key/value对的位置时，他调用remote procedure来从map worker的本地硬盘上读取缓冲的中间数据。当reduce的worker读到了所有的中间数据，他就使用中间key进行排序，这样可以使得相同key的值都在一起。因为有许多不同key的map都对应相同的reduce任务，所以，排序是必须的。如果中间结果集太大了，那么就需要使用外排序。
6． reduce worker根据每一个唯一中间key来遍历所有的排序后的中间数据，并且把key和相关的中间结果值集合传递给用户定义的reduce函数。reduce函数的对于本reduce区块的输出到一个最终的输出文件。

7． 当所有的map任务和reduce任务都已经完成了的时候，master激活用户程序。在这时候MapReduce返回用户程序的调用点。

当这些成功结束以后，mapreduce的执行数据存放在总计R个输出文件中（每个都是由reduce任务产生的，这些文件名是用户指定的）。通常，用户不需要合并这R个输出文件到一个文件，他们通常把这些文件作为输入传递到另一个MapReduce调用，或者用另一个分布式应用来处理这些文件，并且这些分布式应用把这些文件看成为输入文件由于分区（partition）成为的多个块文件。

以上便是综合各种资料所了解的Google 云计算三大技术，有待进一步的学习。关于hadoop 的相关技术 to be continued~~~