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á.
# Requisitos do confirmador otimizado para EMRFS S3
O committer otimizado para EMRFS S3 é usado quando as seguintes condições são atendidas:
+ Você executa trabalhos do Spark que usam o Spark ou conjuntos de dados para gravar arquivos no Amazon S3. DataFrames Desde o Amazon EMR 6.4.0, esse confirmador pode ser usado para todos os formatos comuns, incluindo parquet, ORC e formatos baseados em texto (incluindo CSV e JSON). Para versões anteriores ao Amazon EMR 6.4.0, somente o formato Parquet é compatível.
+ Carregamentos multipart estão habilitados no Amazon EMR. Esse é o padrão. Para obter mais informações, consulte [O confirmador otimizado para EMRFS S3 e carregamentos multipart](emr-spark-committer-multipart.md).
+ O suporte a formato de arquivo integrado do Spark é usado. O suporte a formato de arquivo integrado é usado nas seguintes circunstâncias:
+ Para tabelas do Hive Metastore, quando `spark.sql.hive.convertMetastoreParquet` é definido como `true` para tabelas do Parquet ou `spark.sql.hive.convertMetastoreOrc` é definido como `true` para tabelas do Orc com as versões 6.4.0 ou superiores do Amazon EMR. Essas são as configurações padrão.
+ Quando os trabalhos são gravados em fontes de dados ou tabelas do Parquet, por exemplo, a tabela de destino é criada com a cláusula `USING parquet`.
+ Quando os trabalhos gravam em tabelas Parquet de metastore do Hive não particionadas. O suporte ao Parquet incorporado do Spark oferece suporte a tabelas particionadas do Hive, o que é uma limitação conhecida. Para obter mais informações, consulte [Conversão da tabela Parquet do Hive metastore](https://spark.apache.org/docs/latest/sql-data-sources-parquet.html#hive-metastore-parquet-table-conversion) no Apache Spark e no Guia de conjuntos de dados. DataFrames
+ As operações de trabalhos do Spark que gravam em um local de partição padrão, como `${table_location}/k1=v1/k2=v2/`, usam o confirmador. O confirmador não será usado se uma operação de trabalho gravar em um local de partição personalizado, por exemplo, se o local de uma partição personalizado for definido usando o comando `ALTER TABLE SQL`.
+ Os valores a seguir para o Spark devem ser usados:
+ A propriedade `spark.sql.parquet.fs.optimized.committer.optimization-enabled` deve ser definida como `true`. Essa é a configuração padrão com as versões 5.20.0 e posteriores do Amazon EMR. Com o Amazon EMR 5.19.0, o valor padrão é `false`. Para obter informações sobre como configurar esse valor, consulte [Ative o confirmador otimizado para EMRFS S3 para o Amazon EMR 5.19.0](emr-spark-committer-enable.md).
+ Se você está gravando em tabelas da metastore do Hive não particionadas, somente os formatos de arquivo Parquet e Orc são compatíveis. `spark.sql.hive.convertMetastoreParquet` deve ser definido como `true` se você está gravando em tabelas da metastore do Hive não particionadas em Paquet. `spark.sql.hive.convertMetastoreOrc` deve ser definido como `true` se estiver gravando em tabelas da metastore do Hive não particionadas em Orc. Essas são as configurações padrão.
+ `spark.sql.parquet.output.committer.class` deve ser definido como `com.amazon.emr.committer.EmrOptimizedSparkSqlParquetOutputCommitter`. Essa é a configuração padrão.
+ `spark.sql.sources.commitProtocolClass` deve ser definido como `org.apache.spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol` ou `org.apache.spark.sql.execution.datasources.SQLHadoopMapReduceCommitProtocol`. `org.apache.spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol` é a configuração padrão para as versões 5.30.0 e superiores do Amazon EMR série 5.x e para as versões 6.2.0 e superiores do Amazon EMR série 6.x. `org.apache.spark.sql.execution.datasources.SQLHadoopMapReduceCommitProtocol` é a configuração padrão para as versões anteriores do Amazon EMR.
+ Se os trabalhos do Spark substituírem os conjuntos de dados Parquet por colunas de partição dinâmica, as opções de gravação `partitionOverwriteMode` e `spark.sql.sources.partitionOverwriteMode` deverão ser definidas como `static`. Essa é a configuração padrão.
**nota**
A opção de gravação `partitionOverwriteMode` foi introduzida no Spark 2.4.0. Para a versão 2.3.2 do Spark, incluída com a versão 5.19.0 do Amazon EMR, defina a propriedade `spark.sql.sources.partitionOverwriteMode`.
## Ocasiões em que o confirmador otimizado para EMRFS S3 não é usado
Geralmente, o confirmador otimizado para EMRFS S3 não é usado nas situações a seguir.
****
| Situação | Por que o confirmador não é usado |
| --- | --- |
| Quando você grava no HDFS | O confirmador só permite gravação no Amazon S3 com o uso do EMRFS. |
| Quando você usa o sistema de arquivos S3A | O confirmador só é compatível com o EMRFS. |
| Quando você usa MapReduce nossa API RDD do Spark | O committer só oferece suporte ao uso de SparkSQL ou Dataset DataFrame. APIs |
Os exemplos do Scala a seguir demonstram algumas situações adicionais que impedem que o confirmador otimizado para EMRFS S3 seja usado por completo (o primeiro exemplo) e em parte (o segundo exemplo).
**Example – Modo de substituição de partição dinâmica**
O exemplo do Scala a seguir instrui o Spark a usar um algoritmo de confirmação diferente, o que impede totalmente o uso do confirmador otimizado para EMRFS S3. O código define a propriedade `partitionOverwriteMode` como `dynamic` para subtituir somente as partições nas quais você está gravando dados. Em seguida, as colunas de partição dinâmica são especificadas por `partitionBy` e o modo de gravação é definido como `overwrite`.
```
val dataset = spark.range(0, 10)
.withColumn("dt", expr("date_sub(current_date(), id)"))
dataset.write.mode("overwrite")
.option("partitionOverwriteMode", "dynamic")
.partitionBy("dt")
.parquet("s3://amzn-s3-demo-bucket1/output")
```
Você deve definir todas as três configurações para evitar o uso do confirmador otimizado para EMRFS S3. Quando você faz isso, o Spark executa um algoritmo de confirmação diferente, especificado no protocolo de confirmação do Spark. Para versões do Amazon EMR 5.x anteriores à 5.30.0 e para versões do Amazon EMR 6.x anteriores à 6.2.0, o protocolo de confirmação usa o diretório de teste do Spark, que é um diretório temporário criado no local de saída que começa com `.spark-staging`. O algoritmo renomeia sequencialmente diretórios de partição, o que pode afetar negativamente a performance. Para obter mais informações sobre as versões 5.30.0 e posteriores e 6.2.0 e posteriores do Amazon EMR, consulte. [Use o protocolo de confirmação otimizada para EMRFS S3](emr-spark-s3-optimized-commit-protocol.md)
O algoritmo no Spark 2.4.0 segue estas etapas:
1. As tentativas de tarefa gravam a saída nos diretórios de partição do diretório de teste do Spark, por exemplo, `${outputLocation}/spark-staging-${jobID}/k1=v1/k2=v2/`.
1. Para cada partição gravada, a tentativa de tarefa acompanha os caminhos de partição relativos, por exemplo, `k1=v1/k2=v2`.
1. Quando uma tarefa é concluída com êxito, ela fornece o driver com todos os caminhos de partição relativos que ela controlou.
1. Depois que todas as tarefas forem concluídas, a fase de confirmação do trabalho coletará todos os diretórios da partição que as tentativas de tarefas bem-sucedidas gravaram no diretório de preparação do Spark. O Spark renomeia sequencialmente cada um desses diretórios para o local de saída final usando as operações para renomear a árvore de diretórios.
1. O diretório de preparação é excluído antes de a fase de confirmação de trabalho ser concluída.
**Example – Local de partição personalizado**
Neste exemplo, o código Scala insere em duas partições. Uma partição tem um local de partição personalizado. A outra partição usa o local de partição padrão. O committer otimizado para EMRFS S3 é usado somente para gravar a saída da tarefa na partição que usa o local de partição padrão.
```
val table = "dataset"
val location = "s3://bucket/table"
spark.sql(s"""
CREATE TABLE $table (id bigint, dt date)
USING PARQUET PARTITIONED BY (dt)
LOCATION '$location'
""")
// Add a partition using a custom location
val customPartitionLocation = "s3://bucket/custom"
spark.sql(s"""
ALTER TABLE $table ADD PARTITION (dt='2019-01-28')
LOCATION '$customPartitionLocation'
""")
// Add another partition using default location
spark.sql(s"ALTER TABLE $table ADD PARTITION (dt='2019-01-29')")
def asDate(text: String) = lit(text).cast("date")
spark.range(0, 10)
.withColumn("dt",
when($"id" > 4, asDate("2019-01-28")).otherwise(asDate("2019-01-29")))
.write.insertInto(table)
```
O código Scala cria os seguintes objetos do Amazon S3:
```
custom/part-00001-035a2a9c-4a09-4917-8819-e77134342402.c000.snappy.parquet
custom_$folder$
table/_SUCCESS
table/dt=2019-01-29/part-00000-035a2a9c-4a09-4917-8819-e77134342402.c000.snappy.parquet
table/dt=2019-01-29_$folder$
table_$folder$
```
Ao gravar em partições em locais personalizados, o Spark usa um algoritmo de confirmação semelhante ao exemplo anterior, que é descrito abaixo. Como no exemplo anterior, o algoritmo resulta em renomeações sequenciais, o que pode afetar negativamente a performance.
1. Ao gravar a saída em uma partição em um local personalizado, as tarefas gravam em um arquivo no diretório de preparação do Spark, que é criado no local de saída final. O nome do arquivo inclui um UUID aleatório para evitar colisões de nomes de arquivos. A tentativa de tarefa controla cada arquivo junto com o caminho de saída final desejado.
1. Quando uma tarefa é concluída com êxito, ela fornece o driver com os arquivos e os caminhos desejados de saída final.
1. Depois que todas as tarefas forem concluídas, a fase de confirmação do trabalho renomeará sequencialmente todos os arquivos que foram gravados para partições em locais personalizados em seus caminhos de saída final.
1. O diretório de preparação é excluído antes de a fase de confirmação de trabalho ser concluída.