在我的组织中，我们有一个分布在二十几台 Linux 机器上的处理和存储系统，可以处理超过 1PB 的数据。目前的系统非常临时；处理自动化和数据管理由独立机器上的一组大型 perl 程序处理。我正在寻找分布式处理和存储系统，以便更易于维护、通过复制均匀分布负载和数据，并增加磁盘空间和计算能力。
该系统需要能够处理数百万个文件，大小在 50 兆字节到 50 千兆字节之间。一旦创建，文件将不会被追加，只有在需要时才会被完全替换。客户需要通过 HTTP 访问这些文件以供下载。
目前，处理由 perl 脚本（我完全控制）自动完成，这些脚本调用一系列其他程序（我无法控制，因为它们是闭源的），本质上将一个数据集转换为另一个数据集。这里没有进行数据挖掘。
以下是我正在寻找的东西的简要列表：
可靠性：这些数据必须大约 99％ 的时间都可以通过 HTTP 访问，因此我需要某种可以在集群内进行数据复制的东西。
可扩展性：我希望能够轻松添加更多的处理能力和存储空间，并重新平衡整个集群的数据。
分布式处理：简单且自动化的作业调度和负载平衡，适合我上面简要描述的处理工作流程。
数据位置感知：不是严格要求但值得追求。由于数据和处理将在同一组节点上，我希望作业调度程序将作业调度到数据实际所在的节点上或靠近该节点的位置，以减少网络流量。
以下是我目前所看到的内容：
存储管理：
GlusterFS：看起来确实很棒，而且易于使用，但似乎没有办法确定文件实际驻留在哪个节点上，以便为作业调度程序提供提示。
GPFS：似乎是集群文件系统的黄金标准。除了像 glusterfs 一样的数据位置感知之外，它满足了我的大部分要求。
Ceph：目前似乎还不成熟。
分布式处理：
- Sun Grid Engine：我对此有丰富的经验，而且它相对容易使用（只要正确配置即可）。但 Oracle 对其控制力冷淡，似乎不再那么受欢迎。
两个都：
Hadoop/HDFS：乍一看，Hadoop 似乎非常适合我的情况。分布式存储和作业调度，这是我发现的唯一能够让我获得所需数据位置感知的东西。但我不喜欢 namename 成为单点故障。此外，我不确定 MapReduce 范例是否适合我的处理工作流类型。似乎您需要专门为 MapReduce 编写所有软件，而不是仅将 Hadoop 用作通用作业调度程序。
OpenStack：我读过一些相关资料，但我无法决定它是否适合我的问题。
有人能给我一些适合我的问题的技术意见或建议吗？任何建议或意见都将不胜感激。
谢谢！
答案1
听起来你已经基本了解了你需要的东西。现有的技术（GlusterFS、GPFS）具有你正在寻找的功能，但没有数据本地性功能。根据你对数据的处理方式，这可以内置到你的作业调度程序中。
在我看来，您需要在处理管道中构建一个索引阶段来确定数据局部性。这可以并行化，然后在数据库中重新序列化，尽管这一步可能是自定义代码（您比我更了解您的数据）。一旦有了数据局部性，打包工作节点的处理工作单元应该相当简单；首先为节点本地数据构建工作单元，然后为节点相邻数据构建工作单元（如果该概念适用于您的情况），最后在大多数处理完成但一些工作单元似乎需要很长时间并且它们的节点本地处理器正在忙于处理它们时使用全局上下文。
这是高层次的观点。更关注问题的本质。从你目前所说的来看，听起来你正在处理更大的数据块，并且出于带宽原因，你希望在本地存储上进行处理。我看到了一些选择：
第一个想法是，当数据从源中提取时，它会被复制到 Gluster/GPFS/任何分布式文件系统中。然后，运行我上面描述的索引过程。然后，当工作者处理数据时，处理后的数据集会报告给另一组服务器，该组服务器的作用是通过 HTTP 提供处理后的数据。报告方法甚至可以通过 HTTP PUT 完成，然后将数据放入另一个复制的文件系统。这种方法的缺点是它会存储两次数据（原始数据和修改后的数据），但我不知道你是否已经这样做了。这允许你将处理基础设施扩展到相当远的地方，同时保持你的客户端服务基础设施相当小。
第二种想法，如上所述，但当工作者完成工作单元的处理时，保存的数据将存储到 Gluster/GPFS/任何文件系统中。HTTP 服务器然后直接从这些存储库提供数据，但它们并不像处理节点那样关心节点本地。为此，最好有单独的客户端服务和处理网络来限制这些大型数据集的双重传输问题。
第三个想法，如果搞清楚 GPFS/Gluster 的数据局部性并不可行（我没有使用过它们，所以我不确定），您可能需要研究构建自己的存储类型。这需要大量工作，但如果您真的需要局部性，那么这对您来说可能是值得的。当您获取数据时，每个数据集都会在数据库中建立索引，并根据需要通过 HTTP PUT 发送到多个节点。在处理时，会为各个节点创建作业，这些作业首先针对它们自身的节点本地数据。当工作者收到作业时，它会从数据库指定的节点（应该是它自己，但不一定是）HTTP GET 数据。当工作完成后，它会通知数据库并接收有关将结果放在何处的指令。
为了向客户端提供处理过的数据集，您可能必须引入一些应用程序代码来转换文件以便从您的节点获取代理的 HTTP GET。
这确实以数据库的形式引入了高带宽部分。它可以在它前面有多个负载平衡的 Web 服务器来处理逻辑，但数据库本身最终会成为单点故障（尽管更了解数据库的人可能知道如何解决这个问题）。数据库本质上充当大型基于 HTTP 的文件系统的文件分配表。由于您的处理似乎需要非常简单的文件系统语义（获取/放置，可能锁定/解锁正在处理数据集的节点），可以通过这样的数据库进行调解。显然，这个数据库将非常大，因此出于性能原因，某些 NoSQL 技术可能更适合。
我知道这不是你正在寻找的特定技术，更多的是关于解决市场缺陷的技术。数据局部性和复制似乎是一种极端情况。碰巧的是，我们用较小的数据集做了类似的事情，所以这也是我考虑的一个话题。