Hadoop源代码分析
Hadoop源代码分析（一）
关键字: 分布式 云计算
Google的核心竞争技术是它的计算平台。Google的大牛们用了下面5篇文章，介绍了它们的计算设施。
GoogleCluster：
http://research.google.com/archive/googlecluster.html
Chubby：http://labs.google.com/papers/chubby.html
GFS：http://labs.google.com/papers/gfs.html
BigTable：http://labs.google.com/papers/bigtable.html
MapReduce：http://labs.google.com/papers/mapreduce.html
很快，Apache上就出现了一个类似的解决方案，目前它们都属于Apache的Hadoop项目，对应的分别是：
Chubby-->ZooKeeper
GFS-->HDFS
BigTable-->HBase
MapReduce-->Hadoop
目前，基于类似思想的Open Source项目还很多，如Facebook用于用户分析的Hive。
HDFS作为一个分布式文件系统，是所有这些项目的基础。分析好HDFS，有利于了解其他系统。由于Hadoop的HDFS和MapReduce是同一个项目，我们就把他们放在一块，进行分析。
下图是MapReduce整个项目的顶层包图和他们的依赖关系。Hadoop包之间的依赖关系比较复杂，原因是HDFS提供了一个分布式文件系统，该系统提供API，可以屏蔽本地文件系统和分布式文件系统，甚至象Amazon S3这样的在线存储系统。这就造成了分布式文件系统的实现，或者是分布式文件系统的底层的实现，依赖于某些貌似高层的功能。功能的相互引用，造成了蜘蛛网型的依赖关系。一个典型的例子就是包conf，conf用于读取系统配置，它依赖于fs，主要是读取配置文件的时候，需要使用文件系统，而部分的文件系统的功能，在包fs中被抽象了。
Hadoop的关键部分集中于图中蓝色部分，这也是我们考察的重点。
Hadoop源代码分析（二）
下面给出了Hadoop的包的功能分析。
|
Package |
Dependences |
|
tool |
提供一些命令行工具，如DistCp，archive |
|
mapreduce |
Hadoop的Map/Reduce实现 |
|
filecache |
提供HDFS文件的本地缓存，用于加快Map/Reduce的数据访问速度 |
|
fs |
文件系统的抽象，可以理解为支持多种文件系统实现的统一文件访问接口 |
|
hdfs |
HDFS，Hadoop的分布式文件系统实现 |
|
ipc |
一个简单的IPC的实现，依赖于io提供的编解码功能 参考：http://zhangyu8374.javaeye.com/blog/86306 |
|
io |
表示层。将各种数据编码/解码，方便于在网络上传输 |
|
net |
封装部分网络功能，如DNS，socket |
|
security |
用户和用户组信息 |
|
conf |
系统的配置参数 |
|
metrics |
系统统计数据的收集，属于网管范畴 |
|
util |
工具类 |
|
record |
根据DDL（数据描述语言）自动生成他们的编解码函数，目前可以提供C++和Java |
|
http |
基于Jetty的HTTP Servlet，用户通过浏览器可以观察文件系统的一些状态信息和日志 |
|
log |
提供HTTP访问日志的HTTP Servlet |
Hadoop源代码分析（三）
由于Hadoop的MapReduce和HDFS都有通信的需求，需要对通信的对象进行序列化。Hadoop并没有采用Java的序列化，而是引入了它自己的系统。
org.apache.hadoop.io中定义了大量的可序列化对象，他们都实现了Writable接口。实现了Writable接口的一个典型例子如下：
Java代码
- public class MyWritable implements Writable {
- // Some data
- private int counter;
- private long timestamp;
- public void write(DataOutput out) throws IOException {
- out.writeInt(counter);
- out.writeLong(timestamp);
- }
- public void readFields(DataInput in) throws IOException {
- counter = in.readInt();
- timestamp = in.readLong();
- }
- public static MyWritable read(DataInput in) throws IOException {
- MyWritable w = new MyWritable();
- w.readFields(in);
- return w;
- }
- }
public class MyWritable implements Writable {
// Some data
private int counter;
private long timestamp;
public void write(DataOutput out) throws IOException {
out.writeInt(counter);
out.writeLong(timestamp);
}
public void readFields(DataInput in) throws IOException {
counter = in.readInt();
timestamp = in.readLong();
}
public static MyWritable read(DataInput in) throws IOException {
MyWritable w = new MyWritable();
w.readFields(in);
return w;
}
}
其中的write和readFields分别实现了把对象序列化和反序列化的功能，是Writable接口定义的两个方法。下图给出了庞大的org.apache.hadoop.io中对象的关系。
这里，我把ObjectWritable标为红色，是因为相对于其他对象，它有不同的地位。当我们讨论Hadoop的RPC时，我们会提到RPC上交换的信息，必须是Java的基本类型，String和Writable接口的实现类，以及元素为以上类型的数组。ObjectWritable对象保存了一个可以在RPC上传输的对象和对象的类型信息。这样，我们就有了一个万能的，可以用于客户端/服务器间传输的Writable对象。例如，我们要把上面例子中的对象作为RPC请求，需要根据MyWritable创建一个ObjectWritable，ObjectWritable往流里会写如下信息
对象类名长度，对象类名，对象自己的串行化结果
这样，到了对端，ObjectWritable可以根据对象类名创建对应的对象，并解串行。应该注意到，ObjectWritable依赖于WritableFactories，那存储了Writable子类对应的工厂。我们需要把MyWritable的工厂，保存在WritableFactories中（通过WritableFactories.setFactory）。
Hadoop源代码分析（五）
介绍完org.apache.hadoop.io以后，我们开始来分析org.apache.hadoop.rpc。RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。当我们讨论HDFS的，通信可能发生在：
- Client-NameNode之间，其中NameNode是服务器
- Client-DataNode之间，其中DataNode是服务器
- DataNode-NameNode之间，其中NameNode是服务器
- DataNode-DateNode之间，其中某一个DateNode是服务器，另一个是客户端
如果我们考虑Hadoop的Map/Reduce以后，这些系统间的通信就更复杂了。为了解决这些客户机/服务器之间的通信，Hadoop引入了一个RPC框架。该RPC框架利用的Java的反射能力，避免了某些RPC解决方案中需要根据某种接口语言（如CORBA的IDL）生成存根和框架的问题。但是，该RPC框架要求调用的参数和返回结果必须是Java的基本类型，String和Writable接口的实现类，以及元素为以上类型的数组。同时，接口方法应该只抛出IOException异常。（参考自http://zhangyu8374.javaeye.com/blog/86306）
既然是RPC，当然就有客户端和服务器，当然，org.apache.hadoop.rpc也就有了类Client和类Server。但是类Server是一个抽象类，类RPC封装了Server，利用反射，把某个对象的方法开放出来，变成RPC中的服务器。
