从Hadoop提供静态文件

Question

我的工作是为静态图像/视频文件设计分布式系统。数据大小约为数十TB。它主要用于HTTP访问（因此不对数据进行处理;或者只进行简单的处理，例如调整大小 - 但这并不重要，因为它可以直接在应用程序中完成）。

为了更清楚一点，这是一个系统：

1. 必须分布（水平刻度），因为数据的总大小非常大。
2. 主要通过 HTTP 提供小型静态文件（如图片，缩略图，短片）。
3. 通常，不需要处理数据（因此不需要MapReduce）
4. 可以轻松完成对数据的HTTP访问。
5. （应该）良好的吞吐量。

我在考虑：

1. 原生网络文件系统：但似乎不可行，因为数据无法放入一台机器中。

2. Hadoop文件系统。之前我使用过Hadoop mapreduce，但我没有使用Hadoop作为HTTP请求的静态文件存储库的经验。所以我不知道它是否可行或是否是推荐的方式。

3. MogileFS。这似乎很有希望，但我觉得使用MySQL来管理本地文件（在一台机器上）会产生太多的开销。

有什么建议吗？

Answer 1

我是Weed-FS的作者。根据您的要求，WeedFS是理想的选择。 Hadoop无法处理很多小文件，除了你的原因，每个文件都需要在master中有一个条目。如果文件数量很大，则hdfs主节点无法扩展。

使用最新的Golang版本编译时，Weed-FS的速度越来越快。

最近对Weed-FS进行了许多新的改进。现在，您可以使用内置的上传工具轻松进行测试和比较。这个文件在目录下递归上传所有文件。

weed upload -dir=/some/directory

现在您可以通过“du -k / some / directory”来查看磁盘使用情况，并通过“ls -l / your / weed / volume / directory”来查看Weed-FS磁盘使用情况。

我想你需要复制数据中心，机架识别等等。他们现在就在这里！

Answer 2

Hadoop针对大型文件进行了优化，例如它的默认块大小为64M。许多小文件既浪费又难以在Hadoop上管理。

您可以查看其他分布式文件系统，例如GlusterFS

Answer 3

Hadoop有一个用于访问文件的rest API。请参阅文档中的this条目。我觉得Hadoop不适合存储大量的小文件。

• HDFS无法有效地访问小文件：它主要用于大型文件的流式访问。通过小文件读取通常会导致大量的搜索和从datanode到datanode的大量跳转，以检索每个小文件，所有这些都是低效的数据访问模式。
• HDFS中的每个文件，目录和块都表示为namenode内存中的一个对象，每个对象占用150个字节。块大小为64 MB。所以即使文件是10kb，也会分配一个64 MB的整个块。这是一个废物磁盘空间。
• 如果文件非常小并且有很多文件，那么每个地图任务处理的输入都很少，而且还有更多的地图任务，每个任务都会增加额外的簿记开销。将1GB文件分成16个64MB块文件和10,000个左右100KB文件。 10,000个文件每个使用一个映射，并且作业时间可能比具有单个输入文件的等效文件慢几十或几百倍。

在“2011年Hadoop峰会”中，Karthik Ranganathan发表了this talk关于Facebook Messaging的文章，他放弃了这一点：Facebook将数据（个人资料，消息等）存储在HDFS上，但他们没有使用相同的基础设施图像和视频。他们有自己的系统名为Haystack用于图像。它不是开源的，但是他们分享了关于它的抽象设计级细节。

这让我想到了weed-fs：一个受Haystacks设计灵感启发的开源项目。它的定制用于存储文件。我到现在还没用过它，但似乎值得一试。

Answer 4

如果您能够批量处理文件并且在添加到HDFS后无需更新批处理，则可以将多个小文件编译为单个较大的二进制序列文件。这是一种在HDFS中存储小文件的更有效方法（正如Arnon指出的那样，HDFS是为大文件设计的，在处理小文件时变得非常低效）。

这是我在使用Hadoop处理CT图像时采用的方法（详见Image Processing in Hadoop）。在这里，225片CT扫描（每个单独的图像）被编译成一个更大的二进制序列文件，用于长流读取到Hadoop进行处理。

希望这有帮助！