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.
# Trabajos en ejecución
Una vez que haya preparado su aplicación, envíe trabajos a la dicha aplicación. En esta sección se explica cómo utilizar el AWS CLI para ejecutar estos trabajos. Esta sección también identifica los valores predeterminados para cada tipo de aplicación que está disponible en EMR sin servidor.
**Topics**
+ [Estados de ejecuciones de trabajos](job-states.md)
+ [Cancelación de la ejecución de un trabajo de EMR sin servidor con período de gracia](job-cancellation-grace-period.md)
+ [Ejecución de trabajos desde la consola de EMR Studio](jobs-studio.md)
+ [Ejecutar trabajos desde el AWS CLI](jobs-cli.md)
+ [Política de IAM de ejecución](jobs-cli-execution.md)
+ [Uso de discos optimizados para reproducción aleatoria](jobs-shuffle-optimized-disks.md)
+ [Uso del almacenamiento sin servidor para Amazon EMR Serverless](jobs-serverless-storage.md)
+ [Trabajos de streaming para procesar datos transmitidos de forma continua](jobs-streaming.md)
+ [Uso de configuraciones de Spark al ejecutar trabajos de EMR sin servidor](jobs-spark.md)
+ [Uso de configuraciones de Hive al ejecutar trabajos de EMR sin servidor](jobs-hive.md)
+ [Resiliencia de trabajos de EMR sin servidor](jobs-resiliency.md)
+ [Configuración de metaalmacenes para EMR sin servidor](metastore-config.md)
+ [Acceso a los datos de S3 en otra AWS cuenta desde EMR Serverless](jobs-s3-access.md)
+ [Solución de errores en EMR sin servidor](jobs-troubleshoot.md)
+ [Habilitar la asignación de costos a nivel de trabajo](jobs-job-level-cost-allocation.md)
# Estados de ejecuciones de trabajos
Al enviar una ejecución de trabajo a una cola de trabajos de Amazon EMR sin servidor, el trabajo pasa al estado `SUBMITTED`. El estado de un trabajo pasa desde el `SUBMITTED` pasando por `RUNNING` hasta que llega a `FAILED`, `SUCCESS` o `CANCELLING`.
Las ejecuciones de trabajos pueden tener los siguientes estados:
****
| Estado | Description (Descripción) |
| --- | --- |
| Enviado | El estado inicial del trabajo al enviar un trabajo se ejecuta en EMR sin servidor. El trabajo espera a que se programe para la solicitud. EMR sin servidor comienza a priorizar y programar la ejecución del trabajo. |
| En cola | La ejecución de la tarea espera en este estado cuando la ejecución simultánea de tareas a nivel de aplicación esté completamente ocupada. Para obtener más información acerca de la cola y de la simultaneidad, consulte [Simultaneidad de trabajos y colas para una aplicación EMR sin servidor](applications-concurrency-queuing.md). |
| Pendiente | El programador evalúa la ejecución del trabajo para priorizar y programar la ejecución de la aplicación. |
| Programados | EMR sin servidor ha programado la ejecución del trabajo para la aplicación y está asignando recursos para ejecutarlo. |
| En ejecución | EMR sin servidor ha asignado los recursos que el trabajo necesita inicialmente y el trabajo se está ejecutando en la aplicación. En las aplicaciones de Spark, esto significa que el estado del proceso del controlador de Spark es running. |
| Con error | EMR sin servidor no pudo enviar la ejecución del trabajo a la aplicación o se completó sin éxito. Consulte StateDetails para obtener información adicional sobre este error en el trabajo. |
| Correcto | El trabajo se ha completado correctamente. |
| Cancelling | La API CancelJobRun solicitó la cancelación de la ejecución de la tarea o se agotó el tiempo de espera de la ejecución de la tarea. EMR sin servidor está intentando cancelar el trabajo en la aplicación y liberar los recursos. |
| Cancelado | La ejecución del trabajo se canceló correctamente y se han liberado los recursos que utilizaba. |
# Cancelación de la ejecución de un trabajo de EMR sin servidor con período de gracia
En los sistemas de procesamiento de datos, las terminaciones abruptas pueden provocar un desperdicio de recursos, operaciones incompletas y posibles inconsistencias en los datos. Amazon EMR sin servidor le permite especificar un período de gracia al cancelar la ejecución de trabajos. Esta característica permite disponer de tiempo para limpiar adecuadamente y completar la tarea en curso antes de terminar el trabajo.
Al cancelar la ejecución de un trabajo, especifique un período de gracia (en segundos) mediante el parámetro `shutdownGracePeriodInSeconds` durante el cual el trabajo puede realizar operaciones de limpieza antes de su finalización definitiva. El comportamiento y los ajustes predeterminados varían entre los trabajos por lotes y en streaming.
## Período de gracia para trabajos por lotes
Para los trabajos por lotes, EMR sin servidor le permite implementar operaciones de limpieza personalizadas que se ejecutan durante el período de gracia. Puede registrar estas operaciones de limpieza como parte del enlace de cierre de la JVM en el código de su aplicación.
**Comportamiento predeterminado**
El comportamiento predeterminado para el cierre es no tener ningún período de gracia. Consta de las dos siguientes acciones:
+ Terminación inmediata
+ Los recursos se liberan inmediatamente
**Opciones de configuración**
Puede especificar una configuración que dé como resultado un cierre estable:
+ Intervalo válido para el período de gracia de cierre: de 15 a 1800 segundos (opcional)
+ Terminación inmediata (sin período de gracia): 0 segundos
### Habilite un cierre estable
Para implementar un cierre estable en los trabajos por lotes, siga estos pasos:
1. Agregue un enlace de apagado en el código de la aplicación que contenga una lógica de cierre personalizada.
------
#### [ Example in Scala ]
```
import org.apache.hadoop.util.ShutdownHookManager
// Register shutdown hook with priority (second argument)
// Higher priority hooks run first
ShutdownHookManager.get().addShutdownHook(() => {
logger.info("Performing cleanup operations...")
}, 100)
```
Uso de [ShutdownHookManager](https://hadoop.apache.org/docs/r2.8.0/hadoop-project-dist/hadoop-common/api/org/apache/hadoop/util/ShutdownHookManager.html)
------
#### [ Example in PySpark ]
```
import atexit
def cleanup():
# Your cleanup logic here
print("Performing cleanup operations...")
# Register the cleanup function
atexit.register(cleanup)
```
------
1. Especifique un período de gracia al cancelar el trabajo para dar tiempo a que se ejecuten los enlaces añadidos anteriormente
**Ejemplo**
```
# Default (immediate termination)
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID
# With 5-minute grace period
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID \
--shutdown-grace-period-in-seconds 300
```
## Período de gracia para los trabajos de streaming
En Spark Structured Streaming, donde los cálculos implican leer o escribir en orígenes de datos externos, las interrupciones abruptas pueden provocar resultados no deseados. Los trabajos de streaming procesan los datos en microlotes y, si se interrumpen estas operaciones a mitad de camino, se puede duplicar el procesamiento en los siguientes intentos. Esto ocurre cuando no se ha escrito el último punto de control del microlote anterior, lo que provoca que los mismos datos se procesen de nuevo cuando se reinicie el trabajo de streaming. Este procesamiento duplicado no solo desperdicia recursos informáticos, sino que también puede afectar a las operaciones comerciales, por lo que es crucial evitar interrupciones abruptas.
EMR sin servidor proporciona soporte integrado para un cierre estable a través de un oyente de consultas de streaming. Esto garantiza la correcta finalización de los microlotes en curso antes de la finalización del trabajo. El servicio gestiona automáticamente el cierre estable entre los microlotes para las aplicaciones de streaming, lo que garantiza que el microlote actual complete el procesamiento, que los puntos de control se escriban correctamente y que el contexto de transmisión finalice de forma limpia sin ingerir nuevos datos durante el proceso de cierre.
**Comportamiento predeterminado**
+ El período de gracia de 120 segundos está activado de forma predeterminada.
+ El oyente de consultas de streaming integrado gestiona el cierre estable.
**Opciones de configuración**
+ Intervalo válido para el período de gracia de cierre: de 15 a 1800 segundos (opcional)
+ Terminación inmediata: 0 segundos
### Habilite el cierre estable
Para implementar un cierre estable de los trabajos de streaming:
Especifique un período de gracia al cancelar el trabajo para dar tiempo a que se complete el microlote en curso.
**Ejemplo**
```
# Default graceful shutdown (120 seconds)
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID
# Custom grace period (e.g. 300 seconds)
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID \
--shutdown-grace-period-in-seconds 300
# Immediate Termination
aws emr-serverless cancel-job-run \
--application-id APPLICATION_ID \
--job-run-id JOB_RUN_ID \
--shutdown-grace-period-in-seconds 0
```
### Añada enlaces de cierre personalizados (opcional)
Si bien EMR sin servidor gestiona un cierre estable de forma predeterminada a través de su oyente de consultas de streaming integrado, puede implementar opcionalmente una lógica de cierre personalizada para las consultas de streaming individuales. EMR Serverless registra su elegante detector de apagado con prioridad 60 (en uso). ShutdownHookManager Como los enlaces de mayor prioridad se ejecutan primero, puede registrar sus operaciones de limpieza personalizadas con una prioridad superior a 60 para asegurarse de que se ejecuten antes de que comience el proceso de cierre de EMR sin servidor.
Para añadir un enlace personalizado, consulte el primer ejemplo de este tema, que muestra cómo añadir un enlace de cierre en el código de la aplicación. En este caso, 100 es la prioridad, que es mayor que 60. Por lo tanto, dicho enlace de cierre se ejecuta primero.
**nota**
Los enlaces de cierre personalizados son opcionales y no son necesarios para una funcionalidad de cierre estable, que EMR sin servidor gestiona automáticamente.
### Cargos del período de gracia y duración del lote
Si se utiliza el valor predeterminado para el período de gracia (120 segundos):
+ Si la duración del lote es inferior a 120 segundos, solo se le cobrará el tiempo real necesario para completar el lote.
+ Si la duración del lote supera los 120 segundos, se le cobrará el período de gracia máximo (120 segundos), pero es posible que la consulta no se cierre correctamente, ya que finalizará de manera forzosa.
Para optimizar los costos y garantizar un cierre estable:
+ Para lotes con una duración superior a 120 segundos: considere aumentar el período de gracia para que coincida con la duración del lote
+ Para lotes con una duración inferior a 120 segundos: no es necesario ajustar el período de gracia, ya que solo se le cobrará por el tiempo de procesamiento real
## Consideraciones
### Comportamiento del período de gracia
+ El período de gracia proporciona tiempo para que se completen los enlaces de cierre registrados.
+ El trabajo finaliza tan pronto como finaliza el enlace de cierre, incluso si es mucho antes del período de gracia.
+ Si las operaciones de limpieza superan el período de gracia, el trabajo finalizará forzosamente.
### Comportamiento de servicio
+ El cierre por período de gracia solo está disponible para los trabajos en estado EN EJECUCIÓN.
+ Las solicitudes de cancelación posteriores durante el estado CANCELANDO se ignoran.
+ Si EMR sin servidor no puede iniciar el cierre por período de gracia debido a errores internos del servicio:
+ El servicio se volverá a intentar durante un máximo de 2 minutos.
+ Si los reintentos no se realizan correctamente, el trabajo finalizará de manera forzosa.
### Facturación
Los trabajos se facturan por los recursos informáticos utilizados hasta que el trabajo se cierre por completo, lo que incluye el tiempo transcurrido durante el período de gracia.
# Ejecución de trabajos desde la consola de EMR Studio
Puede enviar ejecuciones de trabajos a aplicaciones EMR sin servidor y acceder a los trabajos desde la consola de EMR Studio. Para crear –o ir hasta– la aplicación EMR sin servidor en EMR Studio, siga las instrucciones de [Introducción a la consola](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html#gs-console).
## Enviar un trabajo
En la página **Enviar trabajo**, envíe un trabajo a una aplicación EMR sin servidor de la siguiente manera.
------
#### [ Spark ]
1. En el campo **Nombre**, introduzca un nombre para la ejecución del trabajo.
1. En el campo **Rol del tiempo de ejecución**, introduzca el nombre del rol de IAM que la aplicación EMR sin servidor puede asumir para la ejecución del trabajo. Para obtener más información acerca de los roles de tiempos de ejecución, consulte [Roles en tiempo de ejecución de trabajo para Amazon EMR sin servidor](security-iam-runtime-role.md).
1. En el campo **Ubicación del script**, introduzca la ubicación de Amazon S3 del script o el JAR que desee ejecutar. Para los trabajos de Spark, el script puede ser un archivo Python (`.py`) o un archivo JAR (`.jar`).
1. Si la ubicación del script es un archivo JAR, introduzca el nombre de la clase que es el punto de entrada del trabajo en el campo **Clase principal**.
1. (Opcional) Introduzca los valores en el resto de los campos.
+ **Argumentos del script**: introduzca cualquier argumento que desee pasar a su script JAR o Python principal. El código lee estos parámetros. Separe cada argumento del conjunto con una coma.
+ **Propiedades de Spark**: expanda la sección de propiedades de Spark e introduzca cualquier parámetro de configuración de Spark en ese campo.
**nota**
Si especifica los tamaños del controlador y del ejecutor de Spark, tenga en cuenta la sobrecarga de memoria. Especifique los valores de sobrecarga de memoria en las propiedades `spark.driver.memoryOverhead` y `spark.executor.memoryOverhead`. La sobrecarga de memoria tiene un valor predeterminado del 10 % de la memoria del contenedor, con un mínimo de 384 MB. La memoria del ejecutor y la sobrecarga de memoria juntas no pueden superar la memoria de trabajo. Por ejemplo, la `spark.executor.memory` máxima en un trabajador de 30 GB debe ser de 27 GB.
+ **Configuración del trabajo**: especifique cualquier configuración de trabajo en este campo. Puede usar estas configuraciones del trabajo para anular las configuraciones predeterminadas de las aplicaciones.
+ **Ajustes adicionales**: active o desactive el catálogo de datos de Glue de AWS como metaalmacén y modifique los ajustes del registro de la aplicación. Para obtener más información sobre las configuraciones del metalmacén, consulte [Configuración de metaalmacenes para EMR sin servidor](metastore-config.md). Para obtener más información sobre las opciones de registro de aplicaciones, consulte [Almacenamiento de registros](logging.md).
+ **Etiquetas**: asigne etiquetas personalizadas a la aplicación.
1. Seleccione **Enviar el trabajo**.
------
#### [ Hive ]
1. En el campo **Nombre**, introduzca un nombre para la ejecución del trabajo.
1. En el campo **Rol del tiempo de ejecución**, introduzca el nombre del rol de IAM que la aplicación EMR sin servidor puede asumir para la ejecución del trabajo.
1. En el campo **Ubicación del script**, introduzca la ubicación de Amazon S3 del script o el JAR que desee ejecutar. Para los trabajos de Hive, el script debe ser un archivo Hive (`.sql`).
1. (Opcional) Introduzca los valores en el resto de los campos.
+ **Ubicación del script de inicialización**: introduzca la ubicación del script que inicializa las tablas antes de que se ejecute el script de Hive.
+ **Propiedades de Spark**: expanda la sección de propiedades de Hive e introduzca cualquier parámetro de configuración de Hive en ese campo.
+ **Configuración del trabajo**: especifique cualquier configuración del trabajo. Puede usar estas configuraciones del trabajo para anular las configuraciones predeterminadas de las aplicaciones. Para los trabajos de Hive, `hive.exec.scratchdir` y `hive.metastore.warehouse.dir` son propiedades obligatorias en la configuración del `hive-site`.
```
{
"applicationConfiguration": [
{
"classification": "hive-site",
"configurations": [],
"properties": {
"hive.exec.scratchdir": "s3://DOC-EXAMPLE_BUCKET/hive/scratch",
"hive.metastore.warehouse.dir": "s3://DOC-EXAMPLE_BUCKET/hive/warehouse"
}
}
],
"monitoringConfiguration": {}
}
```
+ **Ajustes adicionales**: active o desactive el catálogo de datos de AWS Glue como metaalmacén y modifique la configuración del registro de la aplicación. Para obtener más información sobre las configuraciones del metalmacén, consulte [Configuración de metaalmacenes para EMR sin servidor](metastore-config.md). Para obtener más información sobre las opciones de registro de aplicaciones, consulte [Almacenamiento de registros](logging.md).
+ **Etiquetas**: asigne cualquier etiqueta personalizada a la aplicación.
1. Seleccione **Enviar el trabajo**.
------
## Acceso a las ejecuciones de trabajos
En la pestaña **Ejecuciones de trabajo** de la página **Detalles** de una aplicación, puede acceder a las ejecuciones de trabajos y realizar las siguientes acciones para las ejecuciones de trabajos.
**Cancelar trabajo**: para cancelar una ejecución de trabajo que esté en el estado `RUNNING`, elija esta opción. Para obtener más información sobre las transiciones de ejecución de trabajos, consulte [Estados de ejecuciones de trabajos](job-states.md).
**Clonar un trabajo**: para clonar una ejecución de trabajo anterior y volver a enviarlo, seleccione esta opción.
# Ejecutar trabajos desde el AWS CLI
En la AWS CLI, puede crear, describir y eliminar trabajos individuales. También puede enumerar todos sus trabajos para acceder a ellos de un vistazo.
Para enviar un nuevo trabajo, utilice `start-job-run`. Proporcione el ID de la aplicación que desea ejecutar, junto con las propiedades específicas del trabajo. Para ver ejemplos de Spark, consulte [Uso de configuraciones de Spark al ejecutar trabajos de EMR sin servidor](jobs-spark.md). Para ver ejemplos de Hive, consulte [Uso de configuraciones de Hive al ejecutar trabajos de EMR sin servidor](jobs-hive.md). Este comando devuelve su `application-id`, ARN y un `job-id` nuevo.
Cada ejecución de trabajo tiene un tiempo de espera establecido. Si la ejecución del trabajo supera esta duración, EMR sin servidor la cancelará automáticamente. El tiempo de espera predeterminado es de 12 horas. Al iniciar la ejecución del trabajo, configure este ajuste de tiempo de espera en un valor que cumpla con los requisitos del trabajo. Configure el valor con la propiedad `executionTimeoutMinutes`.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--execution-timeout-minutes 15 \
--job-driver '{
"hive": {
"query": "s3://amzn-s3-demo-bucket/scripts/create_table.sql",
"parameters": "--hiveconf hive.exec.scratchdir=s3://amzn-s3-demo-bucket/hive/scratch --hiveconf hive.metastore.warehouse.dir=s3://amzn-s3-demo-bucket/hive/warehouse"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.client.cores": "2",
"hive.client.memory": "4GIB"
}
}]
}'
```
Para describir un trabajo, utilice `get-job-run`. Este comando devuelve las configuraciones específicas del trabajo y la capacidad establecida para el nuevo trabajo.
```
aws emr-serverless get-job-run \
--job-run-id job-id \
--application-id application-id
```
Para enumerar sus trabajos, utilice `list-job-runs`. Este comando devuelve un conjunto abreviado de propiedades que incluye el tipo de trabajo, el estado y otros atributos de alto nivel. Si no desea acceder a todos sus trabajos, especifique el número máximo de trabajos a los que desea acceder, hasta 50. En el ejemplo siguiente, se especifica que desea acceder a las dos últimas ejecuciones de sus trabajos.
```
aws emr-serverless list-job-runs \
--max-results 2 \
--application-id application-id
```
Para cancelar un trabajo, utilice `cancel-job-run`. Proporcione el `application-id` y el `job-id` del trabajo que desea cancelar.
```
aws emr-serverless cancel-job-run \
--job-run-id job-id \
--application-id application-id
```
Para obtener más información sobre cómo ejecutar trabajos desde AWS CLI, consulte la referencia de la API [sin servidor de EMR.](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/Welcome.html)
# Política de IAM de ejecución
Puede especificar una política de IAM de ejecución, además de un rol de ejecución, al enviar las ejecuciones de trabajos en EMR sin servidor. Los permisos resultantes que asume la ejecución del trabajo son la intersección de los permisos del rol de ejecución y la política de IAM de ejecución especificada.
## Introducción
Pasos para usar la política de IAM de ejecución:
Cree una aplicación `emr-serverless` o use una existente y, a continuación, ejecute la siguiente CLI de para iniciar una ejecución de trabajo con una política de IAM integrada:
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options \
--execution-iam-policy '{"policy": "inline-policy"}'
```
## Ejemplos de comandos de la CLI
Si tenemos la siguiente política almacenada en el archivo `policy.json` de la máquina:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-test-bucket",
"arn:aws:s3:::my-test-bucket/*"
],
"Sid": "AllowS3Getobject"
}
]
}
```
------
A continuación, podemos iniciar un trabajo con esta política mediante el siguiente AWS CLI comando:
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options
--execution-iam-policy '{
"policy": '$(jq -c '. | @json' policy.json)'
}'
```
También puede utilizar ambas políticas AWS y las gestionadas por el cliente, especificándolas mediante ARNs:
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options
--execution-iam-policy '{
"policyArns": [
"arn:aws:iam::aws:policy/AmazonS3FullAccess",
"arn:aws:iam::aws:policy/CloudWatchLogsFullAccess"
]
}'
```
También es posible especificar una política de IAM integrada y una política gestionada ARNs en la misma solicitud:
```
aws emr-serverless start-job-run --region us-west-2 \
--application-id application-id \
--execution-role-arn execution-role-arn \
--job-driver job-driver-options
--execution-iam-policy '{
"policy": '$(jq -c '. | @json' policy.json)',
"policyArns": [
"arn:aws:iam::aws:policy/AmazonS3FullAccess",
"arn:aws:iam::aws:policy/CloudWatchLogsFullAccess"
]
}'
```
## Notas importantes
+ El campo `policy` de la `execution-role-policy` puede tener una longitud máxima de 2048 caracteres.
+ La cadena de política de IAM integrada que se especifica en el campo `policy` de la `execution-iam-policy` debe ajustarse al estándar de cadenas json y no debe omitir líneas nuevas ni comillas como en el ejemplo anterior.
+ Se ARNs puede especificar una lista de hasta 10 políticas gestionadas como valor en el campo`execution-iam-policy`. `policyArns`
+ La política administrada ARNs debe ser una lista de ARN de políticas administradas por el cliente AWS o válidas. Cuando se especifica un ARN de política administrada por el cliente, la política debe pertenecer a la misma AWS cuenta del EMR-S. JobRun
+ Cuando se usan una política de IAM integrada y políticas administradas, el texto simple que se utilice para ambas políticas combinadas no puede superar los 2048 caracteres.
+ Los permisos resultantes que asume JobRun son la intersección de los permisos de la función de ejecución y la política de IAM de ejecución especificada.
## Intersección de políticas
Los permisos resultantes que asume la ejecución del trabajo son la intersección de los permisos del rol de ejecución y la política de IAM de ejecución especificada. Lo que significa que cualquier permiso requerido tendrá que especificarse en ambos lugares JobRun para que funcione. Sin embargo, es posible especificar una declaración de autorización general adicional en la política integrada para cualquier permiso que no se pretenda actualizar o sobrescribir.
Ejemplo
Dada la siguiente política de rol de IAM de ejecución:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"*"
],
"Sid": "AllowS3"
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": [
"arn:aws:logs:us-west-2:123456789012:log-group::log-stream"
],
"Sid": "AllowLOGSDescribeloggroups"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:DescribeTable"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/MyCompany1table"
],
"Sid": "AllowDYNAMODBDescribetable"
}
]
}
```
------
Y la siguiente política de IAM insertada:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-test-bucket/tenant1",
"arn:aws:s3:::my-test-bucket/tenant1/*"
],
"Sid": "AllowS3Getobject"
},
{
"Effect": "Allow",
"Action": [
"logs:*",
"dynamodb:*"
],
"Resource": [
"*"
],
"Sid": "AllowLOGS"
}
]
}
```
------
Los permisos resultantes que asumen JobRun son:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-test-bucket/tenant1",
"arn:aws:s3:::my-test-bucket/tenant1/*"
],
"Sid": "AllowS3Getobject"
},
{
"Effect": "Allow",
"Action": [
"logs:DescribeLogGroups"
],
"Resource": [
"arn:aws:logs:us-west-2:123456789012:log-group::log-stream"
],
"Sid": "AllowLOGSDescribeloggroups"
},
{
"Effect": "Allow",
"Action": [
"dynamodb:DescribeTable"
],
"Resource": [
"arn:aws:dynamodb:*:*:table/MyCompany1table"
],
"Sid": "AllowDYNAMODBDescribetable"
}
]
}
```
------
# Uso de discos optimizados para reproducción aleatoria
Con las versiones 7.1.0 y posteriores de Amazon EMR, utilice discos optimizados para la reproducción aleatoria cuando ejecute tareas de Apache Spark o Hive para mejorar el rendimiento de las operaciones (por segundo), a fin de acelerar el movimiento de los datos y reducir la latencia durante I/O-intensive workloads. Compared to standard disks, shuffle-optimized disks provide higher IOPS (I/O las operaciones de mezcla aleatoria. Los discos optimizados para la reproducción aleatoria le permiten conectar discos de hasta 2 TB por trabajador, por lo que puede configurar la capacidad adecuada para sus requisitos de cargas de trabajo.
## Ventajas principales
Los discos optimizados para la reproducción aleatoria proporcionan las siguientes ventajas.
+ **Alto rendimiento de IOPS**: los discos optimizados para la reproducción aleatoria proporcionan más IOPS que los discos estándar, lo que permite una transferencia de datos más eficiente y rápida durante las tareas de Spark y Hive y otras cargas de trabajo de uso intensivo en su reproducción.
+ **Tamaño de disco más grande**: los discos optimizados para la reproducción aleatoria admiten tamaños de disco de 20 GB a 2 TB por trabajador, por lo que puede elegir la capacidad adecuada en función de sus cargas de trabajo.
## Introducción
Consulte los siguientes pasos para usar discos optimizados para la reproducción aleatoria en sus flujos de trabajo.
------
#### [ Spark ]
1. Cree una aplicación EMR sin servidor versión 7.1.0 con el siguiente comando.
```
aws emr-serverless create-application \
--type "SPARK" \
--name my-application-name \
--release-label emr-7.1.0 \
--region
```
1. Configure su trabajo de Spark para que incluya los parámetros que se ejecutarán con discos optimizados para la reproducción aleatoria. `spark.emr-serverless.driver.disk.type` and/or `spark.emr-serverless.executor.disk.type` Puede utilizar uno o ambos parámetros en función de su caso de uso.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi
--conf spark.executor.cores=4
--conf spark.executor.memory=20g
--conf spark.driver.cores=4
--conf spark.driver.memory=8g
--conf spark.executor.instances=1
--conf spark.emr-serverless.executor.disk.type=shuffle_optimized"
}
}'
```
Para obtener más información, consulte [Spark job properties](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-spark.html#spark-defaults).
------
#### [ Hive ]
1. Cree una aplicación EMR sin servidor versión 7.1.0 con el siguiente comando.
```
aws emr-serverless create-application \
--type "HIVE" \
--name my-application-name \
--release-label emr-7.1.0 \
--region
```
1. Configura tu trabajo de Hive para que incluya los parámetros que se ejecutarán con discos optimizados `hive.driver.disk.type` and/or `hive.tez.disk.type` para la reproducción aleatoria. Puede utilizar uno o ambos parámetros en función de su caso de uso.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "s3:///emr-serverless-hive/query/hive-query.ql",
"parameters": "--hiveconf hive.log.explain.output=false"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.exec.scratchdir": "s3:///emr-serverless-hive/hive/scratch",
"hive.metastore.warehouse.dir": "s3:///emr-serverless-hive/hive/warehouse",
"hive.driver.cores": "2",
"hive.driver.memory": "4g",
"hive.tez.container.size": "4096",
"hive.tez.cpu.vcores": "1",
"hive.driver.disk.type": "shuffle_optimized",
"hive.tez.disk.type": "shuffle_optimized"
}
}]
}'
```
Para obtener más información, consulte [Propiedades de trabajos de Hive](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/jobs-hive.html#hive-defaults).
------
**Configuración de una aplicación con capacidad preinicializada**
Consulte los siguientes ejemplos para crear aplicaciones basadas en la versión 7.1.0 de Amazon EMR. Estas aplicaciones tienen las propiedades siguientes:
+ 5 controladores de Spark preinicializados, cada uno con 2 vCPU, 4 GB de memoria y 50 GB de disco optimizado para reproducción aleatoria.
+ 50 ejecutores preinicializados, cada uno con 4 vCPU, 8 GB de memoria y 500 GB de disco optimizado para reproducción aleatoria.
Cuando esta aplicación ejecuta tareas de Spark, primero consume los trabajadores preinicializados y, a continuación, escala verticalmente los trabajadores bajo demanda hasta la capacidad máxima de 400 vCPU y 1024 GB de memoria. Si lo desea, puede omitir la capacidad del trabajador del `DRIVER` o del `EXECUTOR`.
------
#### [ Spark ]
```
aws emr-serverless create-application \
--type "SPARK" \
--name \
--release-label emr-7.1.0 \
--initial-capacity '{
"DRIVER": {
"workerCount": 5,
"workerConfiguration": {
"cpu": "2vCPU",
"memory": "4GB",
"disk": "50GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
},
"EXECUTOR": {
"workerCount": 50,
"workerConfiguration": {
"cpu": "4vCPU",
"memory": "8GB",
"disk": "500GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
}
}' \
--maximum-capacity '{
"cpu": "400vCPU",
"memory": "1024GB"
}'
```
------
#### [ Hive ]
```
aws emr-serverless create-application \
--type "HIVE" \
--name \
--release-label emr-7.1.0 \
--initial-capacity '{
"DRIVER": {
"workerCount": 5,
"workerConfiguration": {
"cpu": "2vCPU",
"memory": "4GB",
"disk": "50GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
},
"EXECUTOR": {
"workerCount": 50,
"workerConfiguration": {
"cpu": "4vCPU",
"memory": "8GB",
"disk": "500GB",
"diskType": "SHUFFLE_OPTIMIZED"
}
}
}' \
--maximum-capacity '{
"cpu": "400vCPU",
"memory": "1024GB"
}'
```
------
# Uso del almacenamiento sin servidor para Amazon EMR Serverless
Con las versiones 7.12 y posteriores de Amazon EMR, utilice almacenamiento sin servidor cuando ejecute trabajos de Apache Spark para eliminar el aprovisionamiento de discos locales y reducir los costes de procesamiento de datos, además de evitar errores en los trabajos debido a las limitaciones de capacidad del disco. El almacenamiento sin servidor gestiona automáticamente las operaciones de mezcla, dispersión de discos y almacenamiento en caché de disco para sus trabajos sin necesidad de configurar la capacidad y almacena los datos intermedios sin coste alguno. Amazon EMR Serverless almacena los datos intermedios en un almacenamiento sin servidor totalmente gestionado que se escala automáticamente en función de las exigencias de la carga de trabajo y permite a Spark liberar a los trabajadores informáticos inmediatamente cuando están inactivos, lo que reduce los costes de procesamiento.
## Ventajas principales
El almacenamiento sin servidor para EMR Serverless ofrece las siguientes ventajas.
+ Almacenamiento **sin configuración: el almacenamiento** sin servidor elimina la necesidad de configurar el tipo y el tamaño del disco local para cada aplicación o trabajo. EMR Serverless administra automáticamente las operaciones de datos intermedias sin planificar la capacidad.
+ **Evita las fallas en los trabajos mediante el escalado automático**: la capacidad de almacenamiento se escala automáticamente en función de la demanda de carga de trabajo, lo que evita que se produzcan fallas en las tareas debido a una capacidad de disco insuficiente.
+ **Reducción de los costos de procesamiento de datos**: el almacenamiento sin servidor reduce los costos de procesamiento mediante dos mecanismos. En primer lugar, el almacenamiento intermedio de datos se proporciona sin costo alguno; solo se paga por los recursos de cómputo y memoria. En segundo lugar, el almacenamiento disociado de la asignación dinámica de recursos de Spark permite a Spark liberar a los trabajadores inmediatamente cuando están inactivos, en lugar de retenerlos para conservar los datos intermedios en los discos locales. Esto permite una escalabilidad horizontal y horizontal más rápida por etapa de Spark, lo que reduce los costos de cómputo en trabajos en los que las etapas posteriores requieren menos trabajadores que las etapas iniciales.
+ **Almacenamiento cifrado con aislamiento a nivel de trabajo**: todos los datos intermedios se cifran en tránsito y en reposo con un aislamiento estricto a nivel de trabajo.
+ **Soporte de control de acceso detallado: el almacenamiento sin servidor admite un control** de acceso detallado a través de la integración de AWS Lake Formation.
## Introducción
Consulta los siguientes pasos para usar el almacenamiento sin servidor para EMR Serverless en tus flujos de trabajo de Spark.
1. **Crear una aplicación EMR sin servidor**
Cree una aplicación EMR Serverless versión 7.12 (o posterior) con el almacenamiento sin servidor habilitado estableciendo la propiedad spark en **true** en la clasificación `spark.aws.serverlessStorage.enabled` spark-defaults.
```
aws emr-serverless create-application \
--type "SPARK" \
--name my-application \
--release-label emr-7.12.0 \
--runtime-configuration '[{
"classification": "spark-defaults",
"properties": {
"spark.aws.serverlessStorage.enabled": "true"
}
}]' \
--region
```
1. **Inicie un trabajo en Spark**
Inicie una ejecución de tareas en su aplicación. Almacenamiento sin servidor para EMR Serverless gestiona automáticamente las operaciones de datos intermedias, como la mezcla aleatoria, para su trabajo.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3:///script.py",
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=20g
--conf spark.driver.cores=4
--conf spark.driver.memory=8g
--conf spark.executor.instances=10"
}
}'
```
También puede habilitar el almacenamiento sin servidor para EMR Serverless a nivel de trabajo, incluso cuando no esté habilitado a nivel de aplicación. Esto lanzará nodos de trabajo habilitados con almacenamiento sin servidor para procesar sus trabajos. **También puedes inhabilitar el almacenamiento sin servidor para un trabajo específico configurando la misma propiedad de Spark en `spark.aws.serverlessStorage.enabled` false.**
```
# Turn on serverless storage for EMR serverless for a specific job
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi
--conf spark.aws.serverlessStorage.enabled": "true"
}
}'
```
**nota**
**Para seguir utilizando el aprovisionamiento de discos locales tradicional, omite la `spark.aws.serverlessStorage.enabled` configuración o establézcala en false.**
## Consideraciones y limitaciones
+ **Versión de lanzamiento**: el almacenamiento sin servidor es compatible con la versión 7.12 y versiones posteriores de Amazon EMR.
+ **Límites de volumen de datos**: cada trabajo puede leer y escribir hasta un total de 200 GB de datos intermedios por ejecución de trabajo. Los trabajos que superen este límite fallarán y aparecerá un mensaje de error que indicará que se ha alcanzado el límite de almacenamiento sin servidor.
+ Tiempo de **espera de ejecución de trabajos**: el almacenamiento sin servidor admite trabajos con tiempos de espera de ejecución de hasta 24 horas. Los trabajos configurados para tiempos de espera de ejecución más prolongados fallarán y aparecerá un mensaje de error.
+ Capacidad **preinicializada: los trabajadores con capacidad** preinicializada no admiten el almacenamiento sin servidor. Al configurar la capacidad preinicializada, solo la utilizarán los trabajos que inhabiliten explícitamente el almacenamiento sin servidor a nivel de trabajo. Los trabajos con almacenamiento sin servidor habilitado siempre aprovisionarán nuevos trabajadores a pedido y no utilizarán ninguna capacidad preinicializada, independientemente de la configuración a nivel de aplicación.
+ **Tipos de carga de trabajo**: el almacenamiento sin servidor no es compatible con los trabajos interactivos y de streaming.
+ **Configuración de trabajo**: el almacenamiento sin servidor no es compatible con los trabajadores con 1 o 2 unidades. CPUs
## Compatible Regiones de AWS
EMR Serverless admite el almacenamiento sin servidor en las siguientes regiones:
+ Este de EE. UU. (Norte de Virginia)
+ Oeste de EE. UU. (Oregón)
+ Europa (Irlanda)
# Trabajos de streaming para procesar datos transmitidos de forma continua
Un trabajo de streaming en EMR sin servidor es un modo de trabajo que le permite analizar y procesar los datos de streaming casi en tiempo real. Estos trabajos de larga duración recopilan los datos de streaming y procesan continuamente los resultados a medida que llegan los datos. Los trabajos de streaming son los más adecuados para las tareas que requieren un procesamiento de datos en tiempo real, como los análisis casi en tiempo real, la detección de fraudes y los motores de recomendaciones. Los trabajos de streaming de EMR sin servidor proporcionan optimizaciones, como la resiliencia de los trabajos integrada, la monitorización en tiempo real, la administración mejorada de registros y la integración con conectores de streaming.
Estos son algunos casos de uso con trabajos de streaming:
+ **Análisis casi en tiempo real**: los trabajos de streaming en Amazon EMR sin servidor le permiten procesar los datos de streaming casi en tiempo real, de modo que puede realizar análisis en tiempo real de flujos de datos continuos, como datos de registros, datos de sensores o flujos de clics para obtener información y tomar decisiones oportunas en función de la información más reciente.
+ **Detección de fraudes**: use los trabajos de streaming para detectar fraudes casi en tiempo real en transacciones financieras, operaciones con tarjetas de crédito o actividades en línea al analizar los flujos de datos e identificar anomalías y patrones sospechosos a medida que se producen.
+ **Motores de recomendación**: los trabajos de streaming pueden procesar los datos de actividad de los usuarios y actualizar los modelos de recomendaciones. Esto abre la posibilidad de realizar recomendaciones personalizadas y en tiempo real en función de los comportamientos y las preferencias.
+ **Análisis de redes sociales**: los trabajos de streaming pueden procesar datos de redes sociales en tiempo real, como tuits, publicaciones o comentarios, lo que permite a las organizaciones supervisar las tendencias, analizar las opiniones y gestionar la reputación de la marca en casi tiempo real.
+ **Análisis del Internet de las cosas (IoT)**: los trabajos de streaming pueden permitir gestionar y analizar los flujos de datos de alta velocidad de maquinaria conectada y dispositivos y sensores del IoT, de modo que usted pueda ejecutar la detección de anomalías, el mantenimiento predictivo y otros casos de uso de análisis del IoT.
+ **Análisis del flujo de clics**: los trabajos de streaming pueden procesar y analizar los datos del flujo de clics procedentes de sitios web o aplicaciones móviles. Las empresas que utilizan estos datos pueden realizar análisis para obtener más información sobre el comportamiento de los usuarios, personalizar las experiencias de los usuarios y optimizar las campañas de marketing.
+ **Supervisión y análisis de registros**: los trabajos de streaming pueden también procesarlos datos del registro de servidores, aplicaciones o dispositivos de red. Esto le permite detectar anomalías, solucionar problemas y obtener información acerca del estado y el rendimiento del sistema.
**Ventajas principales**
Los trabajos de streaming en EMR sin servidor proporcionan automáticamente *resiliencia al trabajo*, siendo una combinación de los siguientes factores:
+ **Reintento automático**: EMR sin servidor reintenta automáticamente cualquier trabajo que haya fallado sin ninguna intervención manual por su parte.
+ **Resiliencia de la zona de disponibilidad (AZ)**: EMR sin servidor cambia automáticamente los trabajos de streaming a una AZ en buen estado si la AZ original tiene problemas.
+ **Administración de registros:**
+ **Rotación de registros**: para una administración más eficiente del almacenamiento en disco, EMR sin servidor rota periódicamente los registros para trabajos de streaming prolongados. De este modo, se evita la acumulación de registros que podrían consumir todo el espacio en disco.
+ **Compactación de registros**: le ayuda a administrar y optimizar de manera eficiente los archivos de registro en sistemas de persistencia administrada. La compactación también mejora la experiencia de depuración cuando se utiliza el servidor de historial de Spark administrado.
**Fuentes de datos y receptores de datos compatibles**
EMR sin servidor funciona con varias fuentes de datos de entrada y receptores de datos de salida:
+ Fuentes de datos de entrada admitidas: Amazon Kinesis Data Streams, Amazon Managed Streaming para Apache Kafka y los clústeres de Apache Kafka autogestionado. De forma predeterminada, las versiones 7.1.0 y posteriores de Amazon EMR incluyen el [conector de Amazon Kinesis Data Streams](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-structured-streaming-kinesis.html), por lo que no es necesario crear ni descargar ningún paquete adicional.
+ Sumideros de datos de salida compatibles: tablas de AWS Glue Data Catalog, Amazon S3, Amazon Redshift, MySQL, PostgreSQL, Oracle, Oracle, Microsoft SQL, Apache Iceberg, Delta Lake y Apache Hudi.
## Consideraciones y limitaciones
Cuando utilice los trabajos de streaming, tenga en cuenta las siguientes consideraciones y limitaciones.
+ Los trabajos de streaming son compatibles con las [versiones 7.1.0 y posteriores de Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-710-release.html).
+ EMR sin servidor espera que los trabajos de streaming se ejecuten durante mucho tiempo, por lo que no puede establecer un tiempo de espera de ejecución para limitar el tiempo de ejecución del trabajo.
+ Los trabajos de streaming solo son compatibles con el motor Spark, que se basa en el [marco de streaming estructurado](https://spark.apache.org/streaming/).
+ EMR sin servidor reintenta los trabajos de streaming de forma indefinida y usted no se puede personalizar el número máximo de intentos. La función de prevención de errores se incluye automáticamente para detener el reintento del trabajo si la cantidad de intentos fallidos ha superado el umbral establecido durante un período de una hora. El umbral predeterminado es de cinco intentos fallidos en una hora. Puede configurar este umbral para que esté entre 1 y 10 intentos. Para obtener más información, consulte [Resiliencia de trabajos](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/SECTION-jobs-resiliency.xml.html).
+ Los trabajos de streaming tienen puntos de comprobación para guardar el estado y el progreso del tiempo de ejecución, por lo que EMR sin servidor puede reanudar el trabajo de streaming desde el último punto de comprobación. Para obtener más información, consulte [Recovering from failures with Checkpointing](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#recovering-from-failures-with-checkpointing) en la documentación de Apache Spark.
# Introducción a trabajos de streaming
Consulte las siguientes instrucciones para obtener información sobre cómo empezar a realizar trabajos de streaming.
1. Siga con al [Introducción a Amazon EMR sin servidor para crear una aplicación](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/getting-started.html). Tenga en cuenta que su aplicación debe ejecutar [Amazon EMR con la versión 7.1.0 o superior](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-710-release.html).
1. Una vez que la aplicación esté lista, defina el `mode` parámetro `STREAMING` para enviar un trabajo de streaming, similar al ejemplo siguiente. AWS CLI
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3"
}
}'
```
# Conectores de streaming admitidos
Los conectores de streaming facilitan la lectura de datos de una fuente de streaming y también pueden escribir datos en un receptor de streaming.
Los siguientes son los conectores de streaming admitidos:
**Conector Amazon Kinesis Data Streams**
El [conector Amazon Kinesis Data Streams](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-spark-structured-streaming-kinesis.html) para Apache Spark permite crear aplicaciones y canalizaciones de streaming que consumen datos del Amazon Kinesis Data Streams, además de escribir en él. El conector permite aumentar el consumo del ventilador con una velocidad de lectura específica de hasta 2 MB/segundo por partición. De forma predeterminada, Amazon EMR sin servidor 7.1.0 y versiones posteriores incluyen el conector, por lo que no es necesario compilar ni descargar ningún paquete adicional. Para obtener más información sobre el conector, consulte la [ spark-sql-kinesis-connectorpágina de GitHub](https://github.com/awslabs/spark-sql-kinesis-connector/).
A continuación, se muestra un ejemplo de cómo iniciar la ejecución de un trabajo con la dependencia del conector de Kinesis Data Streams.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3
--jars /usr/share/aws/kinesis/spark-sql-kinesis/lib/spark-streaming-sql-kinesis-connector.jar"
}
}'
```
Para conectarse a Kinesis Data Streams, configure la aplicación EMR sin servidor con acceso a la VPC y usar un punto de conexión de VPC para permitir el acceso privado, o usar una puerta de enlace NAT para obtener el acceso público. Para obtener más información, consulte [Configuración del acceso a la VPC](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/vpc-access.html). Asimismo, debe asegurarse de que su rol de tiempo de ejecución de trabajos tenga los permisos de lectura y escritura necesarios para obtener acceso a los flujos de datos requeridos. Para obtener más información sobre cómo configurar un rol de tiempo de ejecución de tareas, consulte [Job runtime roles for Amazon EMR Serverless](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/security-iam-runtime-role.html). Para obtener una lista completa de todos los permisos necesarios, consulte la [spark-sql-kinesis-connector página en GitHub](https://github.com/awslabs/spark-sql-kinesis-connector/?tab=readme-ov-file#how-to-use-it).
**Conector Kafka de Apache**
El conector Apache Kafka para el streaming estructurado de Spark es un conector de código abierto de la comunidad de Spark y está disponible en un repositorio de Maven. Este conector facilita que las aplicaciones de streaming estructurado de Spark lean y escriban datos en Apache Kafka autogestionado y Amazon Managed Streaming para Apache Kafka. Para obtener más información sobre el conector, consulte [Structured Streaming \$1 Kafka Integration Guide](https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html) en la documentación de Apache Spark.
En el siguiente ejemplo se muestra cómo incluir el conector Kafka en la solicitud de ejecución de trabajos.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3
--packages org.apache.spark:spark-sql-kafka-0-10_2.12:"
}
}'
```
La versión del conector Apache Kafka depende de la versión de EMR sin servidor y de la versión de Spark correspondiente. Para encontrar la versión correcta de Kafka, consulte [Structured Streaming \$1 Kafka Integration Guide](https://spark.apache.org/docs/latest/structured-streaming-kafka-integration.html).
Para utilizar Amazon Managed Streaming para Apache Kafka con autenticación de IAM, incluya otra dependencia para permitir que el conector de Kafka se conecte a Amazon MSK con IAM. Para obtener más información, consulte el [aws-msk-iam-auth repositorio en GitHub](https://github.com/aws/aws-msk-iam-auth). Asimismo, debe asegurarse de que el rol de tiempo de ejecución del trabajo tenga los permisos de IAM necesarios. En el siguiente ejemplo se muestra cómo utilizar el conector con la autenticación de IAM.
```
aws emr-serverless start-job-run \
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://",
"entryPointArguments": ["s3:///output"],
"sparkSubmitParameters": "--conf spark.executor.cores=4
--conf spark.executor.memory=16g
--conf spark.driver.cores=4
--conf spark.driver.memory=16g
--conf spark.executor.instances=3
--packages org.apache.spark:spark-sql-kafka-0-10_2.12:,software.amazon.msk:aws-msk-iam-auth:"
}
}'
```
Para utilizar el conector Kafka y la biblioteca de autenticación de IAM de Amazon MSK, configure la aplicación EMR sin servidor con acceso a la VPC. Sus subredes deben tener acceso a Internet y utilizar una puerta de enlace NAT para acceder a las dependencias de Maven. Para obtener más información, consulte [Configuración del acceso a la VPC](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/vpc-access.html). Las subredes deben tener conectividad de red para acceder al clúster de Kafka. Esto ocurre independientemente de si su clúster de Kafka es autogestionado o si utiliza Amazon Managed Streaming para Apache Kafka.
# Administración de registros de trabajos en streaming
Los trabajos de streaming admiten la rotación de registros para los registros de aplicaciones y eventos de Spark, así como la compactación de registros para los registros de eventos de Spark. Esto le ayuda a administrar sus recursos con eficacia.
**Rotación de registros**
Los trabajos de streaming admiten la rotación de registros para los registros de aplicaciones y registros de eventos de Spark. La rotación de registros evita que los trabajos de streaming prolongados generen archivos de registro de gran tamaño que podrían ocupar todo el espacio disponible en el disco. La rotación de registros le ayuda a ahorrar espacio en disco y evita errores en los trabajos debido a la falta de espacio en disco. Para obtener más información, consulte [Rotación de registros](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/rotating-logs.html).
**Compactación de registros**
Los trabajos de streaming también admiten la compactación de registros para los registros de eventos de Spark siempre que haya registros administrados disponibles. Para obtener más información sobre los registros administrados, consulte [Logging with managed storage](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/logging.html#jobs-log-storage-managed-storage). Los trabajos de streaming pueden durar bastante, y la cantidad de datos de eventos puede acumularse con el tiempo y aumentar considerablemente el tamaño de los archivos de registro. El servidor de historial de Spark lee y carga estos eventos en la memoria para la IU de la aplicación Spark. Este proceso puede provocar elevados costes y latencias, especialmente si los registros de eventos almacenados en Amazon S3 son muy grandes.
La compactación de registros reduce el tamaño del registro de eventos, por lo que el servidor de historial de Spark no necesita cargar más de 1 GB de registros de eventos en ningún momento. Para obtener más información, consulte [Monitoring and Instrumentation](https://spark.apache.org/docs/latest/monitoring.html) en la documentación de Apache Spark.
# Uso de configuraciones de Spark al ejecutar trabajos de EMR sin servidor
Puede ejecutar trabajos de Spark en una aplicación con el parámetro `type` establecido en `SPARK`. Los trabajos deben ser compatibles con la versión de Spark compatible con la versión de lanzamiento de Amazon EMR. Por ejemplo, cuando ejecuta trabajos en una aplicación con la versión 6.6.0 de Amazon EMR, su trabajo debe ser compatible con Apache Spark 3.2.0. Para obtener información sobre las versiones de la aplicación para cada versión, consulte [Versiones lanzamiento de Amazon EMR sin servidor](release-versions.md).
## Parámetros de trabajos de Spark
Al utilizar la [API `StartJobRun`](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html) para ejecutar un trabajo de Spark, especifique los siguientes parámetros.
**Topics**
+ [Rol de tiempo de ejecución de trabajos de Spark](#spark-defaults-executionRoleArn)
+ [Parámetro del controlador de trabajos de Spark](#spark-defaults-jobDriver)
+ [Parámetro de anulación de configuración de Spark](#spark-defaults-configurationOverrides)
+ [Optimización de asignación de recursos dinámicos de Spark](#spark-defaults-dynamicResourceAllocation)
### Rol de tiempo de ejecución de trabajos de Spark
Utilice **`executionRoleArn`** para especificar el ARN del rol de IAM que la aplicación utiliza para ejecutar los trabajos de Spark. Este rol debe tener los siguientes permisos:
+ Lectura de los buckets de S3 u otras fuentes de datos en las que residen sus datos
+ Lea los buckets o prefijos de S3 donde reside su PySpark script o archivo JAR
+ Escritura en los buckets de S3 donde desee escribir el resultado final
+ Escritura en los registros en un prefijo o bucket de S3 que especifique `S3MonitoringConfiguration`
+ Acceso a las claves de KMS si usa claves de KMS para cifrar los datos en el bucket de S3
+ Acceso al catálogo de datos de AWS Glue si usa SparkSQL
Si su trabajo de Spark lee o escribe datos en –o desde– otras fuentes de datos, especifique los permisos adecuados en este rol de IAM. Si no proporciona estos permisos al rol de IAM, es posible que el trabajo no funcione. Para obtener más información, consulte [Roles en tiempo de ejecución de trabajo para Amazon EMR sin servidor](security-iam-runtime-role.md) y [Almacenamiento de registros](logging.md).
### Parámetro del controlador de trabajos de Spark
Utilice **`jobDriver`** para proporcionar datos al trabajo. El parámetro del controlador de trabajo solo acepta un valor para el tipo de trabajo que desee ejecutar. Para un trabajo de Spark, el valor del parámetro es `sparkSubmit`. Puede usar este tipo de trabajo para ejecutar Scala PySpark, Java y cualquier otro trabajo compatible a través de Spark submit. Los trabajos de Spark tienen los parámetros siguientes:
+ **`sparkSubmitParameters`**: son los parámetros de Spark adicionales que desea enviar al trabajo. Use este parámetro para anular las propiedades predeterminadas de Spark, como la memoria del controlador o el número de ejecutores, como aquellos definidos en los argumentos `--conf` o `--class`.
+ **`entryPointArguments`**: se trata de un conjunto de argumentos que desea pasar a su archivo Python o JAR principal. Debería manejar la lectura de estos parámetros mediante su código de punto de entrada. Separe cada argumento del conjunto con una coma.
+ **`entryPoint`**: esta es la referencia en Amazon S3 al archivo Python o JAR principal que desea ejecutar. Si está ejecutando un JAR de Scala o Java, especifique la clase de entrada principal en `SparkSubmitParameters` utilizando el argumento `--class`.
Para obtener más información, consulte [Launching Applications with spark-submit](https://spark.apache.org/docs/latest/submitting-applications.html#launching-applications-with-spark-submit).
### Parámetro de anulación de configuración de Spark
Utilice **`configurationOverrides`** para anular las propiedades de configuración a nivel de monitorización y de aplicación. Este parámetro acepta un objeto JSON con los dos campos siguientes:
+ **`monitoringConfiguration`**: utilice este campo para especificar la URL de Amazon S3 (`s3MonitoringConfiguration`) en la que quiere que el trabajo del EMR sin servidor almacene los registros de su trabajo de Spark. Asegúrate de haber creado este bucket con el mismo lugar en el Cuenta de AWS que se aloja tu aplicación y en el mismo Región de AWS lugar en el que se ejecuta tu trabajo.
+ **`applicationConfiguration`**: para anular las configuraciones predeterminadas de las aplicaciones, puede proporcionar un objeto de configuración en este campo. Puede utilizar una sintaxis abreviada para proporcionar la configuración o hacer referencia al objeto de configuración en un archivo JSON. Los objetos de configuración se componen de una clasificación, propiedades y configuraciones anidadas opcionales. Las propiedades consisten en las configuraciones que desea anular en ese archivo. Es posible especificar varias clasificaciones para varias aplicaciones en un solo objeto JSON.
**nota**
Las clasificaciones de configuración disponibles varían en función de la versión específica de EMR sin servidor. Por ejemplo, las clasificaciones para el Log4j personalizado `spark-driver-log4j2` y `spark-executor-log4j2` solo están disponibles en las versiones 6.8.0 y posteriores.
Si usa la misma configuración en una anulación de aplicación y en los parámetros de envío de Spark, los parámetros de envío de Spark tendrán prioridad. Las configuraciones se clasifican según prioridad de la siguiente manera, de mayor a menor:
+ Configuración que EMR sin servidor proporciona cuando crea `SparkSession`.
+ Configuración que usted proporciona como parte de los `sparkSubmitParameters` con el argumento `--conf`.
+ Configuración que usted proporciona como parte de la aplicación que se anula al iniciar un trabajo.
+ Configuración que usted proporciona como parte de la `runtimeConfiguration` al crear una aplicación.
+ Configuraciones optimizadas que Amazon EMR utiliza para la versión.
+ Configuraciones de código abierto predeterminadas para la aplicación.
Para obtener más información sobre la declaración de configuraciones a nivel de aplicación y la anulación de las configuraciones durante la ejecución de un trabajo, consulte [Configuración predeterminada de aplicación para EMR sin servidor](default-configs.md).
### Optimización de asignación de recursos dinámicos de Spark
Utilice `dynamicAllocationOptimization` para optimizar el uso de recursos en EMR sin servidor. Al establecer esta propiedad `true` en la clasificación de configuración de Spark, EMR sin servidor debe optimizar la asignación de recursos de los ejecutores para alinear mejor la velocidad a la que Spark solicita y cancela ejecutores con la velocidad a la que EMR sin servidor crea y libera trabajadores. Al hacerlo, EMR sin servidor reutiliza de manera más óptima a los trabajadores en todas las etapas, lo que reduce los costes al ejecutar trabajos con varias etapas y, al mismo tiempo, mantiene el mismo rendimiento.
Esta propiedad está disponible en todas las versiones de lanzamiento de Amazon EMR.
A continuación se muestra una clasificación de configuración de ejemplo con `dynamicAllocationOptimization`.
```
[
{
"Classification": "spark",
"Properties": {
"dynamicAllocationOptimization": "true"
}
}
]
```
Tenga en cuenta lo siguiente si utiliza la optimización de asignación dinámica:
+ Esta optimización está disponible para los trabajos de Spark para los que ha activado la asignación dinámica de recursos.
+ Para lograr la mejor rentabilidad, le sugerimos configurar un límite de escalado superior para los trabajadores, y utilice la configuración a nivel de trabajo `spark.dynamicAllocation.maxExecutors` o la configuración de [capacidad máxima a nivel de aplicación](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/app-behavior.html#max-capacity) en función de la carga de trabajo.
+ Es posible que no vea una mejora en los costes de los trabajos más sencillos. Por ejemplo, si su trabajo se ejecuta en un conjunto de datos pequeño o termina de ejecutarse en una etapa, es posible que Spark no necesite un mayor número de ejecutores ni varios eventos de escalado.
+ Los trabajos con una secuencia de una etapa grande, etapas más pequeñas y, después, una etapa más grande podrían experimentar una regresión en el tiempo de ejecución del trabajo. Dado que EMR sin servidor utiliza los recursos de manera más eficiente, es posible que haya menos trabajadores disponibles para las etapas más grandes y, por lo tanto, un tiempo de ejecución más prolongado.
## Propiedades de trabajo de Spark
La siguiente tabla enumera las propiedades opcionales de Spark y sus valores predeterminados que puede anular al enviar un trabajo de Spark.
**Propiedades opcionales y valores predeterminados de Spark**
| Key | Description (Descripción) | Predeterminado |
| --- | --- | --- |
| spark.archives | Lista separada por comas de archivos que Spark extrae en el directorio de trabajo de cada ejecutor. Los tipos de archivos admitidos son .jar, .tar.gz, .tgz y .zip. Para especificar el nombre del directorio que se va a extraer, añada \$1 después del nombre del archivo que desee extraer. Por ejemplo, file.zip\$1directory. | NULL |
| spark.authenticate | Opción que activa la autenticación de las conexiones internas de Spark. | TRUE |
| spark.driver.cores | La cantidad de núcleos que utiliza el controlador. | 4 |
| spark.driver.extraJavaOptions | Opciones de Java adicionales para el controlador de Spark. | NULL |
| spark.driver.memory | La cantidad de memoria que utiliza el controlador. | 14 G |
| spark.dynamicAllocation.enabled | Opción que activa la asignación dinámica de recursos. Esta opción escala o reduce verticalmente el número de ejecutores registrados en la aplicación, en función de la carga de trabajo. | TRUE |
| spark.dynamicAllocation.executorIdleTimeout | El tiempo que un ejecutor puede permanecer inactivo antes de que Spark lo elimine. Esto solo se aplica si activa la asignación dinámica. | 60 s |
| spark.dynamicAllocation.initialExecutors | El número inicial de ejecutores que se ejecutarán si activa la asignación dinámica. | 3 |
| spark.dynamicAllocation.maxExecutors | El límite superior del número de ejecutores si activa la asignación dinámica. | Para 6.10.0 y versiones posteriores, `infinity` Para 6.9.0 y versiones anteriores, `100` |
| spark.dynamicAllocation.minExecutors | El límite superior del número de ejecutores si activa la asignación dinámica. | 0 |
| spark.emr-serverless.allocation.batch.size | El número de contenedores que se van a solicitar en cada ciclo de asignación de ejecutores. Hay un intervalo de un segundo entre cada ciclo de asignación. | 20 |
| spark.emr-serverless.driver.disk | El disco del controlador de Spark. | 20 G |
| spark.emr-serverless.driverEnv.[KEY] | Opción que añade variables de entorno al controlador de Spark. | NULL |
| spark.emr-serverless.executor.disk | El disco ejecutor de Spark. | 20 G |
| spark.emr-serverless.memoryOverheadFactor | Establece la sobrecarga de memoria para añadirla a la memoria del contenedor del controlador y del ejecutor. | 0.1 |
| spark.emr-serverless.driver.disk.type | El tipo de disco conectado al controlador de Spark. | Standard |
| spark.emr-serverless.executor.disk.type | El tipo de disco conectado a los ejecutores de Spark. | Standard |
| spark.executor.cores | El número de núcleos que usa cada ejecutor. | 4 |
| spark.executor.extraJavaOptions | Opciones de Java adicionales para el ejecutor de Spark. | NULL |
| spark.executor.instances | El número de contenedores de ejecutores de Spark que se asignarán. | 3 |
| spark.executor.memory | La cantidad de memoria que utiliza cada ejecutor. | 14 G |
| spark.executorEnv.[KEY] | Opción que añade variables de entorno a los ejecutores de Spark. | NULL |
| spark.files | Lista de archivos separados por comas que se colocarán en el directorio de trabajo de cada ejecutor. Puede acceder a las rutas de estos archivos en el ejecutor con SparkFiles.get(fileName). | NULL |
| spark.hadoop.hive.metastore.client.factory.class | La clase de implementación del metaalmacén de Hive. | NULL |
| spark.jars | Archivos jar adicionales para añadirlos a la ruta de clases de tiempo de ejecución del controlador y los ejecutores. | NULL |
| spark.network.crypto.enabled | Opción que activa el cifrado RPC basado en AES. Esto incluye el protocolo de autenticación agregado en Spark 2.2.0. | FALSE |
| spark.sql.warehouse.dir | La ubicación predeterminada para las bases de datos y tablas administradas. | El valor de \$1PWD/spark-warehouse |
| spark.submit.pyFiles | Una lista separada por comas de archivos .zip, .egg o .py para colocarlos en la PYTHONPATH en las aplicaciones de Python. | NULL |
En la tabla siguiente se enumeran los parámetros de envío predeterminados de Spark.
**Parámetros de envío predeterminados de Spark**
| Key | Description (Descripción) | Predeterminado |
| --- | --- | --- |
| archives | Lista separada por comas de archivos que Spark extrae en el directorio de trabajo de cada ejecutor. | NULL |
| class | La clase principal de la aplicación (para aplicaciones Java y Scala). | NULL |
| conf | Una propiedad de configuración arbitraria de Spark. | NULL |
| driver-cores | La cantidad de núcleos que utiliza el controlador. | 4 |
| driver-memory | La cantidad de memoria que utiliza el controlador. | 14 G |
| executor-cores | El número de núcleos que usa cada ejecutor. | 4 |
| executor-memory | La cantidad de memoria que utiliza el ejecutor. | 14 G |
| files | Lista de archivos separados por comas que se colocarán en el directorio de trabajo de cada ejecutor. Puede acceder a las rutas de estos archivos en el ejecutor con SparkFiles.get(fileName). | NULL |
| jars | Lista separada por comas de archivos jar para incluirlos en las rutas de clases del controlador y el ejecutor. | NULL |
| num-executors | El número de ejecutores que se van a lanzar. | 3 |
| py-files | Una lista separada por comas de archivos .zip, .egg o .py para colocarlos en la PYTHONPATH para las aplicaciones de Python. | NULL |
| verbose | Opción que activa una salida de depuración adicional. | NULL |
## Prácticas recomendadas de configuración de recursos
### Configuración de los recursos del controlador y el ejecutor mediante la API StartJobRun
**nota**
Los núcleos y las propiedades de memoria de los controladores y ejecutores de Spark, si se especifican, deben especificarse directamente en la solicitud de la StartJobRun API.
La configuración de los recursos de esta manera garantiza que EMR sin servidor pueda asignar los recursos correctos antes de ejecutar el trabajo. Esto contrasta con la configuración que se proporciona en el script de usuario, como en el archivo .py o .jar, que se evalúa demasiado tarde, ya que los controladores y ejecutores a veces se aprovisionan previamente antes de que comience la ejecución del script. Se admiten dos formas de configurar estos recursos durante el envío del trabajo:
#### Opción 1: utilizar sparkSubmitParameters
```
"jobDriver": {
"sparkSubmit": {
"entryPoint": "s3://your-script-path.py",
"sparkSubmitParameters": "—conf spark.driver.memory=4g \
—conf spark.driver.cores=2 \
—conf spark.executor.memory=8g \
—conf spark.executor.cores=4"
}
}
```
#### Opción 2: use ConfigurationOverrides para la clasificación de spark-defaults
```
"configurationOverrides": {
"applicationConfiguration": [
{
"classification": "spark-defaults",
"properties": {
"spark.driver.memory": "4g",
"spark.driver.cores": "2",
"spark.executor.memory": "8g",
"spark.executor.cores": "4"
}
}
]
}
```
## Ejemplos de Spark
El siguiente ejemplo muestra cómo utilizar la API `StartJobRun` para ejecutar un script de Python. Para ver un end-to-end tutorial que utiliza este ejemplo, consulte[Introducción a Amazon EMR sin servidor](getting-started.md). Puede encontrar ejemplos adicionales de cómo ejecutar PySpark trabajos y agregar dependencias de Python en el repositorio de muestras [sin servidor GitHub de EMR.](https://github.com/aws-samples/emr-serverless-samples/tree/main/examples/pyspark)
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://us-east-1.elasticmapreduce/emr-containers/samples/wordcount/scripts/wordcount.py",
"entryPointArguments": ["s3://amzn-s3-demo-destination-bucket/wordcount_output"],
"sparkSubmitParameters": "--conf spark.executor.cores=1 --conf spark.executor.memory=4g --conf spark.driver.cores=1 --conf spark.driver.memory=4g --conf spark.executor.instances=1"
}
}'
```
El siguiente ejemplo muestra cómo utilizar la API `StartJobRun` para ejecutar un JAR de Spark.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi --conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
}
}'
```
# Uso de configuraciones de Hive al ejecutar trabajos de EMR sin servidor
Puede ejecutar trabajos de Hive en una aplicación con el parámetro `type` establecido en `HIVE`. Los trabajos deben ser compatibles con la versión de Hive compatible con la versión de lanzamiento de Amazon EMR. Por ejemplo, cuando ejecuta trabajos en una aplicación con Amazon EMR versión 6.6.0, su trabajo debe ser compatible con Apache Hive 3.1.2. Para obtener información sobre las versiones de la aplicación para cada versión, consulte [Versiones lanzamiento de Amazon EMR sin servidor](release-versions.md).
## Parámetros de los trabajos de Hive
Al utilizar la [API `StartJobRun`](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/API_StartJobRun.html) para ejecutar un trabajo de Hive, especifique los siguientes parámetros.
**Topics**
+ [Rol de tiempo de ejecución de los trabajos de Hive](#hive-defaults-executionRoleArn)
+ [Parámetros del controlador de los trabajos de Hive](#hive-defaults-jobDriver)
+ [Parámetro de anulación de la configuración de Hive](#hive-defaults-configurationOverrides)
### Rol de tiempo de ejecución de los trabajos de Hive
Utilice **`executionRoleArn`** para especificar el ARN del rol de IAM que la aplicación utiliza para ejecutar los trabajos de Hive. Este rol debe tener los siguientes permisos:
+ Lectura de los buckets de S3 u otras fuentes de datos en las que residen sus datos
+ Lectura de los prefijos o buckets de S3 donde residen el archivo de consulta de Hive y el archivo de consulta de init
+ Lectura y escritura en los buckets de S3 donde se residen el directorio de Hive Scratch y el directorio de almacén de Hive Metastore
+ Escritura en los buckets de S3 donde desee escribir el resultado final
+ Escritura en los registros en un bucket o prefijo de S3 que especifique `S3MonitoringConfiguration`
+ Acceso a las claves de KMS si usa claves de KMS para cifrar los datos en el bucket de S3
+ Acceso al catálogo de datos de AWS Glue
Si su trabajo de Hive lee o escribe datos en –o desde– otras fuentes de datos, especifique los permisos adecuados en este rol de IAM. Si no proporciona estos permisos al rol de IAM, es posible que su trabajo no funcione. Para obtener más información, consulta [Roles en tiempo de ejecución de trabajo para Amazon EMR sin servidor](security-iam-runtime-role.md).
### Parámetros del controlador de los trabajos de Hive
Utilice **`jobDriver`** para proporcionar datos al trabajo. El parámetro del controlador de trabajo solo acepta un valor para el tipo de trabajo que desee ejecutar. Cuando se especifica `hive` como tipo de trabajo, EMR sin servidor pasa una consulta de Hive al parámetro `jobDriver`. Los trabajos de Hive tienen los parámetros siguientes:
+ **`query`**: esta es la referencia en Amazon S3 al archivo de consulta de Hive que desea ejecutar.
+ **`parameters`**: estas son las propiedades de configuración adicionales de Hive que desea anular. Para anular las propiedades, páselas a este parámetro como `--hiveconf property=value`. Para anular las variables, páselas a este parámetro como `--hivevar key=value`.
+ **`initQueryFile`**: este es el archivo de consulta de Hive de init. Hive ejecuta este archivo antes de la consulta y puede usarlo para inicializar tablas.
### Parámetro de anulación de la configuración de Hive
Utilice **`configurationOverrides`** para anular las propiedades de configuración a nivel de monitorización y de aplicación. Este parámetro es un objeto JSON con los dos campos siguientes:
+ **`monitoringConfiguration`**: utilice este campo para especificar la URL de Amazon S3 (`s3MonitoringConfiguration`) donde desea que el trabajo de EMR sin servidor almacene los registros de su trabajo de Hive. Asegúrese de crear este depósito con el mismo Cuenta de AWS que aloja su aplicación y en el mismo Región de AWS lugar en el que se ejecuta su trabajo.
+ **`applicationConfiguration`**: puede proporcionar un objeto de configuración en este campo para anular las configuraciones para aplicaciones predeterminadas. Puede utilizar una sintaxis abreviada para proporcionar la configuración o hacer referencia al objeto de configuración en un archivo JSON. Los objetos de configuración se componen de una clasificación, propiedades y configuraciones anidadas opcionales. Las propiedades consisten en las configuraciones que desea anular en ese archivo. Es posible especificar varias clasificaciones para varias aplicaciones en un solo objeto JSON.
**nota**
Las clasificaciones de configuración disponibles varían en función de la versión específica de EMR sin servidor. Por ejemplo, las clasificaciones para el Log4j personalizado `spark-driver-log4j2` y `spark-executor-log4j2` solo están disponibles en las versiones 6.8.0 y posteriores.
Si pasa la misma configuración en una anulación de aplicación y en los parámetros de Hive, los parámetros de Hive tendrán prioridad. La siguiente lista clasifica las configuraciones de mayor a menor prioridad.
+ Configuración que se proporciona como parte de los parámetros de Hive con `--hiveconf property=value`.
+ Configuración que se proporciona como parte de la aplicación que se anula al iniciar un trabajo.
+ Configuración que se proporciona como parte de la `runtimeConfiguration` al crear una aplicación.
+ Configuraciones optimizadas que Amazon EMR asigna a la versión.
+ Configuraciones de código abierto predeterminadas para la aplicación.
Para obtener más información sobre la declaración de configuraciones a nivel de aplicación y la anulación de las configuraciones durante la ejecución de un trabajo, consulte [Configuración predeterminada de aplicación para EMR sin servidor](default-configs.md).
## Propiedades de los trabajos de Hive
En la siguiente tabla, se enumeran las propiedades obligatorias que debe configurar al enviar un trabajo de Hive.
**Propiedades obligatorias de los trabajos de Hive**
| Opción | Description (Descripción) |
| --- | --- |
| hive.exec.scratchdir | La ubicación de Amazon S3 en la que EMR sin servidor crea archivos temporales durante la ejecución del trabajo de Hive. |
| hive.metastore.warehouse.dir | La ubicación de Amazon S3 de las bases de datos para tablas administradas en Hive. |
La siguiente tabla enumera las propiedades opcionales de Hive y sus valores predeterminados que puede anular al enviar un trabajo de Hive.
**Propiedades opcionales y valores predeterminados de Hive**
| Opción | Description (Descripción) | Predeterminado |
| --- | --- | --- |
| fs.s3.customAWSCredentialsProvider | El proveedor de AWS credenciales que quieres usar. | com.amazonaws.auth.default AWSCredentials ProviderChain |
| fs.s3a.aws.credentials.provider | El proveedor de AWS credenciales que desea utilizar con un sistema de archivos S3A. | com.amazonaws.auth.default AWSCredentials ProviderChain |
| hive.auto.convert.join | Opción que activa la conversión automática de las uniones comunes en mapjoins, en función del tamaño del archivo de entrada. | TRUE |
| hive.auto.convert.join.noconditionaltask | Opción que activa la optimización cuando Hive convierte una unión común en un mapjoin en función del tamaño del archivo de entrada. | TRUE |
| hive.auto.convert.join.noconditionaltask.size | Una unión se convierte directamente en un mapjoin con un tamaño inferior a este tamaño. | El valor óptimo se calcula en función de la memoria de tareas de Tez |
| hive.cbo.enable | Opción que activa las optimizaciones basadas en los costes con el marco Calcite. | TRUE |
| hive.cli.tez.session.async | Opción para iniciar una sesión de Tez en segundo plano mientras se compila la consulta de Hive. Si se establece en false, Tez AM se inicia después de compilar la consulta de Hive. | TRUE |
| hive.compute.query.using.stats | Opción que activa a Hive para responder a determinadas consultas con estadísticas almacenadas en el metaalmacén. Para obtener estadísticas básicas, establezca hive.stats.autogather en TRUE. Para obtener una colección de consultas más avanzada, ejecute analyze table queries. | TRUE |
| hive.default.fileformat | El formato de archivo predeterminado para las instrucciones CREATE TABLE. Puede anular esto de forma explícita si especifica STORED AS [FORMAT] en su comando CREATE TABLE. | TEXTFILE |
| hive.driver.cores | El número de núcleos que se necesitarán para el proceso del controlador de Hive. | 2 |
| hive.driver.disk | El tamaño del disco para el controlador de Hive. | 20 G |
| hive.driver.disk.type | El tipo de disco para el controlador de Hive. | Standard |
| hive.tez.disk.type | El tamaño del disco para los trabajadores Tez. | Standard |
| hive.driver.memory | La cantidad de memoria que utilizar por proceso de controlador de Hive. El maestro de aplicación de Tez y la CLI de Hive CLI comparten esta memoria a partes iguales con un 20 % de espacio libre. | 6 G |
| hive.emr-serverless.launch.env.[KEY] | Opción para establecer la variable de entorno KEY en todos los procesos específicos de Hive, como el controlador de Hive, Tez AM y la tarea de Tez. | |
| hive.exec.dynamic.partition | Opciones que activan las particiones dinámicas en DML/DDL. | TRUE |
| hive.exec.dynamic.partition.mode | Opción que especifica si desea utilizar el modo estricto o el modo no estricto. En modo estricto, especifique al menos una partición estática en caso de que sobrescriba todas las particiones de forma accidental. En el modo no estricto, todas las particiones pueden ser dinámicas. | strict |
| hive.exec.max.dynamic.partitions | El número máximo de particiones dinámicas que Hive crea en total. | 1 000 |
| hive.exec.max.dynamic.partitions.pernode | Número máximo de particiones dinámicas que Hive crea en cada nodo mapeador y reductor. | 100 |
| hive.exec.orc.split.strategy | Se espera que sea uno de los siguientes valores: BI, ETL o HYBRID. No se trata de una configuración a nivel de usuario. BI especifica que desea dedicar menos tiempo a la generación dividida, en lugar de a la ejecución de consultas. ETL especifica que desea dedicar más tiempo a la generación dividida. HYBRID especifica una selección de las estrategias anteriores en función de la heurística. | HYBRID |
| hive.exec.reducers.bytes.per.reducer | El tamaño por reductor. El valor predeterminado es 256 MB. Si el tamaño de entrada es de 1 G, el trabajo utiliza 4 reductores. | 256000000 |
| hive.exec.reducers.max | El número máximo de reductores. | 256 |
| hive.exec.stagingdir | El nombre del directorio que almacena los archivos temporales que Hive crea dentro de las ubicaciones de las tablas y en la ubicación del directorio inicial especificada en la propiedad hive.exec.scratchdir. | .hive-staging |
| hive.fetch.task.conversion | Se espera que sea uno de los siguientes valores: NONE, MINIMAL o MORE. Hive puede convertir consultas seleccionadas en una sola tarea FETCH. Esto minimiza la latencia. | MORE |
| hive.groupby.position.alias | Opción que hace que Hive utilice un alias de posición de columna en las instrucciones GROUP BY. | FALSE |
| hive.input.format | El formato de entrada predeterminado. Establézcalo en HiveInputFormat si surgen problemas con CombineHiveInputFormat. | org.apache.hadoop.hive.ql.io.CombineHiveInputFormat |
| hive.log.explain.output | Opción que activa las explicaciones de los resultados ampliados para cualquier consulta del registro de Hive. | FALSE |
| hive.log.level | El nivel de registro de Hive. | INFO |
| hive.mapred.reduce.tasks.speculative.execution | Opción que activa el lanzamiento especulativo de los reductores. Solo se admite con Amazon EMR 6.10.x y versiones anteriores. | TRUE |
| hive.max-task-containers | El número máximo de contenedores simultáneos. La memoria del mapeador configurada se multiplica por este valor para determinar la memoria disponible que divide el uso de computación y de prioridad de tareas. | 1 000 |
| hive.merge.mapfiles | Opción que hace que los archivos pequeños se fusionen al final de un trabajo de solo mapas. | TRUE |
| hive.merge.size.per.task | El tamaño de los archivos fusionados al final del trabajo. | 256000000 |
| hive.merge.tezfiles | Opción que activa una fusión de archivos pequeños al final de un Tez DAG. | FALSE |
| hive.metastore.client.factory.class | El nombre de la clase de fábrica que produce los objetos que implementan la interfaz IMetaStoreClient. | com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory |
| hive.metastore.glue.catalogid | Si el catálogo de datos de AWS Glue actúa como un metaalmacén pero se ejecuta en un Cuenta de AWS lugar diferente al de los trabajos, el ID del Cuenta de AWS lugar en el que se ejecutan los trabajos. | NULL |
| hive.metastore.uris | El URI de Thrift que el cliente del metaalmacén utiliza para conectarse al metaalmacén remoto. | NULL |
| hive.optimize.ppd | Opción que activa la pulsación de predicados. | TRUE |
| hive.optimize.ppd.storage | Opción que activa la pulsación de predicados en los controladores de almacenamiento. | TRUE |
| hive.orderby.position.alias | Opción que hace que Hive utilice un alias de posición de columna en las instrucciones ORDER BY. | TRUE |
| hive.prewarm.enabled | Opción que activa el precalentamiento del contenedor para Tez. | FALSE |
| hive.prewarm.numcontainers | El número de contenedores que se deben precalentar para el té. | 10 |
| hive.stats.autogather | Opción que hace que Hive recopile estadísticas básicas automáticamente durante el comando INSERT OVERWRITE. | TRUE |
| hive.stats.fetch.column.stats | Opción que desactiva la búsqueda de estadísticas de columnas desde el metaalmacén. La búsqueda de estadísticas de columnas puede resultar costosa cuando el número de columnas es elevado. | FALSE |
| hive.stats.gather.num.threads | El número de subprocesos que utilizan los comandos Analyze partialscan y noscan para las tablas particionadas. Esto solo se aplica a los formatos de archivo que implementan StatsProvidingRecordReader (como ORC). | 10 |
| hive.strict.checks.cartesian.product | Opciones que activan las comprobaciones de unión cartesianas estrictas. Estas comprobaciones no permiten un producto cartesiano (una unión cruzada). | FALSE |
| hive.strict.checks.type.safety | Opción que activa las comprobaciones de seguridad de tipo estricto y desactiva la comparación de bigint con tanto string como double. | TRUE |
| hive.support.quoted.identifiers | Espera un valor de NONE o COLUMN. NONE implica que solo los caracteres alfanuméricos y de subrayado son válidos en los identificadores. COLUMN implica que los nombres de las columnas pueden contener cualquier carácter. | COLUMN |
| hive.tez.auto.reducer.parallelism | Opción que activa la característica de paralelismo del autorreductor Tez. Hive sigue calculando los tamaños de los datos y establece cálculos de paralelismo. Tez toma muestras de los tamaños de salida de los vértices de la fuente y ajusta los cálculos en tiempo de ejecución según sea necesario. | TRUE |
| hive.tez.container.size | La cantidad de memoria que se utilizará por proceso de tarea de Tez. | 6144 |
| hive.tez.cpu.vcores | La cantidad de núcleos que se utilizarán para cada tarea de Tez. | 2 |
| hive.tez.disk.size | El tamaño del disco de cada contenedor de tareas. | 20 G |
| hive.tez.input.format | El formato de entrada para la generación de divisiones en el Tez AM. | org.apache.hadoop.hive.ql.io.HiveInputFormat |
| hive.tez.min.partition.factor | Límite inferior de reductores que Tez especifica al activar el paralelismo del autorreductor. | 0,25 |
| hive.vectorized.execution.enabled | Opción que activa el modo vectorizado de ejecución de consultas. | TRUE |
| hive.vectorized.execution.reduce.enabled | Opción que activa el modo vectorizado en el lado de reducción de ejecución de una consulta. | TRUE |
| javax.jdo.option.ConnectionDriverName | El nombre de clase de controlador para un metaalmacén de JDBC. | org.apache.derby.jdbc.EmbeddedDriver |
| javax.jdo.option.ConnectionPassword | La contraseña asociada a una base de datos de metaalmacén. | NULL |
| javax.jdo.option.ConnectionURL | La cadena para una conexión de JDBC para un metaalmacén de JDBC. | jdbc:derby:;databaseName=metastore\$1db;create=true |
| javax.jdo.option.ConnectionUserName | El nombre de usuario asociado a una base de datos de metaalmacén. | NULL |
| mapreduce.input.fileinputformat.split.maxsize | El tamaño máximo de una división durante la computación de división cuando el formato de entrada es org.apache.hadoop.hive.ql.io.CombineHiveInputFormat. Un valor de 0 indica que no hay ningún límite. | 0 |
| tez.am.dag.cleanup.on.completion | Opción que activa la limpieza de los datos aleatorios cuando finaliza el DAG. | TRUE |
| tez.am.emr-serverless.launch.env.[KEY] | Opción para establecer la variable de entorno KEY en el proceso de Tez AM. Para Tez AM, este valor anula el valor hive.emr-serverless.launch.env.[KEY]. | |
| tez.am.log.level | El nivel de registro raíz que EMR sin servidor pasa al maestro de aplicaciones de Tez. | INFO |
| tez.am.sleep.time.before.exit.millis | EMR sin servidor debería enviar los eventos ATS después de este período de tiempo tras la solicitud de cierre de AM. | 0 |
| tez.am.speculation.enabled | Opción que provoca el lanzamiento especulativo de tareas más lentas. Esto puede ayudar a reducir la latencia de los trabajos cuando algunas tareas se ejecutan más lentamente debido a máquinas defectuosas o lentas. Solo se admite con Amazon EMR 6.10.x y versiones anteriores. | FALSE |
| tez.am.task.max.failed.attempts | El número máximo de intentos que se pueden fallar para una tarea en particular antes de que la tarea de error. En este número no se incluyen intentos finalizados manualmente. | 3 |
| tez.am.vertex.cleanup.height | Distancia a la que, si todos los vértices dependientes están completos, Tez AM eliminará los datos aleatorios de vértices. Esta característica se desactiva cuando el valor es 0. Las versiones 6.8.0 y posteriores de Amazon EMR admiten esta característica. | 0 |
| tez.client.asynchronous-stop | Opción que hace que EMR sin servidor envíe los eventos ATS antes de finalizar el controlador Hive. | FALSE |
| tez.grouping.max-size | El límite de tamaño superior (en bytes) de una división agrupada. Este límite evita que se produzcan divisiones excesivamente grandes. | 1073741824 |
| tez.grouping.min-size | El límite de tamaño inferior (en bytes) de una división agrupada. Este límite evita que se produzcan demasiadas divisiones pequeñas. | 16777216 |
| tez.runtime.io.sort.mb | El tamaño del búfer flexible cuando Tez ordena la salida. | El valor óptimo se calcula en función de la memoria de tareas de Tez |
| tez.runtime.unordered.output.buffer.size-mb | El tamaño del búfer que se utilizará si Tez no escribe directamente en el disco. | El valor óptimo se calcula en función de la memoria de tareas de Tez |
| tez.shuffle-vertex-manager.max-src-fraction | La fracción de tareas de la fuente que deben completarse antes de que EMR sin servidor programe todas las tareas para el vértice actual (en caso de una conexión ScatterGather). La cantidad de tareas listas para su programación en el vértice actual se escala linealmente entre min-fraction y max-fraction. Este valor predeterminado es el valor predeterminado o tez.shuffle-vertex-manager.min-src-fraction, el que sea mayor. | 0.75 |
| tez.shuffle-vertex-manager.min-src-fraction | La fracción de tareas de la fuente que deben completarse antes de que EMR sin servidor programe las tareas para el vértice actual (en caso de una conexión ScatterGather). | 0,25 |
| tez.task.emr-serverless.launch.env.[KEY] | Opción para establecer la variable de entorno KEY en el proceso de tareas de Tez. Para las tareas de Tez, este valor anula el valor hive.emr-serverless.launch.env.[KEY]. | |
| tez.task.log.level | El nivel de registro raíz que EMR sin servidor pasa al las tareas de Tez. | INFO |
| tez.yarn.ats.event.flush.timeout.millis | El tiempo máximo que AM debe esperar para que se vacíen los eventos antes de apagarse. | 300000 |
## Ejemplos de trabajos de Hive
El siguiente ejemplo de código muestra cómo ejecutar una consulta de Hive con la API `StartJobRun`.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "s3://amzn-s3-demo-bucket/emr-serverless-hive/query/hive-query.ql",
"parameters": "--hiveconf hive.log.explain.output=false"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.exec.scratchdir": "s3://amzn-s3-demo-bucket/emr-serverless-hive/hive/scratch",
"hive.metastore.warehouse.dir": "s3://amzn-s3-demo-bucket/emr-serverless-hive/hive/warehouse",
"hive.driver.cores": "2",
"hive.driver.memory": "4g",
"hive.tez.container.size": "4096",
"hive.tez.cpu.vcores": "1"
}
}]
}'
```
Puede encontrar ejemplos adicionales de cómo ejecutar trabajos de Hive en el repositorio de muestras [sin servidor GitHub de EMR.](https://github.com/aws-samples/emr-serverless-samples/tree/main/examples/hive)
# Resiliencia de trabajos de EMR sin servidor
Las versiones 7.1.0 y posteriores de EMR sin servidor incluyen compatibilidad para la resiliencia a trabajos, por lo que reintenta automáticamente cualquier trabajo fallido sin ninguna intervención manual por su parte. Otro beneficio de la resiliencia al trabajo es que EMR sin servidor traslada las ejecuciones de trabajos a diferentes zonas de disponibilidad (AZ) en caso de que una AZ experimente algún problema.
Para habilitar la resiliencia al trabajo en un trabajo, establezca la política de reintentos para su trabajo. Una política de reintentos garantiza que EMR sin servidor reinicie automáticamente un trabajo si se produce un error en algún momento. Las políticas de reintento se admiten para los trabajos por lotes y para los de streaming, por lo que puede personalizar la resiliencia a los trabajos en función de su caso de uso. En la siguiente tabla se comparan los comportamientos y las diferencias en cuanto a la resiliencia al trabajo en trabajos en lotes y en streaming.
| | Tareas por lotes | Trabajos de streaming |
| --- | --- | --- |
| Comportamiento predeterminado | No vuelve a ejecutar el trabajo. | Siempre reintenta la ejecución del trabajo, ya que la aplicación crea puntos de comprobación mientras se ejecuta el trabajo. |
| Punto de reintento | Los trabajos por lotes no cuentan con puntos de comprobación, por lo que EMR sin servidor siempre reintenta la ejecución del trabajo desde su principio. | Los trabajos de streaming admiten puntos de comprobación, por lo que puede configurar la consulta de streaming para guardar el estado del tiempo de ejecución y el progreso hasta una ubicación de punto de comprobación en Amazon S3. EMR sin servidor reanuda la ejecución del trabajo desde el punto de comprobación. Para obtener más información, consulte [Recovering from failures with Checkpointing](https://spark.apache.org/docs/latest/structured-streaming-programming-guide.html#recovering-from-failures-with-checkpointing) en la documentación de Apache Spark. |
| Máximo de reintentos | Permite un máximo de 10 reintentos. | Los trabajos de streaming tienen un control de prevención de errores integrado, por lo que la aplicación deja de reintentar los trabajos si siguen fallando después de una hora. El número predeterminado de reintentos en una hora es de cinco intentos. Puede configurar este número de reintentos para que esté comprendido entre 1 y 10. No puede personalizar el número máximo de intentos. Un valor de 1 indica que no hay reintentos. |
Cuando EMR sin servidor reintenta la ejecución de un trabajo, también indexa el trabajo con un número de intentos, para que realice un seguimiento del ciclo de vida de un trabajo en todos sus intentos.
Utilice las operaciones de la API sin servidor de EMR o AWS CLI para cambiar la resiliencia de los trabajos o acceder a la información relacionada con la resiliencia de los trabajos. Para obtener más información, consulte la [Guía de la API del EMR sin servidor](https://docs.aws.amazon.com/emr-serverless/latest/APIReference/Welcome.html).
De forma predeterminada, EMR sin servidor no reintenta la ejecución de los trabajos por lotes. Para habilitar los reintentos de los trabajos por lotes, configure el parámetro `maxAttempts` al iniciar la ejecución de un trabajo por lotes. El parámetro `maxAttempts` solo se aplica a los trabajos por lotes. El valor predeterminado es 1, lo que significa que no se reintentará la ejecución del trabajo. Los valores aceptados son del 1 al 10, inclusive.
En el siguiente ejemplo, se muestra cómo especificar un número máximo de 10 intentos al iniciar una ejecución de trabajo.
```
aws emr-serverless start-job-run
--application-id \
--execution-role-arn \
--mode 'BATCH' \
--retry-policy '{
"maxAttempts": 10
}' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples-does-not-exist.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi"
}
}'
```
EMR sin servidor reintenta indefinidamente los trabajos de streaming en caso de fallar. Para evitar que se produzcan errores repetidos e irrecuperables, utilice el `maxFailedAttemptsPerHour` para configurar el control de prevención de errores para los reintentos de trabajos de streaming. Este parámetro le permite especificar el número máximo de intentos fallidos y permitidos una hora antes de que EMR sin servidor deje de volver a intentarlo. El valor predeterminado es cinco. Los valores aceptados son del 1 al 10, inclusive.
```
aws emr-serverless start-job-run
--application-id \
--execution-role-arn \
--mode 'STREAMING' \
--retry-policy '{
"maxFailedAttemptsPerHour": 7
}' \
--job-driver '{
"sparkSubmit": {
"entryPoint": "/usr/lib/spark/examples/jars/spark-examples-does-not-exist.jar",
"entryPointArguments": ["1"],
"sparkSubmitParameters": "--class org.apache.spark.examples.SparkPi"
}
}'
```
También puede usar las demás operaciones de la API de ejecución de trabajos para obtener información sobre los trabajos. Por ejemplo, use el parámetro `attempt` con la operación `GetJobRun` para obtener detalles sobre un intento de trabajo específico. Si no incluye el parámetro`attempt`, la operación devuelve información sobre el último intento.
```
aws emr-serverless get-job-run \
--job-run-id job-run-id \
--application-id application-id \
--attempt 1
```
La operación `ListJobRunAttempts` devuelve información sobre todos los intentos relacionados con la ejecución de un trabajo.
```
aws emr-serverless list-job-run-attempts \
--application-id application-id \
--job-run-id job-run-id
```
La `GetDashboardForJobRun` operación crea y devuelve una URL que se utiliza para acceder a la aplicación UIs para ejecutar un trabajo. El parámetro `attempt` le permite obtener una URL para un intento específico. Si no incluye el parámetro`attempt`, la operación devuelve información sobre el último intento.
```
aws emr-serverless get-dashboard-for-job-run \
--application-id application-id \
--job-run-id job-run-id \
--attempt 1
```
## Supervisión de un trabajo con una política de reintento
La compatibilidad de resiliencia al trabajo también agrega el nuevo evento **Reintento de ejecución del trabajo de EMR sin servidor**. EMR sin servidor publica este evento cada vez que se vuelve a intentar el trabajo. Puede utilizar esta notificación para realizar un seguimiento de los reintentos del trabajo. Para obtener más información sobre los eventos, consulta [Amazon EventBridge events](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html).
## Registro con política de reintentos
Cada vez que EMR sin servidor reintenta un trabajo, el intento genera su propio conjunto de registros. Para garantizar que EMR Serverless pueda entregar correctamente estos registros a Amazon S3 y Amazon CloudWatch sin sobrescribir ninguno, EMR Serverless añade un prefijo al formato de la ruta del registro de S3 y CloudWatch al nombre del flujo de registro para incluir el número de intento del trabajo.
El siguiente es un ejemplo de cómo es su formato.
```
'/applications//jobs//attempts//'.
```
Este formato garantiza que EMR Serverless publique todos los registros de cada intento de trabajo en su propia ubicación designada en Amazon S3 y. CloudWatch Para obtener más detalles, consulte [Registros de almacenamiento](https://docs.aws.amazon.com/emr/latest/EMR-Serverless-UserGuide/logging.html).
**nota**
EMR sin servidor solo usa este formato de prefijo con todos los trabajos de streaming y cualquier trabajo por lotes que tengan habilitada la opción de reintento.
# Configuración de metaalmacenes para EMR sin servidor
Un *metaalmacén de Hive* es una ubicación centralizada que almacena información estructural sobre las tablas, incluidos los esquemas, los nombres de las particiones y los tipos de datos. Con EMR sin servidor, conserve los metadatos de esta tabla en un metalmacén que tenga acceso a sus trabajos.
Dispone de dos opciones para un metaalmacén de Hive:
+ El catálogo de datos de AWS Glue
+ Un metaalmacén de Apache Hive externo
## Uso del catálogo de datos de AWS Glue como metaalmacén
Puedes configurar tus trabajos de Spark y Hive para que usen el catálogo de datos de AWS Glue como metaalmacén. Recomendamos esta configuración cuando se necesita un metaalmacén persistente o un metaalmacén compartido por diferentes servicios, aplicaciones o Cuentas de AWS. Para obtener más información sobre el catálogo de datos, consulte Cómo [llenar el catálogo de datos de AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/populate-data-catalog.html). Para obtener información sobre los precios de AWS Glue, consulta los [precios de AWS Glue](https://aws.amazon.com/glue/pricing).
Puede configurar su trabajo EMR Serverless para que utilice el catálogo de datos de AWS Glue en la Cuenta de AWS misma aplicación o en una diferente. Cuenta de AWS
### Configurar el catálogo de datos de AWS Glue
Para configurar el catálogo de datos, elija el tipo de aplicación EMR sin servidor que desee utilizar.
------
#### [ Spark ]
Cuando utilizas EMR Studio para ejecutar tus trabajos con aplicaciones EMR Serverless Spark, el catálogo de datos de AWS Glue es el metabastore predeterminado.
Cuando utiliza SDKs o AWS CLI establece la `spark.hadoop.hive.metastore.client.factory.class` configuración `com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory` en los `sparkSubmit` parámetros de la ejecución de su trabajo. En el siguiente ejemplo se muestra cómo configurar el catálogo de datos con la AWS CLI.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/code/pyspark/extreme_weather.py",
"sparkSubmitParameters": "--conf spark.hadoop.hive.metastore.client.factory.class=com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory --conf spark.driver.cores=1 --conf spark.driver.memory=3g --conf spark.executor.cores=4 --conf spark.executor.memory=3g"
}
}'
```
Como alternativa, puede establecer esta configuración al crear una nueva `SparkSession` en su código de Spark.
```
from pyspark.sql import SparkSession
spark = (
SparkSession.builder.appName("SparkSQL")
.config(
"spark.hadoop.hive.metastore.client.factory.class",
"com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory",
)
.enableHiveSupport()
.getOrCreate()
)
# we can query tables with SparkSQL
spark.sql("SHOW TABLES").show()
# we can also them with native Spark
print(spark.catalog.listTables())
```
------
#### [ Hive ]
Para las aplicaciones EMR sin servidor Hive, el catálogo de datos es el metaalmacén predeterminado. Es decir, cuando ejecuta trabajos en una aplicación EMR Serverless Hive, Hive registra la información del metaalmacén en el catálogo de datos al igual que su aplicación. Cuenta de AWS No necesita una nube privada virtual (VPC) para usar el catálogo de datos como metaalmacén.
Para acceder a las tablas del metaalmacén de Hive, añade las políticas de AWS Glue necesarias que se describen en [Configuración de los permisos de IAM para](https://docs.aws.amazon.com/glue/latest/dg/getting-started-access.html) Glue. AWS
------
### Configurar el acceso multicuenta para EMR Serverless AWS y Glue Data Catalog
Para configurar el acceso multicuenta para EMR Serverless, primero inicie sesión en lo siguiente: Cuentas de AWS
+ `AccountA`— Y Cuenta de AWS donde ha creado una aplicación EMR Serverless.
+ `AccountB`— Y Cuenta de AWS que contiene un catálogo de datos de AWS Glue al que desea que accedan sus trabajos de EMR Serverless.
1. Asegúrese de que un administrador u otra identidad autorizada en la `AccountB` adjunte una política de recursos al catálogo de datos en la `AccountB`. Esta política otorga permisos específicos entre cuentas de `AccountA` para realizar operaciones con los recursos del catálogo de `AccountB`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:CreateDatabase",
"glue:GetDataBases",
"glue:CreateTable",
"glue:GetTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTables",
"glue:GetPartition",
"glue:GetPartitions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"arn:aws:glue:*:123456789012:catalog"
],
"Sid": "AllowGLUEGetdatabase"
}
]
}
```
------
1. Agregue una política de IAM a rol de tiempo de ejecución del trabajo de EMR sin servidor en `AccountA` para que este rol pueda acceder a los recursos del catálogo de datos en `AccountB`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"glue:GetDatabase",
"glue:CreateDatabase",
"glue:GetDataBases",
"glue:CreateTable",
"glue:GetTable",
"glue:UpdateTable",
"glue:DeleteTable",
"glue:GetTables",
"glue:GetPartition",
"glue:GetPartitions",
"glue:CreatePartition",
"glue:BatchCreatePartition",
"glue:GetUserDefinedFunctions"
],
"Resource": [
"arn:aws:glue:*:123456789012:catalog"
],
"Sid": "AllowGLUEGetdatabase"
}
]
}
```
------
1. Inicio de su ejecución de trabajo. Este paso es ligeramente diferente según el tipo de aplicación EMR sin servidor de la `AccountA`.
------
#### [ Spark ]
Establezca la propiedad `spark.hadoop.hive.metastore.glue.catalogid` en `sparkSubmitParameters`, tal y como se muestra en el siguiente ejemplo. Sustituya *`AccountB-catalog-id`* por el ID del catálogo de datos en `AccountB`.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/scripts/test.py",
"sparkSubmitParameters": "--conf spark.hadoop.hive.metastore.client.factory.class=com.amazonaws.glue.catalog.metastore.AWSGlueDataCatalogHiveClientFactory --conf spark.hadoop.hive.metastore.glue.catalogid=AccountB-catalog-id --conf spark.executor.cores=1 --conf spark.executor.memory=1g --conf spark.driver.cores=1 --conf spark.driver.memory=1g --conf spark.executor.instances=1"
}
}' \
--configuration-overrides '{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-bucket/logs/"
}
}
}'
```
------
#### [ Hive ]
Establezca la propiedad `hive.metastore.glue.catalogid` en la clasificación `hive-site`, tal y como se muestra en el siguiente ejemplo. Sustituya *`AccountB-catalog-id`* por el ID del catálogo de datos en `AccountB`.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"hive": {
"query": "s3://amzn-s3-demo-bucket/hive/scripts/create_table.sql",
"parameters": "--hiveconf hive.exec.scratchdir=s3://amzn-s3-demo-bucket/hive/scratch --hiveconf hive.metastore.warehouse.dir=s3://amzn-s3-demo-bucket/hive/warehouse"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"hive.metastore.glue.catalogid": "AccountB-catalog-id"
}
}]
}'
```
------
### Consideraciones a la hora de utilizar el catálogo de datos de AWS Glue
Puede añadir un elemento auxiliar JARs a `ADD JAR` sus scripts de Hive. Para obtener información adicional, consulte [Consideraciones al utilizar el catálogo de datos de AWS Glue](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-hive-metastore-glue.html#emr-hive-glue-considerations-hive).
# Uso de un metaalmacén de Hive externo
Puede configurar sus trabajos de EMR sin servidor Spark y Hive para que se conecten a un metaalmacén de Hive externo, como Amazon Aurora o Amazon RDS para MySQL. En esta sección se describe cómo configurar un metaalmacén Hive de Amazon RDS, cómo configurar su VPC y cómo configurar sus trabajos de EMR sin servidor para usar un metaalmacén externo.
## Creación de un metaalmacén de Hive externo
1. Cree una Amazon Virtual Private Cloud (Amazon VPC) con subredes privadas siguiendo las instrucciones de [Creación de una VPC](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#Create-VPC).
1. Cree su aplicación EMR sin servidor con su nueva Amazon VPC y sus subredes privadas. Cuando configura la aplicación EMR sin servidor con una VPC, aprovisiona en primer lugar una red elástica para cada subred que especifique. A continuación, conecta el grupo de seguridad especificado a esa interfaz de red. Esto le da a la aplicación el control de acceso. Para obtener más información acerca de cómo configurar una VPC, consulte [Configuración del acceso a la VPC para que las aplicaciones EMR sin servidor se conecten a los datos](vpc-access.md).
1. Cómo crear una base de datos de MySQL o Aurora PostgreSQL en una subred privada de Amazon VPC. Para obtener información acerca de cómo crear una base de datos de Amazon RDS, consulte [Creación de una instancia de base de datos de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CreateDBInstance.html).
1. Modifique el grupo de seguridad de la base de datos MySQL o Aurora para permitir las conexiones JDBC desde el grupo de seguridad del EMR sin servidor siguiendo los pasos que se indican en [Modificación de una instancia de base de datos de Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.DBInstance.Modifying.html). Agregue una regla para el tráfico entrante al grupo de seguridad de RDS desde uno de sus grupos de seguridad del EMR sin servidor.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/emr/latest/EMR-Serverless-UserGuide/external-metastore.html)
## Configuración de las opciones de Spark
**Uso de JDBC**
Para configurar su aplicación EMR sin servidor Spark para que se conecte a un metaalmacén de Hive basado en una instancia de Amazon RDS para MySQL o Amazon Aurora MySQL, utilice una conexión JDBC. Pase el `mariadb-connector-java.jar` con `--jars` en los parámetros `spark-submit` de su ejecución de trabajo.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/scripts/spark-jdbc.py",
"sparkSubmitParameters": "--jars s3://amzn-s3-demo-bucket/mariadb-connector-java.jar
--conf spark.hadoop.javax.jdo.option.ConnectionDriverName=org.mariadb.jdbc.Driver
--conf spark.hadoop.javax.jdo.option.ConnectionUserName=
--conf spark.hadoop.javax.jdo.option.ConnectionPassword=
--conf spark.hadoop.javax.jdo.option.ConnectionURL=
--conf spark.driver.cores=2
--conf spark.executor.memory=10G
--conf spark.driver.memory=6G
--conf spark.executor.cores=4"
}
}' \
--configuration-overrides '{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-bucket/spark/logs/"
}
}
}'
```
El siguiente ejemplo de código es un script de punto de entrada de Spark que interactúa con un metaalmacén de Hive en Amazon RDS.
```
from os.path import expanduser, join, abspath
from pyspark.sql import SparkSession
from pyspark.sql import Row
# warehouse_location points to the default location for managed databases and tables
warehouse_location = abspath('spark-warehouse')
spark = SparkSession \
.builder \
.config("spark.sql.warehouse.dir", warehouse_location) \
.enableHiveSupport() \
.getOrCreate()
spark.sql("SHOW DATABASES").show()
spark.sql("CREATE EXTERNAL TABLE `sampledb`.`sparknyctaxi`(`dispatching_base_num` string, `pickup_datetime` string, `dropoff_datetime` string, `pulocationid` bigint, `dolocationid` bigint, `sr_flag` bigint) STORED AS PARQUET LOCATION 's3:///nyctaxi_parquet/'")
spark.sql("SELECT count(*) FROM sampledb.sparknyctaxi").show()
spark.stop()
```
**Uso del servicio Thrift**
Puede configurar su aplicación EMR sin servidor Hive para que se conecte a un metaalmacén de Hive basado en una instancia Amazon RDS para MySQL o Amazon Aurora MySQL. Para ello, ejecute un servidor Thrift en el nodo principal de un clúster de Amazon EMR existente. Esta opción es ideal si ya tiene un clúster de Amazon EMR con un servidor Thrift que desea utilizar para simplificar las configuraciones de los trabajos de EMR sin servidor.
```
aws emr-serverless start-job-run \
--application-id "application-id" \
--execution-role-arn "job-role-arn" \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/thriftscript.py",
"sparkSubmitParameters": "--jars s3://amzn-s3-demo-bucket/mariadb-connector-java.jar
--conf spark.driver.cores=2
--conf spark.executor.memory=10G
--conf spark.driver.memory=6G
--conf spark.executor.cores=4"
}
}' \
--configuration-overrides '{
"monitoringConfiguration": {
"s3MonitoringConfiguration": {
"logUri": "s3://amzn-s3-demo-bucket/spark/logs/"
}
}
}'
```
El siguiente ejemplo de código es un script de punto de entrada (`thriftscript.py`) que utiliza el protocolo Thrift para conectarse a un metaalmacén de Hive. Tenga en cuenta que la propiedad `hive.metastore.uris` debe configurarse para que se lea desde un metaalmacén de Hive externo.
```
from os.path import expanduser, join, abspath
from pyspark.sql import SparkSession
from pyspark.sql import Row
# warehouse_location points to the default location for managed databases and tables
warehouse_location = abspath('spark-warehouse')
spark = SparkSession \
.builder \
.config("spark.sql.warehouse.dir", warehouse_location) \
.config("hive.metastore.uris","thrift://thrift-server-host:thift-server-port") \
.enableHiveSupport() \
.getOrCreate()
spark.sql("SHOW DATABASES").show()
spark.sql("CREATE EXTERNAL TABLE sampledb.`sparknyctaxi`( `dispatching_base_num` string, `pickup_datetime` string, `dropoff_datetime` string, `pulocationid` bigint, `dolocationid` bigint, `sr_flag` bigint) STORED AS PARQUET LOCATION 's3:///nyctaxi_parquet/'")
spark.sql("SELECT * FROM sampledb.sparknyctaxi").show()
spark.stop()
```
## Configuración de las opciones de Hive
**Uso de JDBC**
Si desea especificar una ubicación de base de datos de Hive externa en una instancia de Amazon RDS MySQL o Amazon Aurora, puede anular la configuración predeterminada del metaalmacén.
**nota**
En Hive, puede realizar varias escrituras en tablas de metaalmacenes al mismo tiempo. Si comparte información del metaalmacén entre dos trabajos, debe asegurarse de no escribir en la misma tabla de metaalmacén simultáneamente, a menos que se escriba en distintas particiones de la misma tabla.
Establezca las siguientes configuraciones en la clasificación `hive-site` para activar el metaalmacén de Hive externo.
```
{
"classification": "hive-site",
"properties": {
"hive.metastore.client.factory.class": "org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClientFactory",
"javax.jdo.option.ConnectionDriverName": "org.mariadb.jdbc.Driver",
"javax.jdo.option.ConnectionURL": "jdbc:mysql://db-host:db-port/db-name",
"javax.jdo.option.ConnectionUserName": "username",
"javax.jdo.option.ConnectionPassword": "password"
}
}
```
**Uso de un servidor Thrift**
Puede configurar su aplicación EMR Serverless Hive para que se conecte a un metaalmacén de Hive basado en Amazon RDS for MySQL o Amazon Aurora My. SQLinstance Para ello, ejecute un servidor Thrift en el nodo principal de un clúster de Amazon EMR existente. Esta opción es ideal si ya tiene un clúster de Amazon EMR que ejecuta un servidor Thrift y desea utilizar las configuraciones de trabajo de EMR sin servidor.
Establezca las siguientes configuraciones en la clasificación `hive-site` para que EMR sin servidor pueda acceder al metaalmacén remoto de Thrift. Tenga en cuenta que la propiedad `hive.metastore.uris` debe establecerse para que se lea desde un metaalmacén de Hive externo.
```
{
"classification": "hive-site",
"properties": {
"hive.metastore.client.factory.class": "org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClientFactory",
"hive.metastore.uris": "thrift://thrift-server-host:thirft-server-port"
}
}
```
# Trabajar con la jerarquía de catálogos múltiples de AWS Glue en EMR Serverless
Puede configurar sus aplicaciones EMR Serverless para que funcionen con la jerarquía de catálogos múltiples de AWS Glue. El siguiente ejemplo muestra cómo utilizar EMR-S Spark con la jerarquía de catálogos múltiples de AWS Glue.
Para obtener más información sobre la jerarquía de varios catálogos, consulta Cómo [trabajar con una jerarquía de varios catálogos en AWS Glue Data Catalog with Spark en Amazon EMR](https://docs.aws.amazon.com/emr/latest/ReleaseGuide/emr-multi-catalog.html).
## Uso del almacenamiento gestionado (RMS) de Redshift con Iceberg and Glue Data Catalog AWS
A continuación, se muestra cómo configurar Spark para su integración con un catálogo de datos de AWS Glue con Iceberg:
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/myscript.py",
"sparkSubmitParameters": "--conf spark.sql.catalog.nfgac_rms = org.apache.iceberg.spark.SparkCatalog
--conf spark.sql.catalog.rms.type=glue
--conf spark.sql.catalog.rms.glue.id=Glue RMS catalog ID
--conf spark.sql.defaultCatalog=rms
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions"
}
}'
```
Un ejemplo de consulta de una tabla del catálogo, tras la integración:
```
SELECT * FROM my_rms_schema.my_table
```
## Uso del almacenamiento gestionado (RMS) de Redshift con la API REST de Iceberg y el catálogo de datos de Glue AWS
A continuación, se muestra cómo configurar Spark para que funcione con el catálogo REST de Iceberg:
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "s3://amzn-s3-demo-bucket/myscript.py",
"sparkSubmitParameters": "
--conf spark.sql.catalog.rms=org.apache.iceberg.spark.SparkCatalog
--conf spark.sql.catalog.rms.type=rest
--conf spark.sql.catalog.rms.warehouse=Glue RMS catalog ID
--conf spark.sql.catalog.rms.uri=Glue endpoint URI/iceberg
--conf spark.sql.catalog.rms.rest.sigv4-enabled=true
--conf spark.sql.catalog.rms.rest.signing-name=glue
--conf spark.sql.extensions=org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions"
}
}'
```
Un ejemplo de consulta de una tabla del catálogo:
```
SELECT * FROM my_rms_schema.my_table
```
# Consideraciones sobre el uso de un metaalmacén externo
+ Puede configurar bases de datos que sean compatibles con MariaDB JDBC como su metaalmacén. Algunos ejemplos de estas bases de datos son RDS para MariaDB, MySQL y Amazon Aurora.
+ Los metaalmacenes no se inicializan de forma automática. Si su metaalmacén no se ha inicializado con un esquema para su versión de Hive, utilice la [Herramienta de esquemas de Hive](https://cwiki.apache.org/confluence/display/Hive/Hive+Schema+Tool).
+ EMR sin servidor no admite la autenticación de Kerberos. No puede utilizar un servidor de metaalmacén Thrift con autenticación de Kerberos con trabajos EMR sin servidor Spark o Hive.
+ Debe configurar el acceso a la VPC para usar la jerarquía de catálogos múltiples.
# Acceso a los datos de S3 en otra AWS cuenta desde EMR Serverless
Puede ejecutar trabajos de Amazon EMR Serverless desde una AWS cuenta y configurarlos para acceder a los datos de los buckets de Amazon S3 que pertenezcan a otra cuenta. AWS En esta página se describe cómo configurar el acceso entre cuentas a S3 desde EMR sin servidor.
Los trabajos que se ejecutan en EMR Serverless pueden utilizar una política de bucket de S3 o un rol asumido para acceder a los datos de Amazon S3 desde una cuenta diferente. AWS
## Requisitos previos
Para configurar el acceso multicuenta a Amazon EMR Serverless, complete las tareas con la sesión iniciada en dos cuentas: AWS
+ **`AccountA`**: esta es la cuenta de AWS en la que ha creado una aplicación Amazon EMR sin servidor. Antes de configurar el acceso entre cuentas tenga preparado en su cuenta lo siguiente:
+ Una aplicación de Amazon EMR sin servidor en la que desee ejecutar los trabajos.
+ Un rol de ejecución de trabajos que tenga los permisos necesarios para ejecutar trabajos en la aplicación. Para obtener más información, consulta [Roles en tiempo de ejecución de trabajo para Amazon EMR sin servidor](security-iam-runtime-role.md).
+ **`AccountB`**: esta es la cuenta de AWS que contiene el bucket de S3 al que desea que accedan sus trabajos de Amazon EMR sin servidor.
## Uso de una política de buckets de S3 para acceder a los datos de S3 entre cuentas
Para acceder al bucket de S3 en account B desde account A, adjunte la siguiente política al bucket de S3 en account B.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ExamplePermissions1",
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::my-bucket-name"
]
},
{
"Sid": "ExamplePermissions2",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": [
"arn:aws:s3:::my-bucket-name/*"
]
}
]
}
```
------
Para obtener más información acerca del acceso entre cuentas de S3 con políticas de bucket de S3, consulte [Ejemplo 2: propietario del bucket que concede permisos de bucket entre cuentas](https://docs.aws.amazon.com/AmazonS3/latest/userguide/example-walkthroughs-managing-access-example2.html) en la *Guía del usuario de Amazon Simple Storage Service*.
## Uso de un rol asumido para acceder a los datos de S3 entre cuentas
Otra forma de configurar el acceso multicuenta para Amazon EMR Serverless es con `AssumeRole` la acción de AWS Security Token Service ().AWS STS AWS STS es un servicio web global que le permite solicitar credenciales temporales con privilegios limitados para los usuarios. Puede realizar llamadas de API a EMR sin servidor y Amazon S3 con las credenciales de seguridad temporales que usted crea con `AssumeRole`.
Los siguientes pasos ilustran cómo utilizar un rol asumido para acceder a los datos de S3 entre cuentas desde EMR sin servidor:
1. Cree un bucket de Amazon S3, *cross-account-bucket*, en la `AccountB`. Para obtener más información, consulte [Creación de un bucket](https://docs.aws.amazon.com/AmazonS3/latest/gsg/CreatingABucket.html) en la *Guía del usuario de Amazon Simple Storage Service*. Si desea tener acceso entre cuentas a DynamoDB, también puede crear una tabla de DynamoDB en la `AccountB`. Para obtener más información, consulte [Creación de una tabla de DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/getting-started-step-1.html) en la *Guía para desarrolladores de Amazon DynamoDB*.
1. Cree un rol de IAM `Cross-Account-Role-B` en la `AccountB` que pueda acceder a *cross-account-bucket*.
1. Inicie sesión en la consola de IAM Consola de administración de AWS y ábrala en. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/)
1. Elija **Roles** y, a continuación, cree un nuevo rol: `Cross-Account-Role-B`. Para obtener más información acerca de cómo crear un rol de IAM, consulte [Creación de roles de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create.html) en la Guía del usuario de IAM.
1. Cree una política de IAM que especifique los permisos del `Cross-Account-Role-B` para acceder al bucket de S3 *cross-account-bucket*, tal como se muestra en la siguiente instrucción de política. Adjunte la política de IAM al `Cross-Account-Role-B`. Para obtener más información, consulte [Creación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) en la *Guía del usuario de IAM*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::cross-account-bucket",
"arn:aws:s3:::cross-account-bucket/*"
],
"Sid": "AllowS3"
}
]
}
```
------
Si requiere acceso a DynamoDB, cree una política de IAM que especifique los permisos para acceder a la tabla de DynamoDB entre cuentas. Adjunte la política de IAM al `Cross-Account-Role-B`. Para obtener más información, consulte [Amazon DynamoDB: permite el acceso a una determinada tabla](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_dynamodb_specific-table.html) en la *Guía del usuario de IAM*.
A continuación, se presenta una política para acceder a una tabla de DynamoDB `CrossAccountTable`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:*"
],
"Resource": [
"arn:aws:dynamodb:*:123456789012:table/CrossAccountTable"
],
"Sid": "AllowDYNAMODB"
}
]
}
```
------
1. Edite la relación de confianza del rol `Cross-Account-Role-B`.
1. Para configurar la relación de confianza del rol, elija la pestaña **Relaciones de confianza** en la consola de IAM para el rol `Cross-Account-Role-B` creado en el paso 2.
1. Seleccione **Editar la relación de confianza**.
1. Añada el siguiente documento de política. Esto permite que `Job-Execution-Role-A` en `AccountA` asuma el rol `Cross-Account-Role-B`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": "arn:aws:iam::123456789012:role/Job-Execution-Role-A",
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
1. Otorgue `Job-Execution-Role-A` `AccountA` el AWS STS `AssumeRole` permiso para asumir`Cross-Account-Role-B`.
1. En la consola de IAM de la AWS cuenta`AccountA`, seleccione`Job-Execution-Role-A`.
1. Agregue la siguiente instrucción de política al `Job-Execution-Role-A` para denegar la acción `AssumeRole` en el rol `Cross-Account-Role-B`.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::123456789012:role/Cross-Account-Role-B"
],
"Sid": "AllowSTSAssumerole"
}
]
}
```
------
## Ejemplos de roles asumidos
Use un solo rol asumido para acceder a todos los recursos de S3 de una cuenta o, con Amazon EMR 6.11 y versiones posteriores, configure varios roles de IAM para asumirlos al acceder a diferentes buckets de S3 entre cuentas.
**Topics**
+ [Acceso a los recursos de S3 con un rol asumido](#jobs-s3-access-how-to-assumed-role-single)
+ [Acceso a los recursos de S3 con varios roles asumidos](#jobs-s3-access-how-to-assumed-role-multiple)
### Acceso a los recursos de S3 con un rol asumido
**nota**
Al configurar un trabajo para usar un único rol asumido, todos los recursos de S3 del trabajo usan ese rol, incluido el script de `entryPoint`.
Si desea utilizar un único rol asumido para acceder a todos los recursos de S3 de la cuenta B, especifique las siguientes configuraciones:
1. Especifique la configuración `fs.s3.customAWSCredentialsProvider` para `com.amazonaws.emr.AssumeRoleAWSCredentialsProvider` de EMRFS.
1. En el caso de Spark, utilice `spark.emr-serverless.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` y `spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` para especificar las variables de entorno del controlador y los ejecutores.
1. Para Hive, utilice `hive.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN`, `tez.am.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` y `tez.task.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN` para especificar las variables de entorno en el controlador Hive, el maestro de aplicaciones de Tez y los contenedores de tareas de Tez.
Los siguientes ejemplos muestran cómo usar un rol asumido para iniciar una ejecución de un trabajo EMR sin servidor con acceso entre cuentas.
------
#### [ Spark ]
El siguiente ejemplo muestra cómo usar un rol asumido para iniciar la ejecución de un trabajo de EMR sin servidor Spark con acceso entre cuentas a S3.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "entrypoint_location",
"entryPointArguments": [":argument_1:", ":argument_2:"],
"sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "spark-defaults",
"properties": {
"spark.hadoop.fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.AssumeRoleAWSCredentialsProvider",
"spark.emr-serverless.driverEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
"spark.executorEnv.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
}
}]
}'
```
------
#### [ Hive ]
El siguiente ejemplo muestra cómo usar un rol asumido para iniciar la ejecución de un trabajo de EMR sin servidor Hive con acceso entre cuentas a S3.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "query_location",
"parameters": "hive_parameters"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.AssumeRoleAWSCredentialsProvider",
"hive.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
"tez.am.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B",
"tez.task.emr-serverless.launch.env.ASSUME_ROLE_CREDENTIALS_ROLE_ARN": "arn:aws:iam::AccountB:role/Cross-Account-Role-B"
}
}]
}'
```
------
### Acceso a los recursos de S3 con varios roles asumidos
Con las versiones 6.11.0 y posteriores de EMR sin servidor, configure varios roles de IAM para que los asuma al acceder a diferentes buckets entre cuentas. Si desea acceder a diferentes recursos de S3 con diferentes roles asumidos en la cuenta B, utilice las siguientes configuraciones al iniciar la ejecución del trabajo:
1. Especifique la configuración `fs.s3.customAWSCredentialsProvider` para `com.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider` de EMRFS.
1. Especifique la configuración `fs.s3.bucketLevelAssumeRoleMapping` de EMRFS para definir la asignación desde el nombre del bucket de S3 hasta el rol de IAM que se va a asumir en la cuenta B. El formato del valor debe ser `bucket1->role1;bucket2->role2`.
Por ejemplo, use `arn:aws:iam::AccountB:role/Cross-Account-Role-B-1` para acceder al bucket `bucket1` y use `arn:aws:iam::AccountB:role/Cross-Account-Role-B-2` para acceder al bucket `bucket2`. Los siguientes ejemplos muestran cómo iniciar una ejecución de trabajo de EMR sin servidor con acceso entre cuentas a través de varios roles asumidos.
------
#### [ Spark ]
El siguiente ejemplo muestra cómo usar varios roles asumidos para crear la ejecución de un trabajo de EMR sin servidor Spark.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"sparkSubmit": {
"entryPoint": "entrypoint_location",
"entryPointArguments": [":argument_1:", ":argument_2:"],
"sparkSubmitParameters": "--conf spark.executor.cores=4 --conf spark.executor.memory=20g --conf spark.driver.cores=4 --conf spark.driver.memory=8g --conf spark.executor.instances=1"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "spark-defaults",
"properties": {
"spark.hadoop.fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.BucketLevelAssumeRoleCredentialsProvider",
"spark.hadoop.fs.s3.bucketLevelAssumeRoleMapping": "bucket1->arn:aws:iam::AccountB:role/Cross-Account-Role-B-1;bucket2->arn:aws:iam::AccountB:role/Cross-Account-Role-B-2"
}
}]
}'
```
------
#### [ Hive ]
Los siguientes ejemplos muestran cómo usar varios roles asumidos para crear la ejecución de un trabajo de EMR sin servidor Hive.
```
aws emr-serverless start-job-run \
--application-id application-id \
--execution-role-arn job-role-arn \
--job-driver '{
"hive": {
"query": "query_location",
"parameters": "hive_parameters"
}
}' \
--configuration-overrides '{
"applicationConfiguration": [{
"classification": "hive-site",
"properties": {
"fs.s3.customAWSCredentialsProvider": "com.amazonaws.emr.serverless.credentialsprovider.AssumeRoleAWSCredentialsProvider",
"fs.s3.bucketLevelAssumeRoleMapping": "bucket1->arn:aws:iam::AccountB:role/Cross-Account-Role-B-1;bucket2->arn:aws:iam::AccountB:role/Cross-Account-Role-B-2"
}
}]
}'
```
------
# Solución de errores en EMR sin servidor
Use la siguiente información para diagnosticar y resolver los problemas habituales que ocurren cuando se trabaja con Amazon EMR sin servidor.
**Topics**
+ [Error: el trabajo ha fallado porque la cuenta ha alcanzado el límite de servicio en la cantidad máxima de vCPU que puede utilizar simultáneamente.](#jobs-troubleshoot-allowed-capacity-vcpu)
+ [Error: el trabajo falló porque la aplicación superó la configuración de capacidad máxima.](#jobs-troubleshoot-maxcapacity)
+ [Error: el trabajo falló debido a que no se pudo asignar el trabajador porque la aplicación ha superado la capacidad máxima.](#jobs-troubleshoot-worker-allocated)
+ [Error: Acceso de S3 denegado. Compruebe los permisos de acceso a S3 del rol de ejecución del trabajo en los recursos de S3 necesarios.](#jobs-troubleshoot-s3)
+ [Error ModuleNotFoundError: No hay ningún módulo con nombre. Consulte la guía del usuario sobre cómo utilizar las bibliotecas de Python con EMR sin servidor.](#jobs-troubleshoot-module)
+ [Error: No se pudo asumir la función de ejecución porque no existe o no está configurada con la relación de confianza requerida.](#jobs-troubleshoot-runtime-role)
## Error: el trabajo ha fallado porque la cuenta ha alcanzado el límite de servicio en la cantidad máxima de vCPU que puede utilizar simultáneamente.
Este error indica que EMR sin servidor no pudo enviar el trabajo porque la cuenta ha superado la capacidad máxima. Aumente la capacidad máxima de la cuenta. Compruebe sus límites de servicio en las [cuotas de servicio de EMR Serverless](https://console.aws.amazon.com/servicequotas/home/services/emr-serverless/quotas).
## Error: el trabajo falló porque la aplicación superó la configuración de capacidad máxima.
Este error indica que EMR sin servidor no pudo enviar el trabajo porque la aplicación ha superado la capacidad máxima configurada. Aumente la capacidad máxima de la aplicación.
## Error: el trabajo falló debido a que no se pudo asignar el trabajador porque la aplicación ha superado la capacidad máxima.
Este error indica que el trabajo no se pudo completar. No se pudieron asignar los trabajadores porque la aplicación superó la configuración de capacidad máxima.
## Error: Acceso de S3 denegado. Compruebe los permisos de acceso a S3 del rol de ejecución del trabajo en los recursos de S3 necesarios.
Este error indica que su trabajo no tiene acceso a sus recursos de S3. Compruebe que el rol de ejecución del trabajo tenga permiso para acceder a los recursos de S3 que debe usar el trabajo. Para obtener más información acerca de los roles de tiempos de ejecución, consulte [Roles en tiempo de ejecución de trabajo para Amazon EMR sin servidor](security-iam-runtime-role.md).
## Error ModuleNotFoundError: No hay ningún módulo con nombre. Consulte la guía del usuario sobre cómo utilizar las bibliotecas de Python con EMR sin servidor.
Este error indica que no había un módulo de Python disponible para el trabajo de Spark. Compruebe que las bibliotecas de Python dependientes estén disponibles para el trabajo. Para obtener más información sobre cómo empaquetar las bibliotecas de Python, consulte [Uso de bibliotecas de Python con EMR sin servidor](using-python-libraries.md).
## Error: No se pudo asumir la función de ejecución porque no existe o no está configurada con la relación de confianza requerida.
Este error indica que el rol de ejecución del trabajo que especificó para el trabajo no existe o que el rol no tiene una relación de confianza para los permisos de EMR sin servidor. Para comprobar que el rol de IAM existe y validar que ha configurado correctamente la política de confianza del rol, consulte las instrucciones que aparecen en [Roles en tiempo de ejecución de trabajo para Amazon EMR sin servidor](security-iam-runtime-role.md).
# Habilitar la asignación de costos a nivel de trabajo
La asignación de costos a nivel de trabajo permite una atribución de facturación granular para EMR Serverless a nivel de ejecución de trabajo individual, en lugar de agregar todos los costos a nivel de aplicación. Cuando está habilitada, puede filtrar y realizar un seguimiento de los costos en AWS Cost Explorer y en los informes de costo y uso por ejecución de tareas específicas IDs y etiquetas asociadas a las ejecuciones de tareas, lo que proporciona una mejor visibilidad de los cargos por las ejecuciones de tareas enviadas.
## Comportamiento predeterminado
La asignación de costes a nivel de trabajo no está habilitada de forma predeterminada.
## ¿Cómo activar o desactivar la función
Puede configurar la asignación de costes a nivel de trabajo durante la creación de la aplicación o actualizarla para las aplicaciones existentes.
Especifique el `jobLevelCostAllocation` parámetro al crear una nueva aplicación:
```
# Enable job-level cost allocation:
aws emr-serverless create-application \
--name "my-application" \
--release-label "emr-7.12.0" \
--type "SPARK" \
--job-level-cost-allocation-configuration '{
"enabled": true
}'
# Disable job-level cost allocation:
aws emr-serverless create-application \
--name "my-application" \
--release-label "emr-7.12.0" \
--type "SPARK" \
--job-level-cost-allocation-configuration '{
"enabled": false
}'
```
Actualice el `jobLevelCostAllocationConfiguration` parámetro de una aplicación existente:
```
# Enable job-level cost allocation:
aws emr-serverless update-application \
--application-id \
--job-level-cost-allocation-configuration '{
"enabled": true
}'
# Disable job-level cost allocation:
aws emr-serverless update-application \
--application-id \
--job-level-cost-allocation-configuration '{
"enabled": false
}'
```
## Condiciones y limitaciones
+ Al habilitar la asignación de costos a nivel de trabajo, no se atribuyen retroactivamente los costos de las ejecuciones de tareas que se completaron antes de que se habilitara la función. Las ejecuciones de trabajos que se inicien después de habilitar la función tendrán una atribución de costos granular.
+ El parámetro de asignación de costes a nivel de trabajo solo se puede actualizar cuando una aplicación está en estado CREADA o DETENIDA.
+ Cuando la asignación de costes a nivel de trabajo está habilitada, los costes se atribuyen a las ejecuciones de tareas individuales y no a la aplicación. Para ver los costos agregados a nivel de aplicación, debe aplicar etiquetas consistentes (como el nombre de la aplicación o el identificador de la aplicación) a todas las ejecuciones de trabajos dentro de esa aplicación y filtrar por esas etiquetas en Cost Explorer o Cost and Usage Reports.