为什么在EMR5.x版本中取消了对亚马逊S3的直接写入？

Question

阅读此页面后：

http://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-differences.html

“运营差异和注意事项”部分“消除了对亚马逊S3的直接写入”。

我想知道-这是否意味着在EMR4.x版本中从配置单元写入S3将比5.x版本更快？

如果是这样，这不是一种倒退吗？为什么AWS想要消除这种优化？

写入位于S3中的配置单元表是一种非常常见的情况。

有人能解决这个问题吗？

Answer 1

这种优化最初是由Qubole开发的，并推送到Apache Hive。参见here。

此功能相当危险，因为它绕过了Hive容错机制，还迫使开发人员使用通常不必要的中间表，这反过来会导致性能下降并增加成本。

非常常见的用例是当我们需要将增量数据合并到分区的目标表中时，描述为here查询是从自身插入重写表，没有中间表(在单个查询中)是相当有效的。查询可能要复杂得多，需要连接多个表。在此使用情形中，启用直接写入时会发生以下情况：

正在查询完成之前删除

1. 分区文件夹，这会导致映射器中的FileNotFound异常读取正在写入的同一个表失败，因为在执行映射器之前删除了分区文件夹。

1. 如果目标表最初是空的，则第一次运行会成功，因为配置单元知道没有任何分区并且不读取文件夹。第二次运行失败，因为在映射器完成之前删除了(1)个文件夹。

1. 已知解决方法会影响性能。增量加载数据是非常常见的用例。直接写入S3特性迫使开发人员在这种情况下使用临时表，以消除FileNotFoundException和表损坏。因此，与禁用此功能并从自身写入目标表相比，我们执行此任务的速度和成本都要低得多。

1. 第一次失败后，不可能成功重新启动，表不可选且不可写，因为元数据中存在配置单元分区，但文件夹不存在，这会导致此表中的其他查询出现FileNotFoundException，而这些查询不会覆盖它。

在你引用的亚马逊页面上也有同样的描述，但细节较少：https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-differences.html

在Qubole page上描述了另一个可能的问题，提到了一些使用前缀的现有修复，尽管这不适用于上面的用例，因为将新文件写入正在读取的文件夹无论如何都会产生问题。

此外，映射器，缩减程序可能会失败并重新启动，整个会话可能会失败并重新启动，直接写入文件，即使延迟删除旧文件似乎也不是好主意，因为它增加了无法恢复的失败或数据损坏的机会。

要禁用直接写入，请设置此配置属性：

set hive.allow.move.on.s3=true; --this disables direct write

您可以将此功能用于小任务，当不读取正在写入的同一个表时，尽管对于小任务，它不会给您提供太多。当你在一个非常大的表中重写许多分区，并且最后移动任务非常慢时，这种优化是最有效的，那么你可能想要在数据损坏的风险下启用它。