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

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

Haystack处理的图片数量：

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

如果使用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负责图片永久存储和图片元数据管理。使用逻辑卷和物理卷对应关系保证一个图片存储在三个物理卷上，解决图片高可靠。

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