我有一种情况，我必须将数据/文件从 PROD 复制到 UAT(hadoop 集群)。为此，我现在正在使用 'distcp'。但它需要永远。由于 distcp 在引擎盖下使用 map-reduce，有什么方法可以使用 spark 使过程更快？就像我们可以将 hive 执行引擎设置为 'TEZ'(以替换 map-reduce)，我们是否可以将执行引擎设置为 spark for distcp？或者是否有任何其他 'spark' 跨集群复制数据的方法，甚至可能不关心 distcp？
这是我的第二个问题(假设我们可以将 distcp 执行引擎设置为 spark 而不是 map-reduce，否则请不要费心回答这个问题):-
据我所知，Spark 比 map-reduce 更快主要是因为它将数据存储在内存中，它可能需要在多个场合处理这些数据，这样它就不必从磁盘一直加载数据。这里我们跨集群复制数据，因此不需要多次处理一个文件(或 block 或拆分)，因为每个文件都会进入内存，然后通过网络发送，复制到目标集群磁盘，该文件的故事结束。那么，如果不使用主要功能，Spark 如何使流程更快？
最佳答案
批量跨集群 IO 的瓶颈通常是
- 集群之间的带宽
- 从源集群读取带宽
- 向目标集群写入带宽(使用 3 倍复制，写入确实会占用磁盘和交换机带宽)
- 为工作分配空间(即执行者、任务的数量)
一般来说，长距离上传的瓶颈是您的长途网络:您不需要那么多工作人员来淹没网络。
有一个关于两个 Yahoo! 之间的 distcp 操作的著名故事。确实设法对 Backbone 的一部分做到这一点的集群:Hadoop 运维团队对 distcp 运行得如此之快感到高兴，而网络运维团队则担心他们的核心服务由于两个站点之间的流量而受到某种影响。我相信这个事件是 distcp 现在有一个 -bandwidth 选项的原因:)
在 distcp 中可能存在限制的地方，可能是在任务设置和执行中:要复制哪些文件的决定是提前做出的，如果某些文件复制速度很快而其他文件复制速度不快，则在重新安排工作时没有太多(任何？)智能优秀。
Distcp 只是预先建立列表并将其交给特殊的 distcp 映射器，每个映射器读取其文件列表并将其复制过来。
有人可以尝试做 distcp 的 spark 版本；如果有人想更好地安排工作，这可能是一个有趣的项目，这取决于 spark 非常有效地将新工作推送给现有执行者这一事实:spark 版本可以动态推送工作，而不是提前列出所有内容。事实上，它仍然可以在枚举要复制的文件时开始复制操作，以加快启动时间。即便如此:跨集群带宽通常会成为瓶颈。
关于hadoop - 使用 spark 跨 hadoop 集群复制数据，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39023912/