使用spark在hadoop集群上复制数据

Question

我有一种情况，我必须将数据/文件从PROD复制到UAT（hadoop群集）。 为此，我现在使用'distcp' 。 但这是永远的。 由于distcp在后台使用map-reduce，是否有任何方法可以使用spark来使过程更快？ 就像我们可以将配置单元执行引擎设置为'TEZ' （来代替map-reduce ）一样，我们可以将执行引擎设置为distcp吗？ 还是有其他'spark'方法可以跨集群复制数据，而这甚至可能不会影响distcp？

这是我的第二个问题（假设我们可以将distcp执行引擎设置为spark而不是map-reduce，请不要麻烦回答这个问题）：-据我所知，Spark比map-reduce更快，主要是因为它存储可能需要多次处理的内存中的数据，从而不必从磁盘一直加载数据。 在这里，我们正在跨集群复制数据，因此无需处理一个文件（或块或分割文件）一次以上，因为每个文件都会进入内存，然后通过网络发送，并复制到目标集群磁盘，该文件故事的结尾。 那么，如果不使用主要功能，Spark如何使该过程更快？

Answer 1

Spark并不是真正用于Hadoop集群之间的数据移动。 您可能希望使用"-m"选项为distcp作业查找其他映射器。

Answer 2

您在批量跨集群IO上的瓶颈通常是

1. 集群之间的带宽
2. 从源群集读取带宽
3. 向目标群集写入带宽（并且使用3x复制，写入确实占用磁盘和交换带宽）
4. 分配的工作空间（即执行者，任务的数量）

通常，在远程上载其瓶颈是您的远程网络：您不需要太多的工作人员来泛洪网络。

在两个Yahoo!之间有一个distcp操作的著名故事。 确实做到了部分骨干网的集群：Hadoop ops团队很高兴distcp的发展如此之快，而网络ops团队却因其两个站点之间的通信而感到苦恼。 我相信此事件是distcp现在具有-bandwidth选项的原因:)

在distcp可能存在限制的地方，可能是在任务设置和执行中：要复制的文件是事先做出的决定，如果某些文件快速复制而其他文件非常出色，则重新安排工作的智能就没有多少（任何？）。

Distcp只是预先构建列表，并将其交给特殊的distcp映射器，每个映射器都会读取其文件列表并将其复制过来。

有人可以尝试制作distcp的spark版本； 如果某人想更好地安排工作，这可能是一个有趣的项目，它依赖于spark非常有效地向现有执行者推出新工作的事实：spark版本可以动态推出工作，而不是预先列出所有内容。 确实，它仍可以在枚举要复制的文件时启动复制操作，以缩短启动时间。 即使这样：跨集群带宽通常将成为瓶颈。