Parallel processing 如何及时处理TB级的数据

免责声明

我是一家小商店的系统管理员

形势

我将接收大约3 TB的数据，其中每个逻辑单元由

包含以下内容的目录：

• 包含元数据的CSV格式的文本文件
• 包含实际数据的二进制文件

所以最后我有一个巨大的目录树，里面有很多小文件

我的工作是将元数据文件从CSV转换为XML。我通常使用Perl来处理这个问题。新创建的XML文件将与相应的二进制数据一起复制到一个新目录中，该目录将由封闭源代码软件包的导入程序读入。此导入过程本质上是串行的。它只是一个接一个地读取另一个目录并对其进行处理。越快越好

在过去，为了实现某种程度的并行化，我只运行了几个Perl转换脚本和导入过程的实例。现在随着这3 TB的到来，我怀疑它是否能很好地扩展

就硬件而言，我有6台物理机器供我使用，在这些机器上我可以启动有限数量的轻量级虚拟机（具体来说是Solaris区域）。我说“数量有限”，因为这些机器已经运行带有服务的虚拟机

最后一个限制：由于数据的敏感性，使用任何类型的云服务都是不可能的

问题

我怎样才能明智地处理这件事？。有专门的解决方案吗？我开始研究Hadoop，尽管我仍然需要弄清楚它如何帮助解决我的问题

我可以在Perl格式化脚本中内置线程，并且可以运行它的多个实例来处理目录树的不同部分。这部分我已经完全控制住了

我无法控制的部分是软件包的导入者——在那里，我仅限于创建额外的实例并看着它们缓慢地运行

任何关于如何处理这一问题的建议都将不胜感激

估计导入程序处理元数据和二进制文件的时间

识别瓶颈（占用大部分处理时间）-进口商

按VM复制/增加瓶颈资源（导入器）

为每个VM编写一个脚本（Controler）来控制进程和脚本（Worker）。Controller将解析元数据（如果需要，并行地），并将下一部分工作发送给工作人员（通过小配置文件或TCP/IP协议）

或者，您可以使用不带控制脚本的分布式方法，但这将更难实现

我认为Hadoop会被过度使用