从Hadoop提供静态文件

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

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

必须是分布式的（水平规模），因为数据的总大小非常大

主要通过HTTP提供小型静态文件（如图像、缩略图、短视频）

一般情况下，不需要处理数据（因此不需要MapReduce）

对数据设置HTTP访问很容易

（应该有）良好的吞吐量 我正在考虑：

本机网络文件系统：但似乎不可行，因为数据不能装入一台机器

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

莫吉列夫斯。这看起来很有希望，但我觉得使用MySQL管理本地文件（在一台机器上）会产生太多的开销

---

有什么建议吗？

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

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

在“Hadoop Summit 2011”中，Karthik Ranganathan谈到了Facebook消息，他在其中透露了这一点：Facebook通过HDFS存储数据（个人资料、消息等），但他们在图像和视频中不使用相同的infra。他们有自己的系统，以图像命名。它不是开源的，但是他们分享了关于它的抽象设计级别的细节

---

这让我想到了：一个以Haystacks的设计为灵感的开源项目。它专为存储文件而定制。到目前为止我还没有使用过它，但似乎值得一试。

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

---

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

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

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

希望这有帮助

---

我是《野草》的作者。对于您的需求，WeedFS是理想的选择。Hadoop不能处理很多小文件，除了您的原因，每个文件都需要在主文件中有一个条目。如果文件数量很大，hdfs主节点无法扩展

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

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

weed upload -dir=/some/directory

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

---

我想您需要使用数据中心、机架感知等进行复制。它们现在已经存在

嗨，Chris，我一直在探索分布式fs的可用选项，以便为图像和杂草提供更好的服务。我想知道在weed中转储文件而不将其组织到文件夹中是否有任何缺点。我是新来的，没有太多的信息，这就是我直接联系你的原因。急切地等待你的答复。另外，请给我一个配置xml的示例。我使用的是ubuntu、jdk-8，通过一个由zhangxuYou编写的java客户端连接。您需要有一个地方来存储上传文件生成的文件ID。如果需要遍历文件夹，可能还可以将文件夹与文件ID一起存储。或者您可以使用杂草fs文件管理器。