Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Mejora del rendimiento de Spark con Amazon S3
Amazon EMR ofrece características para ayudar a optimizar el rendimiento cuando se utiliza Spark para consultar, leer y escribir datos guardados en Amazon S3.
[S3 Select](https://aws.amazon.com/blogs/aws/s3-glacier-select/) puede mejorar el rendimiento de las consultas para archivos JSON y CSV en algunas aplicaciones al “delegar” el procesamiento en Amazon S3.
El compilador optimizado para EMRFS para S3 es una alternativa a la [OutputCommitter](https://hadoop.apache.org/docs/current/api/org/apache/hadoop/mapreduce/OutputCommitter.html)clase, que utiliza la función de cargas multiparte de EMRFS para mejorar el rendimiento al escribir archivos Parquet en Amazon S3 mediante Spark y Datasets. DataFrames
**Topics**
+ [Uso de S3 Select con Spark para mejorar el rendimiento de las consultas](emr-spark-s3select.md)
+ [CHISPA EMR MagicCommitProtocol](emr-spark-magic-commit-protocol.md)
+ [Uso del confirmador optimizado para S3 de EMRFS](emr-spark-s3-optimized-committer.md)
+ [Uso del protocolo de confirmación optimizado para S3 de EMRFS](emr-spark-s3-optimized-commit-protocol.md)
+ [Reintento de solicitudes de Amazon S3 con EMRFS](emr-spark-emrfs-retry.md)
# Uso de S3 Select con Spark para mejorar el rendimiento de las consultas
**importante**
Amazon S3 Select ya no está disponible para los nuevos clientes. Los clientes actuales de Amazon S3 Select pueden seguir utilizando la característica de la forma habitual. [Más información](https://aws.amazon.com/blogs/storage/how-to-optimize-querying-your-data-in-amazon-s3/)
Con la versión 5.17.0 y posteriores de Amazon EMR, puede usar [S3 Select](https://aws.amazon.com/blogs/aws/s3-glacier-select/) con Spark en Amazon EMR. *S3 Select* permite que las aplicaciones recuperen únicamente un subconjunto de datos de un objeto. Para Amazon EMR, el clúster “delega” en Amazon S3 el trabajo de computación de filtrar grandes conjuntos de datos para su procesamiento, lo que puede mejorar el rendimiento en algunas aplicaciones y reduce la cantidad de datos transferidos entre Amazon EMR y Amazon S3.
S3 Select es compatible con los archivos JSON y CSV si se utilizan los valores `s3selectCSV` y `s3selectJSON` para especificar el formato de los datos. Para obtener más información y ejemplos, consulta [Especificación de S3 Select en el código](#emr-spark-s3select-specify).
## ¿S3 Select es adecuado para mi aplicación?
Le recomendamos que realice un análisis comparativo sus aplicaciones con y sin S3 Select para ver si su uso puede ser adecuado para su aplicación.
Utilice las siguientes directrices para determinar si la aplicación es candidata a utilizar S3 Select:
+ La consulta filtra más de la mitad del conjunto de datos original.
+ La conexión de red entre Amazon S3 y el clúster de Amazon EMR tiene una buena velocidad de transferencia y ancho de banda disponible. Amazon S3 no comprime las respuestas HTTP, por lo que es probable que el tamaño de la respuesta aumente en el caso de los archivos de entrada comprimidos.
## Consideraciones y limitaciones
+ No se admiten el cifrado del servidor de Amazon S3 con claves de cifrado proporcionadas por el cliente (SSE-C) ni el cifrado del cliente.
+ No se admite la propiedad `AllowQuotedRecordDelimiters`. Si se especifica esta propiedad, se producirá un error en la consulta.
+ Solo se admiten archivos CSV y JSON en formato UTF-8. No se admiten las líneas múltiples. CSVs
+ Solo se admiten los archivos sin comprimir o gzip.
+ No se admiten opciones de JSON y CSV en Spark como, por ejemplo `nanValue`, `positiveInf`, `negativeInf` y las opciones relacionadas con los registros dañados (por ejemplo, failfast y el modo dropmalformed).
+ El uso de comas (,) dentro de los decimales no se admite. Por ejemplo, `10,000` no se admite, pero sí se admite `10000`.
+ No se admiten los caracteres de comentario en la última línea.
+ Las líneas vacías al final de un archivo no se procesan.
+ Los siguientes filtros no se delegan en Amazon S3:
+ Funciones de agregación como `COUNT()` y `SUM()`.
+ Filtros que aplican `CAST()` a un atributo. Por ejemplo, `CAST(stringColumn as INT) = 1`.
+ Filtros con un atributo que es un objeto o es complejo. Por ejemplo, `intArray[1] = 1, objectColumn.objectNumber = 1`.
+ Filtros cuyo valor no es un valor literal. Por ejemplo, `intColumn1 = intColumn2`
+ Solo se admiten los [tipos de datos compatibles con S3 Select](https://docs.aws.amazon.com/AmazonS3/latest/userguide/s3-glacier-select-sql-reference-data-types.html) con las limitaciones que se especifican.
## Especificación de S3 Select en el código
Los siguientes ejemplos muestran cómo especificar S3 Select para CSV mediante Scala, SQL, R y PySpark. Puede utilizar S3 Select para JSON de la misma manera. Para obtener una lista de las opciones, sus valores predeterminados y sus limitaciones, consulte [Opciones](#emr-spark-s3select-specify-options).
------
#### [ PySpark ]
```
spark
.read
.format("s3selectCSV") // "s3selectJson" for Json
.schema(...) // optional, but recommended
.options(...) // optional
.load("s3://path/to/my/datafiles")
```
------
#### [ R ]
```
read.df("s3://path/to/my/datafiles", "s3selectCSV", schema, header = "true", delimiter = "\t")
```
------
#### [ Scala ]
```
spark
.read
.format("s3selectCSV") // "s3selectJson" for Json
.schema(...) // optional, but recommended
.options(...) // optional. Examples:
// .options(Map("quote" -> "\'", "header" -> "true")) or
// .option("quote", "\'").option("header", "true")
.load("s3://path/to/my/datafiles")
```
------
#### [ SQL ]
```
CREATE TEMPORARY VIEW MyView (number INT, name STRING) USING s3selectCSV OPTIONS (path "s3://path/to/my/datafiles", header "true", delimiter "\t")
```
------
### Opciones
Las siguientes opciones están disponibles cuando se utilizan `s3selectCSV` y `s3selectJSON`. Si no se especifican, se usarán los valores predeterminados.
#### Opciones con S3selectCSV
| Opción | Predeterminado | De uso |
| --- | --- | --- |
| `compression` | `"none"` | Indica si se utiliza la compresión. `"gzip"` es la única opción admitida además de `"none"`. |
| `delimiter` | "," | Especifica el delimitador de campo. |
| `quote` | `'\"'` | Especifica el carácter de comillas. No es posible especificar una cadena vacía. Si lo hace, se mostrará un error que indica que el XML no tiene el formato correcto. |
| `escape` | `'\\'` | Especifica el carácter de escape. |
| `header` | `"false"` | `"false"` especifica que no existe ningún encabezado. `"true"` especifica que hay un encabezado en la primera línea. Solo se admiten los encabezados en la primera línea, y no se admiten las líneas vacías antes del encabezado. |
| comentario | `"#"` | Especifica el carácter de comentario. El indicador de comentario no se puede deshabilitar. En otras palabras, no se admite el valor `\u0000`. |
| `nullValue` | "" | |
#### Opciones con S3selectJSON
| Opción | Predeterminado | De uso |
| --- | --- | --- |
| `compression` | `"none"` | Indica si se utiliza la compresión. `"gzip"` es la única opción admitida además de `"none"`. |
| `multiline` | "false" | `"false"` especifica que el JSON está en el formato `LINES` de S3 Select, lo que significa que cada línea de los datos de entrada contiene un único objeto JSON. `"true"` especifica que el JSON está en el formato `DOCUMENT` de S3 Select, lo que significa que un objeto JSON pueden abarcar varias líneas en los datos de entrada. |
# CHISPA EMR MagicCommitProtocol
A partir de la versión 6.15.0 de EMR, MagicCommitProtocol se convierte en la opción predeterminada FileCommitProtocol para Spark cuando se utiliza el sistema de archivos S3A.
## MagicCommitProtocol
MagicCommitProtocol Se trata de una implementación alternativa a la [FileCommitProtocol](https://dlcdn.apache.org/spark/docs/2.4.2/api/java/org/apache/spark/internal/io/FileCommitProtocol.html)que está optimizada para escribir archivos con EMR Spark en Amazon S3 cuando se utiliza el sistema de archivos S3A. Este protocolo busca mejorar el rendimiento de las aplicaciones al evitar operaciones de cambio de nombre en Amazon S3 durante las fases de confirmación del trabajo y de las tareas.
MagicCommitProtocol Es la FileCommitProtocol implementación predeterminada que usa Spark cuando se ejecuta en Amazon Elastic Map Reduce (EMR) cuando se utiliza el sistema de archivos S3A. Utiliza MagicCommitProtocol internamente el [MagicV2Committer](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/s3a-magicv2-committer.html) para realizar las escrituras de archivos en Amazon S3.
En el caso de las operaciones de inserción estática, graba MagicCommitProtocol los archivos en la ubicación de salida del trabajo durante la fase de confirmación de la tarea. En cambio, en operaciones de inserción dinámica con sobrescritura, los archivos generados por los intentos de tarea solo aparecen en la ubicación de salida cuando el trabajo se confirma. Esto se logra mediante la exportación de metadatos de confirmación hacia el controlador de Spark durante la llamada de confirmación de la tarea.
## Habilitando MagicCommitProtocol
MagicCommitProtocol Está habilitado de forma predeterminada para Spark que se ejecuta en Amazon Elastic Map Reduce (EMR) cuando se utiliza el sistema de archivos S3A.
Para usar el sistema de archivos S3A, puede hacer lo siguiente:
1. Especificar el esquema del archivo como `s3a://` al definir la tabla, partición o directorio.
1. Establecer la propiedad `fs.s3.impl=org.apache.hadoop.fs.s3a.S3AFileSystem` en el archivo core-site.xml.
## Deshabilitar el MagicCommitProtocol
1. Puede establecer la propiedad `spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol.leverageMagicCommitProtocol` en falso codificándola de forma rígida en un `SparkConf`, pasándola como un parámetro `--conf` en el intérprete de comandos de Spark o las herramientas `spark-submit` y `spark-sql`, o en `conf/spark-defaults.conf`. Para obtener más información, consulte [Spark configuration](https://spark.apache.org/docs/latest/configuration.html) en la documentación de Apache Spark.
En el siguiente ejemplo, se muestra cómo deshabilitarla MagicCommitProtocol mientras se ejecuta un `spark-sql` comando.
```
spark-sql \
--conf spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol.leverageMagicCommitProtocol=false \
-e "INSERT OVERWRITE TABLE target_table SELECT * FROM source_table;"
```
1. Utilice la clasificación de configuración `spark-defaults` para establecer la propiedad `spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol.leverageMagicCommitProtocol` en falso. Para obtener más información, consulte [Configuración de aplicaciones](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
## MagicCommitProtocol consideraciones
+ En el caso de la inserción de particiones estáticas, en los ejecutores de Spark, se MagicCommitProtocol consume una pequeña cantidad de memoria por cada archivo escrito por un intento de tarea hasta que la tarea se confirma o se anula. En la mayoría de los trabajos, la cantidad de memoria consumida es insignificante. No requiere memoria adicional en el controlador de Spark.
+ En el caso de la inserción dinámica de particiones, en los controladores de Spark, se MagicCommitProtocol necesita memoria para almacenar la información de los metadatos de cada archivo confirmado hasta que el trabajo se confirme o se cancele. En la mayoría de los trabajos, la configuración de memoria predeterminada del controlador de Spark es insignificante.
En los trabajos que tienen tareas de ejecución prolongada y que escriben un gran número de archivos, la memoria que consume el protocolo de confirmación puede ser apreciable y requerir algunos ajustes de la memoria asignada a Spark, especialmente a los ejecutores de Spark. Puede ajustar la memoria mediante la propiedad `spark.driver.memory` para los controladores de Spark y la propiedad `spark.executor.memory` para los ejecutores de Spark. Como pauta general, una sola tarea que escribe 100 000 archivos, normalmente requerirá 200 MB de memoria adicionales. Para obtener más información, consulte [Application properties](https://spark.apache.org/docs/latest/configuration.html#application-properties) en la documentación de configuración de Apache Spark.
# Uso del confirmador optimizado para S3 de EMRFS
El confirmador optimizado para S3 para EMRFS es una [OutputCommitter](https://hadoop.apache.org/docs/current/api/org/apache/hadoop/mapreduce/OutputCommitter.html)implementación alternativa que está optimizada para escribir archivos en Amazon S3 cuando se usa EMRFS. El confirmador optimizado para S3 de EMRFS mejora el rendimiento de las aplicaciones al evitar que se lleven a cabo operaciones de cambio de nombre y de listado en Amazon S3 durante las fases de confirmación de tareas y de trabajos. El confirmador está disponible con la versión 5.19.0 y posteriores de Amazon EMR y está habilitado de forma predeterminada con la versión 5.20.0 y posteriores de Amazon EMR. El confirmador se utiliza para los trabajos de Spark que utilizan Spark o Datasets. DataFrames A partir de Amazon EMR 6.4.0, este confirmador se puede utilizar para todos los formatos habituales, incluidos los formatos Parquet, ORC y basados en texto (incluidos CSV y JSON). En el caso de las versiones anteriores a Amazon EMR 6.4.0, solo se admite el formato Parquet. Existen circunstancias bajo las cuales no se utiliza el confirmador. Para obtener más información, consulte [Requisitos del confirmador optimizado para S3 de EMRFS](emr-spark-committer-reqs.md).
**Topics**
+ [Requisitos del confirmador optimizado para S3 de EMRFS](emr-spark-committer-reqs.md)
+ [El confirmador optimizado para S3 de EMRFS y las cargas multiparte](emr-spark-committer-multipart.md)
+ [Consideraciones sobre el ajuste de trabajos](emr-spark-committer-tuning.md)
+ [Habilitación del confirmador optimizado para S3 de EMRFS para Amazon EMR 5.19.0](emr-spark-committer-enable.md)
# Requisitos del confirmador optimizado para S3 de EMRFS
El confirmador optimizado para S3 de EMRFS se utiliza cuando se cumplen las siguientes condiciones:
+ Ejecuta trabajos de Spark que utilizan Spark o Datasets para escribir archivos en Amazon S3. DataFrames A partir de Amazon EMR 6.4.0, este confirmador se puede utilizar para todos los formatos habituales, incluidos los formatos Parquet, ORC y basados en texto (incluidos CSV y JSON). En el caso de las versiones anteriores a Amazon EMR 6.4.0, solo se admite el formato Parquet.
+ Las cargas multiparte están habilitadas en Amazon EMR. Esta es la opción predeterminada. Para obtener más información, consulte [El confirmador optimizado para S3 de EMRFS y las cargas multiparte](emr-spark-committer-multipart.md).
+ Se utiliza la compatibilidad de formatos de archivos integrados de Spark. La compatibilidad de formatos de archivos integrados se utiliza en las siguientes circunstancias:
+ En el caso de las tablas del almacén de metadatos de Hive, cuando `spark.sql.hive.convertMetastoreParquet` se establece en `true` para tablas Parquet o `spark.sql.hive.convertMetastoreOrc` se establece en `true` para tablas ORC con Amazon EMR 6.4.0 o posteriores. Esta es la configuración predeterminada.
+ Cuando los trabajos escriben orígenes de datos o tablas de formatos de archivos, por ejemplo, la tabla de destino se crea con la cláusula `USING parquet`.
+ Cuando los trabajos escriben en tablas de Parquet de metaalmacenes de Hive no particionadas. La compatibilidad con Parquet integrada de Spark no admite tablas de Hive particionadas, se trata de una limitación conocida. Para obtener más información, consulte la [conversión de tablas de Hive Metastore Parquet](https://spark.apache.org/docs/latest/sql-data-sources-parquet.html#hive-metastore-parquet-table-conversion) en la Guía de conjuntos de datos DataFrames y Spark de Apache.
+ Las operaciones de trabajos de Spark que escriben en una ubicación de partición predeterminada (por ejemplo, `${table_location}/k1=v1/k2=v2/`) utilizan el confirmador. El confirmador no se utiliza si una operación de trabajo escribe en una ubicación de partición personalizada, por ejemplo, si una ubicación de partición personalizada se establece con el comando `ALTER TABLE SQL`.
+ Se deben utilizar los valores siguientes para Spark:
+ La propiedad `spark.sql.parquet.fs.optimized.committer.optimization-enabled` debe establecerse en `true`. Esta es la configuración predeterminada con Amazon EMR 5.20.0 y versiones posteriores. Con Amazon EMR 5.19.0, el valor predeterminado es `false`. Para obtener más información acerca de cómo configurar este valor, consulte [Habilitación del confirmador optimizado para S3 de EMRFS para Amazon EMR 5.19.0](emr-spark-committer-enable.md).
+ Si se escribe en tablas del metaalmacén de Hive no particionadas, solo se admiten los formatos de archivo Parquet y Orc. `spark.sql.hive.convertMetastoreParquet` debe establecerse en `true` si se escribe en tablas Parquet no particionadas del metaalmacén de Hive. `spark.sql.hive.convertMetastoreOrc` debe establecerse en `true` si se escribe en tablas Orc no particionadas del metaalmacén de Hive. Esta es la configuración predeterminada.
+ `spark.sql.parquet.output.committer.class` se debe establecer en `com.amazon.emr.committer.EmrOptimizedSparkSqlParquetOutputCommitter`. Esta es la configuración predeterminada.
+ `spark.sql.sources.commitProtocolClass` debe establecerse en `org.apache.spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol` o `org.apache.spark.sql.execution.datasources.SQLHadoopMapReduceCommitProtocol`. `org.apache.spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol` es la configuración predeterminada para la versión 5.30.0 y posteriores de la serie 5.x de Amazon EMR y para la versión 6.2.0 y posteriores de la serie 6.x de Amazon EMR. `org.apache.spark.sql.execution.datasources.SQLHadoopMapReduceCommitProtocol` es la configuración predeterminada para las versiones anteriores de Amazon EMR.
+ Si los trabajos de Spark sobrescriben conjuntos de datos de Parquet particionados con columnas de partición, entonces la opción de escritura `partitionOverwriteMode` y `spark.sql.sources.partitionOverwriteMode` se deben establecer en `static`. Es la configuración predeterminada.
**nota**
La opción de escritura `partitionOverwriteMode` se introdujo en Spark 2.4.0. En el caso de la versión 2.3.2 de Spark, incluida con la versión 5.19.0 de Amazon EMR, establezca la propiedad `spark.sql.sources.partitionOverwriteMode`.
## Ocasiones en las que no se utiliza el confirmador optimizado para S3 de EMRFS
Por lo general, el confirmador optimizado para S3 de EMRFS no se utiliza en las siguientes situaciones.
****
| Situación | Por qué no se utiliza el confirmador |
| --- | --- |
| Cuando escribe en HDFS | El confirmador solo admite la escritura en Amazon S3 mediante EMRFS. |
| Cuando utiliza el sistema de archivos S3A | El confirmador solo admite EMRFS. |
| Cuando utilizas la MapReduce API RDD de Spark | El confirmador solo admite el uso de SparkSQL o DataFrame Dataset. APIs |
En los siguientes ejemplos se muestran algunas situaciones más que evitan el uso del confirmador optimizado para S3 de EMRFS en su conjunto (el primer ejemplo) y en parte (el segundo ejemplo).
**Example – Modo de sobrescritura de partición dinámica**
En el siguiente ejemplo de Scala se indica a Spark que utilice un algoritmo de confirmación diferente, lo que impide por completo el uso del confirmador optimizado para S3 de EMRFS. El código establece la propiedad `partitionOverwriteMode` en `dynamic` para sobrescribir solo las particiones en las que escriba datos. A continuación, las columnas de particiones dinámicas se especifican mediante `partitionBy` y el modo de escritura se establece en `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")
```
Debe establecer las tres configuraciones para evitar utilizar el confirmador optimizado para S3 de EMRFS. Al hacerlo, Spark ejecuta un algoritmo de confirmación diferente que se especifica en el protocolo de confirmación de Spark. En el caso de las versiones 5.x de Amazon EMR anteriores a la 5.30.0 y las versiones 6.x de Amazon EMR anteriores a la 6.2.0, el protocolo de confirmación utiliza el directorio provisional de Spark, que es un directorio temporal creado en la ubicación de salida que comienza por `.spark-staging`. El algoritmo cambia de forma secuencial el nombre de los directorios de particiones, lo que puede afectar negativamente al rendimiento. Para obtener más información sobre la versión 5.30.0 y posteriores y 6.2.0 y posteriores de Amazon EMR, consulte [Uso del protocolo de confirmación optimizado para S3 de EMRFS](emr-spark-s3-optimized-commit-protocol.md).
El algoritmo de Spark 2.4.0 sigue estos pasos:
1. La tarea intenta escribir su salida en los directorios de particiones en el directorio provisional de Spark (por ejemplo, `${outputLocation}/spark-staging-${jobID}/k1=v1/k2=v2/`).
1. Para cada partición escrita, la tarea intenta llevar un seguimiento de las rutas de partición relativas (por ejemplo, `k1=v1/k2=v2`).
1. Cuando una tarea se completa de forma satisfactoria, proporciona al controlador todas las rutas de partición relativa cuyo seguimiento ha realizado.
1. Una vez completadas todas las tareas, la fase de confirmación del trabajo recopila todos los directorios de partición que los intentos de tarea correctos escribieron en el directorio de ensayo de Spark. Spark cambia el nombre de estos directorios de forma secuencial a su ubicación de salida final utilizando operaciones de cambio de nombre de árbol de directorio.
1. El directorio de ensayo se elimina antes de que se complete la fase de confirmación de trabajo.
**Example – Ubicación de partición personalizada**
En este ejemplo, el código Scala se inserta en dos particiones. Una partición tiene una ubicación de partición personalizada. La otra partición utiliza la ubicación de partición predeterminada. El confirmador optimizado para S3 de EMRFS se utiliza solo para escribir la salida de tarea en la partición que utiliza la ubicación de partición predeterminada.
```
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)
```
El código de Scala crea los siguientes objetos de 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$
```
Al escribir en particiones de ubicaciones personalizadas, Spark utiliza un algoritmo de confirmación similar al del ejemplo anterior, que se detalla a continuación. Como ocurre en el ejemplo anterior, el algoritmo da como resultado cambios de nombre secuenciales, lo que puede afectar negativamente al rendimiento.
1. Al escribir la salida en una partición de una ubicación personalizada, las tareas escriben en un archivo del directorio de ensayo de Spark, que se crea en la ubicación de salida final. El nombre del archivo incluye un UUID aleatorio para proteger contra las colisiones de archivo. La tarea intenta mantener un seguimiento de cada archivo junto con la ruta de salida deseada final.
1. Cuando una tarea se completa de forma satisfactoria, proporciona al controlador los archivos y las rutas de salida deseada final.
1. Una vez completadas todas las tareas, la fase de confirmación de trabajo cambia el nombre de forma secuencial de todos los archivos que se escribieron para particiones en ubicaciones personalizadas en sus rutas de salida finales.
1. El directorio de ensayo se elimina antes de que se complete la fase de confirmación de trabajo.
# El confirmador optimizado para S3 de EMRFS y las cargas multiparte
Para utilizar el confirmador optimizado para S3 de EMRFS, debe habilitar las cargas multiparte para Amazon EMR. Las cargas multiparte están habilitadas de forma predeterminada. Puede volver a habilitarlas si es necesario. Para obtener más información, consulte [Configuración de carga multiparte para Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#Config_Multipart) en la *Guía de administración de Amazon EMR*.
El confirmador optimizado para S3 de EMRFS utiliza las características similares a las transacciones de las cargas multiparte para garantizar que los archivos escritos por los intentos de tareas solo aparecen en la ubicación de salida del trabajo al confirmar las tareas. Al utilizar las cargas multiparte de esta forma, el confirmador mejora el rendimiento de las confirmaciones de tareas en comparación con la versión 2 del algoritmo predeterminado. FileOutputCommitter Cuando se utiliza el confirmador optimizado para S3 de EMRFS, existen algunas diferencias clave que lo distinguen del comportamiento tradicional de las cargas multiparte y que hay que tener en cuenta:
+ Las cargas multiparte siempre se llevan a cabo independientemente del tamaño del archivo. Esto difiere del comportamiento predeterminado de EMRFS, donde la propiedad `fs.s3n.multipart.uploads.split.size` controla el tamaño del archivo en el que se activan las cargas multiparte.
+ Las cargas multiparte se dejan en un estado incompleto durante un periodo de tiempo más prolongado hasta que la tarea se confirma o se anula. Esto difiere del comportamiento predeterminado de EMRFS, donde una carga multiparte se completa cuando una tarea termina de escribir un determinado archivo.
Debido a estas diferencias, si la JVM de un ejecutor de Spark se bloquea o se termina mientras hay tareas ejecutándose y escribiendo datos en Amazon S3, es más probable que queden cargas multiparte incompletas sin finalizar. Por este motivo, cuando utilice el confirmador optimizado para S3 de EMRFS, asegúrese de seguir las prácticas recomendadas para la administración de cargas multiparte con errores. Para obtener más información, consulte [Prácticas recomendadas](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#emr-bucket-bestpractices) para trabajar con buckets de Amazon S3 en la *Guía de administración de Amazon EMR*.
# Consideraciones sobre el ajuste de trabajos
El confirmador optimizado para S3 de EMRFS consume una pequeña cantidad de memoria por cada archivo escrito por un intento de tarea hasta que la tarea se confirma o se anula. En la mayoría de los trabajos, la cantidad de memoria consumida es insignificante. En los trabajos que tienen tareas de ejecución prolongada que escriben un gran número de archivos, la memoria que consume el confirmador puede ser apreciable y requerir algunos ajustes de la memoria asignada a los ejecutores de Spark. Puede ajustar la memoria del ejecutor mediante la propiedad `spark.executor.memory`. Como pauta general, una sola tarea que escribe 100 000 archivos, normalmente requerirá 100 MB de memoria adicionales. Para obtener más información, consulte [Application properties](https://spark.apache.org/docs/latest/configuration.html#application-properties) en la documentación de configuración de Apache Spark.
# Habilitación del confirmador optimizado para S3 de EMRFS para Amazon EMR 5.19.0
Si utiliza Amazon EMR 5.19.0, puede establecer manualmente la propiedad `spark.sql.parquet.fs.optimized.committer.optimization-enabled` en `true` al crear un clúster o desde Spark si está utilizando Amazon EMR.
## Habilitación del confirmador optimizado para S3 de EMRFS al crear un clúster
Utilice la clasificación de configuración `spark-defaults` para establecer la propiedad `spark.sql.parquet.fs.optimized.committer.optimization-enabled` en `true`. Para obtener más información, consulte [Configuración de aplicaciones](emr-configure-apps.md).
## Habilitación del confirmador optimizado para S3 de EMRFS desde Spark
Puede establecer la propiedad `spark.sql.parquet.fs.optimized.committer.optimization-enabled` en `true` codificándola de forma rígida en un `SparkConf`, pasándola como un parámetro `--conf` en el shell de Spark o las herramientas `spark-submit` y `spark-sql`, o en `conf/spark-defaults.conf`. Para obtener más información, consulte [Spark configuration](https://spark.apache.org/docs/latest/configuration.html) en la documentación de Apache Spark.
En el siguiente ejemplo, se muestra cómo activar el confirmador mientras se ejecuta un comando spark-sql.
```
spark-sql \
--conf spark.sql.parquet.fs.optimized.committer.optimization-enabled=true \
-e "INSERT OVERWRITE TABLE target_table SELECT * FROM source_table;"
```
# Uso del protocolo de confirmación optimizado para S3 de EMRFS
El protocolo de confirmación optimizado para S3 para EMRFS es una [FileCommitProtocol](https://spark.apache.org/docs/2.2.0//api/java/org/apache/spark/internal/io/FileCommitProtocol.html)implementación alternativa que está optimizada para escribir archivos con la sobrescritura dinámica de particiones de Spark en Amazon S3 cuando se usa EMRFS. El protocolo mejora el rendimiento de las aplicaciones al evitar las operaciones de cambio de nombre en Amazon S3 durante la fase de confirmación de los trabajos de sobrescritura de particiones dinámicas de Spark.
Tenga en cuenta que el [confirmador optimizado para S3 de EMRFS](emr-spark-s3-optimized-committer.html) también mejora el rendimiento al evitar las operaciones de cambio de nombre. Sin embargo, no funciona para los casos de sobrescritura de particiones dinámicas, mientras que las mejoras del protocolo de confirmación solo se dirigen a los casos de sobrescritura de particiones dinámicas.
El protocolo de confirmación está disponible con la versión 5.30.0 y posteriores y 6.2.0 y posteriores de Amazon EMR y está habilitado de forma predeterminada. Amazon EMR agregó una mejora de paralelismo a partir de la versión 5.31.0. El protocolo se utiliza para los trabajos de Spark que utilizan Spark o Datasets. DataFrames Existen circunstancias en las cuales no se utiliza el protocolo de confirmación. Para obtener más información, consulte [Requisitos del protocolo de confirmación optimizado para S3 de EMRFS](emr-spark-committer-reqs.md).
**Topics**
+ [Requisitos del protocolo de confirmación optimizado para S3 de EMRFS](emr-spark-commit-protocol-reqs.md)
+ [El protocolo de confirmación optimizado para S3 de EMRFS y las cargas multiparte](emr-spark-commit-protocol-multipart.md)
+ [Consideraciones sobre el ajuste de trabajos](emr-spark-commit-protocol-tuning.md)
# Requisitos del protocolo de confirmación optimizado para S3 de EMRFS
El protocolo de confirmación optimizado para S3 de EMRFS se utiliza cuando se cumplen las siguientes condiciones:
+ Ejecutas trabajos de Spark que usan Spark o Datasets para sobrescribir tablas particionadas. DataFrames
+ Ejecuta trabajos de Spark cuyo modo de sobrescritura de particiones es `dynamic`.
+ Las cargas multiparte están habilitadas en Amazon EMR. Esta es la opción predeterminada. Para obtener más información, consulte [El protocolo de confirmación optimizado para S3 de EMRFS y las cargas multiparte](emr-spark-commit-protocol-multipart.md).
+ La caché del sistema de archivos para EMRFS está habilitada. Es el valor predeterminado. Compruebe que la configuración `fs.s3.impl.disable.cache` esté establecida en `false`.
+ Se utiliza la compatibilidad de orígenes de datos integrados de Spark. La compatibilidad de orígenes de datos integrados se utiliza en las siguientes circunstancias:
+ Cuando los trabajos escriben en orígenes de datos o tablas integrados.
+ Cuando los trabajos escriben en tablas Parquet del metaalmacén de Hive. Esto sucede cuando `spark.sql.hive.convertInsertingPartitionedTable` y `spark.sql.hive.convertMetastoreParquet` se establecen en true. Esta es la configuración predeterminada.
+ Cuando los trabajos escriben en tablas ORC del metaalmacén de Hive. Esto sucede cuando `spark.sql.hive.convertInsertingPartitionedTable` y `spark.sql.hive.convertMetastoreOrc` se establecen en `true`. Esta es la configuración predeterminada.
+ Las operaciones de trabajos de Spark que escriben en una ubicación de partición predeterminada (por ejemplo, `${table_location}/k1=v1/k2=v2/`) utilizan el protocolo de confirmación. El protocolo no se utiliza si una operación de trabajo escribe en una ubicación de partición personalizada, por ejemplo, si una ubicación de partición personalizada se establece con el comando `ALTER TABLE SQL`.
+ Se deben utilizar los valores siguientes para Spark:
+ `spark.sql.sources.commitProtocolClass` se debe establecer en `org.apache.spark.sql.execution.datasources.SQLEmrOptimizedCommitProtocol`. Esta es la configuración predeterminada para las versiones 5.30.0 y posteriores y 6.2.0 y posteriores de Amazon EMR.
+ La opción de escritura `partitionOverwriteMode` o `spark.sql.sources.partitionOverwriteMode` debe estar establecida en `dynamic`. El ajuste predeterminado es `static`.
**nota**
La opción de escritura `partitionOverwriteMode` se introdujo en Spark 2.4.0. En el caso de la versión 2.3.2 de Spark, incluida con la versión 5.19.0 de Amazon EMR, establezca la propiedad `spark.sql.sources.partitionOverwriteMode`.
+ Si los trabajos de Spark sobrescriben en la tabla Parquet del metaalmacén de Hive, `spark.sql.hive.convertMetastoreParquet`, `spark.sql.hive.convertInsertingPartitionedTable` y `spark.sql.hive.convertMetastore.partitionOverwriteMode` debe establecerse en `true`. Esta es la configuración predeterminada.
+ Si los trabajos de Spark sobrescriben en la tabla ORC del metaalmacén de Hive, `spark.sql.hive.convertMetastoreOrc`, `spark.sql.hive.convertInsertingPartitionedTable` y `spark.sql.hive.convertMetastore.partitionOverwriteMode` debe establecerse en `true`. Esta es la configuración predeterminada.
**Example – Modo de sobrescritura de partición dinámica**
En este ejemplo de Scala, se activa la optimización. En primer lugar, establece la propiedad `partitionOverwriteMode` en `dynamic`. Esto solo sobrescribe las particiones en las que escribe datos. A continuación, especifica las columnas de particiones dinámicas mediante `partitionBy` y establece el modo de escritura en `overwrite`.
```
val dataset = spark.range(0, 10)
.withColumn("dt", expr("date_sub(current_date(), id)"))
dataset.write.mode("overwrite") // "overwrite" instead of "insert"
.option("partitionOverwriteMode", "dynamic") // "dynamic" instead of "static"
.partitionBy("dt") // partitioned data instead of unpartitioned data
.parquet("s3://amzn-s3-demo-bucket1/output") // "s3://" to use Amazon EMR file system, instead of "s3a://" or "hdfs://"
```
## Cuando no se utiliza el protocolo de confirmación optimizado para S3 de EMRFS
Por lo general, el protocolo de confirmación optimizado para S3 de EMRFS funciona igual que el protocolo de confirmación de Spark predeterminado de código abierto, `org.apache.spark.sql.execution.datasources.SQLHadoopMapReduceCommitProtocol`. La optimización no se producirá en las siguientes situaciones.
****
| Situación | Por qué no se utiliza el protocolo de confirmación |
| --- | --- |
| Cuando escribe en HDFS | El protocolo de confirmación solo admite la escritura en Amazon S3 mediante EMRFS. |
| Cuando utiliza el sistema de archivos S3A | El protocolo de confirmación solo admite EMRFS. |
| Cuando utilizas la MapReduce API RDD de Spark | El protocolo de confirmación solo admite el uso de SparkSQL o DataFrame Dataset. APIs |
| Cuando no se activa la sobrescritura de particiones dinámicas | El protocolo de confirmación solo optimiza los casos de sobrescritura de particiones dinámicas. Para los demás casos, consulte [Uso del confirmador optimizado para S3 de EMRFS](emr-spark-s3-optimized-committer.md). |
En los siguientes ejemplos de Scala se muestran algunas situaciones adicionales en las que el protocolo de confirmación optimizado para S3 de EMRFS delega en `SQLHadoopMapReduceCommitProtocol`.
**Example – Modo de sobrescritura de particiones dinámica con ubicación de partición personalizada**
En este ejemplo, los programas de Scala sobrescriben dos particiones en el modo de sobrescritura de particiones dinámicas. Una partición tiene una ubicación de partición personalizada. La otra partición utiliza la ubicación de partición predeterminada. El protocolo de confirmación optimizado para S3 de EMRFS solo mejora la partición que utiliza la ubicación de partición predeterminada.
```
val table = "dataset"
val inputView = "tempView"
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")))
.createTempView(inputView)
// Set partition overwrite mode to 'dynamic'
spark.sql(s"SET spark.sql.sources.partitionOverwriteMode=dynamic")
spark.sql(s"INSERT OVERWRITE TABLE $table SELECT * FROM $inputView")
```
El código de Scala crea los siguientes objetos de 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$
```
Escribir en ubicaciones de particiones personalizadas en versiones anteriores de Spark puede provocar la pérdida de datos. En este ejemplo, la partición `dt='2019-01-28'` se perdería. Para obtener más información, consulte [SPARK-35106](https://issues.apache.org/jira/browse/SPARK-35106). Esto se corrigió en la versión 5.33.0 y posteriores de Amazon EMR, excluidas las 6.0.x y 6.1.x.
Al escribir en particiones de ubicaciones personalizadas, Spark utiliza un algoritmo de confirmación similar al del ejemplo anterior, que se detalla a continuación. Como ocurre en el ejemplo anterior, el algoritmo da como resultado cambios de nombre secuenciales, lo que puede afectar negativamente al rendimiento.
El algoritmo de Spark 2.4.0 sigue estos pasos:
1. Al escribir la salida en una partición de una ubicación personalizada, las tareas escriben en un archivo del directorio de ensayo de Spark, que se crea en la ubicación de salida final. El nombre del archivo incluye un UUID aleatorio para proteger contra las colisiones de archivo. La tarea intenta mantener un seguimiento de cada archivo junto con la ruta de salida deseada final.
1. Cuando una tarea se completa de forma satisfactoria, proporciona al controlador los archivos y las rutas de salida deseada final.
1. Una vez completadas todas las tareas, la fase de confirmación de trabajo cambia el nombre de forma secuencial de todos los archivos que se escribieron para particiones en ubicaciones personalizadas en sus rutas de salida finales.
1. El directorio de ensayo se elimina antes de que se complete la fase de confirmación de trabajo.
# El protocolo de confirmación optimizado para S3 de EMRFS y las cargas multiparte
Para utilizar la optimización de la sobrescritura de particiones dinámicas en el protocolo de confirmación optimizado para S3 de EMRFS, las cargas multiparte deben estar habilitadas en Amazon EMR. Las cargas multiparte están habilitadas de forma predeterminada. Puede volver a habilitarlas si es necesario. Para obtener más información, consulte [Configuración de carga multiparte para Amazon S3](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#Config_Multipart) en la *Guía de administración de Amazon EMR*.
Durante la sobrescritura de particiones dinámicas, el protocolo de confirmación optimizado para S3 de EMRFS utiliza las características similares a las transacciones de las cargas multiparte para garantizar que los archivos escritos por los intentos de tareas solo aparecen en la ubicación de salida del trabajo al confirmar las tareas. Al utilizar las cargas multiparte de este modo, el protocolo de confirmación mejora el rendimiento de las confirmaciones de trabajos en comparación con la opción predeterminada `SQLHadoopMapReduceCommitProtocol`. Cuando se utiliza el protocolo de confirmación optimizado para S3 de EMRFS, hay algunas diferencias clave que lo distinguen del comportamiento tradicional de las cargas multiparte y que hay que tener en cuenta:
+ Las cargas multiparte siempre se llevan a cabo independientemente del tamaño del archivo. Esto difiere del comportamiento predeterminado de EMRFS, donde la propiedad `fs.s3n.multipart.uploads.split.size` controla el tamaño del archivo en el que se activan las cargas multiparte.
+ Las cargas multiparte se dejan en un estado incompleto durante un periodo de tiempo más prolongado hasta que la tarea se confirma o se anula. Esto difiere del comportamiento predeterminado de EMRFS, donde una carga multiparte se completa cuando una tarea termina de escribir un determinado archivo.
Debido a estas diferencias, si la JVM de un ejecutor de Spark se bloquea o se termina mientras hay tareas ejecutándose y escribiendo datos en Amazon S3, o la JVM de un controlador de Spark se bloquea o se termina durante la ejecución de un trabajo, es más probable que queden cargas multiparte incompletas sin finalizar. Por este motivo, cuando utilice el protocolo de confirmación optimizado para S3 de EMRFS, asegúrese de seguir las prácticas recomendadas para la administración de cargas multiparte con errores. Para obtener más información, consulte [Prácticas recomendadas](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#emr-bucket-bestpractices) para trabajar con buckets de Amazon S3 en la *Guía de administración de Amazon EMR*.
# Consideraciones sobre el ajuste de trabajos
En los ejecutores de Spark, el protocolo de confirmación optimizado para S3 de EMRFS consume una pequeña cantidad de memoria por cada archivo escrito por un intento de tarea hasta que la tarea se confirma o se anula. En la mayoría de los trabajos, la cantidad de memoria consumida es insignificante.
En los controladores de Spark, el protocolo de confirmación optimizado para S3 de EMRFS requiere memoria para almacenar la información de los metadatos de cada archivo confirmado hasta que el trabajo se confirma o se anula. En la mayoría de los trabajos, la configuración de memoria predeterminada del controlador de Spark es insignificante.
En los trabajos que tienen tareas de ejecución prolongada y que escriben un gran número de archivos, la memoria que consume el protocolo de confirmación puede ser apreciable y requerir algunos ajustes de la memoria asignada a Spark, especialmente a los ejecutores de Spark. Puede ajustar la memoria mediante la propiedad `spark.driver.memory` para los controladores de Spark y la propiedad `spark.executor.memory` para los ejecutores de Spark. Como pauta general, una sola tarea que escribe 100 000 archivos, normalmente requerirá 100 MB de memoria adicionales. Para obtener más información, consulte [Application properties](https://spark.apache.org/docs/latest/configuration.html#application-properties) en la documentación de configuración de Apache Spark.
# Reintento de solicitudes de Amazon S3 con EMRFS
En este tema se proporciona información sobre las estrategias de reintentos que puede utilizar al realizar solicitudes a Amazon S3 con EMRFS. Cuando la tasa de solicitudes aumenta, S3 intenta escalar para dar cabida a la nueva tasa. Durante este proceso, S3 puede limitar las solicitudes y devolver un error `503 Slow Down`. Para mejorar la tasa de éxito de las solicitudes de S3, puede configurar las propiedades de la configuración `emrfs-site` para ajustar la estrategia de reintentos.
Puede ajustar la estrategia de reintentos de las siguientes maneras.
+ Aumente el límite máximo de reintentos para la estrategia de reintentos de retroceso exponencial predeterminada.
+ Habilite y configure la estrategia de reintentos de aumento aditivo/disminución multiplicativa (AIMD). AIMD es compatible con la versión 6.4.0 y posteriores de Amazon EMR.
## Uso de la estrategia de retroceso exponencial predeterminada
De forma predeterminada, EMRFS utiliza una estrategia de retroceso exponencial para reintentar las solicitudes de Amazon S3. El límite de reintentos de EMRFS predeterminado es de 15. Para evitar un error `503 Slow Down` de S3, puede aumentar el límite de reintentos al crear un clúster nuevo, en un clúster en ejecución o durante el tiempo de ejecución de la aplicación.
Para aumentar el límite de reintentos, debe cambiar el valor de `fs.s3.maxRetries` de la configuración `emrfs-site`. En el siguiente ejemplo de configuración se establece `fs.s3.maxRetries` en un valor personalizado de 30.
```
[
{
"Classification": "emrfs-site",
"Properties": {
"fs.s3.maxRetries": "30"
}
}
]
```
Para obtener información acerca del uso de objetos de configuración, consulte [Configuración de aplicaciones](emr-configure-apps.md).
## Uso de la estrategia de reintentos de AIMD
Con la versión 6.4.0 y posteriores de Amazon EMR, EMRFS admite una estrategia de reintentos alternativa basada en un modelo de aumento aditivo/disminución multiplicativa (AIMD). La estrategia de reintentos de AIMD resulta especialmente útil cuando se trabaja con clústeres grandes de Amazon EMR.
AIMD calcula una tasa de solicitudes personalizada a partir de los datos sobre las solicitudes recientes que se han realizado correctamente. Esta estrategia reduce el número de solicitudes limitadas y el total de intentos necesarios por solicitud.
Para habilitar la estrategia de reintentos de AIMD, debe establecer la propiedad `fs.s3.aimd.enabled` en `true` en la configuración `emrfs-site`, como en el siguiente ejemplo.
```
[
{
"Classification": "emrfs-site",
"Properties": {
"fs.s3.aimd.enabled": "true"
}
}
]
```
Para obtener información acerca del uso de objetos de configuración, consulte [Configuración de aplicaciones](emr-configure-apps.md).
## Configuración avanzada de reintentos de AIMD
Puede configurar las propiedades que se muestran en la siguiente tabla para refinar el comportamiento de los reintentos al utilizar la estrategia de reintentos de AIMD. Para la mayoría de los casos de uso, le recomendamos que utilice los valores predeterminados.
**Propiedades avanzadas de la estrategia de reintentos de AIMD**
| Propiedad | Predeterminado | Description (Descripción) |
| --- | --- | --- |
| fs.s3.aimd.increaseIncrement | 0.1 | Controla la rapidez con la que aumenta la tasa de solicitudes cuando las solicitudes consecutivas se realizan correctamente. |
| fs.s3.aimd.reductionFactor | 2 | Controla la rapidez con la que disminuye la tasa de solicitudes cuando Amazon S3 devuelve una respuesta 503. El factor predeterminado de 2 reduce la tasa de solicitudes a la mitad. |
| fs.s3.aimd.minRate | 0.1 | Establece el límite inferior de la tasa de solicitudes cuando las solicitudes sufren una limitación constante por parte de S3. |
| fs.s3.aimd.initialRate | 5500 | Establece la tasa de solicitudes inicial, que luego cambia según los valores que especifique para fs.s3.aimd.increaseIncrement y fs.s3.aimd.reductionFactor.La tasa inicial también se usa para las solicitudes GET y se escala de forma proporcional (3500/5500) para las solicitudes PUT. |
| fs.s3.aimd.adjustWindow | 2 | Controla la frecuencia con la que se ajusta la tasa de solicitudes, medida en número de respuestas. |
| fs.s3.aimd.maxAttempts | 100 | Establece el número máximo de intentos para intentar una solicitud. |