从 Hadoop 提供静态文件

Question

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

说得更清楚一点，这是一个系统：

1. 必须是分布式的（横向尺度），因为数据的总规模非常大。
2. 主要通过 HTTP 提供小型静态文件（例如图像、缩略图、短视频）。
3. 通常不需要处理数据（因此不需要 MapReduce）
4. 可以轻松地设置对数据的 HTTP 访问。
5. （应该有）良好的吞吐量。

我正在考虑：

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

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

3. MogileFS。看起来很有希望，但我觉得使用 MySQL 来管理本地文件（在单机上）会产生太多开销。

有什么建议吗？

Answer 1

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

• HDFS 不适合高效访问小文件：它主要设计用于大文件的流式访问。读取小文件通常会导致大量搜索和从数据节点到数据节点的大量跳跃来检索每个小文件，所有这些都是低效的数据访问模式。
• HDFS 中的每个文件、目录和块都表示为 namenode 内存中的一个对象，每个对象占用 150 个字节。块大小为 64 MB。所以即使文件是 10kb，它也会被分配 64mb 的整个块。那是浪费磁盘空间。
• 如果文件非常小并且数量很多，那么每个 map 任务处理的输入非常少，并且有很多 map 任务，每个任务都会带来额外的簿记开销。比较一个 1GB 的文件分成 16 个 64MB 块的文件和 10,000 个左右 100KB 的文件。 10,000 个文件每个都使用一张地图，与使用单个输入文件的同等文件相比，作业时间可能会慢数十或数百倍。

在“2011 年 Hadoop 峰会”中，Karthik Ranganathan 发表了 this talk 关于 Facebook 消息传递的文章，其中他放弃了这一点：Facebook 在 HDFS 上存储数据（配置文件、消息等），但他们不使用相同的基础架构来存储图像和视频。他们有自己的图像系统，名为Haystack。它不是开源的，但他们分享了关于它的抽象设计级别的详细信息。

这让我想到了weed-fs：一个受 Haystacks 设计启发的开源项目。它是为存储文件量身定制的。到目前为止我还没有使用它，但似乎值得一试。

Answer 2

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

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

Answer 3

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

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

希望这会有所帮助！

G

Answer 4

我是 Weed-FS 的作者。对于您的要求，WeedFS 是理想的选择。 Hadoop不能处理很多小文件，除了你的原因，每个文件都需要在master中有一个入口。如果文件数量很大，hdfs master节点无法伸缩。

使用最新的 Golang 版本编译时，Weed-FS 变得更快。

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

weed upload -dir=/some/directory

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

我想您需要使用数据中心、机架感知等进行复制。它们现在就在里面！