在我的组织中，我们有一个处理和存储系统，分布在二十几台Linux机器上，可处理超过1 PB的数据。 现在的系统是非常特殊的; 处理自动化和数据pipe理由一系列独立机器上的大型Perl程序处理。 我正在研究分布式处理和存储系统，以便于维护，通过复制平均分配负载和数据，并在磁盘空间和计算能力上增长。
系统需要能够处理数百万个文件，大小在50兆字节到50千兆字节之间。 一旦创build，文件将不会被追加，只有在需要时才被完全replace。 这些文件需要通过HTTP访问，以供客户下载。
现在，perl脚本（我完全控制了）调用了一系列其他程序（我没有控制权，因为它们是封闭的源代码），从本质上将一个数据集转换成另一个数据集。 没有数据挖掘发生在这里。
这里是我正在寻找的一个快速列表：
可靠性：这些数据必须能够在99％的时间内通过HTTP访问，所以我需要在集群中进行数据复制。
可伸缩性：我希望能够轻松添加更多处理能力和存储，并重新平衡整个群集中的数据。
分布式处理：简单和自动的作业调度和负载平衡，适合我上面简要描述的处理工作stream程。
数据位置感知：不是严格要求，而是可取的。 由于数据和处理将在同一组节点上，所以我希望作业调度程序在或靠近实际数据的节点上调度作业以减lessnetworkingstream量。
这是我迄今为止所看到的：
存储pipe理：
GlusterFS：看起来非常好，易于使用，但似乎没有办法找出文件实际驻留的节点，以提供给作业调度器。
GPFS：看起来像集群文件系统的黄金标准。 满足我的大部分要求，除了glusterfs，数据位置感知。
Ceph：现在似乎还不成熟。
分布式处理：
都：
Hadoop / HDFS：乍一看，hadoop看起来非常适合我的情况。 分布式存储和作业调度，这是我发现的唯一一件能够提供我想要的数据位置感知function的工具。 但是我不喜欢这个名字是一个单一的失败点。 另外，我不确定MapReduce范例是否适合我拥有的处理工作streamtypes。 您似乎需要专门为MapReduce编写所有软件，而不是将Hadoop用作通用作业调度程序。
OpenStack：我已经做了一些阅读，但是我很难判断它是否适合我的问题。
有没有人有意见或build议的技术，以适应我的问题呢？ 任何build议或意见将不胜感激。
谢谢！
听起来像你是最需要你的方式。 那里的技术（GlusterFS，GPFS）有你正在寻找的function，但不是数据本地的function。 根据您对数据的处理方式，这可能会内置到您的作业调度程序中。
对我来说，这听起来像你需要build立一个索引阶段到你的处理pipe道，确定数据的地方。 这可以并行化，然后在数据库中重新序列化，尽pipe这一步可能是自定义代码（您比我更了解您的数据）。 一旦拥有数据本地化，工作节点的打包处理工作单元应该相当简单; 首先为节点本地数据build立工作单元，然后build立节点邻接（如果这个概念适用于你的情况），最后是在大多数处理完成时使用的全局上下文，但是less数工作单元似乎要花费一定的时间他们的节点本地处理器正在忙着咀嚼它们。
这是一个高层次的观点。 把重点放在问题的螺栓上。 就目前为止你所说的话来看，这听起来像是你正在处理更大的数据块，并且你想要在本地存储上进行处理以获得带宽的原因。 我看到一些select：
第一个想法是，当数据从源头被摄入时，它会被复制到Gluster / GPFS /任何分布式文件系统中。 然后，运行我上面描述的索引过程。 然后，当工作人员处理数据时，处理过的数据集会被报告回另一组服务器，其angular色是通过HTTP提供处理后的数据。 报告返回方法甚至可以通过HTTP PUT来完成，然后将数据放到另一个复制的文件系统上。 这种方法的缺点是它存储你的数据两次（原始和修改），但我不知道这是你已经做的事情。 这使您可以在很大程度上扩展处理基础架构，同时保持客户端服务基础架构的规模。
第二个想法，如上所述，但是当工作人员完成一个工作单元的处理时，保存的数据被存储到Gluster / GPFS /任何文件系统。 然后，HTTP服务器直接从这些存储库提供数据，但它们不像处理节点那样关心节点本地。 为此，build立独立的客户服务和处理networking来限制这些大型数据集的双重运输问题可能是一个好主意。
第三个想法，如果搞清楚GPFS / Gluster的数据本地化是不是真的可行（我没有使用它们，所以我不知道），你可能想要build立自己的存储types。 这是很多的工作，如果你真的需要本地化，这可能是值得的。 在您提取数据时，每个数据集都会在数据库中进行索引，并根据需要将HTTP PUT分配给多个节点。 处理发生时，首先为自己节点本地的数据创build单个节点的作业。 当一个工作人员接收到一个作业时，它从数据库指定的节点（它应该是自己，但不一定是）获取数据。 工作完成后，它会通知数据库并收到有关将PUT结果放在哪里的说明。
为了向客户端提供处理过的数据集，您可能需要引入一些应用程序代码来转换文件，以便从您的节点获取代理HTTP GET。
这确实以该数据库的forms引入了高带宽部分的过程。 它可以在它之前有多个负载平衡的Web服务器用于处理逻辑，但是数据库本身最终会成为一个单点故障（尽pipe人们对数据库方式的了解更多，可能知道的方法） 。 数据库本质上充当基于HTTP的大型文件系统的文件分配表。 由于您的处理似乎需要非常简单的文件系统语义（读取/放置，可能locking/解锁正在处理数据集的节点），可以由这样的数据库调解。 显然这个数据库将会非常大，所以一些NoSQL技术可能更适合性能的原因。
我知道这不是你正在寻找的具体技术，而是关于解决市场缺陷的技术。 看来，数据局部性和复制是一个边缘案例。 碰巧，我们只是用较小的数据集做类似于你的事情，所以这也是我的想法。