

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# O protocolo de S3-optimized confirmação do EMRFS e os carregamentos em várias partes
<a name="emr-spark-commit-protocol-multipart"></a>

Para usar a otimização para substituição dinâmica de partições no protocolo de S3-optimized confirmação do EMRFS, os uploads de várias partes devem ser habilitados no Amazon EMR. Multipart uploads são habilitados por padrão. Você pode habilitá-los novamente, se necessário. Para obter mais informações, consulte [Configure multipart upload for Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#Config_Multipart) (Configurar o carregamento fracionado no Amazon S3) no *Guia de gerenciamento do Amazon EMR*. 

Durante a substituição dinâmica da partição, o protocolo de S3-optimized confirmação do EMRFS usa as características de transação dos carregamentos de várias partes para garantir que os arquivos gravados por tentativas de tarefa apareçam apenas no local de saída do trabalho após a confirmação do trabalho. Ao usar carregamentos multipart dessa maneira, o protocolo de confirmação melhora a performance de confirmação de trabalhos em relação ao padrão `SQLHadoopMapReduceCommitProtocol`. Ao usar o protocolo de S3-optimized confirmação do EMRFS, há algumas diferenças importantes em relação ao comportamento tradicional de upload em várias partes a serem consideradas:
+ Os multipart uploads são sempre executados, independentemente do tamanho do arquivo. Isso é diferente do comportamento padrão do EMRFS, em que a propriedade `fs.s3n.multipart.uploads.split.size` controla o tamanho do arquivo no qual multipart uploads são acionados.
+ Os multipart uploads são deixados incompletos por um período mais longo até que a tarefa seja confirmada ou cancelada. Isso é diferente do comportamento padrão do EMRFS no qual um multipart upload é concluído quando uma tarefa é concluída ao gravar um determinado arquivo.

Devido a essas diferenças, se uma JVM do executor do Spark apresenta falha ou é eliminada enquanto as tarefas estão executando e gravando dados no Amazon S3 ou se uma JVM do executor do Spark apresenta falha ou é eliminada enquanto um trabalho está sendo executado, é mais provável que os carregamentos multipart sejam abandonados. Por esse motivo, ao usar o protocolo de S3-optimized confirmação do EMRFS, certifique-se de seguir as melhores práticas para gerenciar uploads de várias partes com falha. Para obter mais informações, consulte [Práticas recomendadas](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#emr-bucket-bestpractices) para trabalhar com buckets do Amazon S3 no *Guia de gerenciamento do Amazon EMR*.