hadoop工作中遇到三个问题

此问题来自about云群，尝试给出解决方案

1。hdfs的block设置的是128M，发现存储利用率比较低,文件平均大小只有200K-3M左右，图片资源居多，每个文件占用一个BLOCK,通过50070发现文件数与已用BLOCK数基本相当。
     问题一：已部署实施的HAOOP,格式化过的HDFS存储的BLOCK的大小能否从128M调整为64M甚至到32M，在不影响已存储文件的情况下完成；
     问题二：如何实现多个小文件共存储于一个BLOCK中，即共享存储块和其文件读写接口的实现，压缩访问的实现
     问题三：HDFS的并发读出性能并不是很高，并发量大时会拒绝服务；M级文件TPS大约只有60左右，如何提高并发处理能力

解答1：
在hdfs-site.xml文件中修改配置块大小的地方，dfs.block.size节点。
重启集群后，重新上传文件到hadoop集群上，新增的文件会按照新的块大小存储，旧的不会改变。

解答2：
小文件方案有很多，        对于小文件问题，Hadoop本身也提供了几个解决方案，分别为：Hadoop Archive，Sequence file和CombineFileInputFormat。
1.Hadoop Archive或者HAR，是一个高效地将小文件放入HDFS块中的文件存档工具
2.sequence file由一系列的二进制key/value组成，如果为key小文件名，value为文件内容，则可以将大批小文件合并成一个大文件。
3.CombineFileInputFormat是一种新的inputformat，用于将多个文件合并成一个单独的split，另外，它会考虑数据的存储位置。

解答3：

为了增加Hadoop的可移植性，它采用java语言编写，这实际上也潜在的造成了HDFS低效。Java尽管可以让Hadoop的可移植性增强，但是它屏蔽了底层文件系统，这使它没法利用一些底层的API对数据存储和读写进行优化。首先，在共享集群环境下，大量并发读写会增加随机寻道，这大大降低读写效率；另外，并发写会增加磁盘碎片，这将增加读取代价（HDFS适合文件顺序读取）。

为了解决该问题，可以考虑的解决方案有：修改tasktracker上的线程模型，现在Hadoop上的采用的模型是one thread per client，即每个client连接由一个线程处理（包括接受请求，处理请求，返回结果）；修改之后，可将线程分成两组，一组用于处理client通信（Client Thread），一组用于存取数据（Disk Threads，可采用one thread per disk）。

共享环境下的文件并发存取。在共享环境下，HDFS的随机寻道次数增加，这大大降低了文件存取效率。可以通过优化磁盘调度策略的方法改进。


引用：http://www.aboutyun.com/blog-331-659.html