Java 将数据并行加载到hdfs中

我有一个由3个节点组成的Hadoop集群。我想尽快将一个180 GB的文件加载到HDFS中。我知道-put和-copyFromLocal都不会在这方面帮助我，因为它们是单线程的

我在考虑地图/缩小。是否有办法将加载过程分发到节点本身。因此，每个节点将加载文件的一部分，例如每个60 GB。我不想在每个节点上手动执行此操作（这违背了目的）。如果有办法使用Java和Map/Reduce实现这一点，我很想了解一下。我知道Hadoop可以处理通配符输入文件。假设每个60GB块的名称如下：file_1、file_2、file_3..然后我就可以在下一个MR作业中使用file_*了。我遇到的麻烦是理解如何以快速/多线程的方式高效地首先将文件加载到hadoop中

提前谢谢

编辑：

distcp-似乎正在并行复制到HDFS中，但仅在集群之间，而不是集群内。我想知道为什么他们没有想到这一点，如果他们想到了，围绕这一点的限制或瓶颈是什么。

---

似乎还围绕这个主题记录了基准测试，但他们使用DMExpress（商业工具）来进行加载。如果有一个开源的替代方案，那就太好了。

根据您的配置，我不知道写操作的并行化是否会提高性能，因为您想写一个文件

假设我们有默认配置。默认复制系数为3，因此当文件的每个块都写入集群的3台计算机（在您的情况下，在集群的所有计算机中）时，您的文件被视为已写入

如果您的每台计算机有多个磁盘，则只有当您的应用程序是唯一使用群集的应用程序并且您不受网络限制时，将文件划分为最小部分（作为一台计算机上HDFS使用的磁盘的一部分）才有助于提高写入性能。在这种情况下，瓶颈是磁盘

如果您可以在客户机上管理分割的文件，确保文件的所有部分都复制到HDFS上的一种简单方法是创建一个目录，该目录是您的文件名，并带有一个后缀，表示该文件处于复制状态。此目录包含文件的所有部分。当所有复制线程完成后，您可以重命名目录而不使用后缀。只有在删除后缀后，您的客户端才能访问文件的所有部分。重命名由Namenode上的元数据中的操作组成。与文件复制相比，重命名是最快的操作

其他解决方案：

• 使用标记文件不是最佳选择，因为您会丢失一个HDFS块（默认块大小为128 MB）
• 从文件的各个部分重新创建文件类似于重写数据，因此效率低下

---

如果你从一个硬盘上读取180gb的文件，我怀疑你能比按顺序读取快得多，因为HDD是瓶颈。MapReduce映射程序如何访问单个服务器本地磁盘上的内容？我希望你们明白为什么他们不把这个添加到distcp中，因为这毫无意义（没有加速，磁盘和网络是有限的，这就是无法扩展）。