Architecture 可扩展存储&x2B；处理集群（Hadoop是我需要的吗？）

目标
我需要为web应用程序实现文件存储和处理后端。应用程序具有以下特征：

（#1）客户端将存储各种格式和大小的文件（可能在GB范围内）
（#2）有时客户端需要检索文件本身
（#3）有时客户机需要检索输出数据（“OD”），其中对先前存储的文件执行处理以生成OD。重要提示：OD大小通常是原始文件大小的一小部分——2GB文件可能产生1MB OD）。
（#4）有时客户端会对文件应用转换（例如，文件修补）。

考虑解决方案
我可以使用存储集群（例如SAN）来实现#1和#2，然后使用计算集群来实现#3和#4。但是，在SAN和计算集群之间传输大量数据（想象一下，有100多个用户请求ODs或修补文件）对我来说并不合适，特别是因为文件数据可能很大，而且大多数时候客户端只需要少量ODs或什么都不需要（修补操作消耗客户端输入，但不会将数据返回到客户端）

因此，我认为我需要的是一个节点集群，其中每个节点都是一个大数据节点和一个有能力的处理节点，以避免存储和处理集群之间的通信量（因为现在它们是一个）。节点负责处理其存储的文件，从而避免网络带宽。如果一个节点碰巧因处理请求而过载，那么该节点可能会将一些工作卸载给相邻节点（因此仍然会产生带宽成本，但只有在必要时）

问题
（1） Wikimedia使用“文件服务器”和单独的“图像缩放”服务器……但就我而言，我担心的是不必要的大带宽。我的担心是否合理？因此，在我的情况下，存储/处理节点的分离是否不合适

（2） 我的方法（大存储集群+强大的处理节点）是否可取？或者我应该考虑一种不同的架构

（2） 我考虑过Hadoop，但不知道它是否适合这项任务（巨大的带宽成本，而且我并不真正处理大数据）。另外，如果Hadoop适合这个任务，请说明原因

（3） 是否有开源/其他框架可用于管理这些服务器集群

（4） 如果没有，我想我将不得不开发一个内部解决方案。我该怎么开始呢

---

呼。那太多了。提前谢谢

Hadoop并同时使用HDFS和MR可能是一个可行的解决方案。注意事项和 但考虑到：

在一般情况下，用于创建“OD”的算法可并行化吗？如果不是这样，您可能无法从数据局部性中获益，hadoop将把文件的数据从保存它的datanodes复制到执行处理的单个节点

使用mapreduce，您将无法在位修改文件。因此，您还必须考虑一个后处理步骤，其中将输出文件重命名为输入文件和其他此类事务处理。

管理/部署集群并不十分困难。查看Cloudera Manager和Hortonworks数据平台。这些将为您提供从部署到管理和监视的一切。但是，Cloudera产品的许可成本可能超过一定数量的节点。HDP对AFAIK没有此类限制

---

我认为Hadoop最接近我所需要的，尽管仍然存在文件处理和带宽方面的问题。谢谢