Hadoop源代码学习(完整版)

源地址:http://caibinbupt.iteye.com/blog/280790

注:再对照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的包的功能分析。

 

Package

Dependences

tool

提供一些命令行工具,如DistCp,archive

mapreduce

Hadoop的Map/Reduce实现

filecache

提供HDFS文件的本地缓存,用于加快Map/Reduce的数据访问速度

fs

文件系统的抽象,可以理解为支持多种文件系统实现的统一文件访问接口

hdfs

HDFS,Hadoop的分布式文件系统实现

ipc

一个简单的IPC的实现,依赖于io提供的编解码功能

参考:http://zhangyu8374.iteye.com/blog/86306

io

表示层。将各种数据编码/解码,方便于在网络上传输

net

封装部分网络功能,如DNS,socket

security

用户和用户组信息

conf

系统的配置参数

metrics

系统统计数据的收集,属于网管范畴

util

工具类

record

根据DDL(数据描述语言)自动生成他们的编解码函数,目前可以提供C++和Java

http

基于Jetty的HTTP Servlet,用户通过浏览器可以观察文件系统的一些状态信息和日志

log

提供HTTP访问日志的HTTP Servlet


由于Hadoop的MapReduce和HDFS都有通信的需求,需要对通信的对象进行序列化。Hadoop并没有采用Java的序列化,而是引入了它自己的系统。

org.apache.hadoop.io中定义了大量的可序列化对象,他们都实现了Writable接口。实现了Writable接口的一个典型例子如下:

Java代码  收藏代码
  1. public class MyWritable implements Writable {     
  2.     // Some data          
  3.     private int counter;     
  4.     private long timestamp;     
  5.     
  6.     public void write(DataOutput out) throws IOException {     
  7.         out.writeInt(counter);     
  8.         out.writeLong(timestamp);     
  9.     }     
  10.         
  11.     public void readFields(DataInput in) throws IOException {     
  12.         counter = in.readInt();     
  13.         timestamp = in.readLong();     
  14.     }     
  15.     
  16.     public static MyWritable read(DataInput in) throws IOException {     
  17.         MyWritable w = new MyWritable();     
  18.         w.readFields(in);     
  19.         return w;     
  20.     }     
  21. }   

 

 

 

其中的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)。


为org.apache.hadoop.io.compress等的分析预留位置


介绍完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.iteye.com/blog/86306

既然是RPC,当然就有客户端和服务器,当然,org.apache.hadoop.rpc也就有了类Client和类Server。但是类Server是一个抽象类,类RPC封装了Server,利用反射,把某个对象的方法开放出来,变成RPC中的服务器。

下图是org.apache.hadoop.rpc的类图。



既然是RPC,自然就有客户端和服务器,当然,org.apache.hadoop.rpc也就有了类Client和类Server。在这里我们来仔细考察org.apache.hadoop.rpc.Client。下面的图包含了org.apache.hadoop.rpc.Client中的关键类和关键方法。

由于Client可能和多个Server通信,典型的一次HDFS读,需要和NameNode打交道,也需要和某个/某些DataNode通信。这就意味着某一个Client需要维护多个连接。同时,为了减少不必要的连接,现在Client的做法是拿ConnectionId(图中最右侧)来做为Connection的ID。ConnectionId包括一个InetSocketAddress(IP地址+端口号或主机名+端口号)对象和一个用户信息对象。这就是说,同一个用户到同一个InetSocketAddress的通信将共享同一个连接。

 

 

 

连接被封装在类Client.Connection中,所有的RPC调用,都是通过Connection,进行通信。一个RPC调用,自然有输入参数,输出参数和可能的异常,同时,为了区分在同一个Connection上的不同调用,每个调用都有唯一的id。调用是否结束也需要一个标记,所有的这些都体现在对象Client.Call中。Connection对象通过一个Hash表,维护在这个连接上的所有Call:

Java代码  收藏代码
  1. private Hashtable<Integer, Call> calls = new Hashtable<Integer, Call>();  

 

一个RPC调用通过addCall,把请求加到Connection里。为了能够在这个框架上传输Java的基本类型,String和Writable接口的实现类,以及元素为以上类型的数组,我们一般把Call需要的参数打包成为ObjectWritable对象。

Client.Connection会通过socket连接服务器,连接成功后回校验客户端/服务器的版本号(Client.ConnectionwriteHeader()方法),校验成功后就可以通过Writable对象来进行请求的发送/应答了。注意,每个Client.Connection会起一个线程,不断去读取socket,并将收到的结果解包,找出对应的Call,设置Call并通知结果已经获取。

Call使用Obejct的wait和notify,把RPC上的异步消息交互转成同步调用。

还有一点需要注意,一个Client会有多个Client.Connection,这是一个很自然的结果。因为在Client类包含有一个成员变量connections,其完整定义为“private Hashtable<ConnectionId, Connection> connections = new Hashtable<ConnectionId, Connection>();”,从这个语句可以看出,connections是一个hash表,包含多个Connection。



没有更多推荐了,返回首页

私密
私密原因:
请选择设置私密原因
  • 广告
  • 抄袭
  • 版权
  • 政治
  • 色情
  • 无意义
  • 其他
其他原因:
120
出错啦
系统繁忙,请稍后再试