UDN-企业互联网技术人气社区

板块导航

浏览  : 1431
回复  : 0

[运维] 业内公认难题,如何解决小文件存储

[复制链接]
小辫儿的头像 楼主
发表于 2016-9-12 10:32:03 | 显示全部楼层 |阅读模式
  背景:

  当今互联网,数据呈现爆炸式增长,社交网络、移动通信、网络视频、电子商务等各种应用往往能产生亿级甚至十亿、百亿级的海量小文件。由于在元数据管理、访问性能、存储效率等方面面临巨大的挑战,海量小文件问题成为了业界公认的难题。

  业界的一些知名互联网公司,也对海量小文件提出了解决方案,例如:著名的社交网站Facebook,存储了超过600亿张图片,专门推出了Haystack系统,针对海量小图片进行定制优化的存储。

  白山云存储CWN-X,针对小文件问题,也推出独有的解决方案,我们称之为Haystack_plus。该系统提供高性能数据读写、数据快速恢复、定期重组合并等功能。

  Facebook的Haystack简介:

  Facebook的Haystack对小文件的解决办法是合并小文件。将小文件数据依次追加到数据文件中,并且生成索引文件,通过索引来查找小文件在数据文件中的offset和size,对文件进行读取。

  Haystack的数据文件部分:
19.png


  Haystack的数据文件,将每个小文件封装成一个needle,包含文件的key、size、data等数据信息。所有小文件按写入的先后顺序追加到数据文件中。

  Haystack的索引文件部分:
18.png


  Haystack的索引文件保存每个needle的key,以及该needle在数据文件中的offset、size等信息。程序启动时会将索引加载到内存中,在内存中通过查找索引,来定位在数据文件中的偏移量和大小。

  面临的问题:

  Facebook的Haystack特点是将文件的完整key都加载到内存中,进行文件定位。机器内存足够大的情况下,Facebook完整的8字节key可以全部加载到内存中。

  但是现实环境下有两个主要问题:

  1.存储服务器内存不会太大,一般为32G至64G;

  2.小文件对应的key大小难控制,一般选择文件内容的MD5或SHA1作为该文件的key。

  场景举例:

  一台存储服务器有12块4T磁盘,内存为32GB左右。

  服务器上现需存储大小约为4K的头像、缩略图等文件,约为10亿个。

  文件的key使用MD5,加上offset和size字段,平均一个小文件对应的索引信息占用28字节。

  在这种情况下,索引占用内存接近30GB, 磁盘仅占用4TB。内存消耗近100%,磁盘消耗只有8%。

  所以索引优化是一个必须要解决的问题。

  Haystack_plus:

  Haystack_plus的核心也由数据文件和索引文件组成。

  1. Haystack_plus的数据文件:
17.png

  与Facebook的Haystack类似,Haystack_plus将多个小文件写入到一个数据文件中,每个needle保存key, size, data等信息。

  2. Haystack_plus的索引文件:
16.png

  索引是我们主要优化的方向:

  1. 索引文件只保存key的前四字节,而非完整的key;

  2. 索引文件中的offset和size字段,通过512字节对齐,节省1个字节;并根据整个Haystack_plus数据文件实际大小计算offset和size使用的字节数。

  3. Haystack_plus的不同之处:

  数据文件中的needle按照key的字母顺序存放。
15.png

  由于索引文件的key,只保存前四字节,如果小文件key的前四字节相同,不顺序存放,就无法找到key的具体位置。可能出现如下情况:
14.png

  例如:用户读取的文件key是0x ab cd ef ac ee,但由于索引文件中的key只保存前四字节,只能匹配0x ab cd ef ac这个前缀,此时无法定位到具体要读取的offset。

  我们可以通过needle顺序存放,来解决这个问题:
13.png

  例如:用户读取文件的key是0x ab cd ef ac bb,匹配到0x ab cd ef ac这个前缀,此时offset指向0x ab cd ef ac aa这个needle,第一次匹配未命中。

  通过存放在needleheader中的size,我们可以定位0x ab cdef ac bb位置,匹配到正确needle,并将数据读取给用户。

  4. 索引搜索流程为:
12.png


  问题:

  我们应用折半查找算法在内存查找key ,时间复杂度为O(log(n)),其中n为needle数目。索引前缀相同时,需要在数据文件中继续查找。此时访问的文件不存在时,容易造成多次IO查找。

  解决方法:

  在内存中,将存在的文件映射到 bloomfilter中。此时只需要通过快速搜索,就可以排除不存在的文件。
11.png


  6. 前缀压缩,效果如何:

  与Facebook Haystack对内存消耗:

  场景举例:

  文件(如:头像、缩略图等)大小4K,key为MD5

  Facebook的Haystack:

  key: 使用全量的key,为16字节。

  offset, size:needle为追加写入,因此offset和size大小固定,offset为8字节,size为4字节。

  Haystack_plus:

  key: 使用key的前4字节,为4字节。

  offset: 根据Haystack_plus数据文件的地址空间计算字节数,并按512字节对齐,为 4字节。

  size: 根据实际文件的大小计算字节数,并按512对齐,为1字节。
10.png

  从上图可以看出在文件数量为10亿的情况下,使用Facabook的Haystack消耗的内存超过26G,使用Haystack_plus仅消耗9G多内存,内存使用降低了2/3。

  7.索引优化根本就停不下来:

  10 亿 个4K小文件,消耗内存超过9G。

  Key占用4字节,Offset占用4字节,还需要再小一些。

  下面介绍索引分层:
9.png

  根据文件key的前缀,进行分层,相同的前缀为一层。

  分层的好处:

  (1)减少key的字节数:
8.png


  (2)减少offset的字节数:
6.png

  优化前的offset,偏移范围为整个Haystack_plus的数据文件的地址空间。

  优化后,只需在数据文件中的层内进行偏移,根据最大的层地址空间可以计算所需字节数,

  分层后的效果:
7.png

  从上图可以看出,进行分层后,内存消耗从优化前的9G多,降低到4G多,节省了一半的内存消耗。

  Haystack_plus整体架构:

  1.Haystack_plus组织:
5.png

  每台服务器上,我们将所有文件分成多个group,每个group创建一个Haystack_plus。系统对所有的Haystack_plus进行统一管理。

  读、写、删除等操作,都会在系统中定位操作某个Haystack_plus,然后通过索引定位具体的needle,进行操作。

  2.索引组织
4.png

  之前已经介绍过,所有needle顺序存放,索引做前缀压缩,并分层。

  3.文件组成:
3.png

  chunk文件: 小文件的实际数据被拆分保存在固定数量的chunk数据文件中,默认为12个数据块;

  needle list文件: 保存每个needle的信息(如文件名、offset等);

  needle index 和layerindex文件: 保存needle list在内存中的索引信息;

  global version文件: 保存版本信息,创建新version时自动将新版本信息追加到该文件中;

  attribute文件: 保存系统的属性信息(如chunk的SHA1等);

  original filenames: 保存所有文件原始文件名。

  (1)Haystack_plus数据文件被拆分为多个chunk组织,chunk1,chunk2,chunk3 ….

  (2)分成多个chunk的好处:

  数据损坏时,不影响其它chunk的数据;

  数据恢复时,只需恢复损坏的chunk。

  (3)每个chunk的SHA1值存放在attribute文件中。

  4.版本控制:

  由于needle在数据文件中按key有序存放,为不影响其顺序,新上传的文件无法加入Haystack_plus,而是首先被保存到hash目录下,再通过定期自动合并方式,将新文件加入到Haystack_plus中。

  合并时将从needle_list文件中读取所有needle信息,将删除的needle剔除,并加入新上传的文件,同时重新排序,生成chunk数据文件、索引文件等。

  重新合并时将生成一个新版本Haystack_plus。版本名称是所有用户的文件名排序的SHA1值的前4字节。

  每半个月系统自动进行一次hash目录检查,查看是否有新文件,并计算下所有文件名集合的SHA1,查看与当前版本号是否相同,不同时说明有新文件上传,系统将重新合并生成新的数据文件。

  同时,系统允许在hash目录下超过指定的文件数时,再重新创建新版本,从而减少重新合并次数。
2.png

  版本的控制记录在global_version文件中,每次创建一个新版本,版本号和对应的crc32将追加到global_version文件(crc32用于查看版本号是否损坏)。

  每次生成新版本时,自动通知程序重新载入索引文件、attribute文件等。

  5.数据恢复:

  用户的文件将保存成三副本存放,因此Haystack_plus也会存放在3台不同的机器上。

  恢复场景一:
1.png

  当一个Haystack_plus的文件损坏时,会在副本机器上,查找是否有相同版本的Haystack_plus,如果版本相同,说明文件的内容都是一致,此时只需将要恢复的文件从副本机器下载下来,进行替换。

  恢复场景二:
2.png

  如果副本机器没有相同版本的Haystack_plus,但存在更高版本,那此时可以将该版本的整个Haystack_plus从副本机器上拷贝下来,进行替换。

  恢复场景三:
2.png

  如果前两种情况都不匹配,那就从另外两台副本机器上,将所有文件都读到本地上的hash目录下,并将未损坏的chunk中保存的文件也提取到hash目录下,用所有文件重新生成新版本的Haystack_plus。

  Haystack_plus效果如何:

  在使用Haystack_plus后一段时间,我们发现小文件的整体性能有显著提高,RPS提升一倍多,机器的IO使用率减少了将近一倍。同时,因为优化了最小存储单元,碎片降低80%。

  使用该系统我们可以为用户提供更快速地读写服务,并且节省了集群的资源消耗。

原文作者:陈闯 来源:运维帮


相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部