目标
我需要为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） 如果没有，我想我必须制定一个内部解决方案。我该怎么开始？
呼。太多了。提前谢谢！