hadoop文件系统架构分析

(软件体系结构的大作业，阅读分析hadoop文件系统)

写在前面/后面

FileSystem = abstractFileSystem -》 面向文件系统实现者

​ FileContext -》面向应用程序编写者

FS中具体的文件系统作为最基层的类，用于实现对对应的文件系统的读取，同一继承自FileSystem/AbstarctFileSystem，HDFS是单独的一套系统，对等于VFS，用于操作不同的文件系统。HDFS虽然继承于AbstractFileSystem，主体又DFSClient类实现，（借尸还魂），只是为了做一个文件系统的样子，内在的实现在另外一个HDFS的文件夹里（有单独的DFSInputStream），独立于fs文件夹

FileSystem的结构：

extends Config(提供访问配置文件的功能)

​ 文件创建，读取，重命名，拷贝，删除等操作

GlobFilter

​ description:A class that could decide if a string matches the glob or not

Cache:

​ Caching FileSystem objects,内含有hashMap

Statistics：

statisticsTable是一个IdentityHashMap

BlockLocation:

包含一个文件块的详细信息（全部副本，主机端口，网络拓扑结构，块文件长度，偏移，块长度等）

java
string[] {副本主机}；
string[] {副本主机端口};
string[] {主机网络中的拓扑路径};


FileStatus:

​ extends PathFilter，用来过滤文件，或的想要的文件。

​ 获取文件状态，path.length,isdir,block_replocation等

Trash：

垃圾桶的功能

fs有用文章：

http://huashuizhuhui.iteye.com/blog/1867511

http://huashuizhuhui.iteye.com/category/209973

其他类：

DFSClinet:

​ DFSClient can connect to a Hadoop FileSystem and perform basic file tasks.It uses the ClientProtocol to commuicate with a NameNode daemon,and connects directly to DataNodes to read/write block data.HDFS users should obtain an instance of DistributedFileSystem,whith uses DFSClient to handle fileSystem tasks.

要求

1. 阅读教师提供的前期分析报告[3]，并仔细阅读与修正。

   ​ –

2. 下载 JDK、Apache 的构建工具 Maven[4]、Eclipse[2]，构建阅读代码的环 境。

   ​ –

3. 在详细阅读源代码的基础上，理解设计思想，并给出软件架构图。

​ FS中具体的文件系统作为最基层的类，用于实现对对应的文件系统的读取，同一继承自FileSystem/AbstarctFileSystem，HDFS是单独的一套系统，对等于VFS，用于操作不同的文件系统。HDFS虽然继承于AbstractFileSystem，主体又DFSClient类实现，（借尸还魂），只是为了做一个文件系统的样子，内在的实现在另外一个HDFS的文件夹里（有单独的DFSInputStream），独立于fs文件夹

1. 在软件架构图的基础上，给出源代码的详细类图和核心过程的顺序图， 说明源代码的设计如何与设计思想呼应。

   • FS的架构
     

     可以看出类图的继承结构，FileSystem = abstractFileSystem + FileContext ，所以继承自abstractFileSystem 的类基本与fileSystem的类的实现方式功能一样，所以不再重复说明。

     我们可以把FS的有关类分为2部分，一个是工具类，一个是实现类。

     • 工具类：

     • FilterFileSystem

       FilterFileSystem继承FileSystem，声明了一个FileSystem的对象，自己做一些处理，交给FS处理

     • CheckSumFileSystem

       ChecksumFileSystem类继承FilterFileSystem类,提供校验CRC

     • LocalFilesystem

       继承自ChecksumFileSystem，重写父类的文件复制的类，添加内部对象rfs,不过没咋用，判断为基本同父类一样

     • 实现类：

     • NativeS3FileSystem

       实现具体功能的文件系统子类与其父类FileSystem的差异显而易见，除去父类中的抽象函数如append，Create，delete，getUri，getFileStatus，getWorkingDirectory等需要根据子类的情况实现重写的函数之外，一些函数子类利用了其系统中独有的类或者接口进行了自己的实现。

     • FTPFileSystem

       子类FTPFileSystem与父类FileSystem的函数实现差异很大，主要原因在于FTPFileSystem引入了Client对象并利用其完成了很多与父类不同的函数实现机制

     • KosmosFileSystem

       子类KosmosFileSystem与父类FileSystem的函数实现差异较大，主要原因在于KosmosFileSystem利用了KfsImpl接口

     • S3FileSystem

       子类S3FileSystem与父类FileSystem的函数实现差异较大，子类利用INode节点的特性对函数的实现方式进行重写

     • RawLocalFileSytem

       自己重写filesystem的大多数方法，去操作文件，所依赖的流都是自己重载过的内部类流

     • HDFS

       文件系统实现主体依靠DFSClient来实现，只是为了包装一层filesystem

   • Stream流的架构

   

   流的结构类似与Fs的结构，FSInputStream/FSOutputStream是每一个具体（实际）文件系统的父类，每一个文件系统都有对应的流作为内部流，

   然后内部流最终需要作为参数被包装为FSDataInputStream/FSDataOutputStream在HDFS上传递。

   （java流的一大特色，嵌套包装）

   比如：new FSDataInputSteam(new S3InputStream(…))

   同时，流的结构也印证了上述的架构，fs只是为HDFS做同一的文件系统接口，消除每一个文件系统的差异

   • 接口的继承
     

     这里值得注意的就是writealbe是序列化的接口，继承该结构的类可以将对象转化为流的形式。

     ​

   • 操作/异常处理/config+shell![异常错误]
     
     

     无可奉告！

2. 在明确详细设计的基础上，以源代码中的相关代码为例证明自己的判断。

   ​ 新建文件系统的流程 -》

   1. 得到configuration的对象，
   2. 用filesystem.get(configuration)得到对应的文件系统
   3. 对文件进行操作
   4. 如果对文件的读写，单独用DataInput/OutputStream操作

   文件系统的创建流程：

Filesystem.get() public static FileSystem get(URI uri, Configuration conf) throws IOException {    String scheme = uri.getScheme();    String authority = uri.getAuthority();    if (scheme == null) {                       // no scheme:不知道是什么文件系统      return get(conf);    }    if (authority == null) {                       // no authority      URI defaultUri = getDefaultUri(conf);       //如果没有权限，从默认配置里获取URI      if (scheme.equals(defaultUri.getScheme())    // if scheme matches default          && defaultUri.getAuthority() != null) {  // & 有解码权限（不爽很懂）        return get(defaultUri, conf);              // 返回默认的参数      }    }    String disableCacheName = String.format("fs.%s.impl.disable.cache", scheme);    //是否可以从cache里获取    if (conf.getBoolean(disableCacheName, false)) {      return createFileSystem(uri, conf);    }    return CACHE.get(uri, conf);  }//FileSystem.createFileSystem()  private static FileSystem createFileSystem(URI uri, Configuration conf      ) throws IOException {  Class<?> clazz = conf.getClass("fs." + uri.getScheme() + ".impl", null);  //really create filesystem，获取对应文件系统的名称if (clazz == null) {  throw new IOException("No FileSystem for scheme: " + uri.getScheme());}FileSystem fs = (FileSystem)ReflectionUtils.newInstance(clazz, conf);//用反射的机制去构造类，提供类的位置，找文件找类fs.initialize(uri, conf);return fs;  }     //Cache.get()   获取key（）-》scheme,authority,username标识   private FileSystem getInternal(URI uri, Configuration conf, Key key) throws IOException{    FileSystem fs;     synchronized (this) {       fs = map.get(key);     }     if (fs != null) {       return fs;     }     fs = createFileSystem(uri, conf); //以下涉及同步问题     synchronized (this) { // refetch the lock again       FileSystem oldfs = map.get(key);       if (oldfs != null) { // 一样的系统被创建当这个fs在创建的时候，比你早一步         fs.close(); // close the new file system         return oldfs;  // return the old file system       }       // now insert the new file system into the map       if (map.isEmpty() && !clientFinalizer.isAlive()) {         Runtime.getRuntime().addShutdownHook(clientFinalizer);       }       fs.key = key;       map.put(key, fs);   //加入map中       if (conf.getBoolean("fs.automatic.close", true)) {         toAutoClose.add(key);       //自动关闭的链表，如果需要自动关闭       }       return fs;     }   }

这里的文件系统只是本地的文件系统，HDFS的专门处理分布式的文件系统，继承于abstractFileSystem的目的是为了接口通信。在完整的源码中，有hadoop-common-project /hadoop-hdfs-project,在这个版本里hdfs放在hdfs-project里，而不是common里，推测老师给的版本应该是过渡版本

1. 通过阅读源代码，深刻体会 Hadoop 云计算平台与文件系统之间的关系， 修正提供的分析报告，给出完整的分析过程与修订后的报告

   ​ 云计算的主体的存储部分又HDFS实现，而我们研究的fs为HDFS提供一个同一的接口，用来屏蔽每一种文件系统内部具体的特性或者细节。使得HDFS可以将他们同一视为一种文件系统而不用在意其他细节。

   ​ 在文件系统的提供的服务上，为了实现云存储，适合分布式存储，又有nameNode和dataNode的结构。
   

   • dataNode作为存储节点，具体负责存储文件数据，是文件系统的工作节点，根据需要存储并检索数据块（受客户端或namenode调度），并且定期向namenode发送它们所存储的块的列表。

   • nameNode负责存储文件的元数据， 管理文件系统的命名空间，主要作用是维护着文件系统树及整棵树内所有的文件和目录、数据节点信息，并将命名空间镜像文件、编辑日志文件永久保存在本地磁盘。虽然都是依赖与文件系统，但是有一个主从的逻辑关系在里面。

   

   1. dataNode多备份为数据存储可靠性提供保障。

   2. 多备份同时对系统的吞吐量有一定提升，客户端从namenode获取需要的BlockLocation(参见上文)，然后由HDFS去寻找对应的数据主机，返回

   3. 一个HDFS 集群可能包含上千DataNode 节点，这些DataNode 定时和 NameNode通信，接受NameNode的指令。为了减轻NameNode的负担，NameNode不永久保存数据块的位置信息，系统启动时通过DataNode的上报，来重建NameNode上的映射表

   4. 通过Client的文件读写分析：

      
      

      HDFS数据存储：