基于h a d oop的海量图片存储模型 的分析和设计


       截止至201 1年6月,Facebook用户已经上传了150亿张照片,加上缩略图,总容量超过1.5PB。此外,每周新增照片为2.2亿张,约25TB。高峰期,Facebook每秒处理55万张照片!国外最大的图片分享网站Flickr共存储4.7亿张图片,而且相当多的图片是高清数码图片,单张图片大小4-5M左右,消耗2PB存储空间,每秒需要处理38000次请求,每天新增图片超过40万。Flickr采用的squid缓存了总计3500万张图片,内存中存储有200万张图片。淘宝网作为我国最大的电子商务平台,在线商品达到10亿,图片服务器存储286亿张图片,总容量达到1PB,且每天仍在以千万级别增长。由于图片表达信息远胜于文字描述,所以电子商务尤其注重图片的显示质量、上传时问、访问速度等问题。根据淘宝网的流量分析,整个淘宝网流量中,图片的访问流量达到90%以上。腾讯的相册用户总上传图片数600亿存储量12PB、每周上传图片数10亿、存储3种规格1300亿图片,峰值访问每秒50万次。由于图片量非常大,海量图片需要消耗海量的存储空问,图片的存储和检索都会出现一定的瓶颈,存储系统的快速访问、扩容性、容错性都将是存储系统设计的目标。

       由此可见,面对海量的图片,如何高效的存储、管理这些图片已经成为一个迫切需要解决的问题。

       NetApp,美国网域存储技术有限公司,是IT存储业界的佼佼者,倡导向数据密集型的企业提供统一的存储解决方案,用以整合在网络上来自服务器的数据,并有效管理呈爆炸性增长的数据。大多数IT公司在面临海量数据存储问题的时候都会选择NetApp公司提供的商用存储系统,淘宝网2007前一直使用应用该公司的文件存储系统。但随着图片文件数量以每年2倍的速度增长,NetApp公司最高端的产品也不能满足淘宝网存储的要求。商业存储服务的不足有以下几点:
       首先是文件数量太大,网络存储设备无法支撑,连接存储系统的服务器越来越多,网络连接数已经达到了网络存储设备的极限。
       其次是商用存储系统不能根据企业特定的业务进行存储和读取优化,导致面对大规模的小文件存储与读取,磁盘磁头需要频繁的寻道和换道,造成读取上的延迟。再加上高并发访问量的背景,系统很容易出现问题。
      最后是花费问题,商业存储系统扩容成本太高,10T的存储容量需要几百万人民币。在面临海量存储需求的时候,高成本并没有带来高效率,高可靠性,高容错性。况且,过分依赖商业系统在维护性、创造性上受到商业公司约束,难以满足互联网企业的飞速发展。云计算的出现带动了技术发展朝向一个新的方向。它创造性的根据分布式处理、并行处理和网格计算的发展,提出了新的分布式集群技术。云存储概是在云计算概念上延伸和发展出来的一个新的概念,是指通过集群应用、网格技术或分布式文件系统等功能,将网络中大量各种不同类型的存储设备通过应用软件集合起来协同工作,共同对外提供数据存储和业务访问功能的一个系统。当云计算系统运算和处理的核心是大量数据的存储和管理时,云计算系统中就需要配置大量的存储设备,那么云计算系统就转变成为一个云存储系统,所以云存储是一个以数据存储和管理为核心的云计算系统。

        云存储的概念改变了存储领域,可以尝试以相对廉价的存储设备部署在云端作为存储服务器,利用分布式文件系统统一管理,对外提供存储和业务访问接口。由云端提供存储服务,达到业务与存储的解耦合,不仅能根据不同业务背景设定不同的存储、访问接口,优化存取服务,还能将容灾和安全性固定在云端,此外,由于采用分布式文件系统,云端服务器扩展相对容易。

        目前国内外在面对图片存储问题时,所采取的解决方案有两种,分别是图片保存至数据库和图片存储在硬盘。鉴于海量图片规模下,数据库承载太多图片会导致数据库容量和效率成为极大的瓶颈。常见的做法是图片保存至硬盘,数据库中保存图片的存储路径。分布式存储为海量图片存储提供了原始模型,一些研究成果和实践表明,图片存储架构需要从容量和负载两方面设计,且还要根据业务需求制定特定的缓存策略。容量方面,大部分的解决方案都是使用海量存储,比如专业的磁盘阵列,入门级的磁盘柜或者高级的光纤盘阵、局域网盘阵等。此外,在采用多台服务器存储的前提下,需要提供NFS的分区给前端应用使用,在前端应用的程序逻辑中加入控制图片存储在哪一台服务器的NFS分区,常用的根据用户id或者图片id,通过关键词的散列,到达同一类型图片存储在一台服务器,加快读取效率。基本上图片负载高的解决办法有两种,前端squid缓存和镜像,通过对存储设备使用镜像,可以分布到多台服务器上对外提供图片服务,然后再配合squid实现负载的降低和提高用户访问速度。这里我们采用Hadoop作为我们设计图片存储系统的基础,一方面是因为Hadoop开源的特性,方便我们根据业务需求做一些源代码方面的改善;令一方面,Hadoop可以部署在廉价的PC上,通过软件实现高容错性,符合图片存储业务发展的特性。Hadoop各方面都符合我们的项目需求,这使其成为我们确定的基础研究技术方向。同时我们采用Ngix+Redis做缓存策略,优化图片读取。

        存储系统架构

1、存储单元:采用Hadoop中的HDFS存储大、中、小图片,其中小图片采用打包策略存储,并且提供监控管理界面,查看各个节点存储空问运行状态。通过HDFS的冗余备份和心跳检测保证存储数据的安全性,通过设定负载均衡策略,保证各个存储节点的运行稳定。
2、图片索引:将图片名和图片元数据作为键值对<Key,Value>,放入HBase中存储,并且进行数据查询,避免图片重复存储,便于将来管理。
3、采用MapReduce进行图片业务处理的编程实现,针对大数据上传后的批量处理和存储优化制定相应策略。
4、W曲服务:采用Nginx.0.9.6做图片的web服务器,对网站的大、中、小图片进行读取,加上Nginx的Redis模块对缓存中的微型图片进行读取。
5、缓存服务器:存储网站的微型图片,签名照,小头像,表情图片,通过Nginx的Redis模块直接读取,通过调用Redis的JavaAPI程序对数据进行写入。
6、负载均衡:HAproxy采用RoundRobin负载均衡算法,分载前端用户请求的压力到每个web图片服务器上。 

7、应用服务器:对图片写入的操作全部由Java应用服务器完成。

       存储系统写流程

图片写请求由用户发起后,通过负载均衡模块的过滤,首先来到应用服务器排队等待进入HDFS存储系统,通过NameNode分配DataNode进行存储,图片写入过程中先确定写入Block,再确定Sequence File,系统将二者的ID组合命名为图片的系统内的名称。图片元数据保存在HBase,同时元数据也保存在由Redis构建的缓存系统中。

Hadoop是为解决大文件存储、大任务处理而生的分布式架构,作为图片存储业务中的图片一般大小小于Hadoop的设计要求,这里我们通过合并小文件实现基于Hadoop的海量图片存储系统的设计,并采取了优化,总结如下:
1、通过HA的架构对NameNode进行了热备份,采用heartbeat3实现心跳检测判断NameNode健康状况,解决了NameNode单点的安全隐患。
2、针对图片的大小,对大图片采取并行读取,提高了大图片存取效率,且还能通过配置文件的修改动态更改图片大小设定。通过Sequence实现对小图片的合并,并在合并过程中设定单个Sequence File的偏移量,加快图片的访问。
3、设计了图片URL,将图片存储信息设定在图片URL中,通过解析URL快速定位存储图片Block的DataNode和Fileld。将图片元数据存放在HBase中,解决海量数据扩容和快速检索的问题。
4、使用了Redis和HAProxy构建缓存区和负载均衡,使整个系统达到稳定健康状态。


相关内容