hadoop上传文件效率特别慢，怎么解决

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

一、读写机制　　

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

使用HDFS提供的客户端开发库，向远程的Namenode发起RPC请求；

Namenode会视情况返回文件的部分或者全部block列表，对于每个block，Namenode都会返回有该block拷贝的datanode地址；

客户端开发库会选取离客户端最接近的datanode来读取block；

读取完当前block的数据后，关闭与当前的datanode连接，并为读取下一个block寻找最佳的datanode；

当读完列表的block后，且文件读取还没有结束，客户端开发库会继续向Namenode获取下一批的block列表。

读取完一个block都会进行checksum验证，如果读取datanode时出现错误，客户端会通知Namenode，然后再从下一个拥有该block拷贝的datanode继续读取。

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

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

使用HDFS提供的客户端开发库，向远程的Namenode发起RPC请求；

Namenode会检查要创建的文件是否已经存在，创建者是否有权限进行操作，成功则会为文件创建一个记录，否则会让客户端抛出异常；

当客户端开始写入文件的时候，开发库会将文件切分成多个packets，并在内部以"data queue"的形式管理这些packets，并向Namenode申请新的blocks，获取用来存储replicas的合适的datanodes列表， 列表的大小根据在Namenode中对replication的设置而定。开始以pipeline（管道）的形式将packet写入所有的replicas中。开发库把packet以流的方式写入第一个 datanode，该datanode把该packet存储之后，再将其传递给在此pipeline中的下一个datanode，直到最后一个 datanode，这种写数据的方式呈流水线的形式。

最后一个datanode成功存储之后会返回一个ack packet，在pipeline里传递至客户端，在客户端的开发库内部维护着"ack queue"，成功收到datanode返回的ack packet后会从"ack queue"移除相应的packet。

如果传输过程中，有某个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并行读取。

HDFS处理大量小文件时的问题

小文件指的是那些size比HDFS 的block size(默认64M)小的多的文件。如果在HDFS中存储小文件，那么在HDFS中肯定会含有许许多多这样的小文件(不然就不会用hadoop了)。
而HDFS的问题在于无法很有效的处理大量小文件。

任何一个文件，目录和block，在HDFS中都会被表示为一个object存储在namenode的内存中，没一个object占用150 bytes的内存空间。所以，如果有10million个文件，
没一个文件对应一个block，那么就将要消耗namenode 3G的内存来保存这些block的信息。如果规模再大一些，那么将会超出现阶段计算机硬件所能满足的极限。

不仅如此，HDFS并不是为了有效的处理大量小文件而存在的。它主要是为了流式的访问大文件而设计的。对小文件的读取通常会造成大量从
datanode到datanode的seeks和hopping来retrieve文件，而这样是非常的低效的一种访问方式。

大量小文件在mapreduce中的问题

Map tasks通常是每次处理一个block的input(默认使用FileInputFormat)。如果文件非常的小，并且拥有大量的这种小文件，那么每一个map task都仅仅处理了非常小的input数据，
并且会产生大量的map tasks，每一个map task都会消耗一定量的bookkeeping的资源。比较一个1GB的文件，默认block size为64M，和1Gb的文件，没一个文件100KB，
那么后者没一个小文件使用一个map task，那么job的时间将会十倍甚至百倍慢于前者。

hadoop中有一些特性可以用来减轻这种问题：可以在一个JVM中允许task reuse，以支持在一个JVM中运行多个map task，以此来减少一些JVM的启动消耗
(通过设置mapred.job.reuse.jvm.num.tasks属性，默认为1，－1为无限制)。另一种方法为使用MultiFileInputSplit，它可以使得一个map中能够处理多个split。

为什么会产生大量的小文件？

至少有两种情况下会产生大量的小文件

1. 这些小文件都是一个大的逻辑文件的pieces。由于HDFS仅仅在不久前才刚刚支持对文件的append，因此以前用来向unbounde files(例如log文件)添加内容的方式都是通过将这些数据用许多chunks的方式写入HDFS中。
2. 文件本身就是很小。例如许许多多的小图片文件。每一个图片都是一个独立的文件。并且没有一种很有效的方法来将这些文件合并为一个大的文件

这两种情况需要有不同的解决方 式。对于第一种情况，文件是由许许多多的records组成的，那么可以通过件邪行的调用HDFS的sync()方法(和append方法结合使用)来解 决。或者，可以通过些一个程序来专门合并这些小文件(see Nathan Marz’s post about a tool called the Consolidator which does exactly this).

对于第二种情况，就需要某种形式的容器来通过某种方式来group这些file。hadoop提供了一些选择：

* HAR files

Hadoop Archives (HAR files)是在0.18.0版本中引入的，它的出现就是为了缓解大量小文件消耗namenode内存的问题。HAR文件是通过在HDFS上构建一个层次化的文件系统来工作。一个HAR文件是通过hadoop的archive命令来创建，而这个命令实 际上也是运行了一个MapReduce任务来将小文件打包成HAR。对于client端来说，使用HAR文件没有任何影响。所有的原始文件都 visible && accessible（using har://URL）。但在HDFS端它内部的文件数减少了。

通 过HAR来读取一个文件并不会比直接从HDFS中读取文件高效，而且实际上可能还会稍微低效一点，因为对每一个HAR文件的访问都需要完成两层index 文件的读取和文件本身数据的读取(见上图)。并且尽管HAR文件可以被用来作为MapReduce job的input，但是并没有特殊的方法来使maps将HAR文件中打包的文件当作一个HDFS文件处理。 可以考虑通过创建一种input format，利用HAR文件的优势来提高MapReduce的效率，但是目前还没有人作这种input format。 需要注意的是：MultiFileInputSplit，即使在HADOOP-4565的改进(choose files in a split that are node local)，但始终还是需要seek per small file。

* Sequence Files

通 常对于“the small files problem”的回应会是：使用SequenceFile。这种方法是说，使用filename作为key，并且file contents作为value。实践中这种方式非常管用。回到10000个100KB的文件，可以写一个程序来将这些小文件写入到一个单独的 SequenceFile中去，然后就可以在一个streaming fashion(directly or using mapreduce)中来使用这个sequenceFile。不仅如此，SequenceFiles也是splittable的，所以mapreduce 可以break them into chunks，并且分别的被独立的处理。和HAR不同的是，这种方式还支持压缩。block的压缩在许多情况下都是最好的选择，因为它将多个 records压缩到一起，而不是一个record一个压缩。

将已有的许多小文件转换成一个SequenceFiles可能会比较慢。但 是，完全有可能通过并行的方式来创建一个一系列的SequenceFiles。(Stuart Sierra has written a very useful post about converting a tar file into a SequenceFile — tools like this are very useful).更进一步，如果有可能最好设计自己的数据pipeline来将数据直接写入一个SequenceFile。

阅读全文