如今我们来深入了解一下Hadoop的FileSystem类。

这个类是用来跟Hadoop的文件系统进行交互的。尽管我们这里主要是针对HDFS。可是我们还是应该让我们的代码仅仅使用抽象类FileSystem。这样我们的代码就能够跟不论什么一个Hadoop的文件系统交互了。在写測试代码时，我们能够用本地文件系统測试，部署时使用HDFS。仅仅需配置一下，不须要改动代码了。

在Hadoop 1.x以后的版本号中引入了一个新的文件系统接口叫FileContext，一个FileContext实例能够处理多种文件系统。并且接口更加清晰和统一。

在讨论Java API之前。先来看一个用Hadoop URL来读文件数据的方式。这样的方式从严格意义上讲不能算是Hadoop给Java的接口。应该说是用Java Net的方式来向HDFS发送一个网络请求然后读取返回流。

与通过URL去读取一个HTTP服务拿到一个流相似

InputStream in = null;
try {in = new URL("hdfs://host/path").openStream();//操作输入流in。能够读取到文件的内容
} finally {IOUtils.closeStream(in);
}

这个方式有个小问题。Java虚拟机默认是不认识hdfs这个协议的，要想让它知道，须要通过

URL.setURLStreamHandlerFactory(new FsUrlStreamHandlerFactory());

来设置一个UrlStreamHandlerFactory，以便使其认识hdfs协议。

可是这种方法的调用是对整个虚拟机生效的，所以，假设程序中有其他部分，尤其是第三方框架，设置了这个工厂。那就会出现故障。因此这就成为了使用这样的方式来訪问HDFS的限制。

完整代码例如以下：

import java.io.InputStream;
import java.net.URL;
import org.apache.hadoop.fs.FsUrlStreamHandlerFactory;
import org.apache.hadoop.io.IOUtils;public class URLCat {static {URL.setURLStreamHandlerFactory(new FsUrlStreamHandlerFactory());}public static void main(String[] args) throws Exception {InputStream in = null;try { in = new URL(args[0]).openStream(); IOUtils.copyBytes(in, System.out, 4096, false); } finally { IOUtils.closeStream(in); }}
}

在这个程序里，先设置JVM的URLStreamHandlerFactory。然后通过url打开一个流，读取流，就得到了文件的内容，通过IOUtils.copyBytes()把读到的内容写出到标准输出流里。也就是控制台上，就实现了类似于Linux里的cat命令的功能。

最后把输入流关闭。

IOUtils是hadoop提供的一个工具类。copyBytes的后两个參数分别表示buffer大小和结束后是否关闭流，我们在后面手动关闭流。所以传false。

将程序打成jar包放到hadoop上去，运行：

$hadoop jar urlcat.jar hdfs://localhost/user/norris/weatherdata.txt

可将前一节放到hdfs上去的weatherdata.txt里的内容显示到控制台上。

运行hadoop jar的方法好像之前忘记写博客了，简单说一句，就是把程序打成jar包。能够指定一个可运行类，然后运行：

$hadoop jar xxx.jar

或者假设不打jar包。把class文件直接放上去。然后运行hadoop XxxClass也行，事实上说白了hadoop命令就是启动一个虚拟机，跟运行java XxxClass或者java -jar xxx.jar一样。仅仅只是用hadoop命令启动虚拟机。在启动前，hadoop命令自己主动把须要的类库增加到了CLASSPATH中。因此省去了自己去环境变量设置的麻烦。

值得注意的是，假设你把class放在了/home/norris/data/hadoop/bin/文件夹下，须要在$HADOOP_INSTALL/etc/hadoop/hadoop-env.sh最后一行加入

export HADOOP_CLASSPATH=$HADOOP_CLASSPATH:/home/norris/data/hadoop/bin/

把自己的class存放位置变成hadoop搜索class位置的一个选项。

有个类叫Path（org.apache.hadoop.fs.Path），这个类的实例代表HDFS里的一个文件（或文件夹），能够把它理解成java.io.File，跟这个File类是一样的。仅仅只是File这个名字听起来就像是一个本地文件系统的类，所以为了差别。取名为Path。也能够把Path理解成一个HDFS上的URI，比方hdfs://localhost/user/norris/weatherdata.txt。

FileSystem类是一个抽象类。代表全部能够执行在Hadoop上的文件系统，我们这里尽管在讨论HDFS，但事实上FileSystem类能够代表如本地文件系统等的不论什么能够执行于Hadoop上的文件系统。我们敲代码也应该针对FileSystem来写，而不是org.apache.hadoop.hdfs.DistributedFileSystem，以便方便移植到其它文件系统上去。

第一步，先要拿到一个FileSystem实例。通过以下API能够获取到实例：

public static FileSystem get(Configuration conf) throws IOException;
public static FileSystem get(URI uri, Configuration conf) throws IOException;
public static FileSystem get(final URI uri, final Configuration conf,  final String user) throws IOException, InterruptedException;

当中，

Configuration（org.apache.hadoop.conf.Configuration）是指Hadoop的配置，假设用默认的构造函数构造出Configuration，就是指core-site.xml里的配置。前面《配置Hadoop》（http://blog.csdn.net/norriszhang/article/details/38659321）一节讲到了该配置。把fs配置成了hdfs。所以依据这个配置Hadoop就知道该取到一个DistributedFileSystem（org.apache.hadoop.hdfs.DistributedFileSystem）实例。

URI是指文件在HDFS里存放的路径。

String user这个參数，将在《安全》章节讨论。

即使在操作HDFS。你可能也同一时候希望訪问本地文件系统。能够通过以下API方便地获取：

public static LocalFileSystem getLocal(Configuration conf)  throws IOException;

通过调用FileSystem实例的open方法能够得到一个输入流：

public FSDataInputStream open(Path f) throws IOException;
public abstract FSDataInputStream open(Path f, int bufferSize)  throws IOException;

当中的int bufferSize是缓冲区大小。假设不传这个參数，默认大小是4K。

以下是使用FileSystem读取HDFS中文件内容的完整程序：

import java.net.URI;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FSDataInputStream;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.IOUtils;
public class FileSystemCat {public static void main(String[] args) throws Exception {String uri = args[0];Configuration conf = new Configuration();FileSystem fs = FileSystem.get(URI.create(uri), conf);//System.out.println(fs.getClass().getName()); //这里能够看到得到的实例是DistributedFileSystem，由于core-site.xml里配的是hdfsFSDataInputStream in = null;try {in = fs.open(new Path(uri));IOUtils.copyBytes(in, System.out, 4096, false);} finally {IOUtils.closeStream(in);}}
}

打成jar包放到hadoop上去执行：

$hadoop jar filesystemcat.jar hdfs://localhost/user/norris/weatherdata.txt

在控制台输出了weatherdata.txt文件里的内容。

大家看一下API，fs.open方法的返回值是FSDataInputStream。而不是java.io包里的流。

这个流继承自java.io.DataInputStream，同一时候实现Seekable（org.apache.hadoop.fs.Seekable）。也就是说能够调用seek()方法读取文件的任何位置数据。

比如上面程序加两行：

in.seek(0);
IOUtils.copyBytes(in, System.out, 4096, false);

就能够实现把文件内容打印两遍。

另外。FSDataInputStream类同一时候也实现了PositionedReadable（org.apache.hadoop.fs.PositionedReadable）接口，接口中定义的三个方法同意在任何位置读取文件内容：

public int read(long position, byte[] buffer, int offset, int length) throws IOException;
public void readFully(long position, byte[] buffer, int offset, int length) throws IOException;
public void readFully(long position, byte[] buffer) throws IOException;

而且，这些方法是线程安全的，可是FSDataInputStream不是线程安全的，仅仅是说不同的FSDataInputStream实例在不同的线程里读文件内容是安全的。可是一个FSDataInputStream实例被不同的线程调用是不安全的。所以，应该为每一个线程创建各自的FSDataInputStream实例。

最后，调用seek()方法的开销是相当巨大的。应该尽量少调用，你的程序应该设计成尽量流式获取文件内容。

FileSystem类里提供了一大堆API用来在创建文件。当中最简单的一个是：

public FSDataOutputStream create(Path f) throws IOException;

创建一个Path类代表的文件。并返回一个输出流。

这种方法有一大堆的重载方法。能够用来设置是否覆盖已有文件，该文件复制的份数，写入时的缓冲区大小，文件块大小（block），权限等。

假设该Path代表的文件的父文件夹（甚至爷爷文件夹）不存在。这些文件夹会被自己主动创建，这样确时在非常多情况下提供了方便。可是有时却与我们的需求不相符，假设你确实希望当父文件夹不存在时不要创建。应该自己推断其父文件夹是否存在。原来的API中有个createNonRecursive方法，假设父文件夹不存在会失败。但如今这一组方法已经被废弃。不建议使用了。

create方法的一个重要重载方法是：

public FSDataOutputStream create(Path f, Progressable progress) throws IOException;

Progressable接口的progress方法能够用来当有数据写入时回调。

public interface Progressable {public void progress();
}

假设不想新建一个文件，而是希望向已有文件追加内容，能够调用：

public FSDataOutputStream append(Path f) throws IOException;

该方法是可选实现方法，也就是说不是全部的Hadoop FileSystem都实现了该方法，比如。HDFS实现了。而S3文件系统就没有实现。而且。HDFS在1.x以后的版本号中的实现才是稳定的实现，之前的实现是有问题的。

以下这个程序把一个本地文件上传到HDFS上。而且在每次progress方法被调用时输出一个点（.）

import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.io.InputStream;
import java.io.OutputStream;
import java.net.URI;import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.io.IOUtils;
import org.apache.hadoop.util.Progressable;public class FileCopyWithProgress {public static void main(String[] args) throws Exception {String localSrc = args[0];String dst = args[1];InputStream in = new BufferedInputStream(new FileInputStream(localSrc));Configuration conf = new Configuration();FileSystem fs = FileSystem.get(URI.create(dst), conf);OutputStream out = fs.create(new Path(dst), new Progressable() {@Overridepublic void progress() {System.out.print(".");
//             try {
//                 Thread.sleep(1000);
//             } catch (Exception e) {
//                 e.printStackTrace();
//             }}});IOUtils.copyBytes(in, out, 4096, true);System.out.println();System.out.println("end.");}
}

程序中的progress什么条件下被调用呢？这个API并没有说明，也就是说你不能如果它在某时会被调用。实际的測试结果是大概写入64K时会被调用一次，但多次測试也不一致，尤其在文件小时，更加不可预知。

假设打开上面程序的Thread.sleep()的凝视，会发现，事实上在progress在被调用时，主程序是等待的。假设把主线程的ID和调用progress方法的线程ID打印出来发现。每次调用progress的线程都是同一个线程，但不是主线程。可是，主线程的"end."确实是在全部点（.）都输出后才输出的。

我复制的文件是4743680字节，即大概4.5M，打出73个点。平均64K一个点。

到眼下为止，仅仅有HDFS在写入文件时回调progress，其他文件系统都没有实现回调progress，在后面做MapReduce程序时会发现，这一回调很实用。

FileSystem里的create方法返回的FSDataOutputStream类有一个方法：

public long getPos() throws IOException;

能够查询当前在往文件的哪个位置写，一个写入的偏移量。

可是与FSDataInputStream不同，FSDataOutputStream没有seek方法，由于HDFS仅仅同意顺序写，对于一个打开的文件。仅仅同意向尾部追加，不同意在任何位置写，因此也就没有必要提供seek方法了。

FileSystem中的创建文件夹的方法：

public boolean mkdirs(Path f) throws IOException;

与java.io.File.mkdirs方法一样，创建文件夹，并同一时候创建缺失的父文件夹。

我们一般不须要创建文件夹，由于创建文件时，默认就把所需的文件夹都创建好了。

FileSystem类中的getFileStatus()方法返回一个FileStatus实例。该FileStatus实例中包括了该Path（文件或文件夹）的元信息：文件大小，block大小，复制的份数，最后改动时间。全部者。权限等。

程序简单，先上代码，再解释一下

import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.io.OutputStream;
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.FileStatus;
import org.apache.hadoop.fs.FileSystem;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.hdfs.MiniDFSCluster;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
public class ShowFileStatusTest {private static final String SYSPROP_KEY = "test.build.data";/** MiniDFSCluster类在hadoop-hdfs-2.4.1-tests.jar中，是一个专门用于測试的in-process HDFS集群 */private MiniDFSCluster cluster;private FileSystem fs;@Beforepublic void setUp() throws IOException {Configuration conf = new Configuration();String sysprop = System.getProperty(SYSPROP_KEY);if (sysprop == null) {System.setProperty(SYSPROP_KEY, "/tmp");}cluster = new MiniDFSCluster(conf, 1, true, null);fs = cluster.getFileSystem();OutputStream out = fs.create(new Path("/dir/file"));out.write("content".getBytes("UTF-8"));out.close();}@Afterpublic void tearDown() throws IOException {if (fs != null) {fs.close();}if (cluster != null) {cluster.shutdown();}}@Test(expected = FileNotFoundException.class)public void throwsFileNotFoundForNonExistentFile() throws IOException {fs.getFileStatus(new Path("no-such-file"));}@Testpublic void fileStatusForFile() throws IOException {Path file = new Path("/dir/file");FileStatus stat = fs.getFileStatus(file);assertThat(stat.getPath().toUri().getPath(), is("/dir/file"));assertThat(stat.isDirectory(), is(false));assertThat(stat.getLen(), is(7L));assertTrue(stat.getModificationTime() <= System.currentTimeMillis());assertThat(stat.getReplication(), is((short)1));assertThat(stat.getBlockSize(), is(64 * 1024 * 1024L));assertThat(stat.getOwner(), is("norris"));assertThat(stat.getGroup(), is("supergroup"));assertThat(stat.getPermission().toString(), is("rw-r--r--"));}@Testpublic void fileStatusForDirectory() throws IOException {Path dir = new Path("/dir");FileStatus stat = fs.getFileStatus(dir);assertThat(stat.getPath().toUri().getPath(), is("/dir"));assertThat(stat.isDirectory(), is(true));assertThat(stat.getLen(), is(0L));assertTrue(stat.getModificationTime() <= System.currentTimeMillis());assertThat(stat.getReplication(), is((short)0));assertThat(stat.getBlockSize(), is(0L));assertThat(stat.getOwner(), is("norris"));assertThat(stat.getGroup(), is("supergroup"));assertThat(stat.getPermission().toString(), is("rwxr-xr-x"));}
}

程序编译须要引入hadoop-hdfs-2.4.1-tests.jar和hadoop-hdfs-2.4.1.jar，在Hadoop的安装包中能够找到。

MiniDFSCluster类在hadoop-hdfs-2.4.1-tests.jar中，是一个专门用于測试的内存HDFS集群。

其他代码看名称都能够理解，仅仅是这个JUnit的assertThat方法让我整了好半天，不知道is方法是哪个类里的静态方法。找了网上都直接这样写。好像写了就能用似的，可是我却编译只是，后来才知道，是org.hamcrest.CoreMatchers类里的静态方法。须要静态引入该类。另外有个lessThanOrEqualTo方法，死活没找到在哪个类里，仅仅好用assertTrue方法取代了。

程序执行须要用JUnit启动，由于这是一个test case。

把junit.jar和org.hamcrest.core_1.3.0.v201303031735.jar放到server上。改动hadoop-env.sh。把我们刚才改动的最后一行：

export HADOOP_CLASSPATH=$HADOOP_CLASSPATH:/home/norris/data/hadoop/bin/

再追加上这两个jar。即：

export HADOOP_CLASSPATH=$HADOOP_CLASSPATH:/home/norris/data/hadoop/bin/:/home/norris/data/hadoop/lib/junit.jar:/home/norris/data/hadoop/lib/org.hamcrest.core_1.3.0.v201303031735.jar

然后执行时不是执行我们写的类，而是执行junit，然后让junit去test我们写的类：

$hadoop org.junit.runner.JUnitCore ShowFileStatusTest

执行结果发现，进行了三个測试。两个成功了，一个失败了，失败在

assertThat(stat.getBlockSize(), is(64 * 1024 * 1024L));这行

期望值是：67108864。也就是64M。实际值是：134217728，也就是128M。也就是说HDFS的block size的默认值是128M，这个我还没搞明确是由于新版的Hadoop改动了block size的默认值还是由于我又一次在64位系统下编译了Hadoop，假设在hdfs-site.xml中设置：

<property>

    <name>dfs.block.size</name>

    <value>67108864</value>

</property>

把block size设成64M，就三个都成功了。