1.方法原理:
系统借鉴Hbase存储的基本原理,提出以“状态标记位”的方法为当前并不能完美支持追加处理的HDFS的Mapfile文件提供了一种有效的解决方法,既解决了HDFS小文件存储的问题,又解决了Mapfile即时修改的问题。
2.方法介绍:
在海量图片背景中,图片的存储形式探讨就成为了保证系统性能的重要部分。HDFS存在普遍的小文件存储的通病,对小文件的读取通常会造成大量从datanode到datanode的seeks和hopping来retrieve文件,而这样是非常的低效的一种访问方式。因此对于大小远小于HDFS的块大小的文件,需要进行处理后再存入HDFS中。
几乎所有的图片都远远小于64M(HDFS默认数据块大小),处理这些大量的小图片就需要某种形式的容器来通过某种方式来打包这些file。Hadoop提供了一些选择。主要可以选择的有HARfile、Sequencefile、Mapfile。本系统采用了Mapfile作为小文件的容器存储。
同时,若对于所有小于64M的图片均进行打包,则会加大打包文件的过程的资源损耗,因此需要定一个阈值,当文件大小超过该阈值后进行打包操作,否则直接通过namenode进行上传。本系统所定的阈值为2MB。
此外,由于Hadoop在最新的版本才支持文件的追加append操作,但对于Mapfile还没有完善的支持。这意味着若用原始处理方法,每一次上传操作将会重写原Mapfile,效率低下。本系统采用了“标记法”对Mapfile打包小文件时的增删改查进行处理,保证了图片存储访问的效率。
3.具体实现:
图片基本操作包括图片的增加、删除、修改和查询。由于图片存储在HDFS的特殊环境,因此图片的增删改查操作需要进行特殊的处理。由于mapfile不支持追加写入操作,这样每次进行操作需要对原mapfile文件进行覆盖写入,效率低下。
为了实现相应功能,本系统对Hbase中存储的图片元数据增加了一个状态标志位,该状态位可能的取值为“HdfsLargeFile”,“HdfsMapflie”,“LocalSmallFile”以及“Deleted”四种。每次上传操作会进行会进行文件大小判断,并对其进行相应处理,更新标志位。
对于mapfile的增加操作,本系统使用了写缓存队列的操作进行