一种基于HBase韵海量图片存储技术

针对海量图片存储,已有若干个基于Hadoop的方案被设计出来。这些方案在系统层小文件合并、全局名字空间以及通用性方面存在不足。本文基于HBase提出了一种海量图片存储技术,成功解决了上述问题。本文将介绍基于HBase海量图片存储技术方案,分析其原理及优势,该方案在城市交通监控中得到应用验证。

随着互联网、云计算及大数据等信息技术的发展,越来越多的应用依赖于对海量数据的存储和处理,如智能监控、电子商务、地理信息等,这些应用都需要对海量图片的存储和检索。由于图片大多是小文件(80%大小在数MB以内),以GFS、HDFS为代表的适用于流式访问大文件的分布式存储系统,若直接用来存储图片,由于元数据膨胀,在扩展性和性能方面均存在严重问题。

为了解决HDFS在小文件存储方面的问题,通常的做法是先将很多小文件合并成一个大文件再保存到HDFS,同时为这些小文件建立索引,以便进行快速存取。典型技术包括Hadoop自带的Archive、SequenceFile,但均需要用户自己编写程序,实现小文件的合并。为了实现小文件合并对用户的透明,需从系统层面解决HDFS小文件问题。论文针对具体应用场景进行了探索,但不具有通用性。与前面方案不改变HDFS本身不同,淘宝TFS对HDFS的元数据存储架构进行了调整。在元数据节点仅存放数据块与数据节点的映射,而将文件与数据块的映射关系保存到文件名,不再需要在元数据节点同时存放这两类映射,最终实现了系统层面解决小文件问题。但由于文件名包含数据块信息,为文件和数据块建立了强关系,导致数据块使用僵硬,TFS在文件的命名、移动方面带来新的问题,限制了其应用场景。

HBase是基于HDFS的简单结构化数据分布式存储技术,其可被用来存储海量图片小文件,并具有系统层小文件合并、全局名字空间等多种优势。但基于HBase的海量图片存储技术也存在一些问题。本文将介绍基于HBase的海量图片存储技术,并针对其问题给出改进方法。本文第1部分介绍了基于HBase的海量图片存储技术方案,并分析了原理及优势。第2部分介绍了该方案存在的问题及改进方法。第3部介绍了改进后方案的应用效果。第4部分总结全文,并指明下一步工作。

一、基于HBase的海量图片存储技术

Google利用BigTable来存储网页快照及属性信息,来支持网页搜索。受此启发,在HBase中用同样的方法来存储图片及其属性信息。具体方法即建立一张大表,用一个单独的列簇存储图片内容,用其他列簇存储图片的类型、大小、创建时间、修改时间等标准属性及应用相关的属性信息。HBase的列簇划分除了考虑逻辑关系外,还需考虑数据类型,即将逻辑关系相近且数据类型相同的作为一个列簇。大表的具体设计如表1所示。

表1:基于HBase的海量图片存储技术的大表设计

HBase是采用面向列的存储模型,按列簇来存储和处理数据,即同一列簇的数据会连续存储。HBase在存储每个列簇时,会以Key-Value的方式来存储每行单元格(Cell)中的数据,形成若干数据块,然后把数据块保存到HFile中,最后把HFile保存到后台的HDFS上。由于用单元格(Cell)存储图片小文件的内容,上述存储数据的过程实际上隐含了把图片小文件打包的过程。

搭建HBase集群后,采用上面设计的大表即可存储海量图片。但由于HBase存在数据块限制,还需要根据应用进行调整。默认情况下,HBase数据块限制为64KB。由于图片内容作为单元格(Cell)的值保存,其大小受制于数据块的大小。在应用中需根据最大图片大小对HBase数据块大小进行修改。具体修改方法是在表创建时,用HColumnDescriptor指定数据块大小,可分列簇指定,具体配置代码如下。

代码1:用HCoIumnDescriptor将数据块限制调整为512KB

图1 配置代码

上述基于HBase的海量图片存储技术具有如下优点:

(1)通过将图片属性信息与图片内容存储到一个大表中,可支持图片的多属性综合查询。此外,还可以根据应用需求,对列簇进行扩展以保存应用相关信息,从而支持应用相关的图片查询。可见,基于HBase的海量图片存储技术不仅解决了图片存储,还实现了灵活的图片检索。

(2)HBase隐含了小文件打包过程,无需进行二次开发即实现了系统层小文件合并。

(3)HBase采用分布式B+树对图片元数据进行全局统一管理,实现了全局名字空间,方便了对图片的管理。

二、基于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的时间顺序合并切片,即可恢复出原始图片。

三、应用效果

某市交通管理部门拟建立一套城市交通监控系统,在辖区各路口安装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后台处理图片打包,避免了二次开发。系统架构统一、简单,易管理维护;智能检索。支持根据图片文件的多个属性进行综合检索;智能纠错。可自动发现文件读写错误,并进行纠正。

四、结束语

本文设计并实现了基于HBase的海量图片存储技术方案,实现了系统层小文件合并、全局名字空间、并具有良好的通用性;通过对HFile Key-Value字节数组结构的完善,实现了图片读取时的自动纠错,提高了系统可靠性。系统在某城市监控系统的设计中得到验证。由于HBase采用分布式B+树存储图片内容元数据,使得读操作在定位图片数据的时候必须经历多次网络延迟,影响了图片数据的读取性能,下一步将研究该问题的改进方法。

时间: 2024-10-09 22:34:28

一种基于HBase韵海量图片存储技术的相关文章

海量图片存储--MogileFS分布式存储集群的实现

分布式存储 当下互联网飞速发展,海量并发所产生的数据量以几何方式增长,随着信息链接方式日益多样化,数据存储的结构也发生了变化,在这样的压力下我们不得不重新审视大量数据的存储所带来的挑战,比如:数据采集.数据存储.数据搜索.数据共享.数据传输.数据分析.数据可视化等一些列问题 传统存储在面对海量数据存储时已经力不从心,比如纵向扩展受阵列空间限制.横向扩展受交换设备限制.节点受文件系统限制 分布式存储的出现在在一定程度上缓解了这一问题 分布式存储基础介绍 (一)多线程与进程的执行模式 #互不通信的多

基于HBASE的并行计算架构之rowkey设计篇

1.大数据在HBASE存储.计算以及查询的应用场景 海量数据都是事务数据,事务数据都是在时间的基础上产生的.数据的业务时间可能会顺序产生,也可能不会顺序产生,比如某些事务发生在早上10点,但是在下午5点才结束闭并生成出来,这样的数据就会造成存储加载时的时间连续性.另外海量数据的挖掘后产生的是统计数据,统计数据也有时间属性,统计数据如果进行保存必须保证在统计计算之后数据尽量不再变化,如果统计发生后又有新的事务数据产生,那么将重新触发统计计算然后重新保存覆盖原有已经存储的数据.其它数据则主要是以配置

基于Hadoop2.0、YARN技术的大数据高阶应用实战(Hadoop2.0\YARN\Ma

Hadoop的前景 随着云计算.大数据迅速发展,亟需用hadoop解决大数据量高并发访问的瓶颈.谷歌.淘宝.百度.京东等底层都应用hadoop.越来越多的企 业急需引入hadoop技术人才.由于掌握Hadoop技术的开发人员并不多,直接导致了这几年hadoop技术的薪水远高于JavaEE及 Android程序员. Hadoop入门薪资已经达到了8K以上,工作1年可达到1.2W以上,具有2-3年工作经验的hadoop人才年薪可以达到30万—50万. 一般需要大数据处理的公司基本上都是大公司,所以学

(转)基于即时通信和LBS技术的位置感知服务(二):XMPP协议总结以及开源解决方案

在<基于即时通信和LBS技术的位置感知服务(一):提出问题及解决方案>一文中,提到尝试使用XMPP协议来实现即时通信.本文将对XMPP协议框架以及相关的C/S架构进行介绍,协议的底层实现不再本文的讨论范围. 一.什么是XMPP? 介 绍XMPP之前,我们先来聊聊GTalk.GTalk是Google推出的IM(Instant Messaging,即时通讯)软件,类似于QQ和MSN.从技术角度来说,GTalk与QQ和MSN的差异是使用了不同的通讯协议,QQ使用了自己的私 有协议(未公开),MSN也

基于HBase的冠字号查询系统2--实现部分

1. 软件版本和部署 maven:3.3.9,jdk:1.7 ,Struts2:2.3.24.1,hibernate:4.3.6,spring:4.2.5,MySQL:5.1.34,Junit:4,Myeclipse:2014: Hadoop2.6.4,HBase1.1.2 源码下载:https://github.com/fansy1990/ssh_v3/releases 部署参考:http://blog.csdn.net/fansy1990/article/details/51356583 数

16种基于 CSS3 &amp; SVG 的创意的弹窗效果

在去年,我给大家分享了<基于 CSS3 的精美模态窗口效果>,而今天我要与大家分享一些新鲜的想法.风格和趋势变化,要求更加适合现代UI的不同的效果.这组新模态窗口效果包含了一些微妙的动画,还有一些应用了SVG变形技术. 在线演示      源码下载 您可能感兴趣的相关文章 网站开发中很有用的 jQuery 效果[附源码] 分享35个让人惊讶的 CSS3 动画效果演示 十分惊艳的8个 HTML5 & JavaScript 特效 Web 开发中很实用的10个效果[源码下载] 12款经典的白

(转)基于即时通信和LBS技术的位置感知服务(一):提出问题及解决方案

一.前言.提出问题 公司最近举行2011年度创新设计大赛,快年底了正打算写写2010年以来Android开发的心得与经验,正好同事出了个点子:假如A和B两个人分别在不同的地点,能不能实现这样的功能,让A和B之间可以互相感知对方的位置信息. 于是整理了一下思绪,说白了分解开来就是两个方面的问题:一.实现信息的即时传递,二.实现基站/wifi.GPS的定位. 1. 实现消息的即时传递:说到这个问题大家应该能联想到QQ.MSN.Gtalk这些即时通信软件. 2. 定位:这个让人联想到时下非常火的LBS

HQueue:基于HBase的消息队列

HQueue:基于HBase的消息队列 凌柏 ?1. HQueue简介 HQueue是一淘搜索网页抓取离线系统团队基于HBase开发的一套分布式.持久化消息队列.它利用HTable存储消息数据,借助HBase Coprocessor将原始的KeyValue数据封装成消息数据格式进行存储,并基于HBase Client API封装了HQueue Client API用于消息存取. HQueue可以有效使用在需要存储时间序列数据.作为MapReduce Job和iStream等输入.输出供上下游共享

一种基于uCos-II操作系统和lwIP协议栈的IEEE-1588主站以及基于该主站的报文处理方法

本发明公开了一种基于uCos‐II操作系统和lwIP协议栈的IEEE‐1588主站以及应用于电力系统的支持IEEE‐1588协议的主时钟(IEEE‐1588主站)的实现方法.该方法是在一个低成本的硬件平台上,借助uCos‐II操作系统和TCP/IP的协议栈,对以太网数据进行了分类处理,实现了在同一个以太网端口提供基于二层和三层报文交换的IEEE‐1588的主站功能.另外,通过使用不同的操作系统进程来处理E2E和P2P对时,实现了两种对时模式在同一端口上的共存. 技术领域 [0001] 本发明属于