随着互联网、云计算及大数据等信息技术的发展,愈来愈多的应用依赖于对海量数据的存储和处理,如智能监控、电子商务、地理信息等,这些应用都须要对海量图片的存储和检索。因为图片大可能是小文件(80%大小在数MB之内),以GFS、HDFS为表明的适用于流式访问大文件的分布式存储系统,若直接用来存储图片,因为元数据膨胀,在扩展性和性能方面均存在严重问题。算法
为了解决HDFS在小文件存储方面的问题,一般的作法是先将不少小文件合并成一个大文件再保存到HDFS,同时为这些小文件创建索引,以便进行快速存取。典型技术包括Hadoop自带的Archive、SequenceFile,但均须要用户本身编写程序,实现小文件的合并。为了实现小文件合并对用户的透明,需从系统层面解决HDFS小文件问题。论文针对具体应用场景进行了探索,但不具备通用性。与前面方案不改变HDFS自己不一样,淘宝TFS对HDFS的元数据存储架构进行了调整。在元数据节点仅存放数据块与数据节点的映射,而将文件与数据块的映射关系保存到文件名,再也不须要在元数据节点同时存放这两类映射,最终实现了系统层面解决小文件问题。但因为文件名包含数据块信息,为文件和数据块创建了强关系,致使数据块使用僵硬,TFS在文件的命名、移动方面带来新的问题,限制了其应用场景。数组
HBase是基于HDFS的简单结构化数据分布式存储技术,其可被用来存储海量图片小文件,并具备系统层小文件合并、全局名字空间等多种优点。但基于HBase的海量图片存储技术也存在一些问题。本文将介绍基于HBase的海量图片存储技术,并针对其问题给出改进方法。本文第1部分介绍了基于HBase的海量图片存储技术方案,并分析了原理及优点。第2部分介绍了该方案存在的问题及改进方法。第3部介绍了改进后方案的应用效果。第4部分总结全文,并指明下一步工做。安全
1、基于HBase的海量图片存储技术服务器
Google利用BigTable来存储网页快照及属性信息,来支持网页搜索。受此启发,在HBase中用一样的方法来存储图片及其属性信息。具体方法即创建一张大表,用一个单独的列簇存储图片内容,用其余列簇存储图片的类型、大小、建立时间、修改时间等标准属性及应用相关的属性信息。HBase的列簇划分除了考虑逻辑关系外,还需考虑数据类型,即将逻辑关系相近且数据类型相同的做为一个列簇。大表的具体设计如表1所示。网络
表1:基于HBase的海量图片存储技术的大表设计架构
HBase是采用面向列的存储模型,按列簇来存储和处理数据,即同一列簇的数据会连续存储。HBase在存储每一个列簇时,会以Key-Value的方式来存储每行单元格(Cell)中的数据,造成若干数据块,而后把数据块保存到HFile中,最后把HFile保存到后台的HDFS上。因为用单元格(Cell)存储图片小文件的内容,上述存储数据的过程实际上隐含了把图片小文件打包的过程。分布式
搭建HBase集群后,采用上面设计的大表便可存储海量图片。但因为HBase存在数据块限制,还须要根据应用进行调整。默认状况下,HBase数据块限制为64KB。因为图片内容做为单元格(Cell)的值保存,其大小受制于数据块的大小。在应用中需根据最大图片大小对HBase数据块大小进行修改。具体修改方法是在表建立时,用HColumnDescriptor指定数据块大小,可分列簇指定,具体配置代码以下。oop
代码1:用HCoIumnDescriptor将数据块限制调整为512KB性能
图1 配置代码大数据
上述基于HBase的海量图片存储技术具备以下优势:
(1)经过将图片属性信息与图片内容存储到一个大表中,可支持图片的多属性综合查询。此外,还能够根据应用需求,对列簇进行扩展以保存应用相关信息,从而支持应用相关的图片查询。可见,基于HBase的海量图片存储技术不只解决了图片存储,还实现了灵活的图片检索。
(2)HBase隐含了小文件打包过程,无需进行二次开发即实现了系统层小文件合并。
(3)HBase采用分布式B+树对图片元数据进行全局统一管理,实现了全局名字空间,方便了对图片的管理。
2、基于HBase的海量图片存储技术存在问题及改进方法
基于HBase的海量图片存储技术虽有上述优势,但也存在一些问题。为了说明问题,首先分析HBase中图片数据的存储结构。在基于HBase的海量图片存储技术中,图片内容数据1)2Key-Value的方式进行保存,每一个Key-Value对就是一个简单的字节数组。这个字节数组里面包含了不少项,而且有固定的结构,如图2所示。开始是两个固定长度的数值,分别表示Key的长度和Value的长度。紧接着是Key部分,在这一部分开始是一个固定长度的数值,表示RowKey的长度,接着是RowKey,而后是固定长度的数值,表示Family的长度,而后是Family,接着是Qualifier,而后是两个固定长度的数值,表示Time Stamp和Key Type(Put/Delete)。Value部分是纯粹的二进制数据。
图2 HFile Cell的Key-Value存储结构
可见,(1)无校验码设计,致使存储图片数据的正确性没法验证;(2)Key-Value字节数组没有进行对齐,影响读写效率。为了解决此两个问题,需对Key-Value存储结构进行完善,在Valu域部分后面增长校验和及补白两个域。校验和为8个字节(64位)。经过补白部分,使每一个Key-Value字节数组大小为8字节的整数倍,从而更加适合64位系统,如图3所示。作了上述调整后,在读写数据时都要进行相应改变。在写数据时,首先对Value域进行校验和计算,并写入校验和域;而后,计算Key-Value字节数组总大小,若是不是8的整数倍,则在补白域存储必定数量的0x00字节,使之总大小为8的整数倍。在读数据时,读Key和Value后,对Value进行校验和计算,并与校验域存储的值进行比较,若是至关,则说明读出的Value是正确的。
图3 HFile Cell的Key-Value改进存储结构
基于HBase的海量图片存储技术另外一个问题是存储图片的大小受到数据块大小的限制。虽然可经过配置将数据块大小调大,但因为HBase自己设计,当数据块过大时,不适合随机读,从而影响图片读取性能。所以数据块不能无限调大,推荐数据块最大不超过1M。可在具体应用场景,即便大多图片在1M之内,也可能存在少许图片超过1M,从而须要对基于HBase的海量图片存储技术进行改进。解决思路是将超过数据块限制的文件进行切片,使每片大小小于数据块大小,而后将全部切片进行保存。须要设计一种机制来记录同一图片的全部切片,并记录切片的顺序,以便恢复图片数据。分析HFile单元格的Key-Value字节数组,发现里面的TimeStamp结构在图片存储时没有很好的进行利用,且TimeStamp可很好的记录存储顺序。将图片的全部切片保存到一样的RowKey、Family,并按照切片顺序逐一保存,HBase会自动打上TimeStamp。如此以来,可根据RowKey+Family找到同一图片的全部切片,而后按照每一个切片TimeStamp的时间顺序合并切片,便可恢复出原始图片。
3、应用效果
某市交通管理部门拟创建一套城市交通监控系统,在辖区各路口安装1500个摄像头,对路口交通状况进行24小时监控,对通行车辆逐辆拍照。在拍照的同时,借助图片识别技术从图片识别出车辆号牌信息。车辆号牌信息、拍摄时间、拍摄摄像头ID等做为图片元数据,与图片一并集中保存到后台数据中心,用于支持对图片的综合检索和分析。在图片存储方面。平均每小时每一个摄像头拍照300张,每张图片的大小约为500KB。6个月的图片信息所占的容量为0.5MB*300*1500*24*30*6=IPB。考虑到数据安全,则须要2.3倍的存储空间。所需的存储空间巨大,所以需在保证数据安全的前提下,尽量节省成本,并支持容量扩展。基于改进后的HBase海量图片存储技术解决了这个问题。具体配置以下:HBase Master服务器。配置16核CPU、64G内存、1TB SSD硬盘。2台Master服务器实现高可用,消除无单点故障;HBase HRegion服务器。配置16核CPU、64G内存、1TB SSD硬盘。共用了10台;HDFS NameNode服务器。配置16核CPU、64G内存、1TB SSD硬盘。共用了2台,其中一台做为Secondary NameNode服务器;HDFS DataNode服务器。配置4核CPU、16G内存、2TB*12 SAS硬盘。共用了85台;ZooKeeper服务器。4台服务器(2台HBase Master服务器、2台HDFS NameNode服务器)复用后做为集群的ZooKeeper服务器。采用Paxos算法从4台中推选一台做为主服务器,其他3台做为备用服务器;核心交换机2台,互为热备。汇聚交换机6台,分红3组,两两热备。每台48口。经验证,系统彻底知足需求,实现预期目标,具备以下突出优点;成本节省。采用分布式存储,比采用共享存储方案,成本节省60%以上;扩展性好。元数据字段可根据应用状况灵活添加。系统存储容量、并行处理能力可按需平滑扩展;
实施、管理方便。由HBase后台处理图片打包,避免了二次开发。系统架构统1、简单,易管理维护;智能检索。支持根据图片文件的多个属性进行综合检索;智能纠错。可自动发现文件读写错误,并进行纠正。
4、结束语
本文设计并实现了基于HBase的海量图片存储技术方案,实现了系统层小文件合并、全局名字空间、并具备良好的通用性;经过对HFile Key-Value字节数组结构的完善,实现了图片读取时的自动纠错,提升了系统可靠性。系统在某城市监控系统的设计中获得验证。因为HBase采用分布式B+树存储图片内容元数据,使得读操做在定位图片数据的时候必须经历屡次网络延迟,影响了图片数据的读取性能,下一步将研究该问题的改进方法。