从Hadoop提供静态文件

Question

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

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

1. 必须分布(水平比例尺)，因为数据的总大小非常大。
2. 主要通过HTTP提供小的静态文件(如图像、缩略图、短视频)。
3. 通常，不需要处理数据(因此不需要MapReduce )
4. 可以很容易地对数据设置HTTP访问。
5. (应该有)良好的吞吐量。

我正在考虑：

1. 本机网络文件系统:但似乎不可行，因为数据不能适应一台机器。
2. Hadoop文件系统。我以前使用过Hadoop，但我没有使用Hadoop作为HTTP请求的静态文件存储库的经验。所以我不知道这是可能的还是推荐的方法。
3. MogileFS。这看起来很有希望，但是我觉得使用MySQL来管理本地文件(在一台机器上)会造成太多的开销。

有什么建议吗？

Answer 1

我是“杂草-FS”的作者。对于您的需求，WeedFS是理想的。Hadoop不能处理很多小文件，除了您的原因之外，每个文件都需要在主文件中有一个条目。如果文件数量大，则hdfs主节点无法缩放。

当使用最新的Golang版本编译时，Weed正在变得更快。

最近在Weed上做了许多新的改进。现在，您可以很容易地测试和比较内置的上传工具。这个文件以递归方式上传到一个目录下。

weed upload -dir=/some/directory

现在，您可以通过"du -k /some/目录“来比较磁盘的使用情况，并通过"ls -l /your/Weed/音量/目录”来查看Weed磁盘的使用情况。

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

Answer 2

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

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

Answer 3

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

• HDFS并不适合高效地访问小文件:它主要是为大文件的流访问而设计的。读取小文件通常会导致大量的查找和从datanode到datanode的大量跳转来检索每个小文件，所有这些都是一种低效的数据访问模式。
• HDFS中的每个文件、目录和块都表示为namenode内存中的一个对象，每个对象占用150个字节。块体尺寸为64毫巴。因此，即使文件为10 mb，也会分配64 mb的整个块。那是个浪费的磁盘空间。
• 如果文件非常小，并且有很多这样的文件，那么每个映射任务处理的输入都非常少，并且有更多的映射任务，每个任务都会增加额外的簿记开销。将一个1GB的文件分解为16个64 so块的文件和大约10,000 so的文件进行比较。10,000个文件每个使用一个映射，作业时间可能比一个输入文件的等效文件慢几十倍或数百倍。

在“2011年哈多普峰会”中，卡蒂克·兰加纳坦( Karthik Ranganathan )的这次谈话讲述了Facebook消息传递的内容: Facebook通过HDFS存储数据(个人资料、信息等)，但它们在图片和视频中不使用相同的内容。他们有自己的系统，名为干草堆图像。它不是开源的，但是他们共享了抽象的设计层次的细节。

这让我想到了杂草-fs：一个受Haystack设计启发的开源项目。它为存储文件量身定做。我至今还没有用过它，但似乎值得一试。