Hadoop为什么处理小数据量时效果不好？

旃麒雅

Every file, directory and block in HDFS is represented as an object in the namenode’s memory, each of which occupies 150 bytes, as a rule of thumb. So 10 million files, each using a block, would use about 3 gigabytes of memory.

摘自：http://blog.cloudera.com/blog/2009/02/the-small-files-problem/

hadoop处理大量小数据文件效果不好。

hadoop对数据的处理是分块处理的，默认是64M分为一个数据块，如果存在大量小数据文件（例如：2-3M一个的文件）这样的小数据文件远远不到一个数据块的大小就要按一个数据块来进行处理。
这样处理带来的后果由两个：1.存储大量小文件占据存储空间，致使存储效率不高检索速度也比大文件慢。
2.在进行MapReduce运算的时候这样的小文件消费计算能力，默认是按块来分配Map任务的（这个应该是使用小文件的主要缺点）

那么如何解决这个问题呢？
1.使用Hadoop提供的Har文件，Hadoop命令手册中有可以对小文件进行归档。
2.自己对数据进行处理，把若干小文件存储成超过64M的大文件。

hadoop 针对大块数据、流式处理
小文件： 网络、IO的开销与文件本身传输的开销比重太大，如果大文件就不一样了
SequeceFile是Hadoop API提供的一种二进制文件支持。这种二进制文件直接将<key, value>对序列化到文件中。一般对小文件可以使用这种文件合并，即将文件名作为key，文件内容作为value序列化到大文件中。这种文件格式有以下好处：
支持压缩，且可定制为基于Record或Block压缩（Block级压缩性能较优）
本地化任务支持：因为文件可以被切分，因此MapReduce任务时数据的本地化情况应该是非常好的。
难度低：因为是Hadoop框架提供的API，业务逻辑侧的修改比较简单。
坏处是需要一个合并文件的过程，且合并后的文件将不方便查看。

除了 小文件会占用太多NN的元数据存储外，过多的小文件会产生更多的小任务，任务上下文切换时间过多，CPU等资源利用也不足，整理计算性能会大大降低.