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.
# Sistema de archivos S3A
En esta sección, se describen los protocolos de Spark que se ejecutan en Amazon Elastic Map Reduce (EMR) cuando se utiliza el sistema de archivos S3A.
# Confirmador de S3A MagicV2
Con la versión EMR-6.15.0, Amazon EMR presenta un nuevo tipo de confirmador S3A conocido como MagicV2. Para obtener información completa sobre esta característica, consulte las secciones de documentación correspondientes.
El MagicV2 Committer representa una implementación mejorada del código abierto [MagicCommitter](https://javadoc.io/static/org.apache.hadoop/hadoop-aws/3.4.0/org/apache/hadoop/fs/s3a/commit/magic/MagicS3GuardCommitter.html), diseñada específicamente para optimizar la escritura de archivos en Amazon S3 a través del sistema de archivos S3A. Al igual que su predecesora, aprovecha las capacidades de carga multiparte de Amazon S3 para eliminar la lista tradicional y cambiar el nombre de las operaciones que suelen asociarse a las fases de confirmación de trabajos y tareas.
En comparación con el original MagicCommitter, el compilador MagicV2 demuestra un rendimiento superior al escribir los archivos en la ubicación de salida del trabajo durante la fase de confirmación de la tarea, en lugar de la fase de confirmación del trabajo. Este enfoque permite la escritura distribuida de archivos y elimina la necesidad de almacenar temporalmente los metadatos de confirmación en Amazon S3, lo que se traduce en una mayor rentabilidad. Además, el confirmador de MagicV2 ofrece una mayor flexibilidad, ya que permite sobrescribir las rutas de los archivos en múltiples subprocesos durante el proceso de confirmación.
## Habilite el confirmador de MagicV2
Para habilitar el confirmador de MagicV2, introduzca la siguiente configuración en los ajustes de su trabajo o utilice la configuración del sitio principal para establecer la propiedad. Para obtener más información, consulte [Configuración de aplicaciones](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-configure-apps.html).
```
mapreduce.outputcommitter.factory.scheme.s3a=org.apache.hadoop.fs.s3a.commit.S3ACommitterFactory
fs.s3a.committer.magic.enabled=true
fs.s3a.committer.name=magicv2
fs.s3a.committer.magic.track.commits.in.memory.enabled=true
```
Para las cargas de trabajo que necesitan sobrescribir el directorio existente antes de confirmar o escribir los archivos nuevos, se requiere la siguiente configuración adicional, junto con la configuración mencionada anteriormente.
```
fs.s3a.committer.magic.overwrite.and.commit=true
fs.s3a.committer.magic.delete.directory.threads=thread size
```
El valor predeterminado para la configuración de `threads` es `20`. Sin embargo, este parámetro debe ajustarse cuando haya que sobrescribir un gran número de directorios para mejorar el rendimiento. Está disponible solo para EMR-7.2.0 y versiones posteriores.
## Consideraciones
+ Si la máquina virtual Java (JVM) 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 de MagicV2, asegúrese de seguir las prácticas recomendadas para la administración de cargas multiparte con errores. Para obtener más información, consulte la sección [Best practices for working with Amazon S3 buckets](https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-plan-upload-s3.html#emr-bucket-bestpractices) en la Guía de administración de Amazon EMR.
+ Si ocurre un error en un trabajo, todos los archivos confirmados por las tareas realizadas correctamente seguirán estando visibles en la ruta de destino. En esos casos, el usuario tendrá que limpiar manualmente los archivos confirmados antes de volver a ejecutar el trabajo en la misma ruta de destino.
+ El confirmador de MagicV2 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. Sin embargo, en algunos casos en los que un solo proceso ejecutor gestiona un gran número de tareas de forma simultánea, puede suponer una gran carga para la memoria, y el contenedor o el ejecutor podrían quedarse sin memoria (OOM). El aumento de la memoria del contenedor o del ejecutor debería solucionar este problema.
# Guía de migración: EMRFS al sistema de archivos S3A
A partir de la versión EMR-7.10.0, el sistema de archivos S3A es el conector predeterminado de filesystem/s3 para los clústeres de EMR para todos los esquemas de archivos de S3, incluidos los siguientes:
+ **s3://**
+ **s3n://**
+ **s3a://**
Este cambio se aplica a todas las implementaciones de EMR EC2, incluidas EKS y EMR Serverless.
Si desea seguir utilizando EMRFS, puede configurarlo agregando la siguiente propiedad al archivo de configuración `core-site.xml`:
```
fs.s3.impl
com.amazon.ws.emr.hadoop.fs.EmrFileSystem
```
## Migración de las configuraciones de EMRFS existentes a las configuraciones de S3A
**nota**
Amazon EMR implementa una asignación de configuración automático entre EMRFS y S3A cuando se cumplen condiciones específicas. El proceso de asignación se produce automáticamente cuando las configuraciones de S3A no están definidas, mientras que las configuraciones de EMRFS correspondientes están presentes. Esta funcionalidad de asignación automática se extiende a las configuraciones a nivel de bucket, lo que permite una integración perfecta entre las configuraciones de EMRFS y S3A. A modo ilustrativo, cuando se configura una configuración de cifrado específica para un bucket en EMRFS mediante 'fs.s3.bucket.amzn-s3-demo-bucket1. serverSideEncryption.kms.keyID' con el valor «XYZ», el sistema lo asigna automáticamente a la configuración S3A equivalente al establecer «fs.s3a.encryption.key» en «XYZ» para el bucket especificado amzn-s3-demo-bucket1.
El siguiente conjunto predefinido de configuraciones de EMRFS se traducirá automáticamente a sus correspondientes equivalentes de configuración de S3A. Cualquier configuración que se implemente actualmente mediante la anulación de clústeres o tareas pasará sin problemas al sistema de archivos del S3A sin necesidad de realizar modificaciones o configuraciones manuales adicionales.
De forma predeterminada, esta característica de asignación de configuración se activa automáticamente. Los usuarios que deseen deshabilitar esta traducción automática pueden hacerlo al agregar la siguiente propiedad al archivo de configuración core-site.xml.
```
fs.s3a.emrfs.compatibility.enable
false
```
**nota**
La asignación de claves de cifrado de EMRFS (fs.s3. serverSideEncryption.kms.keyID o fs.s3.cse.kms.keyID) a S3A (fs.s3a.encryption.key) solo se produce cuando el cifrado SSE-KMS o CSE-KMS está habilitado en cualquiera de los sistemas de archivos.
**Asignación de configuración de EMRFS a S3A**
| Nombre de la configuración EMRFS | Nombre de la configuración S3A |
| --- | --- |
| fs.s3.aimd.adjustWindow | fs.s3a.aimd.adjustWindow |
| fs.s3.aimd.enabled | fs.s3a.aimd.enabled |
| fs.s3.aimd.increaseIncrement | fs.s3a.aimd.increaseIncrement |
| fs.s3.aimd.initialRate | fs.s3a.aimd.initialRate |
| fs.s3.aimd.maxAttempts | fs.s3a.aimd.maxAttempts |
| fs.s3.aimd.minRate | fs.s3a.aimd.minRate |
| fs.s3.aimd.reductionFactor | fs.s3a.aimd.reductionFactor |
| fs.s3.sts.endpoint | fs.s3a.assumed.role.sts.endpoint |
| fs.s3.sts. sessionDurationSeconds | fs.s3a.assumed.role.session.duration |
| fs.s3.authorization.roleMapping | fs.s3a.authorization.roleMapping |
| fs.s3.authorization.ugi.groupName.enabled | fs.s3a.authorization.ugi.groupName.enabled |
| fs.s3. credentialsResolverClass | fs.s3a.credentials.resolver |
| fs.s3n.multipart.uploads.enabled | fs.s3a.multipart.uploads.enabled |
| fs.s3n.multipart.uploads.split.size | fs.s3a.multipart.size |
| fs.s3. serverSideEncryption.kms. customEncryptionContext | fs.s3a.encryption.context |
| fs.s3. enableServerSideCifrado | fs.s3a.encryption.algorithm |
| fs.s3. serverSideEncryption.kms.KeyId/fs.s3.cse.kms.keyID | fs.s3a.encryption.key |
| fs.s3.cse.kms.region | fs.s3a.encryption.cse.kms.region |
| fs.s3.authorization.audit.enabled | fs.s3a.authorization.audit.enabled |
| fs.s3.buckets.create.enabled | fs.s3a.bucket.probe |
| fs.s3.delete. maxBatchSize | fs.s3a.bulk.delete.page.size |
| fs.s3.filestatus.metadata.enabled | fs.s3a.metadata.cache.enabled |
| fs.s3.maxConnections | fs.s3a.connection.maximum |
| fs.s3.maxRetries | fs.s3a.retry.limit |
| fs.s3.metadata.cache.expiration.seconds | fs.s3a.metadata.cache.expiration.seconds |
| fs.s3.buffer.dir | fs.s3a.buffer.dir |
| fs.s3.canned.acl | fs.s3a.acl.default |
| fs.s3.positionedRead.optimization.enabled | fs.s3a.positionedRead.optimization.enabled |
| fs.s3. readFullyIntoBúfers.Optimización.Habilitada | fs.s3a. readFullyIntoBúfers.Optimización.Habilitada |
| fs.s3.signerType | fs.s3a.signing-algorithm |
| fs.s3.storageClass | fs.s3a.create.storage.class |
| fs.s3.threadpool.maxSize | fs.s3a.threads.max |
| fs.s3. useRequesterPaysEncabezado | fs.s3a.requester.pays.enabled |
| fs.s3n.block.size | fs.s3a.block.size |
| fs.s3n.endpoint | fs.s3a.endpoint |
| fs.s3n.ssl.enabled | fs.s3a.connection.ssl.enabled |
| fs.s3.open. acceptsFileStatus | fs.s3a.open. acceptsFileStatus |
| conexión fs.s3. maxIdleMilliSegundos | fs.s3a.connection.idle.time |
| fs.s3.s3 .habilitado AccessGrants | fs.s3a.access.grants.enabled |
| fs.s3.s3AccessGrants. Recurra a IAM | fs.s3a.access.grants.fallback.to.iam |
### Condiciones y limitaciones
+ Todos los motores EMR (Spark, Flink MapReduce, Tez, Hive, etc.) utilizarán el S3A como conector S3 predeterminado, excepto los motores Trino y Presto.
+ EMR S3A no admite la integración con EMR Ranger. Considere migrar a AWS Lake Formation.
+ AWS Lake Formation Support With RecordServer For EMR Spark with S3A no es compatible. Considere la posibilidad de utilizar el FGAC nativo de Spark.
+ AWS No se admite S3 Select.
+ La opción de limpiar periódicamente las cargas múltiples (MPU) incompletas no está disponible con el S3A. Considere la posibilidad de configurar la [política de ciclo de vida de los cubos de S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) para limpiar los depósitos pendientes. MPUs
+ [Para migrar de EMRFS a S3A con el cifrado S3 CSE-CUSTOM, es necesario reescribir el proveedor de claves personalizadas de una interfaz a otra. [EMRFSRSAEncryptionMaterialsProvider](https://github.com/awslabs/emr-sample-apps/tree/master/emrfs-plugins/EMRFSRSAEncryptionMaterialsProvider)](https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/choose-keyring.html) Consulte la configuración de [CSE-CUSTOM](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-s3a-cse-custom.html) de S3A para obtener más información.
+ Los directorios de Amazon S3 creados con EMRFS se marcan con un sufijo '\$1\$1folder\$1', mientras que los directorios creados con el sistema de archivos S3A terminan con un sufijo '/', que es coherente con los directorios creados a través de la consola S3. AWS
+ Para usar un proveedor de credenciales personalizado de S3, defina la propiedad de configuración de S3A `fs.s3a.aws.credentials.provider` con la misma clase de proveedor de credenciales que se utilizó anteriormente en la configuración de EMRFS `fs.s3.customAWSCredentialsProvider`.
### Configuraciones de EMRFS no compatibles
Las siguientes configuraciones de EMRFS se identificaron como no compatibles u obsoletas y, en consecuencia, no se proporcionará ninguna asignación directa a sus homólogas de configuración S3A. Estas configuraciones específicas no se traducirán ni transferirán automáticamente durante la migración al sistema de archivos S3A.
**Configuraciones y motivos de EMRFS no compatibles**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/ReleaseGuide/emr-s3a-migrate.html)