基于Hadoop的云盘系统客户端技术难点

作者：张子良 

声明：版权所有，转载请注明出处http://www.cnblogs.com/hadoopdev/archive/2013/03/07/2947447.html

一、概述　　

基于任何平台实现的云盘系统，面临的首要的技术问题就是客户端上传和下载效率优化问题。基于Hadoop实现的云盘系统，受到Hadoop文件读写机制的影响，采用Hadoop提供的API进行HDFS文件系统访问，文件读取时默认是顺序、逐block读取；写入时是顺序写入。

二、读写机制　　

首先来看文件读取机制：尽管DataNode实现了文件存储空间的水平扩展和多副本机制，但是针对单个具体文件的读取，Hadoop默认的API接口并没有提供多DataNode的并行读取机制。基于Hadoop提供的API接口实现的云盘客户端也自然面临同样的问题。Hadoop的文件读取流程如下图所示：

1. 使用HDFS提供的客户端开发库，向远程的Namenode发起RPC请求；
2. Namenode会视情况返回文件的部分或者全部block列表，对于每个block，Namenode都会返回有该block拷贝的datanode地址；
3. 客户端开发库会选取离客户端最接近的datanode来读取block；
4. 读取完当前block的数据后，关闭与当前的datanode连接，并为读取下一个block寻找最佳的datanode；
5. 当读完列表的block后，且文件读取还没有结束，客户端开发库会继续向Namenode获取下一批的block列表。
6. 读取完一个block都会进行checksum验证，如果读取datanode时出现错误，客户端会通知Namenode，然后再从下一个拥有该block拷贝的datanode继续读取。

　　这里需要注意的关键点是：多个Datanode顺序读取。

　　其次再看文件的写入机制：

 

1. 使用HDFS提供的客户端开发库，向远程的Namenode发起RPC请求；
2. Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常；
3. 当客户端开始写入文件的时候，开发库会将文件切分成多个packets，并在内部以"data queue"的形式管理这些packets，并向Namenode申请新的blocks，获取用来存储replicas的合适的datanodes列表， 列表的大小根据在Namenode中对replication的设置而定。
4. 开始以pipeline（管道）的形式将packet写入所有的replicas中。开发库把packet以流的方式写入第一个 datanode，该datanode把该packet存储之后，再将其传递给在此pipeline中的下一个datanode，直到最后一个 datanode，这种写数据的方式呈流水线的形式。
5. 最后一个datanode成功存储之后会返回一个ack packet，在pipeline里传递至客户端，在客户端的开发库内部维护着"ack queue"，成功收到datanode返回的ack packet后会从"ack queue"移除相应的packet。
6. 如果传输过程中，有某个datanode出现了故障，那么当前的pipeline会被关闭，出现故障的datanode会从当前的 pipeline中移除，剩余的block会继续剩下的datanode中继续以pipeline的形式传输，同时Namenode会分配一个新的 datanode，保持replicas设定的数量。

　　关键词：开发库把packet以流的方式写入第一个datanode，该datanode将其传递给pipeline中的下一个datanode，知道最后一个Datanode，这种写数据的方式呈流水线方式。

三、解决方案

　　1.下载效率优化

　　通过以上读写机制的分析，我们可以发现基于Hadoop实现的云盘客户段下载效率的优化可以从两个层级着手：

　　1.文件整体层面：采用并行访问多线程（多进程）份多文件并行读取。

　　2.Block块读取：改写Hadoop接口扩展，多Block并行读取。

　　2.上传效率优化

　　上传效率优化只能采用文件整体层面的并行处理，不支持分Block机制的多Block并行读取。

 

 

基于Hadoop的云盘系统客户端技术难点之二 HDFS文件访问控制

作者：张子良

版权所有，转载请注明出处

一、概述　　

　　Hadoop开源技术框架在实际业务应用中，其早期的安全机制饱受诟病，具体到HDFS应用方面的问题，主要包括以下几个方面：

　　1.用户到服务器的认证问题

　　（1）Namenode上没有用户认证：用户只要知道NameNode服务地址和端口信息，就可以访问HDFS，并获取文件namespace信息。

　　（2）Datanode上没有认证机制：Datanode对读入输出并没有认证，导致如果客户端知道Blockid，就可以任意的访问Datanode上的Block数据。

　　2.服务器到服务器的认证信息

　　（1）Namenode对Datanode没有认证机制：非法用户可以伪装成Datanode，去接收Namenode的文件存储任务。

二、hadoop的Security

　　针对用户到服务器的认证问题，Hadoop在1.0.0版本以后增加了Security认证机制。该机制采用类Unix用户管理机制，文件的创建用户和超级用户拥有对文件的所有权限，包括读和写，其他用户拥有访问权，无写权限。具体来讲就是，连接到hadoop 集群的用户/组信息取决于客户端环境，即客户端主机中`whoami`和`bash –c groups`取到的用户名和组名，没有uid和gid，用户属组列表中只要有一个与集群配置的用户组相同即拥有该组权限。

　　值得注意的是当前Hadoop的三个主要版本分支中并不是都实现了对其的支持，具体实施时需要注意不同版本的区别。

三、hadoop的kebores

　　Hadoop的Kebores认证机制，用来解决服务器到服务器的认证，主要涉及云盘系统后台服务分布式集群安全问题，将另开专题讨论。在此不作讨论。

四、云盘系统客户端文件安全保障

　　云盘系统客户端HDFS文件安全保障主要涉及用户对HDFS文件服务集群的安全访问问题，包括某一个注册用户只能访问属于该用户的空间和某一个用户只能在HDFS空间上访问指定大小的空间两个问题。这里面是涉及一个用户管理和空间管理的问题，在此不作详细介绍。

针对问题一，我们可以通过改造现有HadoopThriftServer或者新增服务机制来解决，即客户端登陆时，返回HDFS上该用户的允许访问路径，用户操作过程中进行访问路径检测，非授权路径自动过滤，不允许访问。

针对问题二，提供用户注册机制，服务端根据用户注册的权属组，调用FSadmin设置用户文件夹的授权大小。

 

基于Hadoop的云盘系统客户端技术难点之三 小文件存储优化

作者：张子良

版权所有，转载请注明出处。

一、概述

首先明确概念，这里的小文件是指小于HDFS系统Block大小的文件（默认64M），如果使用HDFS存储大量的小文件，将会是一场灾难，这取决于HDFS的实现机制和框架结构，每一个存储在HDFS中的文件、目录和块映射为一个对象存储在NameNode服务器内存中，通常占用150个字节。如果有1千万个文件，就需要消耗大约3G的内存空间。如果是10亿个文件呢，简直不可想象。这里需要特别说明的是，每一个小于Block大小的文件，存储是实际占用的存储空间仍然是实际的文件大小，而不是整个block大小。

　　为解决小文件的存储Hadoop自身提供了两种机制来解决相关的问题，包括HAR和SequeueFile，这两种方式在某些方面解决了本层面的问题，单仍然存在着各自的不足。下文讲详细说明。

二、Hadoop HAR

　　Hadoop Archives (HAR files) ，这个特性从Hadoop 0.18.0版本就已经引入了，他可以将众多小文件打包成一个大文件进行存储，并且打包后原来的文件仍然可以通过Map-reduce进行操作，打包后的文件由索引和存储两大部分组成，索引部分记录了原有的目录结构和文件状态。其原理如下图所示：

 

 

　　缺点：

1. HAR 方式虽然能够实现NameNode内存空间的优化，但是他是一个人工干预的过程，同时他既不能够支持自动删除原小文件，也不支持追加操作，当有新文件进来以后，需要重新打包。
2. HAR files一旦创建就不能修改，要做增加和修改文件必须重新打包。事实上，这对那些写后便不能改的文件来说不是问题，因为它们可以定期成批归档，比如每日或每周。
3. HAR files目前还不支持文档压缩。

三、SequeuesFile

　　Sequence file由一系列的二进制key/value组成，如果key为小文件名，value为文件内容，则可以将大批小文件合并成一个大文件。Hadoop-0.21.0版本开始中提供了SequenceFile，包括Writer，Reader和SequenceFileSorter类进行写，读和排序操作。该方案对于小文件的存取都比较自由，不限制用户和文件的多少，支持Append追加写入，支持三级文档压缩（不压缩、文件级、块级别）。其存储结构如下图所示：

示例代码如下所示：

  private static void writeTest(FileSystem fs, int count, int seed, Path file, 
                                CompressionType compressionType, CompressionCodec codec)
    throws IOException {
    fs.delete(file, true);
    LOG.info("creating " + count + " records with " + compressionType +
             " compression");

　　//指明压缩方式
    SequenceFile.Writer writer = 
      SequenceFile.createWriter(fs, conf, file, 
                                RandomDatum.class, RandomDatum.class, compressionType, codec);
    RandomDatum.Generator generator = new RandomDatum.Generator(seed);
    for (int i = 0; i < count; i++) {
      generator.next();

　　//keyh
      RandomDatum key = generator.getKey();

　　//value
      RandomDatum value = generator.getValue();
　　//追加写入
      writer.append(key, value);
    }
    writer.close();
  }

　　缺点：

　　目前为止只发现其Java版本API支持，未在其他开发接口中发现相关版本的实现，尤其是LibHDFS和thrift接口中，可能真是C++阵营狂热支持者的一个悲剧。

四、Hbase

　　如果你需要处理大量的小文件，并且依赖于特定的访问模式，可以采用其他的方式，比如Hbase。Hbase以MapFiles存储文件，并支持Map/Reduce格式流数据分析。对于大量小文件的处理，也不失为一种好的选择。