HDFS源码分析（8）：FileSystem

July 14, 2012 / filesystem, Hadoop, HDFS

前提

Hadoop版本：hadoop-0.20.2

概述

之前已对HDFS的datanode部分的源码进行了分析，还剩client和namenode这个最最重要的部分，本着从简单入手，打算继续把namenode当成是一个黑盒，先分析client的代码，毕竟client的代码行数与namenode相比要少得多。

很粗地把client的代码浏览了一下，发现client暴露给用户的接口是DistributedFileSystem这个东东，该类实现了FileSystem这个通用文件系统的抽象类。FileSystem位于core中，并不是HDFS专用的，先对FileSystem进行分析，有助于从宏观上去剖析DFS。

本以为把FileSystem这个类的代码看一遍应该就差不多了，看着看着才发觉FileSystem这个类好庞大、关联依赖的类好多，从下面的类图就可以看出来。虽说类多、方法多，但逻辑相对简单，比较容易理解。

本文所涉及到的类的包结构如下：

下面将简单介绍几个重要的类。

FileSystem

上文已说过FileSystem是一个通用文件系统的抽象基类，它可能被实现为分布式文件系统或本地文件系统。

先来看其重要成员：

从其成员，我们可以看到FileSystem有两个功能：缓存和统计。

下面我们来瞧瞧FileSystem的方法，总共有70多个，够吓人的，不过不能被吓倒了，要硬着头皮去看看究竟在做些什么事情，传统的文件系统里都会有的创建目录、创建文件、打开文件、列举目录的文件、重命名文件、关闭文件等功能都覆盖到，除此还有其它一些重要的方法：

细心的读者是否发现漏了两个重要的静态方法：

在Hadoop生态系统中，可能会经常用到HDFS，也可能会经常见到如下代码：

FileSystem fs = FileSystem.get(URI.create(uri), conf);

上述代码的作用是通过一个uri来取得对应文件系统的实例。

FileSystem.Cache

用于缓存创建的文件系统，实现并不复杂，使用一个HashMap，Map的键类型是Key，值类型是FileSystem。

Key有三个属性：

由此可见，缓冲使用scheme、authority和username来标识文件系统。

FileSystem.Statistics

用于统计文件系统的情况，有三个属性：

Path

用于描述文件或目录的路径，路径使用斜线（/）作为目录的分隔符，如果一个路径以斜线开头则是绝对路径。主要是封装了URI，增添一些检查和处理，使该类能正确处理不同文件系统的路径和目录分隔符。

该类方法名比较直接观，处理逻辑也不复杂，这里就不作一一介绍。

BlockLocation

用于保存文件中一个块的信息，这块和HDFS中的Block是一致的。看其属性就能大概知道其用途：

FileStatus

用于记录文件/目录的信息，记录的内容和Unix、Linux系统很像：

FsPermission

用于控制文件/目录的访问权限，使用POSIX权限方式，控制用户、组、其它的权限，权限有读、写、执行，相信大家都很熟悉。

FSDataOutputStream

在文件系统中用于输出数据的流，继承DataOutputStream，实现Syncable接口，因此，必须支持sync操作。

这个类很简单，当实现一个具体的文件系统时，需要自己定制一个输出流，实现特定的功能，只要继承自FSDataOutputStream，就能符合FileSystem的接口。

FSDataInputStream

在文件系统中用于输入数据的流，继承DataInputStream，实现Seekable和PositionReadable接口，因此，必须支持seek和从某个位置开始读取的操作。

这个类也是很简单，当实现一个具体的文件系统时，需要自己定制一个输入流，实现特定的功能，只要继承自FSDataInputStream，就能符合FileSystem的接口。

后记

文中若有错误或疏漏之处，烦请批评指正。