如何及时处理数TB的数据

Question

声明

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

场合

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

组成

包含以下内容的目录：

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

所以最后我有一个包含大量小文件的大型目录树。

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

过去我只是运行了Perl转换脚本和导入过程的几个实例，以实现某种程度的并行化。现在有了这个3 TB，我怀疑这个规模会很好。

硬件方面我有6台物理机可供我使用，我可以使用有限数量的轻量级VM（特定的Solaris区域）。我说“数量有限”，因为这些机器已经运行了带有服务的虚拟机。

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

问题

我怎样才能明智地解决这个问题？有专门的解决方案吗？我开始研究Hadoop，虽然我仍然需要处理它对我的问题有何帮助。

我可以在Perl格式化脚本中构建线程，我可以运行它的几个实例来处理目录树的不同部分。这部分我完全受到控制。

我无法控制的部分是软件包的导入者 - 我只能创建其他实例并观看它们。

任何关于如何处理此问题的建议都将受到赞赏。

Answer 1

1. 估算导入器进行元数据处理和二进制文件处理的时间。
2. 识别瓶颈（夺走大部分处理时间） - 进口商？
3. 通过VM复制/增加瓶颈资源（导入程序）？
4. 编写一个脚本（Controler）来控制每个VM的进程和脚本（Worker）。 Controler将解析元数据（如果需要则平行）并将下一部分工作发送给Workers（通过小配置文件或通过TCP / IP协议）。
5. 或者您可以在没有Control脚本的情况下使用分布式方法，但这将更难实现。

我认为Hadoop会有点矫枉过正。