异径管被杀死的原因有很多。其中一些是：
低暂存区内存。
资源不可用或死锁。
限制一个任务生成的缩减器的数量。等。
一般来说，如果一个reducer被终止，它将自行重新启动，并且作业完成，就不会有数据丢失。但是，如果减速机一次又一次地被杀死，而你的工作因此陷入停滞状态，那么你可能必须查看Yarn原木才能得到解决方案。
另外，似乎你是在运行在tez模式Hive试着运行在mr模式，可能会有所帮助。

通常每个容器在最终失败之前有3次尝试（可配置，如@rbyndoor所述）。如果一次尝试失败，它将被重新启动，直到尝试次数达到限制；如果失败，则整个顶点将失败，所有其他任务将被终止。
一些任务尝试的罕见失败并不是很关键的问题，特别是在具有spot节点的emr集群上运行时，这些节点可以在执行过程中删除，从而导致一些顶点的失败和部分重新启动。
在大多数情况下，失败的原因可以在tracker日志中找到。
当然，这并不是换用不受欢迎的先生的理由，他试图找出根本原因并加以解决。
在某些边缘情况下，即使某些尝试失败的作业成功，生成的数据也可能部分损坏。例如，在distribute by子句中使用某些不确定函数时。比如兰德（）。在这种情况下，重新启动的容器可能会尝试复制上一步（Map器）生成的数据，并且带有Map器结果的spot节点已经被删除。在这种情况下，会重新启动一些前一步容器，但由于rand函数的不确定性，生成的数据可能会有所不同。
关于任务。
由于许多原因，Map器或还原器可能会被杀死。首先，当其中一个容器完全失败时，所有正在运行的其他任务都将被终止。如果投机性执行被打开，重复的任务会被终止，如果任务长时间没有响应，等等。这是很正常的，通常并不表示出现了问题。如果整个作业失败或多次尝试失败，则需要检查失败的任务日志以查找原因，而不是终止的任务日志。

简短的回答：是的，如果你的工作顺利完成，那么你会看到正确的结果。
任务运行时失败的原因有很多。主要是因为资源。它可以是cpu/磁盘/内存。
tez appmaster负责处理临时容器执行失败，并且必须响应有关已分配和可能已解除分配容器的rm请求。
tez appmaster尝试在其他具有约束的容器上重新分配任务 tez.maxtaskfailures.per.node default=3 以确保同一节点不会用于重新分配。 tez.am.task.max.failed.attempts default=4 在某个任务失败之前，该任务可以失败的最大尝试次数。这不包括被杀死的尝试。4任务失败导致dag失败