我有一种情况，我必须将数据/文件从 PROD 复制到 UAT（hadoop 集群）。为此，我现在正在使用'distcp'。但它需要永远。由于 distcp 在后台使用 map-reduce，有没有办法使用 spark 来加快处理速度？就像我们可以将 hive 执行引擎设置为'TEZ'（替换map-reduce）一样，我们可以将执行引擎设置为 spark fordistcp吗？或者有没有其他'spark'方法可以跨集群复制数据，甚至可能不关心 distcp？
我的第二个问题来了（假设我们可以将distcp执行引擎设置为 spark 而不是 map-reduce，否则请不要费心回答这个问题）：- 据我所知，Spark 比 map-reduce 快，主要是因为它存储数据在它可能需要多次处理的内存中，这样它就不必从磁盘一直加载数据。在这里，我们正在跨集群复制数据，因此无需多次处理一个文件（或块或拆分），因为每个文件将进入内存然后将通过网络发送，被复制到目标集群磁盘，该文件的故事结束。那么如果不使用主要功能，Spark 怎么会加快处理速度呢？
批量跨集群 IO 的瓶颈通常是
通常在长途上传时，您的长途网络是瓶颈：您不需要那么多工人来淹没网络。
两个 Yahoo! 之间有一个著名的 distcp 操作故事。确实设法对部分主干做到这一点的集群：Hadoop ops 团队很高兴 distcp 运行得如此之快，而网络 ops 团队则担心他们的核心服务由于两个站点之间的流量而受到某种程度的影响。我相信这个事件是 distcp 现在有一个-bandwidth选项的原因 :)
在 distcp 中可能存在限制的地方，可能是在任务设置和执行中：提前决定要复制哪些文件，如果某些文件复制速度很快但其他文件非常出色，则重新安排工作的智能并不多（任何？）。
Distcp 只是预先建立列表并将其交给特殊的 distcp 映射器，每个映射器读取其文件列表并将其复制过来。
有人可以尝试做一个 spark 版本的 distcp；如果有人想要更好地调度，这可能是一个有趣的项目，这依赖于 spark 在向现有执行器推送新工作方面非常有效的事实：spark 版本可以动态推送工作，而不是提前列出所有内容。实际上，它仍然可以在枚举要复制的文件时启动复制操作，从而加快启动时间。即便如此：跨集群带宽通常会成为瓶颈。
Spark 并不是真正用于 Hadoop 集群之间的数据移动。您可能希望distcp使用该"-m"选项为您的工作查看其他映射器。