HBase解决海量图片存储方案

随着互联网、云计算及大数据等信息技术的发展，越来越多的应用依赖于对海量数据的存储和处理，如智能监控、电子商务、地理信息等，这些应用都需要对海量图片的存储和检索。由于图片大多是小文件(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指定数据块大小，可分列簇指定，具体配置代码如下。

代码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后台处理图片打包，避免了二次开发。系统架构统一、简单，易管理维护；智能检索。支持根据图片文件的多个属性进行综合检索；智能纠错。可自动发现文件读写错误，并进行纠正。

4. 结束语

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

参考：https://blog.csdn.net/u010670689/article/details/33737989