测试Hadoop Trunk代码

从SVN上checkout代码，然后部署在了两台Linux机器之上。Hadoop版本为0.12.4。过程还是挺顺利的，这得益于以前折腾过Hadoop 0.5版。

如果你在安装的过程中，发现问题，可以参考用Hadoop搭建分布式存储和分布式运算集群。 当然你可以通过Email或者Gtalk与我联系。好久没有关注Hadoop了，发现它已经越来越成熟，开始步入实际使用阶段，比如Amazon 的 EC2 和S3。

另外，令人非常兴奋的是，Yahoo推出Pig。从介绍可知，这是一个非常有意思的项目，建立在Hadoop之上。

看《The Google File System》后的一些笔记

看了基于Google File System思想实现的Hadoop代码，重读了Google的这篇论文《The Google File System》。Paper挺长，网上已经有热心的人把翻译版奉献了出来。在这里，只是把其中的部分内容抽取出来，与大家一起分享。
性能，可扩展性，可靠性，可用性仍然是GFS的目标，但它还有一些与传统分布式文件系统与众不同的东西：
（1）对于大规模的集群系统，机器出现故障很正常，因此系统容错必须十分重视。文件系统必须具有高可用性，数据完整性和相应的诊断工具。通过快速恢复，chunk复制，master复制达到高可用性；通过checksum检查数据完整性；通过log记录系统中出现的各种事件，以便诊断错误。
（2）传统文件系统的block的大小只有几k，而GFS将选用64M，以满足当前出现的越来越庞大的数据集处理需求。选用大的chunk size，可以：
a、减少与master的交互次数；
b、大部分的时候，对chunk的操作都集中在一个chunk上，因此可以维护一个持久的TCP连接减小网络开销；
c、减少存储在master上的元数据把它放在内存中。
在具有优点的同时，存在缺点，就是多个客户端同时访问同一个文件（此文件比较小，由一个chunk组成），易形成hot spot。
（3）通过观察发现，绝大部分的时候，对文件的修改操作都只是附加内容，很少是翻盖写或者随机写。因此在GFS中，对文件附加操作进行重点优化。

GFS的体系结构
GFS的体系结构是由一个master和多个chunkserver组成（在Hadoop中，master称作name node，chunkserver称作data node，chunk称作block）。
采用单一的master，可以简化系统设计，在拥有全局视图的情况下制定更好的chunk处置策略。采用此种方法，存在瓶颈问题是显而易见的。因此master只存储元信息，相当于元数据服务器，具体的数据传输由client和chunkserver来完成。

元数据
包括三类元数据，它们分别是：文件和chunk的命名空间，文件到chunk的映射和每个chunk副本的位置。元数据全部放入内存，这样可以加快master的操作速度，但它受限于内存大小。

操作日志
对文件系统的操作都将被记录到持久化存储介质，通过重新执行这些操作来达到恢复文件系统的目的。当操作日志达到一定大小时，将做checkpoint，这样可以减少文件系统的恢复时间。目前，Hadoop不支持对操作日志做checkpoint。

Data Flow
在GFS中，数据流和控制流分开，这是显而易见的。数据流怎么流动，具有一定的技巧性。它采用的是pipeline方式。一个chunkserver并不是把数据同时分发给其余的chunkserver，而是把数据只传给离自己最近的chunkserver（距离的远近通过IP地址来判断）。此时这个chunkserver在接受数据的同时，把数据转发给离它最近的chunkserver，这样充分利用了全双工网络的带宽。

以上只谈到paper中涉及的一些方面，完整内容请阅读paper。

Hadoop系列－fs包之代码实现

在此包中，最重要的是FileSystem抽象类。它定义了文件系统中涉及的一些基本操作，如：create，rename，delete...另外包括 一些分布式文件系统具有的操作：copyFromLocalFile,copyToLocalFile,...类似于Ftp中put和get操作。 LocalFileSystem和DistributedFileSystem，继承于此类，分别实现了本地文件系统和分布式文件系统。
了解了最重要的类之后，看一看它的一系列stream类：

• FSOutputStream在原有OutputStream基础之上添加了获得文件指针偏移量的getPos方法。可以通过FileSystem的 createRaw获得它的实例。这里存在一个疑问，这个扩展的getPos方法在fs包中没有被使用。如果在其余包中同样没有被使用，那么扩展就显得多 余。

• FSInputStream在原有InputStream基础之上同样添加了getPos方法，同时可以通过seek方法定位指定的偏移量处。可以通过 FileSystem的openRaw获得它的实例。新添加的getPos和seek方法在FSDataInputStream类中被使用。

• FSDataOutputStream继承于DataOutputStream，包装了FSOutputStream。与DataOutputStream相比，不同之处在于：

1. 添加了getPos方法，它是利用PositonCache记录当前的position
2. 通过Buffer内类对输出进行缓存处理，改进性能
3. 可以构建具有checksum的流，保证数据的正确性

• FSDataInputStram继承于DataInputStream，包装了FSInputStream。与DataInputStream相比，不同之处在于：

1. 添加了seek和getPos方法
2. 通过Buffer内类对输入进行缓存处理，改进性能
3. 可以构建具有checksum的流，保证数据的正确性

另外，为了屏蔽Windows和Unix、Linux在路径处理上存在的差异，实现了Path类，提供了统一的处理方式。

Hadoop系列－IPC之代码实现

• 整体结构：在IPC包中，最重要的3个类是Server，Client和RPC，它们具有层次化的结构。

1. RPC类是对Server、Client的具体化。在RPC类中规定，客户程序发出请求调用时，参数类型必须是Invocation；从服务器返回的值类型必须是ObjectWritable。为了加强理解，可以查看测试类TestIPC。在那里，规定的参数类型与返回值类型都是LongWritable。
2. RPC类是对Server、Client的包装，简化用户的使用。如果一个类需充当服务器，只需通过RPC类的静态方法getServer获得Server实例，然后start。同时此类提供协议接口的实现。如果一个类充当客户端，可以通过getProxy或者waitForProxy获得一个实现了协议接口的proxy object，与服务器端交互。为了加强理解，可以查看测试类TestRPC，在那里，实现的协议接口为TestProtocol。

• Server类

1. 启动Listener进程。如果收到需要建立连接的请求，将建立连接，然后在上面捕获读操作的命令。收到命令之后，将把解析客户端发过来信息的工作委派给Connection。Connection把信息封装到Call对象中，放入队列中，待Handler处理。
2. 启动指定数目的Handler线程，处理客户端对指定方法调用的请求，然后把结果返回给客户端。

• Client类

1. 用Call封装好调用信息，然后借助从连接池中取出的Connection向服务器端发送，等待结果。如果到指定服务器的Connection不存在，将马上建立。Connection线程读取服务器方法调用的返回信息。完成之后，通知主线程。

• RPC类

1. 对外使用的窗口，隐藏了Server和Client的背后细节，验证RPC协议版本。

Hadoop系列－IPC模型

IPC

• 实现RPC的一种方法，具有快速、简单的特点。 它不像Sun公司提供的标准RPC包，基于Java序列化。
• IPC无需创建网络stubs和skeletons。
• IPC中的方法调用要求参数和返回值的数据类型必须是Java的基本类型，String和Writable接口的实现类，以及元素为以上类型的数组。接口方法应该只抛出IOException异常。

使用模型

• 采用客户/服务器模型
• Server：它把Java接口暴露给客户端。指定好监听端口和接受远程调用的对象实例后，通过RPC.getServer()可以得到Server实例。
• Client：连接Server，调用它所暴露的方法。Client必须指定远程机器的地址，端口和Java接口类，通过RPC.getClient()可以得到Client实例。
• Server不可以向Client发出调用，但在Hadoop中，有双向调用的需求。 比如在DFS，NameNode和DataNode需要互相了解状态。