海量文件处理方式——facebook开源的Haystack(一)

网友投稿 1023 2022-05-30

最近想研究下FusionInsight HD平台在大数据处理方面面对海量小文件场景自研的smallFS组件的原理,奈何文档太少(基本就是与hdfs和zookeeper关联的图,我想看smallFS自身的架构图和业务流程图),只能转而研究facebook开源的处理海量图片场景的组件Haystack。现在将研究结果汇总如下:

Haystack处理的图片数量:

总数据量2600亿张图片,共计20PB级数据。

海量小文件处理方式——facebook开源的Haystack(一)

如果使用HDFS存储这些图片的话,因为HDFS的Namenode用来存储元数据,元数据就是每张图片的索引,比如大小、存储位置等信息。2600亿张图片存在在namenode中就会产生2600亿个数据。而namenode存储在内存中,就算一个元数据块大小为32B,那么2600亿条数据也需要近76TB内存来存储!!!我们常用的服务器内存一般是64G,根本无法满足存储要求。针对这个问题,Haystack解决思路是将海量小文件拼装为大文件,然后将拼接后的大文件保存起来。同时,维护大文件和小文件之间的map。具体如下:

比如我们假设4M以下的文件就是小文件,那么我们可以将原本几K几十K的文件拼装。假设海量小文件大多是1KB的,那么拼接后的一个大文件就可以一次拼接4096个文件,相当于元数据压缩比为4096。

好了,我们回到Haystack的方案。Haystack假设 近期、常用的图片可以通过缓存CDN的方式解决用户访问,如下图所示

上面的流程可以这么理解:用户通过浏览器访问facebook图片,用户请求会先发到对应的web服务器,web服务器返回存放图片的CDN地址,然后浏览器再到CDN去访问图片,如果CDN刚好存储了该图片则直接返回给用户;如果没有,则到存储设备上访问,图片先缓存到CDN,再返回给用户。

上面是传统的、解决近期、常用图片访问场景的架构。

我们来看看Haystack在解决用户不常用图片访问速率的架构

上图展示了Haystack三个关键组件:Haystack Directory、Haystack Cache和Haystack store。

Haystack store负责图片永久存储和图片元数据管理。使用逻辑卷和物理卷对应关系保证一个图片存储在三个物理卷上,解决图片高可靠。

访问路径与先后顺序如下:

http://///

即先从CDN获取,如果没有再从Haystack Cache获取,如果也没有再从物理卷获取。每一级的效率逐级递减

------------------------------------------------------------------------

未完待续

CDN

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:ML之Clustering之K-means:K-means算法简介、应用、经典案例之详细攻略
下一篇:Java:retrofit2发送http网络请求
相关文章