目标
我需要为 Web 应用程序实现文件存储和处理后端。该应用程序具有以下特征：
（#1）客户端将存储各种格式和大小的文件（可能在千兆字节范围内）
（#2）有时客户端需要自己检索文件
（#3）有时客户端需要检索输出数据（此处为“OD”），其中对先前存储的文件执行处理以生成 OD。重要提示：OD 大小通常是原始文件大小的一小部分——2GB 文件可能产生 1MB OD）。
(#4) 有时客户端会对文件应用转换（例如文件修补）。
考虑解决方案
我可以使用存储集群（例如 SAN）来实现#1 和#2，然后使用计算集群来实现#3 和#4。但是在 SAN 和计算集群之间传输大量数据（假设有 100 多个用户请求 OD 或修补文件）对我来说似乎不合适，特别是因为文件数据可能很大，而且大多数时候客户只需要小的 OD 或什么都没有（修补操作消耗客户端输入但不向客户端返回数据）。
所以我认为我需要一个节点集群，其中每个节点都是一个大数据节点和一个有能力的处理节点，以避免存储和处理集群之间的流量（因为现在它们是一个）。节点负责处理它存储的文件，从而避免网络带宽。如果一个节点碰巧处理请求超载，则该节点可能会将一些工作卸载到相邻节点（因此仍会产生带宽成本，但仅在必要时）。
问题
(1) Wikimedia 使用“文件服务器”和单独的“图像缩放器”服务器……但在我的情况下，我担心大的、不必要的带宽。我的担心是否合理，因此存储/处理节点的分离在我的情况下是否不合适？
(2) 我的方法（大存储集群+强大的处理节点）是否可取？或者我应该考虑不同的架构？
(2) 我考虑过 Hadoop，但不知道它是否适合这项任务（巨大的带宽成本，而且我并没有真正处理大数据）。此外，但如果 Hadoop 适合该任务，请说明原因。
(3) 是否有可用于管理这些服务器集群的开源/其他框架？
(4) 如果没有，我想我将不得不开发一个内部解决方案。我该如何开始？
唷。那是很多。提前致谢！