为什么在EMR 5.x版本中取消了对Amazon S3的直接写入？ [英] Why are direct writes to Amazon S3 eliminated in EMR 5.x versions?

问题描述

阅读本页后：

http://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-differences.html
"运营差异和注意事项"->"消除了对Amazon S3的直接写入"部分。

我想知道-这是否意味着在EMR 4.x版本中从配置单元写入S3将比5.x版本更快？
如果是这样的话，这不是一种倒退吗？为什么AWS要取消此优化？
写入位于S3中的配置单元表是一种非常常见的情况。

有人能解决这个问题吗？

推荐答案

此优化最初由Qubole开发并推送到ApacheHve。 请参阅here。

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

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

1. 正在查询完成之前删除分区文件夹，这导致映射器读取正在写入的同一个表时出现FileNotFound异常，因为在执行映射器之前删除了分区文件夹。

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

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

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

您引用的Amazon页面上的描述相同，但详细信息较少：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

您可以将此功能用于小任务，当不读取正在写入的同一个表时，尽管对于小任务，它不会给您提供太多信息。当您在一个非常大的表中重写多个分区，并且最后的移动任务极其缓慢时，此优化是最有效的，然后您可能需要冒着数据损坏的风险启用它。

这篇关于为什么在EMR 5.x版本中取消了对Amazon S3的直接写入？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！