# Administración de la carga de trabajo Puede utilizar las características de grupo de trabajo, administración de capacidad, ajuste del rendimiento, soporte de compresión, etiquetas y Service Quotas de Athena para administrar su carga de trabajo. **Topics** + [Uso de grupos de trabajo para controlar el acceso a las consultas y los costos](workgroups-manage-queries-control-costs.md) + [Administración de la capacidad de procesamiento de consultas](capacity-management.md) + [Optimización del rendimiento de Athena](performance-tuning.md) + [Uso de la compresión en Athena](compression-formats.md) + [Etiquetado de recursos de Athena](tags.md) + [Service Quotas](service-limits.md) # Uso de grupos de trabajo para controlar el acceso a las consultas y los costos Puede utilizar grupos de trabajo de Athena para separar cargas de trabajo, controlar el acceso del equipo, hacer cumplir configuraciones y rastrear métricas de consultas, así como controlar costos. **Separación de las cargas de trabajo** Puede usar grupos de trabajo para separar las cargas de trabajo. Por ejemplo, puede crear dos grupos de trabajo independientes, uno para aplicaciones programadas automatizadas, como, por ejemplo, la generación de informes y otro para uso ad-hoc por parte de analistas. **Control de acceso por equipos** Debido a que los grupos de trabajo actúan como recursos de IAM, puede utilizar políticas basadas en identidad a nivel de recurso para controlar quién puede acceder a un grupo de trabajo y ejecutar consultas en este. Para aislar consultas de dos equipos diferentes en su organización, puede crear un grupo de trabajo separado para cada equipo. Cada grupo de trabajo tiene su propio historial de consultas y una lista de consultas guardadas para las consultas en ese grupo de trabajo y no para todas las consultas en la cuenta. Para obtener más información, consulte [Uso de políticas de IAM para el control del acceso al grupo de trabajo](workgroups-iam-policy.md). **Aplicación de configuraciones** Si lo desea, puede hacer cumplir las mismas configuraciones a nivel de grupo de trabajo para todas las consultas que se ejecuten en ese grupo. Estas configuraciones incluyen la ubicación de los resultados de las consultas en Amazon S3, el propietario esperado del bucket, la encriptación y el control de los objetos escritos en el bucket de resultados de las consultas. Para obtener más información, consulte [Invalidación de la configuración del cliente](workgroups-settings-override.md). **Rastreo de métricas de consultas, eventos de consultas y control de costos** Para rastrear métricas de consultas, eventos de consultas y controlar costos para cada grupo de trabajo de Athena, puede utilizar las siguientes características: + **Publicar métricas de consulta**: publique las métricas de consulta de su grupo de trabajo en CloudWatch. Puede ver las métricas de consultas para cada grupo de trabajo en la consola de Athena. En CloudWatch, puede crear paneles personalizados y establecer umbrales y alarmas en estas métricas. Para obtener más información, consulte [Habilitación de las métricas de consulta de CloudWatch en Athena](athena-cloudwatch-metrics-enable.md) y [Supervisión de las métricas de consultas de Athena con CloudWatch](query-metrics-viewing.md). + **Supervisar las métricas de uso de Athena**: vea cómo su cuenta usa los recursos al mostrar el uso actual del servicio en los gráficos y paneles de CloudWatch. Para obtener más información, consulte [Supervisión de las métricas de uso de Athena con CloudWatch](monitoring-athena-usage-metrics.md) + **Supervisar los eventos de las consultas**: utilice Amazon EventBridge para recibir notificaciones en tiempo real sobre el estado de las consultas. Para obtener más información, consulte [Supervisión de los eventos de consultas de Athena con EventBridge](athena-events.md). + **Crear controles de uso de datos**: en Athena, puede configurar controles de uso de datos por consulta y por grupo de trabajo. Athena cancela las consultas cuando superan el umbral especificado o activa una alarma de Amazon SNS cuando se supera el umbral de un grupo de trabajo. Para obtener más información, consulte [Configuración de los controles de uso de datos por consulta y por grupo de trabajo](workgroups-setting-control-limits-cloudwatch.md). + **Usar etiquetas de asignación de costos**: use la consola Administración de facturación y costos para etiquetar grupos de trabajo con etiquetas de asignación de costos. Los costos asociados con la ejecución de consultas en el grupo de trabajo aparecen en los informes de costos y usos con la etiqueta de asignación de costos correspondiente. Para obtener más información, consulte [Uso de etiquetas de asignación de costos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) en la *Guía del usuario de AWS Billing*. + **Usar reservas de capacidad**: puede crear reservas de capacidad con el número de unidades de procesamiento de datos que especifique y agregar uno o más grupos de trabajo a la reserva. Para obtener más información, consulte [Administración de la capacidad de procesamiento de consultas](capacity-management.md). Para obtener información adicional sobre el uso de grupos de trabajo de Athena para separar cargas de trabajo, controlar el acceso de usuarios y administrar el uso y los costos de las consultas, consulte la publicación en el blog de macrodatos de AWS titulada [Consultas separadas y administración de costos mediante grupos de trabajo de Amazon Athena](https://aws.amazon.com/blogs/big-data/separating-queries-and-managing-costs-using-amazon-athena-workgroups/). **nota** Ahora se puede acceder a los recursos de Amazon Athena desde el Estudio unificado de Amazon SageMaker (versión preliminar), lo que le ayuda a acceder a los datos de su organización y actuar sobre ellos con las mejores herramientas. Puede migrar consultas guardadas de un grupo de trabajo de Athena a un proyecto del Estudio unificado de SageMaker, configurar proyectos con grupos de trabajo de Athena existentes y mantener los permisos necesarios mediante actualizaciones de roles de IAM. Para obtener más información, consulte [Migración de recursos de Amazon Athena al Estudio unificado de Amazon SageMaker (versión preliminar)](https://github.com/aws/Unified-Studio-for-Amazon-Sagemaker/tree/main/migration/athena). ## Consideraciones y limitaciones Al utilizar grupos de trabajo en Athena, tenga en cuenta los siguientes puntos: + Cada cuenta tiene un grupo de trabajo principal. De forma predeterminada, si no ha creado ningún grupo de trabajo, todas las consultas en su cuenta se ejecutan en el grupo de trabajo principal. No se puede eliminar el grupo de trabajo principal. Los permisos predeterminados permiten a todos los usuarios autenticados acceder a este grupo de trabajo. + Cuando tiene acceso a un grupo de trabajo, puede ver la configuración del grupo de trabajo, la métrica y los límites de control de uso de datos. Con permisos adicionales, puede editar la configuración y los límites de control de uso de datos. + Cuando ejecuta consultas, se ejecutan en el grupo de trabajo actual. Puede ejecutar consultas en el contexto de un grupo de trabajo en la consola, a través de operaciones de la API, mediante la interfaz de línea de comandos o a través de una aplicación cliente utilizando un controlador JDBC o ODBC. + En el editor de consultas de la consola de Athena, puede abrir hasta diez pestañas de consulta en cada grupo de trabajo. Al cambiar entre grupos de trabajo, las pestañas de consulta permanecen abiertas para un máximo de tres grupos de trabajo. + Puede crear hasta 1000 grupos de trabajo por Región de AWS en su cuenta. + Los grupos de trabajo se pueden desactivar. La desactivación de un grupo de trabajo impide la ejecución de consultas en el grupo hasta que lo vuelva a habilitar. + Athena le avisa si intenta eliminar un grupo de trabajo que contiene consultas guardadas. Antes de eliminar un grupo de trabajo al que otros usuarios tienen acceso, asegúrese de que cuenten con acceso a otro grupo de trabajo que puedan utilizar para ejecutar consultas. **Topics** + [Consideraciones y limitaciones](#workgroups-considerations-limitations) + [Creación de un grupo de trabajo](creating-workgroups.md) + [Administración de los grupos de trabajo](workgroups-create-update-delete.md) + [Uso de CloudWatch y EventBridge para la supervisión de consultas](workgroups-control-limits.md) + [Uso de las API de grupos de trabajo de Athena](workgroups-api-list.md) + [Resolución de problemas de grupos de trabajo](workgroups-troubleshooting.md) # Creación de un grupo de trabajo Para crear un grupo de trabajo se necesitan permisos para las acciones de la API `CreateWorkgroup`. Consulte [Configuración del acceso a grupos de trabajo y etiquetas](workgroups-access.md) y [Uso de políticas de IAM para el control del acceso al grupo de trabajo](workgroups-iam-policy.md). Si está añadiendo etiquetas, también tiene que añadir permisos a `TagResource`. Consulte [Ejemplos de política de etiquetas para grupos de trabajo](tags-access-control.md#tag-policy-examples-workgroups). En el siguiente procedimiento, se muestra cómo utilizar la consola de Athena para crear un grupo de trabajo. Para crear un grupo de trabajo con la API de Athena, consulte [CreateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateWorkGroup.html). **Creación de un grupo de trabajo en la consola de Athena** 1. Decida qué grupos de trabajo va a crear. Algunos puntos a considerar: + Quién puede ejecutar consultas en cada grupo de trabajo y quién es el propietario de la configuración del grupo de trabajo. Utilice políticas de IAM para hacer cumplir los permisos del grupo de trabajo. Para obtener más información, consulte [Uso de políticas de IAM para el control del acceso al grupo de trabajo](workgroups-iam-policy.md). + La ubicación en Amazon S3 que se utilizará para los resultados de las consultas del grupo de trabajo. Todos los usuarios del grupo de trabajo deben tener acceso a esta ubicación. + Si es necesario que los resultados de las consultas del grupo de trabajo se encuentren cifrados. Dado que el cifrado es por grupo de trabajo (no por consulta), se recomienda crear grupos de trabajo separados para los resultados de consultas cifrados y sin cifrar. Para obtener más información, consulte [Cifrado de los resultados de las consultas de Athena en Amazon S3](encrypting-query-results-stored-in-s3.md). 1. Si el panel de navegación de la consola no está visible, elija el menú de expansión de la izquierda. ![\[Elija el menú de expansión.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/nav-pane-expansion.png) 1. En el panel de navegación de la consola de Athena, elija **Grupos de trabajo**. 1. En el panel **Grupos de trabajo**, elija **Crear grupo de trabajo**. 1. En la página **Crear grupo de trabajo**, rellene los campos tal y como se indica a continuación: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/creating-workgroups.html) 1. Elija **Crear grupo de trabajo**. El grupo de trabajo aparece en la lista en la página **Grupos de trabajo**. En el editor de consultas, Athena muestra el grupo de trabajo actual en la opción **Grupo de trabajo** en la parte superior derecha de la consola. Puede utilizar esta opción para cambiar de grupo de trabajo. Cuando ejecuta consultas, se ejecutan en el grupo de trabajo actual. 1. Cree políticas de IAM para sus usuarios, grupos o roles para habilitar el acceso de estos a grupos de trabajo. Las políticas establecen la pertenencia a grupos de trabajo y el acceso a acciones en un recurso de `workgroup`. Para obtener más información, consulte [Uso de políticas de IAM para el control del acceso al grupo de trabajo](workgroups-iam-policy.md). Para ver ejemplos de políticas de JSON, consulte [Configuración del acceso a grupos de trabajo y etiquetas](workgroups-access.md). 1. (Opcional) Configure un nivel mínimo de cifrado en Amazon S3 para todos los resultados de las consultas del grupo de trabajo cuando la opción de anular la configuración del lado del cliente no aplique el cifrado a todo el grupo de trabajo. Puede utilizar esta característica para asegurarse de que los resultados de las consultas nunca se almacenen en un bucket de Amazon S3 sin cifrar. Para obtener más información, consulte [Configuración del cifrado mínimo para un grupo de trabajo](workgroups-minimum-encryption.md). 1. (Opcional) Utilice Amazon CloudWatch y Amazon EventBridge para supervisar las consultas de su grupo de trabajo y administrar los costos. Para obtener más información, consulte [Uso de CloudWatch y EventBridge para la supervisión de consultas y la administración de costos](workgroups-control-limits.md). 1. (Opcional) Utilice la consola Administración de facturación y costos para etiquetar el grupo de trabajo con etiquetas de asignación de costos. Para obtener más información, consulte [Uso de etiquetas de asignación de costos](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) en la *Guía del usuario de AWS Billing*. 1. (Opcional) Para obtener una capacidad de procesamiento dedicada a las consultas del grupo de trabajo, añada el grupo de trabajo a una reserva de capacidad. Puede asignar uno o varios grupos de trabajo a una reserva. Para obtener más información, consulte [Administración de la capacidad de procesamiento de consultas](capacity-management.md). # Invalidación de la configuración del cliente Al crear o editar un grupo de trabajo, puede seleccionar la opción **Invalidar la configuración del lado del cliente**. Esta opción no está seleccionada de forma predeterminada. Dependiendo de si lo selecciona, Athena hace lo siguiente: + Si no se selecciona **Invalidar la configuración del cliente**, no se aplica la configuración del grupo de trabajo al nivel del cliente. Cuando la opción de invalidar la configuración del cliente no se encuentra seleccionada para el grupo de trabajo, Athena utiliza la configuración del cliente para todas las consultas que se ejecutan en el grupo de trabajo, incluida la configuración de la ubicación de los resultados de las consultas, el propietario esperado del bucket, el cifrado y el control de los objetos escritos en el bucket de resultados de las consultas. Cada usuario puede especificar su propia configuración en el menú de **Configuración** en la consola. Si no se establece la configuración del cliente, se aplica la configuración del grupo de trabajo. Si utiliza la AWS CLI, las acciones de la API o los controladores JDBC y ODBC para ejecutar consultas en un grupo de trabajo que no invalida la configuración del cliente, las consultas utilizarán la configuración que especifique en las consultas. + Si se selecciona **Invalidar la configuración del cliente**, se aplica la configuración del grupo de trabajo al nivel del cliente. Cuando la opción de invalidar la configuración del cliente se encuentra seleccionada para el grupo de trabajo, Athena utiliza la configuración del grupo de trabajo para todas las consultas que se ejecutan en el grupo de trabajo, incluida la configuración de la ubicación de los resultados de las consultas, el propietario esperado del bucket, el cifrado y el control de los objetos escritos en el bucket de resultados de las consultas. La configuración del grupo de trabajo invalida cualquier configuración del cliente que especifique para una consulta cuando utilice la consola, las acciones de la API o los controladores JDBC u ODBC. Una vez que las configuraciones del grupo de trabajo se establecen para invalidar las configuraciones del lado del cliente, se pueden omitir las configuraciones del lado del cliente en los controladores o la API. Si invalida la configuración del cliente, la próxima vez que usted o cualquier usuario del grupo de trabajo abra la consola de Athena, Athena le notificará que las consultas en el grupo de trabajo utilizan la configuración del grupo de trabajo y le preguntará si acepta este cambio. **nota** Dado que invalidar la configuración del lado del cliente puede interrumpir la automatización personalizada que se basa en la disponibilidad de los resultados en un bucket arbitrario de Amazon S3, le recomendamos que informe a sus usuarios antes de invalidarla. **importante** Si utiliza las acciones de la API, la AWS CLI o los controladores JDBC y ODBC para ejecutar consultas en un grupo de trabajo y anular la configuración del cliente, asegúrese de omitir la configuración del cliente en las consultas o de actualizarla a fin de que coincida con la configuración del grupo de trabajo. Si especifica la configuración del cliente en las consultas, pero la ejecuta en un grupo de trabajo que anula la configuración, las consultas se ejecutarán, pero se utilizará la configuración del grupo de trabajo. Para obtener información sobre la visualización de la configuración de un grupo de trabajo, consulte [Ver los detalles del grupo de trabajo](viewing-details-workgroups.md). # Administración de los grupos de trabajo En la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home), puede realizar las siguientes tareas: | Instrucción | Descripción | | --- | --- | | [Creación de un grupo de trabajo](creating-workgroups.md) | Crear un grupo de trabajo nuevo. | | [Ver los detalles del grupo de trabajo](viewing-details-workgroups.md) | Vea los detalles del grupo de trabajo, por ejemplo, su nombre, descripción, límites de uso de datos, ubicación de los resultados de las consultas, propietario del bucket esperado de los resultados de las consultas, cifrado y control de los objetos escritos en el bucket de los resultados de las consultas. También puede verificar si este grupo de trabajo aplica su configuración, si se ha seleccionado Invalidar la configuración del cliente. | | [Especificación de un grupo de trabajo para las consultas](specify-wkgroup-to-athena-in-which-to-run-queries.md) | Antes de ejecutar consultas, debe especificar a Athena qué grupo de trabajo se debe utilizar. Debe tener permisos en el grupo de trabajo. | | [Cambiar los grupos de trabajo](switching-workgroups.md) | Cambie entre los grupos de trabajo a los que tiene acceso. | | [Editar un grupo de trabajo](editing-workgroups.md) | Editar un grupo de trabajo y cambiar su configuración. No puede cambiar un nombre de grupo de trabajo, pero puede crear un nuevo grupo de trabajo con la misma configuración y un nombre diferente. | | [Habilitación o deshabilitación de un grupo de trabajo](workgroups-enabled-disabled.md) | Habilite o deshabilite un grupo de trabajo. Cuando un grupo de trabajo está deshabilitado, los usuarios no pueden ejecutar consultas o crear consultas con nombre nuevas. Si tiene acceso a él, puede seguir viendo las métricas, los controles de límites de uso de datos, la configuración de los grupos de trabajo, el historial de consultas y las consultas guardadas. | | [Copiar una consulta guardada entre grupos de trabajo](copy-a-query-between-workgroups.md) | Copie una consulta guardada entre grupos de trabajo. Es posible que desee hacerlo si, por ejemplo, creó una consulta en un grupo de trabajo de vista previa y desea que esté disponible en un grupo de trabajo que no sea de vista previa. | | [Eliminar un grupo de trabajo](deleting-workgroups.md) | Elimine un grupo de trabajo. Si elimina un grupo de trabajo, se eliminan el historial de consultas, las consultas guardas, la configuración del grupo de trabajo y los controles de límites de datos por consulta. Los controles del límite de datos del grupo de trabajo permanecen en CloudWatch y puede eliminarlos de manera individual. No se puede eliminar el grupo de trabajo principal. | | [Uso de políticas de IAM para el control del acceso al grupo de trabajo](workgroups-iam-policy.md) | Utilice las políticas de IAM para controlar el acceso al grupo de trabajo. Para obtener ejemplos de políticas de grupo de trabajo, consulte [Ejemplos de políticas de grupo de trabajo](example-policies-workgroup.md). | | [Creación de un grupo de trabajo de Athena que utilice la autenticación del IAM Identity Center](workgroups-identity-center.md) | Para utilizar las identidades del IAM Identity Center con Athena, debe crear un grupo de trabajo habilitado para IAM Identity Center. Después de crear el grupo de trabajo, puede utilizar la consola o la API del IAM Identity Center para asignar usuarios o grupos del IAM Identity Center al grupo de trabajo. | | [Configuración del cifrado mínimo para un grupo de trabajo](workgroups-minimum-encryption.md) | Aplique un nivel mínimo de cifrado en Amazon S3 para todos los resultados de las consultas del grupo de trabajo. Utilice esta característica para garantizar que los resultados de las consultas nunca se almacenen en un bucket de Amazon S3 en un estado sin cifrar. | # Ver los detalles del grupo de trabajo Para cada grupo de trabajo, puede ver sus detalles. Los detalles incluyen el nombre del grupo de trabajo, la descripción, si está habilitado o desactivado, y la configuración que se utiliza para las consultas que se ejecutan en el grupo de trabajo, que incluyen la ubicación de los resultados de las consultas, el propietario del bucket esperado, el cifrado y el control de objetos escritos en el bucket de resultados de las consultas. Si un grupo de trabajo tiene límites de uso de datos, también se muestran. **Para ver los detalles del grupo de trabajo** 1. En el panel de navegación de la consola de Athena, elija **Grupos de trabajo**. 1. En la página **Grupos de trabajo**, elija el enlace del grupo de trabajo que quiere ver. La página **Información general sobre los detalles** muestra la página del grupo de trabajo. # Especificación de un grupo de trabajo para las consultas Para especificar un grupo de trabajo que se va a utilizar, debe tener permisos del grupo de trabajo. **Para especificar el grupo de trabajo que se va a utilizar** 1. Asegúrese de que sus permisos le permiten ejecutar consultas en un grupo de trabajo que pretende utilizar. Para obtener más información, consulte [Uso de políticas de IAM para el control del acceso al grupo de trabajo](workgroups-iam-policy.md). 1. Para especificar el grupo de trabajo, utilice una de estas opciones: + Si va a usar la consola de Athena, establezca el grupo de trabajo [mediante el cambio de grupos de trabajo](switching-workgroups.md). + Si utiliza las operaciones de la API de Athena, especifique el nombre de grupo de trabajo de la acción de la API. Por ejemplo, puede definir el nombre de grupo de trabajo en [StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html), tal y como se indica a continuación: ``` StartQueryExecutionRequest startQueryExecutionRequest = new StartQueryExecutionRequest() .withQueryString(ExampleConstants.ATHENA_SAMPLE_QUERY) .withQueryExecutionContext(queryExecutionContext) .withWorkGroup(WorkgroupName) ``` + Si utiliza el controlador JDBC u ODBC, establezca el nombre del grupo de trabajo en la cadena de conexión mediante el parámetro de configuración `Workgroup`. El controlador pasa el nombre del grupo de trabajo a Athena. Especifique el parámetro de grupo de trabajo en la cadena de conexión tal y como se muestra en el siguiente ejemplo: ``` jdbc:awsathena://AwsRegion=;UID=; PWD=;S3OutputLocation=s3://amzn-s3-demo-bucket/-/; Workgroup=; ``` # Cambiar los grupos de trabajo Puede cambiar de un grupo de trabajo a otro si tiene permisos para ambos. Puede abrir hasta diez pestañas de consulta dentro de cada grupo de trabajo. Al cambiar entre grupos de trabajo, la pestaña de la consulta permanece abierta para hasta tres grupos de trabajo. **Para cambiar grupos de trabajo** 1. En la consola de Athena, utilice la opción **Grupo de trabajo** en la parte superior derecha para elegir uno. 1. Si aparece el cuadro de diálogo de **configuración del grupo de trabajo *workgroup-name***, elija **Confirmación**. La opción **Grupo de trabajo** muestra el nombre del grupo de trabajo al que se ha cambiado. Ahora ya puede ejecutar consultas en este grupo de trabajo. # Editar un grupo de trabajo Para editar un grupo de trabajo se necesitan permisos para las operaciones de la API `UpdateWorkgroup`. Consulte [Configuración del acceso a grupos de trabajo y etiquetas](workgroups-access.md) y [Uso de políticas de IAM para el control del acceso al grupo de trabajo](workgroups-iam-policy.md). Si está añadiendo o editando etiquetas, también tiene que tener permisos para `TagResource`. Consulte [Ejemplos de política de etiquetas para grupos de trabajo](tags-access-control.md#tag-policy-examples-workgroups). **Para editar un grupo de trabajo en la consola** 1. En el panel de navegación de la consola de Athena, elija **Grupos de trabajo**. 1. En la página **Grupos de trabajo**, seleccione el botón del grupo de trabajo que quiere editar. 1. Seleccione **Acciones**, **Editar**. 1. Cambie los campos según sea necesario. Para la lista de campos, consulte [Crear grupo de trabajo](creating-workgroups.md). Puede cambiar todos los campos, excepto el nombre del grupo de trabajo. Si necesita cambiar el nombre, cree otro grupo de trabajo con el nuevo nombre y la misma configuración. 1. Seleccione **Save changes (Guardar cambios)**. El grupo de trabajo actualizado aparece en la lista de la página **Grupos de trabajo**. # Habilitación o deshabilitación de un grupo de trabajo Si tiene permisos para hacerlo, puede habilitar o deshabilitar grupos de trabajo en la consola, mediante las operaciones de la API o con los controladores JDBC y ODBC. **Para habilitar o deshabilitar un grupo de trabajo** 1. En el panel de navegación de la consola de Athena, elija **Grupos de trabajo**. 1. En la página **Grupos de trabajo**, elija el enlace del grupo de trabajo. 1. En la esquina superior derecha, elija **Habilitar grupo de trabajo** o **Desactivar grupo de trabajo**. 1. En la petición de confirmación, elija **Habilitar** o **Desactivar**. Si deshabilita un grupo de trabajo, los usuarios no pueden ejecutar consultas en él ni consultas con nombre nuevas. Si habilita un grupo de trabajo, los usuarios pueden utilizarlo para ejecutar consultas. # Copiar una consulta guardada entre grupos de trabajo Actualmente, la consola de Athena no tiene la opción de copiar una consulta guardada de un grupo de trabajo a otro de forma directa, pero puede realizar la misma tarea manualmente mediante el siguiente procedimiento. **Para copiar una consulta guardada entre grupos de trabajo** 1. En la consola de Athena, en el grupo de trabajo desde el que desea copiar la consulta, elija la pestaña **Consultas guardadas**. 1. Elija el enlace de la consulta guardada que quiere copiar. Athena abre la consulta en el editor de consultas. 1. En el editor de consultas, seleccione el texto de la consulta y, a continuación, presione **Ctrl\$1C** para copiarlo. 1. [Cambie](switching-workgroups.md) al grupo de trabajo de destino o [Cree un grupo de trabajo](creating-workgroups.md) y, a continuación, cambie a él. 1. Abra una nueva pestaña en el editor de consultas y, luego, presione **Ctrl\$1V** para pegar el texto en la pestaña nueva. 1. En el editor de consultas, elija **Guardar como** para guardar la consulta en el grupo de trabajo de destino. 1. En el cuadro de diálogo **Elegir un nombre**, ingrese un nombre para la consulta y una descripción opcional. 1. Seleccione **Save**. # Eliminar un grupo de trabajo Puede eliminar un grupo de trabajo si tiene permiso para hacerlo. No se puede eliminar el grupo de trabajo principal. Si tiene los permisos adecuados, puede eliminar un grupo de trabajo en cualquier momento. También puede eliminar un grupo de trabajo que contiene consultas guardadas. En este caso, antes de proceder a la eliminación de un grupo de trabajo, Athena le avisa de que se eliminarán las consultas guardadas. Si elimina un grupo de trabajo mientras se encuentra en él, la consola cambia el foco al grupo de trabajo principal. Si tiene acceso a él, puede ejecutar consultas y ver su configuración. Si elimina un grupo de trabajo, se eliminan su configuración y los controles del límite de datos por consulta. Los controles del límite de datos del grupo de trabajo permanecen en CloudWatch y puede eliminarlos allí, si es necesario. **importante** Antes de eliminar un grupo de trabajo, asegúrese de que sus usuarios también pertenecen a otros grupos de trabajo donde puedan seguir ejecutando consultas. Si las políticas de IAM de los usuarios les permitían ejecutar consultas *solo* en este grupo de trabajo y lo elimina, ya no tienen permisos para ejecutar consultas. Para obtener más información, consulte [Example policy for running queries in the primary workgroup](example-policies-workgroup.md#example4-run-in-primary-access). **Para eliminar un grupo de trabajo en la consola** 1. En el panel de navegación de la consola de Athena, elija **Grupos de trabajo**. 1. En la página **Grupos de trabajo**, seleccione el botón del grupo de trabajo que quiere eliminar. 1. Elija **Acciones**, **Eliminar**. 1. En la petición de confirmación **Eliminar grupo de trabajo** ingrese el nombre del grupo de trabajo y, a continuación, elija **Eliminar**. Para eliminar un grupo de trabajo con la operación de la API, utilice la acción `DeleteWorkGroup`. # Uso de CloudWatch y EventBridge para la supervisión de consultas y la administración de costos Los grupos de trabajo le permiten definir los límites de control de uso de datos por consulta o por grupo de trabajo, configurar alarmas cuando se superan los límites y publicar métricas de consultas en CloudWatch. En cada grupo de trabajo, puede: + Configurar **controles de uso de datos** por consulta y por grupo de trabajo, y establecer las medidas que se adoptarán en caso de que las consultas superen los umbrales. + Ver y analizar las métricas de consultas, y publicarlas en CloudWatch. Si crea un grupo de trabajo en la consola, la configuración para la publicación de las métricas en CloudWatch se selecciona por usted. Si utiliza las operaciones de la API, debe [habilitar la publicación de las métricas](athena-cloudwatch-metrics-enable.md). Cuando se publican las métricas, se muestran en la pestaña **Métrica** en el panel **Grupos de trabajo**. Las métricas están deshabilitadas de forma predeterminada para el grupo de trabajo principal. ## Video En el siguiente video se muestra cómo crear paneles personalizados y configurar alarmas y desencadenadores en métricas en CloudWatch. Puede utilizar los paneles completados de forma automática directamente desde la consola de Athena para consumir estas métricas de consultas. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/x1V_lhkdKCg/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/x1V_lhkdKCg) **Topics** + [Video](#athena-cloudwatch-metrics-video) + [Habilitación de las métricas de consulta](athena-cloudwatch-metrics-enable.md) + [Supervisión de las métricas de consultas con CloudWatch](query-metrics-viewing.md) + [Supervisión de las métricas de uso con CloudWatch](monitoring-athena-usage-metrics.md) + [Supervisión de los eventos de consultas con EventBridge](athena-events.md) + [Configuración de los controles de uso de datos](workgroups-setting-control-limits-cloudwatch.md) # Habilitación de las métricas de consulta de CloudWatch en Athena Cuando crea un grupo de trabajo en la consola, la configuración para la publicación de las métricas de consultas en CloudWatch se selecciona de forma predeterminada. **Para habilitar o deshabilitar las métricas de consulta en la consola de Athena para un grupo de trabajo** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si el panel de navegación de la consola no está visible, elija el menú de expansión de la izquierda. ![\[Elija el menú de expansión.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/nav-pane-expansion.png) 1. En el panel de navegación, elija **Grupos de trabajo**. 1. Elija el enlace del grupo de trabajo que quiere modificar. 1. En la página de detalles del grupo de trabajo, elija **Editar**. 1. En la sección **Configuración**, seleccione **Publicar métricas de consulta en AWS CloudWatch**. Si utiliza operaciones de la API, la interfaz de línea de comandos o la aplicación cliente con el controlador JDBC para crear grupos de trabajo, para habilitar la publicación de las métricas de consultas, establezca `PublishCloudWatchMetricsEnabled` en `true` en [WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html). En el siguiente ejemplo, se muestra únicamente la configuración de métricas y omite otra configuración: ``` "WorkGroupConfiguration": { "PublishCloudWatchMetricsEnabled": "true" .... } ``` # Supervisión de las métricas de consultas de Athena con CloudWatch Athena publica métricas relacionadas con las consultas en Amazon CloudWatch cuando se selecciona la opción [Publicar métricas de consultas en CloudWatch](athena-cloudwatch-metrics-enable.md). Puede crear tableros personalizados, configurar alarmas y desencadenadores en métricas en CloudWatch, o utilizar los paneles completados de forma automática directamente desde la consola de Athena. Al habilitar las métricas de consultas en grupos de trabajo, las métricas se mostrarán en la pestaña **Métricas** en el panel **Grupos de trabajo**, para cada grupo de trabajo en la consola de Athena. Athena publica las siguientes métricas en la consola de CloudWatch: + `DPUAllocated`: el número total de DPU (unidades de procesamiento de datos) aprovisionadas en una reserva de capacidad para ejecutar consultas. + `DPUConsumed`: el número de DPU consumidas activamente por las consultas en un estado `RUNNING` determinado de una reserva. La métrica se emite solo cuando el grupo de trabajo está asociado a una reserva de capacidad e incluye todos los grupos de trabajo asociados a una reserva. + `DPUCount`: el número máximo de DPU consumidas por la consulta, que se publica exactamente una vez cuando se completa la consulta. + `EngineExecutionTime`: El número de milisegundos que la consulta tardó en ejecutarse. + `ProcessedBytes`: Número de bytes que Athena ha analizado por consulta de DML. + `QueryPlanningTime`: Número de milisegundos que Athena tardó en planificar el flujo de procesamiento de consultas. + `QueryQueueTime`: Número de milisegundos que la consulta estaba en la cola de consultas en espera de recursos. + `ServicePreProcessingTime`: número de milisegundos que Athena tardó en preprocesar la consulta antes de enviarla al motor de consulta. + `ServiceProcessingTime`: Número de milisegundos que Athena tardó en procesar los resultados de la consulta después de que el motor de consulta terminara de ejecutarla. + `TotalExecutionTime`: Número de milisegundos que Athena tardó en ejecutar una consulta de DDL o DML. Para obtener descripciones más completas, consulte [Lista de métricas y dimensiones de CloudWatch para Athena](#athena-cloudwatch-metrics-table) más adelante en este documento. Estas métricas tienen las dimensiones siguientes: + `CapacityReservation`: el nombre de la reserva de capacidad utilizada para ejecutar la consulta, si corresponde. + `QueryState`: `SUCCEEDED`, `FAILED`, o `CANCELED` + `QueryType`: `DML`, `DDL`, o `UTILITY` + `WorkGroup`: nombre del grupo de trabajo Athena publica las siguientes métricas en la consola de CloudWatch bajo el espacio de nombres `AmazonAthenaForApacheSpark`: + `DPUCount`: número de DPU consumidas durante la sesión para ejecutar los cálculos. Esta métrica tiene las siguientes dimensiones: + `SessionId`: ID de la sesión en la que se envían los cálculos. + `WorkGroup`: nombre del grupo de trabajo. Para obtener más información, consulte [Lista de métricas y dimensiones de CloudWatch para Athena](#athena-cloudwatch-metrics-table) más adelante en este tema. Para obtener información sobre las métricas del uso de Athena, consulte [Supervisión de las métricas de uso de Athena con CloudWatch](monitoring-athena-usage-metrics.md). Puede ver las métricas de las consultas en la consola de Athena o en la consola de CloudWatch. ## Visualización de las métricas de las consultas en la consola de Athena **Visualización de las métricas de consultas de un grupo de trabajo en la consola de Athena** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si el panel de navegación de la consola no está visible, elija el menú de expansión de la izquierda. ![\[Elija el menú de expansión.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/nav-pane-expansion.png) 1. En el panel de navegación, elija **Grupos de trabajo**. 1. Elija el grupo de trabajo que quiera de la lista y, a continuación, elija la pestaña **Métricas**. Aparecerá el panel de métricas. **nota** Si ha habilitado recientemente las métricas para el grupo de trabajo y/o no se ha producido ninguna actividad de consulta reciente, los gráficos del panel pueden estar vacíos. La actividad de consulta se recupera de CloudWatch en función del intervalo que especifique en el siguiente paso. 1. En la sección **Métricas**, elija el intervalo de métricas que Athena debe utilizar para obtener las métricas de consulta de CloudWatch, o bien especifique un intervalo personalizado. ![\[Especificación del intervalo de recuperación de métricas para un grupo de trabajo en la consola de Athena.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/wg-custom-interval.png) 1. Para actualizar las métricas mostradas, elija el icono de actualización. ![\[Elija el icono de actualización.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/wg-refresh-metrics.png) 1. Haga clic en la flecha situada junto al icono de actualización para elegir con qué frecuencia quiere que se actualice la visualización de las métricas. ![\[Elección de un intervalo de actualización para ver métricas de grupo de trabajo en la consola de Athena.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/wg-choose-refresh-interval.png) ## Visualización de las métricas de consultas en la consola de CloudWatch **Para consultar las métricas en la consola de Amazon CloudWatch** 1. Abra la consola de CloudWatch en [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. En el panel de navegación, seleccione **Métricas** y, a continuación, **Todas las métricas**. 1. Seleccione el espacio de nombres de **AWS/Athena**. ## Visualización de las métricas de consultas con la AWS CLI **Cómo visualizar las métricas mediante la AWS CLI** + Realice una de las siguientes acciones: + Para enumerar las métricas de Athena, abra un símbolo del sistema y utilice el siguiente comando: ``` aws cloudwatch list-metrics --namespace "AWS/Athena" ``` + Para mostrar todas las métricas disponibles, utilice el siguiente comando: ``` aws cloudwatch list-metrics" ``` ## Lista de métricas y dimensiones de CloudWatch para Athena Si habilitó métricas de CloudWatch en Athena, envía las siguientes métricas a CloudWatch por grupo de trabajo. Las siguientes métricas utilizan el espacio de nombres `AWS/Athena`. | Nombre de métrica | Descripción | | --- | --- | | DPUAllocated | El número total de DPUs (unidades de procesamiento de datos) aprovisionadas en una reserva de capacidad para ejecutar consultas. | | DPUConsumed | El número de DPU consumidas activamente por las consultas en un estado RUNNING determinado de una reserva. Esta métrica se emite solo cuando el grupo de trabajo está asociado a una reserva de capacidad e incluye todos los grupos de trabajo asociados a una reserva. Si mueve un grupo de trabajo de una reserva a otra, la métrica incluye datos del momento en que el grupo de trabajo pertenecía a la primera reserva. Para obtener información sobre cómo compartir reservas de capacidad, consulte [Administración de la capacidad de procesamiento de consultas](capacity-management.md). | | DPUCount | El número máximo de DPU consumidas por la consulta, que se publica exactamente una vez cuando se completa la consulta. Esta métrica se emite solo para los grupos de trabajo asociados a una reserva de capacidad. | | EngineExecutionTime | El número de milisegundos que la consulta tardó en ejecutarse. | | ProcessedBytes | Número de bytes que Athena ha analizado por consulta de DML. En el caso de las consultas canceladas (ya sea por los usuarios, automáticamente o por alcanzar el límite), se incluye la cantidad de datos escaneados antes de la cancelación. Esta métrica no se informa para las consultas de DDL. | | QueryPlanningTime | Número de milisegundos que Athena tardó en planificar el flujo de procesamiento de consultas. Esto incluye el tiempo dedicado a recuperar las particiones de tabla del origen de datos. Tenga en cuenta que debido a que el motor de consultas realiza la planificación de consultas, el tiempo de planificación de consultas es un subconjunto de EngineExecutionTime. | | QueryQueueTime | Número de milisegundos que la consulta estaba en la cola de consultas en espera de recursos. Tenga en cuenta que si se producen errores transitorios, la consulta se puede agregar automáticamente de nuevo a la cola. | | ServicePreProcessingTime | Número de milisegundos que Athena tardó en preprocesar la consulta antes de enviarla al motor de consulta. | | ServiceProcessingTime | Número de milisegundos que Athena tardó en procesar los resultados de la consulta después de que el motor de consulta terminara de ejecutarla. | | TotalExecutionTime | Número de milisegundos que Athena tardó en ejecutar una consulta de DDL o DML. TotalExecutionTime incluye QueryQueueTime, QueryPlanningTime, EngineExecutionTime y ServiceProcessingTime. | Las métricas de CloudWatch para Athena tienen las siguientes dimensiones. | Dimensión | Descripción | | --- | --- | | CapacityReservation | El nombre de la reserva de capacidad utilizada para ejecutar la consulta, si corresponde. Cuando no se utiliza una reserva de capacidad, esta dimensión no devuelve ningún dato. | | QueryState | El estado de la consulta. Estadísticas válidas: SUCCEEDED, FAILED o CANCELED. | | QueryType | El tipo de consulta. Estadísticas válidas: `DDL`, `DML` o `UTILITY`. El tipo de instrucción de consulta que se ejecutó. `DDL` indica las instrucciones de consulta DDL (lenguaje de definición de datos). `DML` indica instrucciones de consulta DML (lenguaje de manipulación de datos), como `CREATE TABLE AS SELECT`. `UTILITY` indica instrucciones de consulta distintas de DDL y DML, como `SHOW CREATE TABLE` o `DESCRIBE TABLE`. | | WorkGroup | El nombre del grupo de trabajo. | # Supervisión de las métricas de uso de Athena con CloudWatch Puede usar las métricas de uso de CloudWatch para proporcionar visibilidad de cómo su cuenta usa los recursos mostrando el uso actual del servicio en los gráficos y paneles de CloudWatch. Para Athena, las métricas de disponibilidad de uso corresponden a las cuotas de Servicio de AWS para Athena. Puede configurar alarmas que le avisen cuando su uso se acerque a una Service Quota. Para obtener más información acerca de Service Quotas de Athena, consulte [Service Quotas](service-limits.md). Para obtener más información sobre las métricas de uso de AWS, consulte [Métricas de uso de AWS](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Service-Quota-Integration.html) en la *Guía del usuario de Amazon CloudWatch*. Athena publica las siguientes métricas en el espacio de nombres `AWS/Usage`. | Nombre de métrica | Descripción | | --- | --- | | `ResourceCount` | La suma de todas las consultas en cola y en ejecución de una cuenta por Región de AWS, separadas por tipo de consulta (DML o DDL). El máximo es la única estadística útil para esta métrica. Esta métrica se publica periódicamente cada minuto. Si no se ejecuta ninguna consulta, la métrica no reporta nada (ni siquiera 0). La métrica solo se publica si se ejecutan consultas activas en el momento en que se toma la métrica. | Las siguientes dimensiones se utilizan para ajustar las métricas de uso publicadas por Athena. | Dimensión | Descripción | | --- | --- | | `Service` | El nombre de Servicio de AWS que contiene el recurso. Para Athena, el valor de esta dimensión es `Athena`. | | `Resource` | El tipo de recurso que se está ejecutando. El valor del recurso para el uso de consultas de Athena es `ActiveQueryCount`. | | `Type` | El tipo de entidad que se notifica. Actualmente, el único valor válido para las métricas de uso de Athena es `Resource`. | | `Class` | La clase de recurso a la que se realiza el seguimiento. Para Athena, `Class` puede ser un `DML` o un `DDL`. | ## Visualización de las métricas de uso de recursos de Athena en la consola de CloudWatch Puede usar la consola de CloudWatch para ver un gráfico de métricas de uso de Athena y configurar alarmas que alerten cuando el uso se acerque a una cuota de servicio. **Para ver las métricas de uso de los recursos de Athena** 1. Abra la consola de CloudWatch en [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/). 1. En el panel de navegación, seleccione **Métricas** y, a continuación, **Todas las métricas**. 1. Elija **Uso** y, luego, **Por recurso de AWS**. Aparecerá la lista de métricas de uso de cuotas de servicio. 1. Seleccione la casilla que está al lado de **Athena** y **ActiveQueryCount**. 1. Elija la pestaña **Métricas diagramadas**. El gráfico anterior muestra el uso actual del recurso de AWS. Para obtener información sobre cómo agregar cuotas de servicio al gráfico y configurar una alarma que notifique si se acerca a la cuota de servicio, consulte [Visualización de las cuotas de servicio y configuración de alarmas](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Quotas-Visualize-Alarms.html) en la *Guía del usuario de Amazon CloudWatch*. Para obtener información sobre la configuración de los límites de uso por grupo de trabajo, consulte [Configuración de los controles de uso de datos por consulta y por grupo de trabajo](workgroups-setting-control-limits-cloudwatch.md). # Supervisión de los eventos de consultas de Athena con EventBridge Puede utilizar Amazon Athena con Amazon EventBridge para recibir notificaciones en tiempo real sobre el estado de las consultas. Cuando una consulta ha enviado estados de transiciones, Athena publica un evento en EventBridge que contiene información sobre esa transición de estado de consulta. Puede escribir reglas simples para eventos que le interesen y realizar acciones automatizadas cuando un evento coincida con una regla. Por ejemplo, puede crear una regla que invoque una función AWS Lambda cuando una consulta alcance un estado terminal. Los eventos se emiten en la medida de lo posible. Antes de crear reglas de eventos para Athena, debe hacer lo siguiente: + Familiarícese con los eventos, las reglas y los destinos de EventBridge. Para obtener más información, consulte [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) Para obtener más información sobre cómo configurar reglas, consulte [Introducción a Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-get-started.html). + Crear el destino o destinos que se van a usar en las reglas de eventos. **nota** Actualmente, Athena ofrece un tipo de evento, Athena Query State Change (Cambio de estado de consulta de Athena), pero puede agregar otros tipos de eventos y detalles. Si va a deserializar datos JSON de eventos mediante programación, asegúrese de que la aplicación esté preparada para tratar propiedades desconocidas para evitar problemas si se agregan estas propiedades adicionales. ## Formato de eventos de Athena El siguiente es el patrón básico de un evento de Amazon Athena. ``` { "source":[ "aws.athena" ], "detail-type":[ "Athena Query State Change" ], "detail":{ "currentState":[ "SUCCEEDED" ] } } ``` ## Evento de cambio de estado de la consulta de Athena En el ejemplo siguiente se muestra el evento de cambio de estado de la consulta de Athena con un valor `currentState` de `SUCCEEDED`. ``` { "version":"0", "id":"abcdef00-1234-5678-9abc-def012345678", "detail-type":"Athena Query State Change", "source":"aws.athena", "account":"123456789012", "time":"2019-10-06T09:30:10Z", "region":"us-east-1", "resources":[ ], "detail":{ "versionId":"0", "currentState":"SUCCEEDED", "previousState":"RUNNING", "statementType":"DDL", "queryExecutionId":"01234567-0123-0123-0123-012345678901", "workgroupName":"primary", "sequenceNumber":"3" } } ``` En el ejemplo siguiente se muestra el evento de cambio de estado de la consulta de Athena con un valor `currentState` de `FAILED`. El bloque `athenaError` aparece solo cuando el valor de `currentState` es `FAILED`. Para obtener información acerca de los valores para `errorCategory` y `errorType`, consulte [Catálogo de errores de Athena](error-reference.md). ``` { "version":"0", "id":"abcdef00-1234-5678-9abc-def012345678", "detail-type":"Athena Query State Change", "source":"aws.athena", "account":"123456789012", "time":"2019-10-06T09:30:10Z", "region":"us-east-1", "resources":[ ], "detail":{ "athenaError": { "errorCategory": 2.0, //Value depends on nature of exception "errorType": 1306.0, //Type depends on nature of exception "errorMessage": "Amazon S3 bucket not found", //Message depends on nature of exception "retryable":false //Retryable value depends on nature of exception }, "versionId":"0", "currentState": "FAILED", "previousState": "RUNNING", "statementType":"DML", "queryExecutionId":"01234567-0123-0123-0123-012345678901", "workgroupName":"primary", "sequenceNumber":"3" } } ``` ### Propiedades de salida La salida JSON incluye las siguientes propiedades. **** | Propiedad | Descripción | | --- | --- | | athenaError | Aparece solo cuando el valor de currentState es FAILED. Contiene información sobre el error que se ha producido, incluida la categoría de error, el tipo de error, el mensaje de error y si se puede reintentar la acción que ha provocado el error. Los valores de cada uno de estos campos dependen de la naturaleza del error. Para obtener información acerca de los valores para errorCategory y errorType, consulte [Catálogo de errores de Athena](error-reference.md). | | versionId | Número de versión del esquema del objeto de detalle. | | currentState | El estado que adoptó la consulta cuando se produjo el evento. | | previousState | El estado que tenía la consulta cuando se produjo el evento. | | statementType | El tipo de instrucción de consulta que se ejecutó. | | queryExecutionId | El identificador único de la consulta que se ejecutó. | | workgroupName | El nombre del grupo de trabajo en el que se ejecutó la consulta. | | sequenceNumber | Un número monótonamente creciente que permite la deduplicación y la ordenación de eventos entrantes que implican una sola ejecución de consulta. Cuando se publican eventos duplicados para la misma transición de estado, el valor de sequenceNumber es el mismo. Cuando una consulta experimenta una transición de estado más de una vez, como las consultas que experimentan una puesta en cola extraña, puede utilizar sequenceNumber para ordenar eventos con valores de currentState y previousState idénticos. | ## Ejemplo En el siguiente ejemplo se publican eventos en un tema de Amazon SNS al que se ha suscrito. Cuando se realice una consulta en Athena, recibirá un correo electrónico. En el ejemplo se presupone que el tema de Amazon SNS existe y que se ha suscrito a él. **Para publicar eventos de Athena en un tema de Amazon SNS** 1. Cree el destino del tema de Amazon SNS. Conceda a la entidad principal de EventBridge Events Service el permiso `events.amazonaws.com` para publicar en el tema de Amazon SNS, como en el siguiente ejemplo. ``` { "Effect":"Allow", "Principal":{ "Service":"events.amazonaws.com" }, "Action":"sns:Publish", "Resource":"arn:aws:sns:us-east-1:111111111111:your-sns-topic" } ``` 1. Utilice el comando `events put-rule` de la AWS CLI para crear una regla para eventos de Athena, como en el siguiente ejemplo. ``` aws events put-rule --name {ruleName} --event-pattern '{"source": ["aws.athena"]}' ``` 1. Utilice el comando `events put-targets` de la AWS CLI para asociar el destino del tema de Amazon SNS, como en el siguiente ejemplo. ``` aws events put-targets --rule {ruleName} --targets Id=1,Arn=arn:aws:sns:us-east-1:111111111111:your-sns-topic ``` 1. Realice una consulta en Athena y observe el destino que se está invocando. Debería recibir mensajes de correo electrónico correspondientes del tema de Amazon SNS. ## Uso de AWS User Notifications con Amazon Athena Puede utilizar las [AWS User Notifications](https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html) para configurar los canales de entrega a fin de recibir notificaciones sobre los eventos de Amazon Athena. Recibirá una notificación cuando un evento coincida con una regla que especifique. Puede recibir notificaciones de eventos a través de varios canales, como correo electrónico, notificaciones por chat de [Amazon Q Developer en aplicaciones de chat](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) o notificaciones push de [AWS Console Mobile Application](https://docs.aws.amazon.com/consolemobileapp/latest/userguide/what-is-consolemobileapp.html). También puede ver las notificaciones en el [Centro de notificaciones de la consola](https://console.aws.amazon.com/notifications/). Las Notificaciones de usuario admiten la agregación, lo que puede reducir el número de notificaciones que recibe durante eventos específicos. Para obtener más información, consulte la [https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html](https://docs.aws.amazon.com/notifications/latest/userguide/what-is.html). # Configuración de los controles de uso de datos por consulta y por grupo de trabajo Athena le permite configurar dos tipos de controles de costos: límite por consulta y límite por grupo de trabajo. Para cada grupo de trabajo, puede establecer un solo límite por consulta y varios límites por grupo de trabajo. + El **límite de control por consulta** especifica la cantidad total de datos escaneados por consulta. Si cualquier consulta que se ejecuta en el grupo de trabajo supera el límite, se cancela. Puede crear solo un límite de control por consulta en un grupo de trabajo y se aplica a cada consulta que se ejecuta en ella. Edite el límite si necesita cambiarlo. Para conocer los pasos en detalle, consulte [Para crear un control de uso de datos por consulta](#configure-control-limit-per-query). + El **límite de control de uso de datos a escala de grupo de trabajo** especifica la cantidad total de datos escaneados para todas las consultas que se ejecutan en este grupo de trabajo durante el periodo de tiempo especificado. Puede crear varios límites por grupo de trabajo. El límite de consulta en todo el grupo de trabajo le permite definir varios umbrales en resúmenes por hora o diarios en los datos examinados por las consultas que se ejecutan en el grupo de trabajo. Si la cantidad agregada de datos escaneados supera el umbral, puede enviar una notificación a un tema de Amazon SNS. Para ello, configure una alarma de Amazon SNS y una acción en la consola de Athena para notificar a un administrador cuando se supere el límite. Para conocer los pasos en detalle, consulte [Para crear un control de uso de datos por grupo de trabajo](#configure-control-limit-per-workgroup). También puede crear una alarma y una acción en cualquiera de las métricas que Athena publica desde la consola de CloudWatch. Por ejemplo, puede establecer una alerta en una serie de consultas fallidas. Esta alerta puede desencadenar un correo electrónico a un administrador si el número supera un determinado umbral. Si se supera el límite, una acción envía una notificación de alarma de Amazon SNS a los usuarios especificados. Otras acciones que puede llevar a cabo: + Invoca una función de Lambda. Para obtener más información, consulte [Invocación de funciones de Lambda mediante notificaciones de Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-lambda-as-subscriber.html) en la *Guía para desarrolladores de Amazon Simple Notification Service*. + Deshabilite el grupo trabajo para detener la ejecución de consultas adicionales. Para ver los pasos, consulte [Habilitación o deshabilitación de un grupo de trabajo](workgroups-enabled-disabled.md). Los límites por consulta y por grupo de trabajo son independientes entre sí. Se toma una acción especificada siempre que se supera cualquiera de los límites. Si dos o más usuarios ejecutan consultas al mismo tiempo en el mismo grupo de trabajo, es posible que cada consulta no supere cualquiera de los límites especificados, pero la suma total de datos escaneados supera el límite de uso de datos por grupo de trabajo. En este caso, se envía al usuario una alarma de Amazon SNS. ## Creación de un control de uso de datos por consulta **Para crear un control de uso de datos por consulta** El límite de control por consulta especifica la cantidad total de datos escaneados por consulta. Si cualquier consulta que se ejecuta en el grupo de trabajo supera el límite, se cancela. Las consultas canceladas se cobran de acuerdo con los [Precios de Amazon Athena](https://aws.amazon.com/athena/pricing/). **nota** En el caso de consultas canceladas o fallidas, es posible que Athena ya haya escrito resultados parciales en Amazon S3. En estos casos, Athena no elimina los resultados parciales del prefijo de Amazon S3 donde se almacenan los resultados. Debe eliminar el prefijo de Amazon S3 con resultados parciales. Athena utiliza cargas multiparte de Amazon S3 para escribir datos en Amazon S3. Le recomendamos que establezca la política del ciclo de vida del bucket para finalizar las cargas multiparte en casos en los que las consultas devuelven un error. Para obtener más información, consulte [Anulación de cargas multiparte incompletas con una política de ciclo de vida de bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html#mpu-abort-incomplete-mpu-lifecycle-config) en la *Guía del usuario de Amazon Simple Storage Service*. En determinadas condiciones, es posible que Athena vuelva automáticamente a intentar ejecutar consultas. En la mayoría de los casos, estas consultas se pueden completar correctamente y el identificador de la consulta se marca como `Completed`. Es posible que estas consultas hayan arrojado resultados parciales durante los intentos iniciales y que generen cargas de varias partes incompletas. Puede crear solo un límite de control por consulta en un grupo de trabajo y se aplica a cada consulta que se ejecuta en ella. Edite el límite si necesita cambiarlo. 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. En el panel de navegación, elija **Grupos de trabajo**. 1. Elija el nombre del grupo de trabajo en la lista. 1. En la pestaña **Controles de ejecución**, elija **Editar controles**. 1. Edite el valor del **límite de datos escaneados**. + Especifique un valor comprendido entre 10 MB (mínimo) y 7 EB (máximo). + Para unidades, seleccione el valor de la unidad de la lista desplegable (por ejemplo, **Kilobytes KB** o **Exabytes EB**). **nota** La acción predeterminada consiste en cancelar la consulta si se supera el límite. Esta configuración no se puede cambiar. 1. Seleccione **Guardar** para aplicar los cambios inmediatamente. ## Creación o edición de una alerta de uso de datos por grupo de trabajo **Para crear o editar una alerta de uso de datos por grupo de trabajo** Puede establecer varios umbrales de alerta cuando las consultas que se ejecutan en un grupo de trabajo analizan una cantidad específica de datos en un periodo específico. Las alertas se implementan mediante las alarmas de Amazon CloudWatch y se aplican a todas las consultas del grupo de trabajo. Cuando se alcanza un umbral, puede hacer que Amazon SNS envíe un correo electrónico a los usuarios que especifique. Las consultas no se cancelan automáticamente cuando se alcanza un umbral. 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si el panel de navegación de la consola no está visible, elija el menú de expansión de la izquierda. 1. En el panel de navegación, elija **Grupos de trabajo**. 1. Elija el nombre del grupo de trabajo en la lista. 1. Elija **Editar** para editar la configuración del grupo de trabajo. 1. Desplácese hasta **Alertas de uso de datos de grupos de trabajo: opcional** y expándalo. 1. Elija **Agregar alerta**. 1. En **Configuración del umbral de uso de datos**, especifique los siguientes valores: + En **Umbral de datos**, especifique un número y, a continuación, seleccione un valor de la unidad de la lista desplegable. + En **Periodo**, elija un periodo de la lista desplegable. + En **Selección de temas de SNS**, elija un tema de Amazon SNS de la lista desplegable. O bien, elija **Crear un tema de SNS** para ir directamente a la [Consola de Amazon SNS](https://console.aws.amazon.com/sns/v2/home), cree el tema de Amazon SNS y configure una suscripción para uno de los usuarios de su cuenta de Athena. Para obtener más información, consulte [Introducción a Amazon SNS](https://docs.aws.amazon.com/sns/latest/dg/sns-getting-started.html) en la *Guía para desarrolladores de Amazon Simple Notification Service*. 1. Elija **Agregar alerta** si va a crear una nueva alerta, o **Guardar** para guardar una alerta existente. # Uso de las API de grupos de trabajo de Athena A continuación, se indican algunas de las operaciones de la API de REST que se utilizan para grupos de trabajo de Athena. En todas las siguientes operaciones, excepto `ListWorkGroups`, debe especificar un grupo de trabajo. En otras operaciones, como, por ejemplo `StartQueryExecution`, el parámetro de grupo de trabajo es opcional y las operaciones no se incluyen aquí. Para obtener la lista completa de operaciones, consulte la [Referencia de la API de Amazon Athena](https://docs.aws.amazon.com/athena/latest/APIReference/). + [CreateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateWorkGroup.html) + [DeleteWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_DeleteWorkGroup.html) + [GetWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetWorkGroup.html) + [ListWorkGroups](https://docs.aws.amazon.com/athena/latest/APIReference/API_ListWorkGroups.html) + [UpdateWorkGroup](https://docs.aws.amazon.com/athena/latest/APIReference/API_UpdateWorkGroup.html) # Resolución de errores de grupos de trabajo Utilice los siguientes consejos para solucionar problemas de grupos de trabajo. + Compruebe los permisos de los usuarios individuales en su cuenta. Deben tener acceso a la ubicación para los resultados de las consultas, así como al grupo de trabajo en el que desean ejecutar consultas. Si desean cambiar de grupo de trabajo, también necesitan permisos para ambos grupos de trabajo. Para obtener más información, consulte [Uso de políticas de IAM para el control del acceso al grupo de trabajo](workgroups-iam-policy.md). + Preste atención al contexto en la consola de Athena para ver en qué grupo de trabajo va a ejecutar consultas. Si utiliza el controlador, asegúrese de establecer el grupo de trabajo que necesita. Para obtener más información, consulte [Especificación de un grupo de trabajo para las consultas](specify-wkgroup-to-athena-in-which-to-run-queries.md). + Si utiliza la API o los controladores para ejecutar consultas, debe especificar la ubicación de los resultados de la consulta de una de las siguientes dos formas: para consultas individuales, utilice [OutputLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_ResultConfiguration.html#athena-Type-ResultConfiguration-OutputLocation) (del cliente). En el grupo de trabajo, utilice [WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html). Si no se especifica la ubicación de alguna de las dos maneras, Athena genera un error de tiempo de ejecución de consulta. + Si invalida la configuración del lado del cliente con la configuración de grupo de trabajo, pueden producirse errores relacionados con la ubicación de resultados de la consulta. Por ejemplo, un usuario del grupo de trabajo podría no tener permisos en la ubicación del grupo de trabajo en Amazon S3 para almacenar los resultados de las consultas. En este caso, añada los permisos necesarios. + Los grupos de trabajo introducen cambios en el comportamiento de las operaciones de la API. Las llamadas a las siguientes operaciones de la API requieren que los usuarios de su cuenta tengan permisos basados en recursos en IAM a los grupos de trabajo donde realizan dichas operaciones. Si no existen permisos para el grupo de trabajo y para las acciones del grupo de trabajo, las siguientes acciones de la API arrojan `AccessDeniedException`: **CreateNamedQuery**, **DeleteNamedQuery**, **GetNamedQuery**, **ListNamedQueries**, **StartQueryExecution**, **StopQueryExecution**, **ListQueryExecutions**, **GetQueryExecution**, **GetQueryResults** y **GetQueryResultsStream** (esta acción de la API solo está disponible para su uso con el controlador y no está expuesta de otra manera para uso público). Para obtener más información, consulte [Acciones, recursos y claves de condición de Amazon Athena](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html) en la *Referencia de autorizaciones de servicio*. Las llamadas a las operaciones de la API **BatchGetQueryExecution** y **BatchGetNamedQuery** devuelven información solo para aquellas consultas que se ejecutan en grupos de trabajo a los que los usuarios tienen acceso. Si el usuario no tiene acceso al grupo de trabajo, estas operaciones de la API devuelven los ID de las consultas no autorizadas como parte de la lista de ID sin procesar. Para obtener más información, consulte [Uso de las API de grupos de trabajo de Athena](workgroups-api-list.md). + Si el grupo de trabajo en el que se ejecuta una consulta se ha configurado con una [ubicación de resultados de consulta impuesta](workgroups-settings-override.md), no especifique una `external_location` para la consulta CTAS. Athena emite un error y falla una consulta que especifica un `external_location` en este caso. Por ejemplo, se produce un error en esta consulta, si invalida la configuración del lado del cliente para la ubicación de resultados de la consulta, que obliga a que el grupo de trabajo utilice su propia ubicación: `CREATE TABLE . WITH (format='Parquet', external_location='s3://amzn-s3-demo-bucket/test/') AS SELECT * FROM . LIMIT 10;` Podría ver los siguientes errores. Esta tabla proporciona una lista de algunos de los errores relacionados con grupos de trabajo y sugiere soluciones. **Errores de grupos de trabajo** | Error | Se produce cuando... | | --- | --- | | estado de consulta CANCELADO. Se ha superado el límite de bytes escaneados. | Una consulta alcanza un límite de datos por consulta y se cancela. Considere la posibilidad de volver a escribir la consulta para que lea menos datos o póngase en contacto con su administrador de cuenta. | | User: arn:aws:iam::123456789012:user/abc is not authorized to perform: athena:StartQueryExecution on resource: arn:aws:athena:us-east-1:123456789012:workgroup/workgroupname (El usuario: arn:aws:iam::123456789012:user/abc no tiene autorizacion para realizar: athena:StartQueryExecution en el recurso: arn:aws:athena:us-east-1:123456789012:workgroup/workgroupname) | Un usuario ejecuta una consulta en un grupo de trabajo, pero no tiene acceso a ella. Actualice su política para tener acceso al grupo de trabajo. | | INVALID\$1INPUT. WorkGroup is disabled. (INVALID\$1INPUT. WorkGroup se ha deshabilitado. | Un usuario ejecuta una consulta en un grupo de trabajo, pero el grupo de trabajo está deshabilitado. Su administrador podría haber deshabilitado el grupo de trabajo. También es posible que no tenga acceso a él. En ambos casos, póngase en contacto con un administrador con acceso para modificar grupos de trabajo. | | INVALID\$1INPUT. WorkGroup is not found. (INVALID\$1INPUT. WorkGroup no se encuentra. | Un usuario ejecuta una consulta en un grupo de trabajo, pero el grupo de trabajo no existe. Esto podría ocurrir si se eliminó el grupo de trabajo. Cambie a otro grupo de trabajo para ejecutar su consulta. | | InvalidRequestException: when calling the StartQueryExecution operation: No output location provided. An output location is required either through the Workgroup result configuration setting or as an API input. (InvalidRequestException: al llamar a la operación StartQueryExecution: no se proporciona ninguna ubicación de salida. Se requiere una ubicación de salida mediante la configuración de resultados del grupo de trabajo o como entrada de la API. | Un usuario ejecuta una consulta con la API sin especificar la ubicación para los resultados de la consulta. Debe establecer la ubicación de salida de los resultados de la consulta de una de las siguientes dos formas: para consultas individuales mediante [OutputLocation](https://docs.aws.amazon.com/athena/latest/APIReference/API_ResultConfiguration.html#athena-Type-ResultConfiguration-OutputLocation) (del cliente) o en el grupo de trabajo, mediante [WorkGroupConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_WorkGroupConfiguration.html). | | La consulta Crear tabla como selección devolvió un error porque se envió con una propiedad “external\$1location” a un grupo de trabajo de Athena que aplica una ubicación de salida centralizada para todas las consultas. Elimine la propiedad 'external\$1location' y vuelva a enviar la consulta. | Si el grupo de trabajo en el que se ejecuta una consulta se ha configurado con una [ubicación de resultados de consulta impuesta](workgroups-settings-override.md) y especifica una external\$1location para la consulta CTAS. En este caso, elimine la external\$1location y vuelva a ejecutar la consulta. | | Cannot create prepared statement prepared\$1statement\$1name. The number of prepared statements in this workgroup exceeds the limit of 1000. (No se puede crear la instrucción preparada “prepared\$1statement\$1name”. El número de instrucciones preparadas en este grupo de trabajo supera el límite de 1000. | El grupo de trabajo contiene más del límite de 1000 instrucciones preparadas. Para solucionar este problema, utilice [DEALLOCATE PREPARE](sql-deallocate-prepare.md) para eliminar una o más instrucciones preparadas del grupo de trabajo. También puede crear un grupo de trabajo nuevo. | # Administración de la capacidad de procesamiento de consultas Puede utilizar las reservas de capacidad a fin de obtener una capacidad de procesamiento sin servidor dedicada para las consultas que ejecute en Athena. Con las reservas de capacidad, puede aprovechar las funciones de administración de la carga de trabajo que lo ayudan a priorizar, controlar y escalar sus cargas de trabajo más importantes. Por ejemplo, puede añadir capacidad para controlar la cantidad de consultas que puede ejecutar al mismo tiempo, elegir qué cargas de trabajo pueden utilizar la capacidad y compartir la capacidad entre las cargas de trabajo. La capacidad es sin servidor y Athena la administra por completo y la conserva durante el tiempo que la necesite. La configuración es sencilla y no es necesario realizar cambios en las consultas SQL. A fin de obtener capacidad de procesamiento para sus consultas, cree una reserva de capacidad, especifique la cantidad de unidades de procesamiento de datos (DPU) que necesita y asigne uno o más grupos de trabajo a la reserva. Los grupos de trabajo desempeñan un rol importante cuando se utilizan reservas de capacidad. Los grupos de trabajo permiten organizar las consultas en agrupaciones lógicas o casos de uso. Con las reservas de capacidad, puede asignar capacidad a los grupos de trabajo de forma selectiva para controlar el comportamiento de las consultas de cada grupo de trabajo y la forma en que se facturan. Para obtener información acerca de los grupos de trabajo, consulte [Uso de grupos de trabajo para controlar el acceso a las consultas y los costos](workgroups-manage-queries-control-costs.md). Al asignar grupos de trabajo a las reservas de capacidad, puede dar prioridad a estas consultas, ya que se ejecutan en la capacidad reservada y no se tienen en cuenta para la cuota de consultas de DDL y DML. Por ejemplo, puede asignar capacidad a un grupo de trabajo que se utilice para consultas de informes financieros urgentes a fin de aislarlas de las consultas menos importantes de otro grupo de trabajo. Esto permite una ejecución predecible de las consultas para las cargas de trabajo importantes y, al mismo tiempo, permite que otras cargas de trabajo se ejecuten de forma independiente. Puede utilizar las reservas de capacidad y los grupos de trabajo de forma conjunta para cumplir distintos requisitos. A continuación se muestran algunas situaciones de ejemplo: + **Aísle las consultas importantes**: para garantizar que una carga de trabajo importante tenga la capacidad que necesita cuando la necesita, cree una reserva de capacidad y asigne su grupo de trabajo a la reserva. Solo las consultas del grupo de trabajo asignado utilizan la capacidad de procesamiento de la reserva elegida. Por ejemplo, para garantizar la ejecución fiable de las consultas compatibles con una aplicación de producción, debe asignar el grupo de trabajo de producción para esas consultas a una reserva de capacidad. Al desarrollar las consultas, utilice un grupo de trabajo independiente que no esté asociado a una reserva y mueva las consultas al grupo de trabajo de producción cuando estén listas. + **Comparta capacidad en cargas de trabajo similares**: varias cargas de trabajo pueden compartir capacidad de una reserva. Esto le permite lograr un costo predecible para estas cargas de trabajo y controlar su simultaneidad. Por ejemplo, si tiene cargas de trabajo programadas que son tolerantes a horas de inicio de ejecución de consultas retrasadas, puede asignar sus grupos de trabajo a una única reserva. Esto libera la cuota de consultas DDL y DML para consultas interactivas que se ejecutan en la misma cuenta, lo que garantiza que estas consultas se inicien con un retraso mínimo. ## Descripción de las DPU La capacidad se mide en unidades de procesamiento de datos (DPU). Las DPU representan los recursos de computación sin servidor y memoria que Athena utiliza para acceder a los datos y procesarlos en su nombre. Normalmente, una DPU proporciona 4 vCPU y 16 GB de memoria. La cantidad de DPU que retenga influirá en la cantidad de consultas que puede ejecutar de forma simultánea. Por ejemplo, una reserva con 256 DPU puede permitir aproximadamente el doble de consultas simultáneas que una reserva con 128 DPU. Para obtener información sobre cómo calcular sus requisitos de capacidad, consulte [Determinación de los requisitos de capacidad](capacity-management-requirements.md). Para obtener información sobre precios, consulte [Precios de Amazon Athena](https://aws.amazon.com/athena/pricing/). ## Consideraciones y limitaciones + Puede utilizar las reservas de capacidad y la facturación por consulta basadas en los datos escaneados al mismo tiempo y en la misma cuenta. + Las consultas que se ejecutan con reservas de capacidad no se tienen en cuenta para la cuota de consultas de DDL y DML. + Si su capacidad está ocupada atendiendo otras consultas, las consultas que enviadas recientemente se pondrán en cola hasta que haya capacidad disponible. El tiempo máximo permitido de espera es de 10 horas. + Un grupo de trabajo se puede asignar a una reserva de capacidad cada vez. Puede asignar un total de 20 grupos de trabajo a una sola reserva. Al asignar varios grupos de trabajo a una reserva, la capacidad se comparte entre los grupos de trabajo y se asigna a las consultas en función del orden de envío. Puede haber variaciones en el orden de ejecución debido a la forma en que Athena asigna dinámicamente la capacidad a las consultas. + Athena asigna automáticamente entre 4 y 124 DPU a las consultas DML en función de su complejidad. Las consultas DDL consumen 4 DPU cada una. Para obtener más información, consulte los siguientes temas: + [Determinación de los requisitos de capacidad](capacity-management-requirements.md) + [Control del uso de la capacidad](capacity-management-control-capacity-usage.md) + La cantidad mínima de DPU necesarias con cada reserva de capacidad es 4. Para obtener información sobre precios, consulte [Precios de Amazon Athena](https://aws.amazon.com/athena/pricing/). + Puede crear hasta 100 reservas de capacidad con un total de hasta 1000 DPU por cuenta y región. Si necesita más de 1000 DPU para su caso de uso, póngase en contacto con [athena-feedback@amazon.com.](mailto:athena-feedback@amazon.com?subject=Athena Provisioned Capacity DPU Limit Request) + Las solicitudes de capacidad no están garantizadas y se pueden completar en hasta 30 minutos. La capacidad no es transferible a otra reserva de capacidad, Cuenta de AWS o Región de AWS. + La métrica de CloudWatch `DPUConsumed` es por grupo de trabajo y no por reserva. Por lo tanto, si mueve un grupo de trabajo de una reserva a otra, la métrica `DPUConsumed` incluye datos del momento en que el grupo de trabajo pertenecía a la primera reserva. Para obtener más información sobre las métricas de CloudWatch en Athena, consulte [Supervisión de las métricas de consultas de Athena con CloudWatch](query-metrics-viewing.md). + Para eliminar un grupo de trabajo que se ha asignado a una reserva, elimine primero el grupo de trabajo de la reserva. + No se admiten grupos de trabajo configurados para usar Apache Spark. + Las reservas de capacidad no están disponibles en las siguientes Regiones de AWS comerciales: + Israel (Tel Aviv) + Medio Oriente (EAU) + Medio Oriente (Baréin) + Asia-Pacífico (Nueva Zelanda) **Topics** + [Descripción de las DPU](#capacity-management-understanding-dpus) + [Consideraciones y limitaciones](#capacity-management-considerations-limitations) + [Determinación de los requisitos de capacidad](capacity-management-requirements.md) + [Creación de reservas de capacidad](capacity-management-creating-capacity-reservations.md) + [Control del uso de la capacidad](capacity-management-control-capacity-usage.md) + [Ajuste de la reserva de la capacidad](capacity-management-automatically-adjust-capacity.md) + [Administración de reservas](capacity-management-managing-reservations.md) + [Políticas de IAM para reservas de capacidad](capacity-reservations-iam-policy.md) + [API de reserva de capacidad de Athena](capacity-management-api-list.md) # Determinación de los requisitos de capacidad Antes de crear una reserva de capacidad, puede calcular la capacidad necesaria para poder asignarle el número correcto de DPU. Y, una vez utilizada una reserva, es posible que desee comprobar si la capacidad de la reserva es insuficiente o excesiva. En este tema se describen las técnicas que puede utilizar para realizar estos cálculos y también se describen algunas herramientas de AWS para evaluar el uso y el costo. **Topics** + [Cálculo de la capacidad requerida](#capacity-management-requirements-estimating) + [Señales de que se necesita más capacidad](#capacity-management-requirements-insufficient-capacity) + [Comprobación de la capacidad inactiva](#capacity-management-requirements-idle-capacity) + [Supervisión del consumo de DPU](#capacity-management-requirements-monitoring-dpu-consumption) ## Cálculo de la capacidad requerida Al calcular los requisitos de capacidad, es útil tener en cuenta dos perspectivas: cuánta capacidad podría requerir una consulta en particular y cuánta capacidad podría necesitar en general. ### Cálculo de los requisitos de capacidad por consulta Para determinar la cantidad de DPU que podría necesitar una consulta, puede utilizar las siguientes pautas: + Las consultas DDL consumen 4 DPU. + Las consultas DML consumen entre 4 y 124 DPU. Athena determina el número de DPU que necesita una consulta DML cuando esta se envía. El número varía según el tamaño de los datos, el formato de almacenamiento, la construcción de la consulta y otros factores. Por lo general, Athena intenta seleccionar el número de DPU más bajo y eficiente. Si Athena determina que se necesita más potencia computacional para que la consulta se complete correctamente, aumentará el número de DPU asignadas a la consulta. ### Cálculo de los requisitos de capacidad específicos de la carga de trabajo Para determinar la capacidad que podría necesitar para ejecutar varias consultas al mismo tiempo, tenga en cuenta las pautas generales de la siguiente tabla: **** | Consultas simultáneas | DPU requeridas | | --- | --- | | 10 | 40 o más | | 20 | 96 o más | | 30 o más | 240 o más | Tenga en cuenta que la cantidad real de DPU que necesita depende de sus objetivos y patrones de análisis. Por ejemplo, si desea que las consultas comiencen inmediatamente sin colas, determine su demanda máxima de consultas simultáneas y, a continuación, aprovisione la cantidad de DPU en consecuencia. Puede aprovisionar menos DPU que la demanda máxima, pero es posible que las consultas se pongan en cola cuando se produzca la demanda máxima. Cuando las consultas se ponen en cola, Athena mantiene las consultas en una cola y las ejecuta cuando hay capacidad disponible. Si su objetivo es ejecutar las consultas dentro de un presupuesto fijo, puede utilizar la [AWScalculadora de precios](https://calculator.aws/#/addService/Athena) para determinar la cantidad de DPU necesarias. Por último, recuerde que el tamaño de los datos, el formato de almacenamiento y la forma en que se escribe una consulta influyen en las DPU que requiere una consulta. Para aumentar el rendimiento de las consultas, puede comprimir o particionar los datos o convertirlos en formatos de columnas. Para obtener más información, consulte [Optimización del rendimiento de Athena](performance-tuning.md). ## Señales de que se necesita más capacidad Los mensajes de error de capacidad insuficiente y la cola de consultas son dos indicios de que la capacidad asignada es inadecuada. Si las consultas fallan y aparece un mensaje de error de capacidad insuficiente, es probable que el recuento de DPU de la reserva de capacidad sea demasiado bajo para la carga de trabajo de la consulta. Por ejemplo, si tiene una reserva con 24 DPU y ejecuta una consulta que requiere más de 24 DPU, la consulta fallará. Para controlar este error de consulta, puede utilizar [Eventos de EventBridge](athena-events.md) de Athena. Intente agregar más DPU y vuelva a ejecutar la consulta. Si hay muchas consultas en cola, significa que otras consultas utilizan al máximo su capacidad. Para reducir las colas, realice una de las siguientes acciones: + Agregue las DPU a su reserva para aumentar la simultaneidad de consultas. + Elimine los grupos de trabajo de su reserva para liberar capacidad para otras consultas. Para comprobar si hay demasiadas colas de consultas, utilice la [métrica de CloudWatch](query-metrics-viewing.md) de tiempo de cola de consultas de Athena para los grupos de trabajo de su reserva de capacidad. Si el valor supera el umbral preferido, puede agregar las DPU a la reserva de capacidad. ## Comprobación de la capacidad inactiva Para comprobar la capacidad inactiva, puede reducir el número de DPU de la reserva o aumentar su carga de trabajo y, a continuación, observar los resultados. **Para comprobar la capacidad inactiva** 1. Realice una de las siguientes acciones: + Reduzca la cantidad de DPU de su reserva (reduzca los recursos disponibles). + Agregue grupos de trabajo a su reserva (aumente la carga de trabajo). 1. Utilice [CloudWatch](query-metrics-viewing.md) para medir el tiempo de espera de las consultas. 1. Si el tiempo de espera aumenta más allá del nivel deseado, realice una de las siguientes acciones. + Elimine los grupos de trabajo. + Agregue las DPU a su reserva de capacidad. 1. Después de cada cambio, compruebe el rendimiento y el tiempo de espera de las consultas. 1. Siga ajustando la carga de trabajo o el recuento de DPU para lograr el equilibrio deseado. Si no desea mantener la capacidad fuera del periodo de tiempo preferido, puede [cancelar](capacity-management-cancelling-a-capacity-reservation.md) la reserva y crear otra más adelante. Sin embargo, aunque haya cancelado recientemente la capacidad de otra reserva, las solicitudes de capacidad nueva no están garantizadas y la creación de reservas nuevas lleva tiempo. ## Supervisión del consumo de DPU Una vez ejecutadas las consultas, puede ver la DPU consumida por las consultas para ajustar sus estimaciones de capacidad. Athena proporciona métricas de consumo de DPU a través de la consola, operaciones de API y CloudWatch. Esta información le ayuda a identificar las consultas que consumen más o menos recursos de lo esperado y a optimizar la asignación de capacidad en función de datos reales. Para obtener información detallada sobre la visualización y el seguimiento del consumo de DPU, consulte [Supervisión del uso de DPU](capacity-management-control-capacity-usage.md#capacity-management-monitor-dpu-usage). ## Herramientas para evaluar los requisitos de capacidad y el costo Puede utilizar los siguientes servicios y características en AWS para medir el uso y los costos de Athena. ### Métricas de CloudWatch Puede configurar Athena para que publique métricas relacionadas con consultas en Amazon CloudWatch a nivel de grupo de trabajo. Después de habilitar las métricas para el grupo de trabajo, las métricas de las consultas del grupo de trabajo se muestran en la consola de Athena, en la página de detalles del grupo de trabajo. Para obtener información sobre las métricas de Athena que se publican en CloudWatch y sus dimensiones, consulte [Supervisión de las métricas de consultas de Athena con CloudWatch](query-metrics-viewing.md). ### Métricas de uso de CloudWatch Puede usar las métricas de uso de CloudWatch para proporcionar visibilidad de cómo su cuenta usa los recursos mostrando el uso actual del servicio en los gráficos y paneles de CloudWatch. En Athena, las métricas de disponibilidad de uso corresponden a las [cuotas de servicio](service-limits.md) de AWS para Athena. Puede configurar alarmas que le avisen cuando su uso se acerque a una Service Quota. Para obtener más información, consulte [Supervisión de las métricas de uso de Athena con CloudWatch](monitoring-athena-usage-metrics.md). ### Eventos de Amazon EventBridge Puede utilizar Amazon Athena con Amazon EventBridge para recibir notificaciones en tiempo real sobre el estado de las consultas. Cuando una consulta ha enviado estados de transiciones, Athena publica un evento en EventBridge que contiene información sobre la transición de estado de consulta. Puede escribir reglas simples para eventos que le interesen y realizar acciones automatizadas cuando un evento coincida con una regla. Para obtener más información, consulte los siguientes recursos. + [Supervisión de los eventos de consultas de Athena con EventBridge](athena-events.md) + [¿Qué es Amazon EventBridge?](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-what-is.html) + [Eventos de Amazon EventBridge](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-events.html) ### Etiquetas En Athena, las reservas de capacidad admiten etiquetas. Una etiqueta consta de una clave y un valor. Para realizar un seguimiento de los costos en Athena, puede utilizar etiquetas de asignación de costos generadas por AWS. AWS utiliza las etiquetas de asignación de costos para organizar los costos de los recursos en el [informe de costos y uso](https://docs.aws.amazon.com/cur/latest/userguide/what-is-cur.html). Esto le facilita la categorización y el seguimiento de los costos de AWS. [Para activar las etiquetas de asignación de costos para Athena, utilice la consola de Administración de facturación y costos de AWS](https://console.aws.amazon.com/billing/). Para obtener más información, consulte los siguientes recursos. + [Etiquetado de recursos de Athena](tags.md) + [Activación de etiquetas de asignación de costos generadas por AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/activate-built-in-tags.html) + [Uso de etiquetas de asignación de costos de AWS](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html) # Creación de reservas de capacidad Para empezar, cree una reserva de capacidad con el número de DPU que necesite y, a continuación, asigne uno o más grupos de trabajo que utilizarán esa capacidad para sus consultas. Puede ajustar su capacidad más adelante según sea necesario para ofrecer un rendimiento más uniforme o administrar mejor los costos. Para obtener información sobre cómo calcular sus requisitos de capacidad, consulte [Determinación de los requisitos de capacidad](capacity-management-requirements.md). **importante** Las solicitudes de capacidad no están garantizadas y se pueden completar en hasta 30 minutos. **Para crear una reserva de capacidad** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si el panel de navegación de la consola no está visible, elija el menú de expansión de la izquierda. 1. Elija **Administración**, **Reservas de capacidad**. 1. Elija **Crear reserva de capacidad**. 1. En la página **Crear reserva de capacidad**, en **Nombre de reserva de capacidad**, introduzca el nombre. El nombre debe ser único, de 1 a 128 caracteres de longitud y usar solo los caracteres a-z, A-Z, 0-9, \$1 (guion de subrayado), . (punto) y - (guion). No se puede cambiar el nombre después de crear la reserva. 1. Para **DPU**, elija o introduzca la cantidad de unidades de procesamiento de datos (DPU) que desee en incrementos de 4. Para obtener más información, consulte [Descripción de las DPU](capacity-management.md#capacity-management-understanding-dpus). 1. (Opcional) Amplíe la opción **Etiquetas** y, a continuación, elija **Agregar nueva etiqueta** para agregar uno o más pares de clave/valor personalizados y asociarlos al recurso de reserva de capacidad. Para obtener más información, consulte [Etiquetado de recursos de Athena](tags.md). 1. Elija **Revisar**. 1. Cuando aparezca el mensaje **Confirmar creación de reserva de capacidad**, confirme la cantidad de DPU, Región de AWS y demás información. Si acepta, seleccione **Enviar**. En la página de detalles, el **estado** de la reserva de capacidad aparece como **Pendiente**. Cuando la capacidad de reserva está disponible para ejecutar consultas, su estado se muestra como **Activa**. En este punto, ya está listo para agregar uno o más grupos de trabajo a su reserva. Para ver los pasos, consulte [Introducción de grupos de trabajo a una reserva](capacity-management-adding-workgroups-to-a-reservation.md). # Control del uso de la capacidad Para controlar la cantidad de DPU que Athena asigna a sus consultas, puede configurar controles de DPU máximos o mínimos. Puede configurarlos a nivel de grupo de trabajo para establecer controles de referencia para todas las consultas, o a nivel de consulta individual para un control detallado. Esto le proporciona un control directo sobre el rendimiento de las consultas, la simultaneidad de la carga de trabajo y el costo. + Al establecer un número máximo de DPU, se evita que las consultas consuman más capacidad de la especificada. Esto facilita el control de la simultaneidad de costos y cargas de trabajo. Por ejemplo, si su reserva de capacidad tiene 200 DPU, si establece el máximo de DPU por consulta en 8, podrá ejecutar 25 consultas simultáneamente. Si aumenta la reserva a 400 DPU, puede ejecutar 50 consultas simultáneamente. + Al establecer un número mínimo de DPU, se asegura de que las consultas se ejecuten con el número mínimo de DPU deseado. Esto resulta útil si se conoce de antemano el perfil de uso de la capacidad típico de las consultas. **nota** Los controles de uso de la DPU solo se aplican a las consultas ejecutadas con reservas de capacidad. **nota** Para usar la misma cantidad de DPU para todas las consultas, use el mismo valor para la DPU mínima y máxima. ## Configuración de los controles de la DPU a nivel de grupo de trabajo Configure los controles de la DPU a nivel de grupo de trabajo para administrar los costos y controlar el rendimiento de la carga de trabajo del grupo de trabajo que elija. Los controles de la DPU configurados a nivel de grupo de trabajo se aplican a todas las consultas cuando está habilitada la opción **Anular la configuración del lado del cliente**. **Configuración de los controles de DPU mediante la consola** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. En el panel de navegación, elija **Workgroups** (Redes globales). 1. Seleccione un grupo de trabajo que utilice una reserva de capacidad. 1. En la pestaña **Controles de ejecución**, elija **Editar controles**. 1. Configura lo siguiente: + En el caso de la **DPU mínima por consulta**, introduzca un valor entre 4 y 124 en incrementos de 4. + En el caso de la **DPU máxima por consulta**, introduzca un valor entre 4 y 124 en incrementos de 4. 1. Seleccione **Save**. 1. (Opcional) Seleccione **Anular la configuración del cliente** para aplicar esta configuración e ignorar las configuraciones de DPU a nivel de consulta. **Configuración de los controles de DPU mediante la AWS CLI** + Utilice el comando `update-work-group` para configurar los controles de la DPU para un grupo de trabajo: ``` aws athena update-work-group \ --work-group my_workgroup \ --configuration-updates '{ "EngineConfiguration": { "Classifications": [ { "Name": "athena-query-engine-properties", "Properties": { "max-dpu-count" : "24", "min-dpu-count" : "12" } } ] }}' ``` Si establece `EnforceWorkGroupConfiguration` en `true`, la configuración del grupo de trabajo anulará cualquier control de DPU especificado en el nivel de consulta cuando se envíe mediante [StartQueryExecution](https://docs.aws.amazon.com/athena/latest/APIReference/API_StartQueryExecution.html). Esto garantiza una asignación coherente de recursos en todas las consultas del grupo de trabajo. ## Configuración de los controles de la DPU con consultas individuales Establezca controles de DPU a nivel de consulta cuando necesite un control detallado con consultas que tengan diferentes requisitos de recursos. Los controles de la DPU a nivel de consulta tienen prioridad sobre la configuración a nivel de grupo de trabajo, a menos que el grupo de trabajo tenga habilitada la opción **Anular la configuración del cliente.** **Configuración de los controles de DPU para una consulta mediante la consola** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. En el panel de navegación, seleccione **Query Editor (Editor de consultas)**. 1. Seleccione un grupo de trabajo que utilice una reserva de capacidad. 1. Seleccione la pestaña de **configuración de consultas**. 1. En la sección **Controles de ejecución**, elija **Editar controles**. 1. Configura lo siguiente: + En el caso de la **DPU mínima por consulta**, introduzca un valor entre 4 y 124 en incrementos de 4. + En el caso de la **DPU máxima por consulta**, introduzca un valor entre 4 y 124 en incrementos de 4. 1. Seleccione **Save**. **Configuración de los controles de DPU para una consulta mediante la AWS CLI** + Utilice el comando `start-query-execution` con el parámetro `engine-configuration`: ``` aws athena start-query-execution \ --query-string "SELECT * FROM my_table LIMIT 10" \ --work-group "my_workgroup" \ --engine-configuration '{ "Classifications": [ { "Name": "athena-query-engine-properties", "Properties": { "max-dpu-count" : "32", "min-dpu-count" : "8" } } ]}' ``` La relación entre la configuración de la DPU a nivel de consulta y a nivel de grupo de trabajo depende de la configuración del grupo de trabajo: + Cuando la opción **Anular la configuración del cliente** está habilitada, los controles de la DPU a nivel de grupo de trabajo tienen prioridad sobre cualquier configuración a nivel de consulta. Esto garantiza un uso coherente de recursos en todas las consultas del grupo de trabajo especificado. + Cuando la opción **Anular la configuración del cliente** no está habilitada, los controles de la DPU a nivel de consulta tienen prioridad sobre la configuración a nivel de grupo de trabajo. Esto ofrece flexibilidad para optimizar las consultas individuales. Si no especifica los controles de la DPU en ninguno de los niveles, Athena asigna automáticamente la capacidad en función de la complejidad de las consultas. **nota** En el caso de las consultas DDL, el valor máximo para las DPU mínimas es 4. Al configurar una cantidad mínima más alta para las consultas DPU se produce un error. ## Supervisión del uso de DPU Tras completar las consultas, puede ver su uso de DPU. Athena proporciona métricas de uso de DPU a través de la consola, operaciones de API y CloudWatch. **Visualización del consumo de DPU en la consola** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. En el panel de navegación, seleccione **Query Editor (Editor de consultas)**. 1. Una vez completada la consulta, consulte su valor de **DPU consumida** en el contenedor de resultados de la consulta. 1. Visualización del consumo de DPU en consultas anteriores: 1. Elija **Consultas recientes** en el panel de navegación. 1. Seleccione el icono de configuración para añadir la columna **DPU consumida** a la tabla si aún no se ha mostrado. 1. Revise el consumo de DPU de cada consulta completada. 1. Si lo desea, en el **editor de consultas**, seleccione la pestaña **Estadísticas de consultas** y revise la **DPU consumida**. **Recuperación del consumo de DPU mediante la API** 1. Use las siguientes operaciones de la API para recuperar el consumo de DPU mediante programación: + `GetQueryExecution`: devuelve los detalles de ejecución de una consulta específica + `BatchGetQueryExecution`: devuelve los detalles de ejecución de varias consultas 1. Ejemplo de uso de la AWS CLI: ``` aws athena get-query-execution \ --query-execution-id "123e4567-e89b-12d3-a456-426614174000" ``` La respuesta incluye el campo `DpuCount` del objeto `Statistics`: ``` { "QueryExecution": { "Statistics": { "DpuCount": 8 } } } ``` **Supervisión del uso de DPU con CloudWatch** + Athena publica métricas relacionadas con la consulta en CloudWatch que le ayudan a supervisar el uso de la capacidad y otros datos de rendimiento. Para obtener más información, consulte [Supervisión de las métricas de consultas de Athena con CloudWatch](query-metrics-viewing.md). # Ajuste de la reserva de la capacidad Puede ajustar automáticamente la capacidad de su reserva en respuesta a la utilización de la carga de trabajo mediante la solución de escalado automático de Athena. Añade capacidad automáticamente cuando la utilización supera el umbral configurado y la elimina durante los periodos de baja utilización para reducir los costos. Para personalizar su comportamiento, establezca diferentes umbrales de utilización, cantidades mínimas y máximas de DPU, incrementos de escalado y frecuencia de evaluación de la utilización. Esto elimina los ajustes manuales de capacidad y, al mismo tiempo, ayuda a equilibrar los requisitos de rendimiento con la optimización de los costos. Implemente esta solución sin servidor mediante una plantilla de CloudFormation. Crea una máquina de estado de Step Functions que supervisa las métricas de utilización y toma decisiones de escalado. Puede personalizar aún más la plantilla o la máquina de estado para satisfacer sus necesidades específicas. Para empezar, use la consola de Athena y seleccione **Configurar escalado automático** en la página de detalles de la reserva de capacidad, que le redireccionará a CloudFormation con la plantilla precargada. De forma alternativa, siga el procedimiento que se describe a continuación. ## Requisitos previos + Se requiere una reserva de capacidad activa + Permisos de IAM necesarios para implementar pilas de CloudFormation y crear recursos de Step Functions ## Lanzar la pila de CloudFormation Esta plantilla de CloudFormation automatizada implementa la solución de escalado automático de reserva de capacidad de Athena. Debe completar los pasos correspondientes en [Requisitos previos](#capacity-management-auto-scaling-prerequisites) antes de lanzar la pila. [https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?&templateURL=https:%2F%2Fathena-downloads.s3.us-east-1.amazonaws.com%2F%2Ftemplates%2F%2Fcapacity-reservation-scaling%2F%2Fstate-machine%2F%2Fathena-capacity-reservation-scaling-template-v1.1.yaml](https://console.aws.amazon.com/cloudformation/home?region=us-east-1#/stacks/new?&templateURL=https:%2F%2Fathena-downloads.s3.us-east-1.amazonaws.com%2F%2Ftemplates%2F%2Fcapacity-reservation-scaling%2F%2Fstate-machine%2F%2Fathena-capacity-reservation-scaling-template-v1.1.yaml) **Lanzamiento de la solución de escalado automático** 1. Inicie sesión en la [consola de administración de AWS](https://console.aws.amazon.com/) y seleccione el botón para lanzar la plantilla `AWSAccelerator-InstallerStack` de CloudFormation. 1. La plantilla se lanza en el Este de EE. UU. (Norte de Virginia) de forma predeterminada. Para activar la solución en una Región de AWS diferente, utilice el selector de regiones de la barra de navegación de la consola. 1. En la página **Crear pila**, verifique que la dirección URL de la plantilla se encuentre en el cuadro de texto **URL de Amazon S3** y elija **Siguiente**. 1. En la página **Especificar los detalles de la pila**, especifique un nombre para la pila. 1. En **Parámetros**, revise los parámetros de esta plantilla de solución y modifíquelos según sea necesario. Esta solución utiliza los siguientes valores predeterminados. **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/capacity-management-automatically-adjust-capacity.html) **nota** Todos los valores de la DPU deben ser múltiplos de 4 para cumplir con los requisitos de reserva de capacidad de Athena. 1. Elija **Siguiente**. 1. En la página **Configurar opciones de pila**, elija **Siguiente**. 1. En la página **Revisar y crear**, revise y confirme la configuración. Seleccione la casilla para aceptar que la plantilla puede crear recursos de IAM. 1. Elija **Crear** para implementar la pila. Puede ver el estado de la pila en la consola de CloudFormation en la columna **Estado**. Debería recibir el estado `CREATE_COMPLETE` en unos minutos. # Administración de reservas Puede ver y administrar sus reservas de capacidad en la página **Reservas de capacidad**. Puede realizar tareas de administración, como agregar o reducir las DPU, modificar las asignaciones de los grupos de trabajo y etiquetar o cancelar las reservas. **Para ver y administrar reservas de capacidad** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si el panel de navegación de la consola no está visible, elija el menú de expansión de la izquierda. 1. Elija **Administración**, **Reservas de capacidad**. 1. En la página de reservas de capacidad, puede realizar las siguientes tareas: + Para crear una reserva de capacidad, seleccione **Crear reserva de capacidad**. + Utilice el cuadro de búsqueda para filtrar las reservas por nombre o cantidad de DPU. + Seleccione el menú desplegable de estado para filtrar por estado de reserva de capacidad (por ejemplo, **Activa** o **Cancelada**). Para obtener más información acerca del estado de las reservas, consulte [Información sobre el estado de las reservas](#capacity-management-understanding-reservation-status). + Para ver los detalles de una reserva de capacidad, seleccione el enlace de la reserva. La página de detalles de la reserva incluye opciones para [editar la capacidad](capacity-management-editing-capacity-reservations.md), [añadir grupos de trabajo](capacity-management-adding-workgroups-to-a-reservation.md), [eliminar grupos de trabajo](capacity-management-removing-a-workgroup-from-a-reservation.md) y [cancelar](capacity-management-cancelling-a-capacity-reservation.md) la reserva. + Para editar una reserva (por ejemplo, mediante la adición o eliminación de DPU), seleccione el botón de la reserva y, a continuación, seleccione **Editar**. + Para cancelar una reserva, seleccione el botón de la reserva y, a continuación, seleccione **Cancelar**. ## Información sobre el estado de las reservas En la siguiente tabla, se describen los valores de estado que una reserva de capacidad puede tener. **** | Estado | Descripción | | --- | --- | | Pending (Pendiente | Athena está procesando su solicitud de capacidad. La capacidad no está lista para ejecutar consultas. | | Activo | Hay capacidad disponible para ejecutar consultas. | | Con error | Su solicitud de capacidad no se completó correctamente. Tenga en cuenta que no se garantiza el cumplimiento de las solicitudes de capacidad. Las reservas fallidas se tienen en cuenta para los límites de DPU de su cuenta. Para liberar el uso, debe cancelar la reserva. | | Actualización pendiente | Athena está procesando un cambio en la reserva. Por ejemplo, este estado se produce después de editar la reserva a fin de agregar o eliminar DPU. | | Cancelling | Athena está procesando una solicitud para cancelar la reserva. Las consultas que aún se estén ejecutando en los grupos de trabajo que utilizaban la reserva se pueden finalizar, pero las demás consultas del grupo de trabajo utilizarán la capacidad bajo demanda (no aprovisionada). | | Cancelado | La cancelación de la reserva de capacidad se completó. Las reservas canceladas permanecen en la consola durante 45 días. Después de 45 días, Athena eliminará la reserva. Durante los 45 días, no podrá readaptar ni reutilizar la reserva, pero podrá consultar las etiquetas y ver los detalles como referencia histórica. No se garantiza que la capacidad cancelada se pueda volver a reservar en una fecha futura. La capacidad no se puede transferir a otra reserva, Cuenta de AWS o Región de AWS. | ## Descripción de las DPU activas y DPU objetivo En la lista de reservas de capacidad de la consola de Athena, su reserva muestra dos valores de DPU: **DPU activa** y **DPU objetivo**. + **DPU activa**: la cantidad de DPU disponibles en su reserva para ejecutar consultas. Por ejemplo, si solicita 100 DPU y se completa su solicitud, la **DPU activa** muestra **100**. + **DPU objetivo**: la cantidad de DPU a las que se está trasladando su reserva. La **DPU objetivo** muestra un valor diferente al de la **DPU activa** cuando se crea una reserva o cuando está pendiente un aumento o una disminución de la cantidad de DPU. Por ejemplo, después de enviar una solicitud para crear una reserva con 24 DPU, el **estado** de la reserva será **Pendiente**, la **DPU activa** será **0** y la **DPU objetivo** será **24**. Si tiene una reserva con 100 DPU y la edita para solicitar un aumento de 20 DPU, el **estado** será **Actualización pendiente**, la **DPU activa** será **100** y la **DPU objetivo** será **120**. Si tiene una reserva con 100 DPU y la edita para solicitar una reducción de 20 DPU, el **estado** será **Actualización pendiente**, la **DPU activa** será **100** y la **DPU objetivo** será **80**. Durante estas transiciones, Athena trabaja activamente para adquirir o reducir la cantidad de DPU en función de su solicitud. Cuando la **DPU activa** se iguala a la **DPU objetivo**, se ha alcanzado el número objetivo y no hay cambios pendientes. Para recuperar estos valores mediante programación, puede llamar a la acción de la API [GetCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityReservation.html). La API hace referencia a la **DPU activa** y la **DPU objetivo** como `AllocatedDpus` y `TargetDpus`. **Topics** + [Información sobre el estado de las reservas](#capacity-management-understanding-reservation-status) + [Descripción de las DPU activas y DPU objetivo](#capacity-management-understanding-dpu-status) + [Edición de reservas de capacidad](capacity-management-editing-capacity-reservations.md) + [Introducción de grupos de trabajo a una reserva](capacity-management-adding-workgroups-to-a-reservation.md) + [Eliminación de un grupo de trabajo de una reserva](capacity-management-removing-a-workgroup-from-a-reservation.md) + [Cancelación de una reserva de capacidad](capacity-management-cancelling-a-capacity-reservation.md) + [Eliminación de una reserva de capacidad](capacity-management-deleting-a-capacity-reservation.md) # Edición de reservas de capacidad Tras crear una reserva de capacidad, puede ajustar la cantidad de DPU y agregar o eliminar sus etiquetas personalizadas. **Para editar una reserva de capacidad** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si el panel de navegación de la consola no está visible, elija el menú de expansión de la izquierda. 1. Elija **Administración**, **Reservas de capacidad**. 1. En la lista de reservas de capacidad, realice una de las siguientes acciones: + Seleccione el botón situado junto a la reserva y, a continuación, elija **Editar**. + Elija el enlace a la reserva y, a continuación, elija **Editar**. 1. Para **DPU**, elija o introduzca la cantidad de unidades de procesamiento de datos que desee. Para obtener más información, consulte [Descripción de las DPU](capacity-management.md#capacity-management-understanding-dpus). **nota** Puede solicitar que se agreguen DPU a una reserva de capacidad activa en cualquier momento. Puede solicitar la reducción de las DPU de una reserva de capacidad activa cuando haya transcurrido 1 minuto desde la última vez que la reserva se activó o se agregaron DPU. Cuando solicita reducir las DPU, Athena prioriza la eliminación de las DPU inactivas en lugar de aquellas activas. Si las consultas consumen DPU que están marcadas para su eliminación, Athena espera a que se completen las consultas antes de eliminar las DPU. 1. (Opcional) En **Etiquetas**, seleccione **Eliminar** para eliminar una etiqueta o **Agregar nueva etiqueta** para agregar una nueva etiqueta. 1. Elija **Enviar**. La página de detalles de la reserva muestra la configuración actualizada. # Introducción de grupos de trabajo a una reserva Tras crear una reserva de capacidad, puede agregar hasta 20 grupos de trabajo a la reserva. Al agregar un grupo de trabajo a una reserva, Athena indica qué consultas debe ejecutar en la capacidad reservada. Las consultas de los grupos de trabajo que no están asociados a una reserva siguen ejecutándose según el modelo de precios predeterminado por terabyte (TB) analizado. Cuando una reserva tiene dos o más grupos de trabajo, las consultas de esos grupos de trabajo pueden utilizar la capacidad de la reserva. Puede agregar y eliminar grupos de trabajo en cualquier momento. Al agregar o eliminar grupos de trabajo, las consultas que se están ejecutando no se interrumpen. Cuando la reserva esté en estado pendiente, las consultas de los grupos de trabajo que haya agregado seguirán ejecutándose según el modelo de precios predeterminado por terabyte (TB) analizado hasta que la reserva se active. **Para agregar uno o más grupos de trabajo a la reserva de capacidad** 1. En la página de detalles de la reserva de capacidad, seleccione **Agregar grupos de trabajo**. 1. En la página **Agregar grupos de trabajo**, seleccione los grupos de trabajo que desee agregar y, a continuación, elija **Agregar grupos de trabajo**. No puede asignar un grupo de trabajo a más de una reserva. La página de detalles de la reserva de capacidad muestra los grupos de trabajo que ha agregado. Las consultas que se ejecuten en esos grupos de trabajo utilizarán la capacidad que haya reservado cuando la reserva esté activa. # Eliminación de un grupo de trabajo de una reserva Si ya no necesita capacidad dedicada para un grupo de trabajo o desea mover un grupo de trabajo a su propia reserva, puede eliminarla en cualquier momento. Eliminar un grupo de trabajo de una reserva es un proceso sencillo. Tras eliminar un grupo de trabajo de una reserva, las consultas del grupo de trabajo eliminado vuelven a utilizar la capacidad bajo demanda y se facturan en función de los terabytes (TB) analizados. **Para eliminar uno o más grupos de trabajo de una reserva** 1. En la página de detalles de la reserva de capacidad, seleccione los grupos de trabajo que desee eliminar. 1. Seleccione **Eliminar grupos de trabajo**. El mensaje **¿Desea eliminar los grupos de trabajo?** le informa que todas las consultas actualmente activas finalizarán antes de eliminar el grupo de trabajo de la reserva. 1. Elija **Eliminar**. La página de detalles de la reserva de capacidad muestra que los grupos de trabajo eliminados ya no están presentes. # Cancelación de una reserva de capacidad Si ya no quiere usar una reserva de capacidad, puede cancelarla. Las consultas que aún se estén ejecutando en los grupos de trabajo que utilizaban la reserva se podrán finalizar, pero las demás consultas del grupo de trabajo ya no utilizarán la reserva. **nota** No se garantiza que la capacidad cancelada se pueda volver a reservar en una fecha futura. La capacidad no se puede transferir a otra reserva, Cuenta de AWS o Región de AWS. **Para cancelar una reserva de capacidad** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si el panel de navegación de la consola no está visible, elija el menú de expansión de la izquierda. 1. Elija **Administración**, **Reservas de capacidad**. 1. En la lista de reservas de capacidad, realice una de las siguientes acciones: + Seleccione el botón situado junto a la reserva y, a continuación, elija **Cancelar**. + Elija el enlace a la reserva y, a continuación, elija **Cancelar reserva de capacidad**. 1. En el mensaje **¿Desea cancelar la reserva de capacidad?**, introduzca **cancelar** y, a continuación, seleccione **Cancelar reserva de capacidad**. El estado de la reserva cambia a **Cancelando** y un cartel de progreso le informa que la cancelación está en curso. Cuando se complete la cancelación, la reserva de capacidad se mantendrá, pero su estado aparecerá como **Cancelada**. La reserva se eliminará 45 días después de la cancelación. Durante los 45 días, no podrá readaptar ni reutilizar una reserva que se ha cancelado, pero podrá consultar las etiquetas y ver los detalles como referencia histórica. # Eliminación de una reserva de capacidad Si desea eliminar todas las referencias a una reserva de capacidad cancelada, puede eliminar la reserva. Se debe cancelar una reserva antes de que esta pueda eliminarse. Una reserva eliminada se elimina inmediatamente de su cuenta y ya no se puede invocar, ni siquiera mediante su ARN. **Para eliminar una reserva de capacidad** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si el panel de navegación de la consola no está visible, elija el menú de expansión de la izquierda. 1. Elija **Administración**, **Reservas de capacidad**. 1. En la lista de reservas de capacidad, realice una de las siguientes acciones: + Seleccione el botón situado junto a la reserva cancelada y, a continuación, elija **Acciones**, **Eliminar**. + Elija el enlace a la reserva y, a continuación, elija **Eliminar**. 1. En el mensaje **¿Desea eliminar la reserva de capacidad?**, seleccione **Eliminar**. Aparecerá un mensaje en el que se le informa que la reserva de capacidad se ha eliminado correctamente. La reserva eliminada ya no aparecerá en la lista de reservas de capacidad. # Políticas de IAM para reservas de capacidad Para controlar el acceso a las reservas de capacidad, utilice permisos de IAM de nivel de recursos o políticas de IAM basadas en identidad. Siempre que utilice políticas de IAM, compruebe que sigue las mejores prácticas IAM. Para obtener más información, consulte la sección [Prácticas recomendadas de seguridad de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía del usuario de IAM*. El siguiente procedimiento es específico de Athena. Para obtener información específica sobre IAM, consulte los enlaces que se enumeran al final de esta sección. Para obtener información sobre las políticas de reservas de capacidad JSON de ejemplo, consulte [Ejemplo de políticas de reserva de capacidad](example-policies-capacity-reservations.md). **Para utilizar el editor visual en la consola de IAM para crear una política de reserva de capacidad** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de IAM en [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/). 1. En el panel de navegación de la izquierda, elija **Políticas** y, a continuación, elija **Crear política**. 1. En la pestaña **Editor visual**, elija **Elegir un servicio**. A continuación, elija un servicio de Athena para agregar a la política. 1. Elija **Seleccionar acciones** y, a continuación, elija las acciones que desea añadir a la política. El editor visual muestra las acciones disponibles en Athena. Para obtener más información, consulte [Acciones, recursos y claves de condición de Amazon Athena](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html) en la *Referencia de autorizaciones de servicio*. 1. Elija **agregar acciones** para escribir una acción específica o utilice caracteres comodín (\$1) para especificar varias acciones. De forma predeterminada, la política que está creando permite las acciones que usted elija. Si eligió una o más acciones que admiten permisos en el nivel de recursos para el recurso `capacity-reservation` en Athena, el editor visual enumera el recurso `capacity-reservation`. 1. Elija **Recursos** a fin de detallar las reservas de capacidad específicas para su política. Para obtener ejemplos de políticas de reservas de capacidad JSON, consulte [Ejemplo de políticas de reserva de capacidad](example-policies-capacity-reservations.md). 1. Especifique el recurso `capacity-reservation` como se indica a continuación: ``` arn:aws:athena:::capacity-reservation/ ``` 1. Elija **Revisar la política** y, a continuación, escriba un **Nombre** y una **Descripción** (opcional) para la política que está creando. Revise el resumen de la política para asegurarse de que ha concedido los permisos deseados. 1. Elija **Crear política** para guardar la nueva política. 1. Adjunte esta política basada en identidad a un usuario, grupo o rol. Para obtener más información, consulte los siguientes temas en la *Referencia de autorizaciones de servicio* y la *Guía del usuario de IAM*: + [Acciones, recursos y claves de condición de Amazon Athena](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonathena.html) + [Creación de políticas con el editor visual](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-visual-editor) + [Adición y eliminación de políticas de IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html) + [Control del acceso a los recursos](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_controlling.html#access_controlling-resources) Para obtener ejemplos de políticas de reservas de capacidad JSON, consulte [Ejemplo de políticas de reserva de capacidad](example-policies-capacity-reservations.md). Para obtener una lista completa de las acciones de Amazon Athena, consulte los nombres de acciones de la API en la [Referencia de API de Amazon Athena](https://docs.aws.amazon.com/athena/latest/APIReference/). # Ejemplo de políticas de reserva de capacidad En esta sección se incluyen ejemplos de políticas que puede utilizar para habilitar varias acciones en las reservas de capacidad. Siempre que utilice políticas de IAM, compruebe que sigue las mejores prácticas IAM. Para más información, consulte [Prácticas recomendadas de seguridad en IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) en la *Guía del usuario de IAM*. Una reserva de capacidad es un recurso de IAM administrado por Athena. Por lo tanto, si la política de reserva de capacidad utiliza acciones que toman `capacity-reservation` como entrada, debe especificar el ARN de la reserva de capacidad de la siguiente manera: ``` "Resource": [arn:aws:athena:::capacity-reservation/] ``` `` es el nombre de su reserva de capacidad. Por ejemplo, para una reserva de capacidad denominada `test_capacity_reservation`, especifíquela como un recurso de la siguiente manera: ``` "Resource": ["arn:aws:athena:us-east-1:123456789012:capacity-reservation/test_capacity_reservation"] ``` Para obtener una lista completa de las acciones de Amazon Athena, consulte los nombres de acciones de la API en la [Referencia de API de Amazon Athena](https://docs.aws.amazon.com/athena/latest/APIReference/). Para obtener más información sobre las políticas de IAM, consulte [Creación de políticas con el editor visual](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-visual-editor) en la *Guía del usuario de IAM*. **Example Ejemplo de política para enumerar las reservas de capacidad** La siguiente política permite a todos los usuarios enumerar todas las reservas de capacidad. **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListCapacityReservations" ], "Resource": "*" } ] } ``` **Example Ejemplo de política para operaciones de administración** La siguiente política permite a un usuario crear, cancelar, obtener detalles y actualizar la reserva de capacidad `test_capacity_reservation`. La política también permite a un usuario asignar `workgroupA` y `workgroupB` a `test_capacity_reservation`. **** ``` { "Version":"2012-10-17", "Statement":[ { "Effect": "Allow", "Action": [ "athena:CreateCapacityReservation", "athena:GetCapacityReservation", "athena:CancelCapacityReservation", "athena:UpdateCapacityReservation", "athena:GetCapacityAssignmentConfiguration", "athena:PutCapacityAssignmentConfiguration" ], "Resource": [ "arn:aws:athena:us-east-1:123456789012:capacity-reservation/test_capacity_reservation", "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA", "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupB" ] } ] } ``` # API de reserva de capacidad de Athena La siguiente lista contiene enlaces de referencia a las acciones de la API de reserva de capacidad. Para ver las estructuras de datos y otras acciones de la API de Athena, consulte [https://docs.aws.amazon.com/athena/latest/APIReference/](https://docs.aws.amazon.com/athena/latest/APIReference/). + [CancelCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_CancelCapacityReservation.html) + [CreateCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_CreateCapacityReservation.html) + [DeleteCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_DeleteCapacityReservation.html) + [GetCapacityAssignmentConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityAssignmentConfiguration.html) + [GetCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_GetCapacityReservation.html) + [ListCapacityReservations](https://docs.aws.amazon.com/athena/latest/APIReference/API_ListCapacityReservations.html) + [PutCapacityAssignmentConfiguration](https://docs.aws.amazon.com/athena/latest/APIReference/API_PutCapacityAssignmentConfiguration.html) + [UpdateCapacityReservation](https://docs.aws.amazon.com/athena/latest/APIReference/API_UpdateCapacityReservation.html) # Optimización del rendimiento de Athena En este tema se proporciona información general y sugerencias específicas para mejorar el rendimiento de las consultas de Athena y para solucionar los errores relacionados con los límites y el uso de recursos. En términos generales, las optimizaciones se pueden agrupar en categorías de servicio, consulta y estructura de datos. Las decisiones que se toman por cada servicio, sobre cómo se escriben las consultas y cómo se estructuran los datos y las tablas pueden influir en el rendimiento. **Topics** + [Optimización del uso de servicio](performance-tuning-service-level-considerations.md) + [Optimización de consultas](performance-tuning-query-optimization-techniques.md) + [Optimización de datos](performance-tuning-data-optimization-techniques.md) + [Uso de formatos de almacenamiento en columnas](columnar-storage.md) + [Uso de particiones y asignación de buckets](ctas-partitioning-and-bucketing.md) + [Partición de datos](partitions.md) + [Uso de proyección de particiones con Amazon Athena](partition-projection.md) + [Evitar la limitación de Amazon S3](performance-tuning-s3-throttling.md) + [Recursos adicionales de](performance-tuning-additional-resources.md) # Optimización del uso de servicio Entre las consideraciones por servicio se incluyen la cantidad de cargas de trabajo que se ejecutan por cuenta, las cuotas de servicio no solo para Athena, sino también para todos los servicios, y pensar en cómo reducir los errores de “falta de recursos”. **Topics** + [Cómo operar cargas de trabajo múltiples dentro de la misma cuenta](#performance-tuning-service-quotas) + [Reducción de los errores de “falta de recursos”](#performance-tuning-resource-limits) ## Cómo operar cargas de trabajo múltiples dentro de la misma cuenta Athena utiliza cuotas para limitar la simultaneidad de consultas y las tasas de solicitudes de API a nivel de cuenta. Superar estas cuotas puede provocar que se produzcan errores en las consultas durante su ejecución o en el momento de su envío. Para obtener más información acerca de estas cuotas, consulte [Service Quotas](service-limits.md). Si opera varias cargas de trabajo dentro de la misma cuenta de AWS, estas competirán por la misma cuota a nivel de cuenta. Por ejemplo, si una carga de trabajo sufre una ráfaga inesperada de consultas, es posible que otra carga de trabajo que se ejecute en la misma cuenta tenga un tiempo de espera elevado o, en el peor de los casos, que se produzcan errores en el envío de las consultas debido a la limitación. Recomendamos utilizar CloudWatch para supervisar el uso del servicio mediante gráficos y paneles. También puede configurar alarmas de CloudWatch que avisen cuando su uso se acerque a la cuota del servicio para consultas simultáneas, con lo cual podrá tomar medidas antes de alcanzar los límites de la cuota. Para obtener más información, consulte [Supervisión de las métricas de uso de Athena con CloudWatch](monitoring-athena-usage-metrics.md). Para controlar la simultaneidad de las consultas y aislar las cargas de trabajo dentro de la cuenta, utilice las reservas de capacidad. Las reservas de capacidad proporcionan capacidad dedicada para el procesamiento de consultas dentro de una sola cuenta. La capacidad se mide en unidades de procesamiento de datos (DPU) y se puede agregar o eliminar para aumentar o disminuir la simultaneidad de las consultas, respectivamente. Las reservas de capacidad permiten aislar las cargas de trabajo entre sí dentro de la cuenta. Esto se consigue al asignar capacidad a uno o más grupos de trabajo. Para obtener más información, consulte [Administración de la capacidad de procesamiento de consultas](capacity-management.md). Aunque debería separar las cargas de trabajo no relacionadas en diferentes cuentas de AWS (como aislar el desarrollo de los entornos de producción), este enfoque no ofrece una forma escalable de aumentar la simultaneidad de las consultas. En su lugar, utilice las reservas de capacidad para administrar y escalar las necesidades de procesamiento de consultas dentro de una sola cuenta. ### Consideración de las cuotas en otros servicios Cuando Athena ejecuta una consulta, puede llamar a otros servicios que imponen cuotas. Durante la ejecución de la consulta, Athena puede realizar llamadas a la API de AWS Glue Data Catalog, Amazon S3 y otros servicios de AWS, como IAM y AWS KMS. Si se utilizan [consultas federadas](federated-queries.md), Athena también llama a AWS Lambda. Todos estos servicios tienen sus propios límites y cuotas que pueden superarse. Cuando la ejecución de una consulta detecta errores de estos servicios, se produce un error e incluye el error del servicio de origen. Los errores recuperables se vuelven a intentar, pero las consultas pueden seguir fallando si el problema no se resuelve a tiempo. Asegúrese de leer detenidamente los mensajes de error para determinar si provienen de Athena o de otro servicio. En esta sección de ajuste del rendimiento se describen algunos de los errores más pertinentes. Para obtener más información sobre cómo solucionar los errores relacionados con las cuotas de servicio de Amazon S3, consulte [Cómo evitar tener demasiados archivos](performance-tuning-data-optimization-techniques.md#performance-tuning-avoid-having-too-many-files) más adelante en este documento. Para obtener más información sobre la optimización del rendimiento de Amazon S3, consulte [Prácticas recomendadas para patrones de diseño: optimizar el rendimiento de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) en la *Guía del usuario de Amazon S3*. ## Reducción de los errores de “falta de recursos” Athena ejecuta las consultas en un motor de consultas distribuido. Al enviar una consulta, el planificador de consultas del motor de Athena calcula la capacidad de procesamiento necesaria para ejecutar la consulta y prepara un clúster de nodos de computación en consecuencia. Algunas consultas, como las consultas DDL, se ejecutan en un solo nodo. Las consultas complejas sobre conjuntos de datos de gran tamaño se ejecutan en clústeres mucho más grandes. Los nodos son uniformes y tienen las mismas configuraciones de disco, CPU y memoria. Athena escala horizontalmente, no verticalmente, para procesar consultas más exigentes. A veces, las demandas de una consulta superan los recursos disponibles para el clúster que ejecuta la consulta. Cuando esto ocurre, la consulta genera el error La consulta agotó los recursos con este factor de escala. El recurso que se agota con más frecuencia es la memoria, pero en raras ocasiones también puede ser el espacio en disco. Los errores de memoria suelen producirse cuando el motor ejecuta una función de unión o ventana, pero también pueden producirse en distintos recuentos y agregaciones. Aunque una consulta falle una vez y muestre el error de “falta de recursos”, es posible que se ejecute correctamente cuando se vuelva a ejecutar. La ejecución de la consulta no es determinista. Factores como el tiempo que se tarda en cargar los datos y la forma en que se distribuyen los conjuntos de datos intermedios en los nodos pueden provocar un uso diferente de los recursos. Imagine una consulta que une dos tablas y presenta un gran sesgo en la distribución de los valores de la condición de unión. Una consulta de este tipo puede funcionar correctamente la mayoría de las veces, pero en ocasiones falla cuando los valores más comunes terminan siendo procesados por el mismo nodo. Para evitar que las consultas superen los recursos disponibles, utilice los consejos de ajuste de rendimiento que se mencionan en este documento. Para obtener consejos sobre cómo optimizar las consultas que agotan los recursos disponibles, consulte [Optimización de combinaciones](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-joins), [Reduzca el alcance de las funciones de la ventana o quítelas](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-window-functions) y [Optimización de las consultas mediante aproximaciones](performance-tuning-query-optimization-techniques.md#performance-tuning-optimizing-queries-by-using-approximations). # Optimización de consultas Utilice las técnicas de optimización de consultas que se describen en esta sección para hacer que las consultas se ejecuten más rápido o como soluciones para las consultas que superan los límites de recursos en Athena. ## Optimización de combinaciones Existen muchas estrategias diferentes para ejecutar uniones en un motor de consultas distribuido. Dos de las más comunes son las uniones hash distribuidas y las consultas con condiciones de unión complejas. ### En una combinación hash distribuida, coloque las tablas grandes a la izquierda y las pequeñas a la derecha El tipo de unión más común utiliza una comparación de igualdad como condición de unión. Athena ejecuta este tipo de unión como una unión hash distribuida. En una unión hash distribuida, el motor crea una tabla de consulta (tabla hash) a partir de uno de los lados de la unión. Este lado se denomina *lado de compilación*. Los registros del lado de compilación se distribuyen entre los nodos. Cada nodo crea una tabla de búsqueda para su subconjunto. El otro lado de la unión, denominado *lado de sondeo*, se transmite a través de los nodos. Los registros del lado de sondeo se distribuyen entre los nodos de la misma manera que en el lado de compilación. Esto permite que cada nodo realice la unión buscando los registros coincidentes en su propia tabla de búsqueda. Cuando las tablas de búsqueda creadas a partir del lado de compilación de la unión no caben en la memoria, las consultas pueden fallar. Aun si el tamaño total del lado de compilación es inferior a la memoria disponible, las consultas pueden fallar si la distribución de los registros presenta un sesgo significativo. En un caso extremo, todos los registros podrían tener el mismo valor para la condición de unión y tener que caber en la memoria de un único nodo. Incluso una consulta con menos asimetría puede fallar si se envía un conjunto de valores al mismo nodo y los valores suman más que la memoria disponible. Los nodos tienen la capacidad de almacenar registros en el disco, pero esto ralentiza la ejecución de la consulta y puede que no sea suficiente para evitar que la consulta falle. Athena intenta reordenar las uniones para usar la relación más grande como el lado de sondeo y la relación más pequeña como el lado de compilación. Sin embargo, como Athena no gestiona los datos de las tablas, tiene información limitada y, a menudo, debe suponer que la primera tabla es la más grande y la segunda es la más pequeña. Al escribir uniones con condiciones de unión basadas en la igualdad, suponga que la tabla situada a la izquierda de la palabra clave `JOIN` corresponde al lado de sondeo y la tabla a la derecha corresponde al lado de compilación. Asegúrese de que la tabla correcta, la del lado de compilación, sea la más pequeña de las tablas. Si no es posible hacer que el lado de compilación de la unión sea lo suficientemente pequeño como para caber en la memoria, considere la posibilidad de ejecutar varias consultas que unan subconjuntos de la tabla de compilación. ### Utilice EXPLAIN para analizar consultas con combinaciones complejas Las consultas con condiciones de unión complejas (por ejemplo, las consultas que utilizan `LIKE`, `>` u otros operadores) suelen ser exigentes desde el punto de vista computacional. En el peor de los casos, todos los registros de un lado de la unión deben compararse con todos los registros del otro lado de la unión. Como el tiempo de ejecución aumenta con el cuadrado del número de registros, estas consultas corren el riesgo de superar el tiempo máximo de ejecución. Para saber de antemano cómo Athena ejecutará su consulta, puede usar la instrucción `EXPLAIN`. Para obtener más información, consulte [Uso de EXPLAIN y EXPLAIN ANALYZE en Athena](athena-explain-statement.md) y [Descripción de los resultados de la instrucción EXPLAIN de Athena](athena-explain-statement-understanding.md). ## Reduzca el alcance de las funciones de la ventana o quítelas Como las funciones de ventana son operaciones que consumen muchos recursos, pueden hacer que las consultas se ejecuten con lentitud o incluso que se produzcan errores con el mensaje La consulta agotó los recursos con este factor de escala. Las funciones de ventana guardan en la memoria todos los registros en los que operan para calcular su resultado. Cuando la ventana es muy grande, la función de ventana puede quedarse sin memoria. Para asegurarse de que las consultas se ejecuten dentro de los límites de memoria disponibles, reduzca el tamaño de las ventanas sobre las que trabajan las funciones de ventana. Para ello, puede agregar una cláusula `PARTITIONED BY` o reducir el alcance de las cláusulas de partición existentes. ### Uso de funciones que no sean de ventana A veces, las consultas con funciones de ventana se pueden reescribir sin funciones de ventana. Por ejemplo, en lugar de utilizar `row_number` para buscar los registros de `N` principales, puede utilizar `ORDER BY` y `LIMIT`. En lugar de usar `row_number` o `rank` para desduplicar registros, puede usar funciones de agregado como [max\$1by](https://trino.io/docs/current/functions/aggregate.html#max_by), [min\$1by](https://trino.io/docs/current/functions/aggregate.html#min_by) y [arbitrary](https://trino.io/docs/current/functions/aggregate.html#arbitrary). Por ejemplo, supongamos que tiene un conjunto de datos con actualizaciones de un sensor. El sensor informa periódicamente el estado de la batería e incluye algunos metadatos, como la ubicación. Si desea saber el último estado de la batería de cada sensor y su ubicación, puede usar la siguiente consulta: ``` SELECT sensor_id, arbitrary(location) AS location, max_by(battery_status, updated_at) AS battery_status FROM sensor_readings GROUP BY sensor_id ``` Los metadatos, como la ubicación, son los mismos para todos los registros, por lo que puede utilizar la función `arbitrary` a fin de seleccionar cualquier valor del grupo. Para obtener el último estado de la batería, puede usar la función `max_by`. La función `max_by` selecciona el valor de una columna del registro en el que se encontró el valor máximo de otra columna. En este caso, devuelve el estado de la batería del registro con la hora de la última actualización del grupo. Esta consulta se ejecuta más rápido y utiliza menos memoria que una consulta equivalente con una función de ventana. ## Optimización de las agregaciones Cuando Athena realiza una agregación, distribuye los registros entre los nodos de trabajo mediante las columnas de la cláusula `GROUP BY`. Para que la tarea de hacer coincidir los registros con los grupos sea lo más eficiente posible, los nodos intentan mantener los registros en la memoria, pero los transfieren al disco si es necesario. También es una buena idea evitar incluir columnas redundantes en las cláusulas `GROUP BY`. Dado que un menor número de columnas requiere menos memoria, resulta más eficaz una consulta que describa un grupo con menos columnas. Las columnas numéricas también utilizan menos memoria que las cadenas. Por ejemplo, al agregar un conjunto de datos que tiene un ID de categoría numérico y un nombre de categoría, utilice únicamente la columna de ID de categoría en la cláusula `GROUP BY`. A veces, las consultas incluyen columnas en la cláusula `GROUP BY` para evitar el hecho de que una columna sea parte de la cláusula `GROUP BY` o una expresión agregada. Si no se sigue esta regla, puede producirse un error con el siguiente mensaje: EXPRESSION\$1NOT\$1AGGREGATE: line 1:8: 'category' must be an aggregate expression or appear in GROUP BY clause (EXPRESSION\$1NOT\$1AGGREGATE: línea 1:8: “categoría” debe ser una expresión agregada o aparecer en la cláusula GROUP BY). Para evitar tener que agregar columnas redundantes a la cláusula `GROUP BY`, puede utilizar la función [arbitrary](https://trino.io/docs/current/functions/aggregate.html#arbitrary), como en el siguiente ejemplo. ``` SELECT country_id, arbitrary(country_name) AS country_name, COUNT(*) AS city_count FROM world_cities GROUP BY country_id ``` La función `ARBITRARY` devuelve un valor arbitrario del grupo. La función resulta útil cuando se sabe que todos los registros del grupo tienen el mismo valor para una columna, pero el valor no identifica al grupo. ## Optimización de las N consultas principales La cláusula `ORDER BY` devuelve los resultados de una consulta ordenados. Athena usa la clasificación distribuida para ejecutar la operación de clasificación en paralelo en varios nodos. Si no necesita estrictamente ordenar el resultado, evite agregar una cláusula `ORDER BY`. Además, evite agregar `ORDER BY` a las consultas internas si no son estrictamente necesarias. En muchos casos, el planificador de consultas puede eliminar la ordenación redundante, pero esto no está garantizado. Una excepción a esta regla es si una consulta interna está realizando una operación `N` principal, como buscar los valores `N` más recientes o los `N` más comunes. Cuando Athena ve `ORDER BY` junto con `LIMIT`, entiende que se está ejecutando una consulta `N` principal y utiliza operaciones dedicadas en consecuencia. **nota** Aunque Athena también suele detectar funciones de ventana como `row_number` que usan `N` principales, recomendamos la versión más sencilla que usa `ORDER BY` y `LIMIT`. Para obtener más información, consulte [Reduzca el alcance de las funciones de la ventana o quítelas](#performance-tuning-optimizing-window-functions). ## Inclusión de las columnas necesarias únicamente Si no necesita estrictamente una columna, no la incluya en la consulta. Cuantos menos datos tenga que procesar una consulta, más rápido se ejecutará. Esto reduce tanto la cantidad de memoria necesaria como la cantidad de datos que deben enviarse entre los nodos. Si utiliza un formato de archivo en columnas, al reducir el número de columnas también se reduce la cantidad de datos que se leen desde Amazon S3. Athena no tiene un límite específico para el número de columnas de un resultado, pero la forma en que se ejecutan las consultas limita el tamaño combinado de las columnas posible. El tamaño combinado de las columnas incluye los nombres y tipos. Por ejemplo, el siguiente error se debe a una relación que supera el límite de tamaño de un descriptor de relación: GENERIC\$1INTERNAL\$1ERROR: io.airlift.bytecode.CompilationException Para solucionar este problema, reduzca el número de columnas de la consulta o cree subconsultas y utilice una cláusula `JOIN` que recupere una cantidad menor de datos. Si tiene consultas que aplican `SELECT *` en la consulta más externa, debe cambiar `*` a una lista de solo las columnas que necesita. ## Optimización de las consultas mediante aproximaciones Athena admite [funciones agregadas de aproximación](https://trino.io/docs/current/functions/aggregate.html#appro) para contar valores distintos, los valores más frecuentes, los percentiles (incluidas las medianas aproximadas) y crear histogramas. Utilice estas funciones siempre que no necesite valores exactos. A diferencia de las operaciones `COUNT(DISTINCT col)`, [approx\$1distinct](https://trino.io/docs/current/functions/aggregate.html#approx_distinct) utiliza mucha menos memoria y se ejecuta más rápido. Del mismo modo, si se utiliza [numeric\$1histogram](https://trino.io/docs/current/functions/aggregate.html#numeric_histogram) en lugar de [histogram](https://trino.io/docs/current/functions/aggregate.html#histogram), se utilizan métodos aproximados y, por lo tanto, se utiliza menos memoria. ## Optimización de LIKE Puede usar `LIKE` para encontrar cadenas coincidentes, pero con cadenas largas, esto requiere un uso intensivo de cómputos. La función [regexp\$1like](https://trino.io/docs/current/functions/regexp.html#regexp_like) es, en la mayoría de los casos, una alternativa más rápida que proporciona más flexibilidad. A menudo, puede optimizar una búsqueda anclando la subcadena que está buscando. Por ejemplo, si busca un prefijo, es mucho mejor usar “*substr*%” en lugar de “%*substr*%”. O bien, si está usando `regexp_like`, “^*substr*”. ## Uso de UNION ALL en lugar de UNION `UNION ALL` y `UNION` son dos formas de combinar los resultados de dos consultas en un solo resultado. `UNION ALL` concatena los registros de la primera consulta con la segunda y `UNION` hace lo mismo, pero también elimina los duplicados. `UNION` necesita procesar todos los registros y encontrar los duplicados, lo que requiere mucha memoria y procesamiento, pero `UNION ALL` es una operación relativamente rápida. A menos que necesite desduplicar registros, use `UNION ALL` para obtener el mejor rendimiento. ## Uso de UNLOAD para conjuntos de resultados grandes Si se espera que los resultados de una consulta sean grandes (por ejemplo, decenas de miles de filas o más), utilice UNLOAD para exportar los resultados. En la mayoría de los casos, esto resulta más rápido que ejecutar una consulta normal y, además, usar `UNLOAD` permite tener más control sobre el resultado. Cuando termina de ejecutarse una consulta, Athena almacena el resultado como un único archivo CSV sin comprimir en Amazon S3. Esto lleva más tiempo que `UNLOAD`, no solo porque el resultado no está comprimido, sino también porque la operación no se puede paralelizar. Por el contrario, `UNLOAD` escribe los resultados directamente desde los nodos de trabajo y aprovecha al máximo el paralelismo del clúster de computación. Además, puede configurar `UNLOAD` para escribir los resultados en formato comprimido y en otros formatos de archivo, como JSON y Parquet. Para obtener más información, consulte [UNLOAD](unload.md). ## Uso de CTAS o ETL de Glue para materializar las agregaciones de uso frecuente La “materialización” de una consulta es una forma de acelerar el rendimiento de la consulta mediante el almacenamiento de resultados de consultas complejas precalculados (por ejemplo, agregaciones y uniones) para reutilizarlos en consultas posteriores. Si varias de las consultas incluyen las mismas uniones y agregaciones, puede materializar la subconsulta común como una tabla nueva y, a continuación, ejecutar las consultas en esa tabla. Puede crear la nueva tabla con [Creación de una tabla a partir de los resultados de una consulta (CTAS)](ctas.md) o una herramienta ETL específica, como [ETL de Glue](https://aws.amazon.com/glue). Por ejemplo, supongamos que tiene un panel con widgets que muestran diferentes aspectos de un conjunto de datos de pedidos. Cada widget tiene su propia consulta, pero todas las consultas comparten las mismas uniones y filtros. Una tabla de pedidos se une a una tabla de líneas de artículos y hay un filtro que muestra solo los últimos tres meses. Si se identifican las características comunes de estas consultas, se puede crear una tabla nueva que los widgets puedan usar. Esto reduce la duplicación y mejora el rendimiento. La desventaja es que se debe mantener la nueva tabla actualizada. ## Reutilización de resultados de las consultas Es habitual que la misma consulta se ejecute varias veces en poco tiempo. Por ejemplo, esto puede ocurrir cuando varias personas abren el mismo panel de datos. Al ejecutar una consulta, puede decirle a Athena que reutilice los resultados calculados con anterioridad. Usted especifica la antigüedad máxima de los resultados que se van a reutilizar. Si la misma consulta se ejecutó anteriormente dentro de ese periodo de tiempo, Athena devuelve esos resultados en lugar de volver a ejecutar la consulta. Para obtener más información, consulte [Reutilización de resultados de las consultas en Athena](reusing-query-results.md) en la *Guía del usuario de Amazon Athena* y [Reducir los costos y mejorar el rendimiento de las consultas con la reutilización de resultados de las consultas de Amazon Athena](https://aws.amazon.com/blogs/big-data/reduce-cost-and-improve-query-performance-with-amazon-athena-query-result-reuse/) en el *Blog de macrodatos de AWS*. # Optimización de datos El rendimiento no solo depende de las consultas, sino también en gran medida de cómo esté organizado el conjunto de datos y del formato de archivo y de la compresión que utilice. ## Partición de datos La creación de particiones divide la tabla en partes y mantiene los datos relacionados juntos de acuerdo con propiedades como la fecha, el país o la región. Las claves de partición actúan como columnas virtuales. Las claves de partición se definen al crear la tabla y se utilizan para filtrar las consultas. Al filtrar las columnas de claves de partición, solo se leen los datos de las particiones coincidentes. Por ejemplo, si el conjunto de datos está dividido por fecha y la consulta tiene un filtro que solo coincide con la última semana, solo se leerán los datos de la última semana. Para obtener más información sobre la creación de particiones, consulte [Partición de datos](partitions.md). ## Elección de claves de partición compatibles con las consultas Dado que la creación de particiones tiene un impacto significativo en el rendimiento de las consultas, asegúrese de considerar cuidadosamente cómo crear las particiones al diseñar el conjunto de datos y las tablas. Tener demasiadas claves de partición puede provocar conjuntos de datos fragmentados con demasiados archivos y archivos demasiado pequeños. Por el contrario, tener muy pocas claves de partición, o no tener ninguna partición, hace que las consultas analicen más datos de los necesarios. ### Cómo evitar optimizar consultas poco frecuentes Una buena estrategia consiste en optimizar las consultas más comunes y evitar la optimización para las consultas poco frecuentes. Por ejemplo, si sus consultas están basadas en intervalos de días, no las divida por hora, incluso si algunas consultas se filtran a ese nivel. Si sus datos tienen una columna de marca de tiempo detallada, las consultas poco frecuentes que se filtran por hora pueden usar la columna de marca de tiempo. Incluso si en los casos poco frecuentes se analizan un poco más de datos de los necesarios, reducir el rendimiento general en aras de los casos excepcionales no suele ser una buena compensación. Para reducir la cantidad de datos que se deben analizar en las consultas y, por lo tanto, mejorar el rendimiento, utilice un formato de archivo en columnas y mantenga los registros ordenados. En lugar de particionar por hora, mantenga los registros ordenados por marca de tiempo. Para las consultas en intervalos de tiempo más cortos, ordenar por marca de tiempo es casi tan eficaz como particionar por hora. Además, la clasificación por marca de tiempo no suele afectar el rendimiento de las consultas en intervalos de tiempo contados en días. Para obtener más información, consulte [Utilizar formatos de archivo en columnas](#performance-tuning-use-columnar-file-formats). Tenga en cuenta que las consultas en tablas con decenas de miles de particiones funcionan mejor si hay predicados en todas las claves de partición. Esta es otra razón para diseñar un esquema de particiones para las consultas más comunes. Para obtener más información, consulte [Consulta de las particiones por igualdad](#performance-tuning-query-partitions-by-equality). ## Uso de la proyección de particiones La proyección de particiones es una característica de Athena que no almacena la información de la partición en el AWS Glue Data Catalog, sino como reglas en las propiedades de la tabla en AWS Glue. Cuando Athena planifica una consulta en una tabla configurada con proyección de particiones, lee las reglas de proyección de particiones de la tabla. Athena calcula las particiones para leerlas en la memoria en función de la consulta y las reglas en lugar de buscar las particiones en el AWS Glue Data Catalog. Además de simplificar la administración de particiones, la proyección de particiones puede mejorar el rendimiento de los conjuntos de datos que tienen un gran número de particiones. Cuando una consulta incluye intervalos en lugar de valores específicos para las claves de partición, la búsqueda de particiones coincidentes en el catálogo lleva más tiempo a medida que aumenta el número de particiones. Con la proyección de particiones, el filtro se puede calcular en la memoria sin tener que consultar el catálogo, lo que puede ser mucho más rápido. En determinadas circunstancias, la proyección de particiones puede reducir el rendimiento. Un ejemplo ocurre cuando una tabla se encuentra “dispersa”. Una tabla dispersa no contiene datos para todas las permutaciones de los valores de clave de partición descritos en la configuración de proyección de particiones. Con una tabla dispersa, el conjunto de particiones calculadas a partir de la consulta y la configuración de proyección de particiones se muestran en Amazon S3, incluso cuando no contienen datos. Cuando utilice la proyección de particiones, asegúrese de incluir los predicados en todas las claves de partición. Limite el alcance de los valores posibles para evitar operaciones de lista innecesarias de Amazon S3. Imagine una clave de partición que tiene un intervalo de un millón de valores y una consulta que no tiene ningún filtro en esa clave de partición. Para ejecutar la consulta, Athena debe realizar al menos un millón de operaciones de lista en Amazon S3. Las consultas son más rápidas cuando se consultan valores específicos, independientemente de si se utiliza la proyección de particiones o se almacena la información de las particiones en el catálogo. Para obtener más información, consulte [Consulta de las particiones por igualdad](#performance-tuning-query-partitions-by-equality). Al configurar una tabla para la proyección de particiones, asegúrese de que los intervalos que especifique sean razonables. Si una consulta no incluye un predicado en una clave de partición, se utilizan todos los valores del intervalo de esa clave. Si el conjunto de datos se creó en una fecha específica, utilice esa fecha como punto de partida para cualquier intervalo de fechas. Utilice `NOW` como el final de los intervalos de fechas. Evite los intervalos numéricos que tengan un gran número de valores y considere usar el tipo [inyectado](partition-projection-dynamic-id-partitioning.md#partition-projection-injection) en su lugar. Para obtener más información sobre la proyección de particiones, consulte [Uso de proyección de particiones con Amazon Athena](partition-projection.md). ## Uso de índices de particiones Los índices de particiones son una característica del AWS Glue Data Catalog que mejora el rendimiento de la búsqueda de particiones en las tablas que tienen un gran número de particiones. La lista de particiones del catálogo es como una tabla de una base de datos relacional. La tabla tiene las columnas para las claves de partición y una columna adicional para la ubicación de la partición. Al consultar una tabla particionada, las ubicaciones de las particiones se buscan mediante el análisis de esta tabla. Al igual que con las bases de datos relacionales, puede aumentar el rendimiento de las consultas gracias a la adición de índices. Puede agregar varios índices para admitir diferentes patrones de consulta. El índice de particiones del AWS Glue Data Catalog admite operadores de igualdad y comparación, como `>`, `>=` y `<` combinados con el operador `AND`. Para obtener más información, consulte [Trabajo con índices de partición en AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) en la *Guía para desarrolladores de AWS Glue* y [Mejora del rendimiento de consultas de Amazon Athena con índices de particiones de AWS Glue Data Catalog](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/) en el *Blog de macrodatos de AWS*. ## Uso siempre de STRING como tipo para las claves de partición Cuando consulte las claves de partición, recuerde que Athena requiere que las claves de partición sean del tipo `STRING` para poder aplicar el filtrado de particiones en AWS Glue. Si el número de particiones no es pequeño, el uso de otros tipos puede reducir el rendimiento. Si los valores de las claves de partición son similares a una fecha o a un número, cámbielos al tipo adecuado en la consulta. ## Eliminación de las particiones antiguas y vacías Si elimina datos de una partición de Amazon S3 (por ejemplo, mediante el [ciclo de vida](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) de Amazon S3), también debe eliminar la entrada de la partición del AWS Glue Data Catalog. Durante la planificación de la consulta, cualquier partición que coincida con la consulta aparece en Amazon S3. Si tiene muchas particiones vacías, la sobrecarga que supone listarlas puede ser perjudicial. Además, si tiene muchos miles de particiones, considere la posibilidad de eliminar los metadatos de las particiones de los datos antiguos que ya no son relevantes. Por ejemplo, si las consultas nunca analizan datos de más de un año, puede eliminar periódicamente los metadatos de las particiones más antiguas. Si el número de particiones aumenta a decenas de miles, eliminar las particiones no utilizadas puede acelerar las consultas que no incluyen predicados en todas las claves de partición. Para obtener información sobre cómo incluir predicados en todas las claves de partición en las consultas, consulte [Consulta de las particiones por igualdad](#performance-tuning-query-partitions-by-equality). ## Consulta de las particiones por igualdad Las consultas que incluyen predicados de igualdad en todas las claves de partición se ejecutan más rápido porque los metadatos de las particiones se pueden cargar de forma directa. Evite las consultas en las que una o más claves de partición no tengan un predicado o en las que el predicado seleccione un intervalo de valores. En este tipo de consultas, se debe filtrar la lista de todas las particiones para encontrar valores coincidentes. En la mayoría de las tablas, la sobrecarga es mínima, pero en las tablas con decenas de miles o más particiones, la sobrecarga puede llegar a ser significativa. Si no es posible reescribir las consultas para filtrar las particiones por igualdad, puede probar la proyección de particiones. Para obtener más información, consulte [Uso de la proyección de particiones](#performance-tuning-use-partition-projection). ## Cómo evitar el uso de MSCK REPAIR TABLE para el mantenimiento de las particiones Como `MSCK REPAIR TABLE` puede tardar mucho en ejecutarse, solo agrega particiones nuevas y no elimina las antiguas, no es una forma eficaz de administrar las particiones (consulte [Consideraciones y limitaciones](msck-repair-table.md#msck-repair-table-considerations)). Las particiones se administran mejor de forma manual mediante las [API del AWS Glue Data Catalog](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api-catalog.html), [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) o los [rastreadores de AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/crawler-running.html). Como alternativa, puede utilizar la proyección de particiones, que elimina por completo la necesidad de administrar las particiones. Para obtener más información, consulte [Uso de proyección de particiones con Amazon Athena](partition-projection.md). ## Comprobar que las consultas sean compatibles con el esquema de particiones Puede comprobar de antemano qué particiones se analizarán en una consulta mediante la instrucción [`EXPLAIN`](athena-explain-statement.md). Agregue el prefijo a la consulta con la palabra clave `EXPLAIN` y, a continuación, busque el fragmento de origen (por ejemplo, `Fragment 2 [SOURCE]`) de cada tabla cerca de la parte inferior del resultado `EXPLAIN`. Busque tareas en las que el lado derecho esté definido como una clave de partición. La línea inferior incluye una lista de todos los valores de esa clave de partición que se analizarán cuando se ejecute la consulta. Por ejemplo, supongamos que tiene una consulta en una tabla con una clave de partición `dt` y agrega el prefijo a la consulta con `EXPLAIN`. Si los valores de la consulta son fechas y con un filtro se selecciona un intervalo de tres días, el resultado `EXPLAIN` puede ser similar a lo siguiente: ``` dt := dt:string:PARTITION_KEY :: [[2023-06-11], [2023-06-12], [2023-06-13]] ``` El resultado `EXPLAIN` muestra que el planificador encontró tres valores para esta clave de partición que coincidían con la consulta. También muestra cuáles son esos valores. Para obtener más información sobre el uso de `EXPLAIN`, consulte [Uso de EXPLAIN y EXPLAIN ANALYZE en Athena](athena-explain-statement.md) y [Descripción de los resultados de la instrucción EXPLAIN de Athena](athena-explain-statement-understanding.md). ## Utilizar formatos de archivo en columnas Los formatos de archivo en columnas, como Parquet y ORC, están diseñados para cargas de trabajo de análisis distribuidas. Organizan los datos por columnas, no por filas. La organización de los datos en formato de columnas ofrece las siguientes ventajas: + Solo se cargan las columnas necesarias para la consulta. + Se reduce la cantidad total de datos que deben cargarse. + Los valores de las columnas se almacenan juntos, por lo que los datos se pueden comprimir de forma eficiente. + Los archivos pueden contener metadatos que permiten que el motor omita la carga de datos innecesarios. Como ejemplo de cómo se pueden utilizar los metadatos de los archivos, los metadatos de los archivos pueden contener información sobre los valores mínimos y máximos de una página de datos. Si los valores consultados no están dentro del intervalo indicado en los metadatos, se puede omitir la página. Una forma de utilizar estos metadatos para mejorar el rendimiento es garantizar que los datos de los archivos estén ordenados. Por ejemplo, supongamos que tiene consultas que buscan registros en los que la entrada `created_at` se encuentra dentro de un periodo de tiempo breve. Si los datos están ordenados por la columna `created_at`, Athena puede usar los valores mínimo y máximo de los metadatos del archivo para omitir las partes innecesarias de los archivos de datos. Cuando utilice formatos de archivo en columnas, asegúrese de que los archivos no sean demasiado pequeños. Como se indica en [Cómo evitar tener demasiados archivos](#performance-tuning-avoid-having-too-many-files), los conjuntos de datos con muchos archivos pequeños generan problemas de rendimiento. Esto se aplica aún más cuando se habla de formatos de archivo en columnas. En el caso de los archivos pequeños, la sobrecarga del formato de archivo en columnas supera las ventajas. Tenga en cuenta que Parquet y ORC están organizados internamente por grupos de filas (Parquet) y bandas (ORC). El tamaño predeterminado para los grupos de filas es de 128 MB y para las bandas, de 64 MB. Si tiene muchas columnas, puede aumentar el tamaño del grupo de filas y de las bandas para obtener un mejor rendimiento. No se recomienda reducir el tamaño del grupo de filas o de las bandas a un valor inferior a sus valores predeterminados. Para convertir otros formatos de datos a Parquet u ORC, puede utilizar ETL de AWS Glue o Athena. Para obtener más información, consulte [Conversión a formatos de columnas](columnar-storage.md#convert-to-columnar). ## Compresión de datos Athena admite una amplia gama de formatos de compresión. La consulta de datos comprimidos es más rápida y económica, ya que se paga por el número de bytes analizados antes de la descompresión. El formato [gzip](https://www.gnu.org/software/gzip/) ofrece buenas relaciones de compresión y es compatible con una amplia gama de herramientas y servicios. El formato [zstd](https://facebook.github.io/zstd/) (Zstandard) es un formato de compresión más reciente con un buen equilibrio entre rendimiento y relación de compresión. Al comprimir archivos de texto, como datos JSON y CSV, intente lograr un equilibrio entre el número de archivos y su tamaño. La mayoría de los formatos de compresión requieren que el lector lea los archivos desde el principio. Esto significa que, en general, los archivos de texto comprimidos no se pueden procesar en paralelo. Los archivos grandes sin comprimir suelen dividirse entre los trabajos para lograr un mayor paralelismo durante el procesamiento de las consultas, pero esto no es posible con la mayoría de los formatos de compresión. Como se explica en [Cómo evitar tener demasiados archivos](#performance-tuning-avoid-having-too-many-files), lo mejor es no tener demasiados archivos ni muy pocos. Como el número de archivos es el límite del número de trabajos que se pueden procesar en la consulta, esta regla se aplica aún más a los archivos comprimidos. Para obtener más información sobre el uso de la compresión en Athena, consulte [Uso de la compresión en Athena](compression-formats.md). ## Creación de buckets para buscar claves con cardinalidad alta La agrupación en buckets es una técnica para distribuir los registros en archivos separados según el valor de una de las columnas. Esto garantiza que todos los registros con el mismo valor estén en el mismo archivo. La agrupación en buckets resulta útil cuando se tiene una clave con una cardinalidad alta y muchas de las consultas buscan valores específicos de la clave. Por ejemplo, supongamos que consulta un conjunto de registros para un usuario específico. Si los datos están agrupados por ID de usuario, Athena sabe de antemano qué archivos contienen registros para un ID específico y cuáles no. Esto permite a Athena leer solo los archivos que pueden contener el ID, lo que reduce de forma significativa la cantidad de datos leídos. También reduce el tiempo de computación que, de otro modo, se necesitaría para buscar el ID específico en los datos. ### Evitar la agrupación en buckets cuando las consultas buscan con frecuencia varios valores en una columna La agrupación en buckets es menos valiosa cuando las consultas buscan con frecuencia múltiples valores en la columna por la que están agrupados los datos. Cuantos más valores se consulten, mayor será la probabilidad de que se tengan que leer todos los archivos o la mayoría de ellos. Por ejemplo, si tiene tres buckets y una consulta busca tres valores diferentes, es posible que deban leerse todos los archivos. La agrupación en buckets funciona mejor cuando las consultas buscan valores únicos. Para obtener más información, consulte [Uso de particiones y asignación de buckets](ctas-partitioning-and-bucketing.md). ## Cómo evitar tener demasiados archivos Los conjuntos de datos que consisten en muchos archivos pequeños dan como resultado un rendimiento general de las consultas deficiente. Cuando Athena planifica una consulta, lista todas las ubicaciones de las particiones, lo que lleva tiempo. La administración y solicitud de cada archivo también supone una sobrecarga computacional. Por lo tanto, cargar un solo archivo más grande desde Amazon S3 es más rápido que cargar los mismos registros desde muchos archivos más pequeños. En casos extremos, es posible que se encuentre con límites de servicio de Amazon S3. Amazon S3 admite hasta 5500 solicitudes por segundo en una sola partición de índice. Inicialmente, un bucket se trata como una partición de índice único, pero a medida que aumentan las cargas de solicitudes, se puede dividir en varias particiones de índice. Amazon S3 analiza los patrones de solicitudes y los divide en función de los prefijos clave. Si su conjunto de datos consiste en muchos miles de archivos, las solicitudes procedentes de Athena pueden superar la cuota de solicitudes. Incluso con menos archivos, se puede superar la cuota si se realizan varias consultas simultáneas en el mismo conjunto de datos. Otras aplicaciones que tengan acceso a los mismos archivos pueden contribuir al número total de solicitudes. Cuando se supera la tasa de solicitudes `limit`, Amazon S3 muestra el siguiente error. Este error se incluye en la información de estado de la consulta en Athena. SlowDown: reduzca la tasa de solicitudes. Para solucionar el problema, comience por determinar si el error se debe a una sola consulta o a varias consultas que leen los mismos archivos. Si se debe a lo último, coordine la ejecución de las consultas para que no se ejecuten al mismo tiempo. Para lograrlo, agregue un mecanismo de colas o incluso de reintentos en su aplicación. Si al ejecutar una sola consulta se desencadena el error, intente combinar archivos de datos o modificar la consulta para leer menos archivos. El mejor momento para combinar archivos pequeños es antes de escribirlos. Para ello, tenga en cuenta las siguientes técnicas: + Cambie el proceso de escritura de los archivos para escribir archivos más grandes. Por ejemplo, puede almacenar los registros en búfer durante más tiempo antes de que se escriban. + Coloque los archivos en una ubicación de Amazon S3 y utilice una herramienta como ETL de Glue para combinarlos en archivos más grandes. Luego, mueva los archivos más grandes a la ubicación a la que apunta la tabla. Para obtener más información, consulte [Lectura de archivos de entrada en grupos más grandes](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) en la *Guía para desarrolladores de AWS Glue* y [¿Cómo puedo configurar un trabajo de ETL en AWS Glue para generar archivos más grandes?](https://repost.aws/knowledge-center/glue-job-output-large-files) en el *Centro de conocimientos de AWS re:Post*. + Reduzca el número de claves de partición. Si tiene demasiadas claves de partición, es posible que cada partición tenga solo algunos registros, lo que se traduce en un número excesivo de archivos pequeños. Para obtener información sobre cómo decidir qué particiones crear, consulte [Elección de claves de partición compatibles con las consultas](#performance-tuning-pick-partition-keys-that-will-support-your-queries). ## Cómo evitar jerarquías de almacenamiento adicionales más allá de la partición Para evitar la sobrecarga de planificación de consultas, almacene los archivos en una estructura plana en cada ubicación de partición. No utilice jerarquías de directorios adicionales. Cuando Athena planifica una consulta, lista todos los archivos de todas las particiones que coinciden con la consulta. Aunque Amazon S3 no tiene directorios propiamente dichos, la convención consiste en interpretar la barra diagonal `/` como un separador de directorios. Cuando Athena lista las ubicaciones de las particiones, lista de forma recursiva cualquier directorio que encuentre. Cuando los archivos de una partición se organizan en una jerarquía, se producen varias rondas de operaciones de lista. Cuando todos los archivos están directamente en la ubicación de la partición, la mayoría de las veces solo se debe realizar una operación de lista. Sin embargo, se requieren varias operaciones de lista secuencial si tiene más de 1000 archivos en una partición, ya que Amazon S3 devuelve solo 1000 objetos por operación de lista. Tener más de 1000 archivos en una partición también puede provocar otros problemas de rendimiento más graves. Para obtener más información, consulte [Cómo evitar tener demasiados archivos](#performance-tuning-avoid-having-too-many-files). ## Uso de SymlinkTextInputFormat solo cuando sea necesario El uso de la técnica [https://athena.guide/articles/stitching-tables-with-symlinktextinputformat](https://athena.guide/articles/stitching-tables-with-symlinktextinputformat) puede ser una forma de evitar situaciones en las que los archivos de una tabla no estén bien organizados en particiones. Por ejemplo, los enlaces simbólicos pueden resultar útiles cuando todos los archivos tienen el mismo prefijo o si los archivos con esquemas diferentes se encuentran en la misma ubicación. Sin embargo, el uso de enlaces simbólicos agrega niveles de indirección a la ejecución de la consulta. Estos niveles de indirección afectan el rendimiento general. Se deben leer los archivos de enlace simbólico y se deben listar las ubicaciones que definen. Esto agrega varios viajes de ida y vuelta a Amazon S3 que las tablas de Hive habituales no requieren. En conclusión, `SymlinkTextInputFormat` solo debe utilizarse cuando no haya mejores opciones disponibles, como la reorganización de archivos. # Uso de formatos de almacenamiento en columnas [Apache Parquet](https://parquet.apache.org) y [ORC](https://orc.apache.org/) son formatos de almacenamiento en columnas que están optimizados para una rápida recuperación de los datos y que se utilizan en las aplicaciones de análisis de AWS. Los formatos de almacenamiento en columnas tienen las siguientes características que los hacen idóneos para su uso con Athena: + *Compresión por columna, con el algoritmo de compresión seleccionado para cada tipo de datos de columna* para ahorrar espacio de almacenamiento en Amazon S3 y reducir el espacio de disco y las operaciones de E/S durante el procesamiento de consultas. + *La inserción de predicados* en Parquet y ORC permite que las consultas de Athena solo obtengan los bloques necesarios, lo que mejora el rendimiento de las consultas. Cuando una consulta de Athena obtiene valores de columna específicos de sus datos, utiliza las estadísticas de los predicados de bloque de datos, como los valores máximos o mínimos, para determinar si se debe leer u omitir el bloque. + *La división de datos* en Parquet y ORC permite a Athena dividir la lectura de los datos entre varios lectores y aumentar el paralelismo durante el procesamiento de consultas. Para convertir sus datos sin procesar existentes de otros formatos de almacenamiento a Parquet u ORC, puede ejecutar [CREATE TABLE AS SELECT (CTAS)](ctas.md) en las consultas de Athena y especificar un formato de almacenamiento de datos como Parquet u ORC, o utilizar el rastreador de AWS Glue. ## Elección entre Parquet y ORC La elección entre ORC (Optimized Row Columnar) y Parquet depende de sus requisitos de uso específicos. Apache Parquet proporciona esquemas eficientes de compresión y codificación de datos y es ideal para ejecutar consultas complejas y procesar grandes cantidades de datos. Parquet está optimizado para su uso con [Apache Arrow](https://arrow.apache.org/), lo que puede resultar ventajoso si utiliza herramientas relacionadas con Arrow. ORC proporciona una forma eficiente de almacenar los datos de Hive. Los archivos ORC suelen ser más pequeños que los archivos Parquet, y los índices ORC pueden agilizar las consultas. Además, ORC admite tipos complejos, como estructuras, mapas y listas. Cuando elija entre Parquet y ORC, tenga en cuenta los siguientes factores: **Rendimiento de consultas**: dado que Parquet admite una gama más amplia de tipos de consultas, Parquet podría ser una mejor opción si planea realizar consultas complejas. **Tipos de datos complejos**: si utiliza tipos de datos complejos, ORC podría ser una mejor opción, ya que admite una gama más amplia de tipos de datos complejos. **Tamaño de archivo**: si el espacio en disco es un problema, ORC suele producir archivos más pequeños, lo que puede reducir los costos de almacenamiento. **Compresión**: tanto Parquet como ORC proporcionan una buena compresión, pero el mejor formato dependerá de su caso de uso específico. **Evolución**: tanto Parquet como ORC admiten la evolución del esquema, lo que significa que puede agregar, eliminar o modificar columnas a lo largo del tiempo. Tanto Parquet como ORC son buenas opciones para aplicaciones de macrodatos, pero tenga en cuenta los requisitos de su escenario antes de elegir. Es posible que desee realizar pruebas comparativas de sus datos y consultas para ver qué formato funciona mejor en su caso de uso. ## Conversión a formatos de columnas Las opciones para convertir fácilmente los datos de origen, como JSON o CSV, a un formato de columnas incluyen el uso de consultas [CREATE TABLE AS](ctas.md) o ejecución de trabajos en AWS Glue. + Puede usar consultas `CREATE TABLE AS` (CTAS) para convertir datos a Parquet u ORC en un solo paso. Para ver un ejemplo, consulte [Ejemplo: escritura de los resultados de la consulta en un formato diferente](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-format) en la página [Ejemplos de consultas CTAS](ctas-examples.md). + Para obtener información acerca del uso de Athena para ETL para transformar los datos de CSV a Parquet, consulte [Uso de CTAS e INSERT INTO en ETL y análisis de datos](ctas-insert-into-etl.md). + Para obtener información sobre cómo ejecutar un trabajo de AWS Glue para transformar datos en CSV a Parquet, consulte la sección “Transformar datos en formato CSV a Parquet” en la publicación del Blog de macrodatos de AWS [Crear una base de lago de datos con AWS Glue y Amazon S3](https://aws.amazon.com/blogs/big-data/build-a-data-lake-foundation-with-aws-glue-and-amazon-s3/). AWS Glue admite el uso de la misma técnica para convertir datos en CSV a ORC, o datos en JSON a Parquet u ORC. # Uso de particiones y asignación de buckets La creación de particiones y la asignación de buckets son dos formas de reducir la cantidad de datos que Athena debe analizar al ejecutar una consulta. La creación de particiones y la asignación de buckets son complementarias y se pueden utilizar juntas. Reducir la cantidad de datos analizados mejora el rendimiento y reduce los costos. Para obtener pautas generales sobre el rendimiento de las consultas de Athena, consulte [Los 10 mejores consejos para ajustar el rendimiento de Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/). **Topics** + [¿Qué es la creación de particiones?](ctas-partitioning-and-bucketing-what-is-partitioning.md) + [¿Qué es la asignación de buckets?](ctas-partitioning-and-bucketing-what-is-bucketing.md) + [Recursos adicionales](ctas-partitioning-and-bucketing-additional-resources.md) # ¿Qué es la creación de particiones? Crear particiones significa organizar los datos en directorios (o “prefijos”) en Amazon S3 en función de una propiedad concreta de los datos. Estas propiedades se denominan claves de partición. Una clave de partición común es la fecha o alguna otra unidad de tiempo, como el año o el mes. Sin embargo, un conjunto de datos se puede particionar en más de una clave. Por ejemplo, los datos sobre las ventas de productos pueden particionarse por fecha, categoría de producto y mercado. ## Decidir cómo crear particiones Las propiedades que se utilizan siempre o con frecuencia en las consultas y que tienen una cardinalidad baja son buenas candidatas para las claves de partición. Hay una disyuntiva entre tener demasiadas particiones y tener muy pocas. Con demasiadas particiones, el aumento del número de archivos genera una sobrecarga. El filtrado de las propias particiones también supone una sobrecarga. Con muy pocas particiones, las consultas suelen tener que analizar más datos. ## Creación de una tabla particionada Cuando un conjunto de datos está particionado, puede crear una tabla particionada en Athena. Una tabla particionada es una tabla que tiene claves de partición. Cuando se utiliza `CREATE TABLE`, se agregan particiones a la tabla. Cuando se utiliza `CREATE TABLE AS`, las particiones que se crean en Amazon S3 se agregan automáticamente a la tabla. En una instrucción `CREATE TABLE`, se especifican las claves de partición en la cláusula `PARTITIONED BY (column_name data_type)`. En una instrucción `CREATE TABLE AS`, se especifican las claves de partición en una cláusula `WITH (partitioned_by = ARRAY['partition_key'])` o `WITH (partitioning = ARRAY['partition_key'])` en las tablas de Iceberg. Por motivos de rendimiento, las claves de partición siempre deben ser del tipo `STRING`. Para obtener más información, consulte [Uso de una cadena como tipo de datos para las claves de partición](data-types-timestamps.md#data-types-timestamps-partition-key-types). Para obtener información adicional sobre la sintaxis de `CREATE TABLE` y `CREATE TABLE AS`, consulte [CREATE TABLE](create-table.md) y [Propiedades de la tabla CTAS](create-table-as.md#ctas-table-properties). ## Consulta de tablas particionadas Cuando se consulta una tabla particionada, Athena usa los predicados de la consulta para filtrar la lista de particiones. A continuación, utiliza las ubicaciones de las particiones coincidentes para procesar los archivos encontrados. Athena puede reducir de manera eficiente la cantidad de datos analizados simplemente al no leer los datos de las particiones que no coinciden con los predicados de la consulta. ### Ejemplos Supongamos que tiene una tabla particionada en `sales_date` y `product_category` y quiere saber los ingresos totales de una semana en una categoría específica. Debe incluir predicados en las columnas `sales_date` y `product_category` para garantizar que Athena analice solo la cantidad mínima de datos, como en el siguiente ejemplo. ``` SELECT SUM(amount) AS total_revenue FROM sales WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' AND product_category = 'Toys' ``` Supongamos que tiene un conjunto de datos que está particionado por fecha, pero que también tiene una marca de tiempo detallada. Con las tablas de Iceberg, puede declarar que una clave de partición tiene una relación con una columna, pero con las tablas de Hive, el motor de consultas no conoce las relaciones entre las columnas y las claves de partición. Por este motivo, debe incluir un predicado tanto en la columna como en la clave de partición de la consulta para asegurarse de que la consulta no analice más datos de los necesarios. Por ejemplo, supongamos que la tabla `sales` del ejemplo anterior también tiene una columna `sold_at` del tipo de datos `TIMESTAMP`. Si desea obtener los ingresos solo para un intervalo de tiempo específico, debe escribir la consulta de la siguiente manera: ``` SELECT SUM(amount) AS total_revenue FROM sales WHERE sales_date = '2023-02-28' AND sold_at BETWEEN TIMESTAMP '2023-02-28 10:00:00' AND TIMESTAMP '2023-02-28 12:00:00' AND product_category = 'Toys' ``` Para obtener más información sobre esta diferencia entre las consultas de las tablas de Hive e Iceberg, consulte [Cómo escribir consultas para campos de marca de tiempo que también se encuentren particionados por tiempo](data-types-timestamps.md#data-types-timestamps-how-to-write-queries-for-timestamp-fields-that-are-also-time-partitioned). # ¿Qué es la asignación de buckets? La asignación de buckets es una forma de organizar los registros de un conjunto de datos en categorías denominadas buckets. Este significado de bucket y creación de buckets es diferente del de bucket de Amazon S3 y no debe confundirse con este. En la asignación de buckets para datos, los registros que tienen el mismo valor para una propiedad se incluyen en el mismo bucket. Los registros se distribuyen de la forma más uniforme posible entre los buckets, de modo que cada uno de ellos tenga aproximadamente la misma cantidad de datos. En la práctica, los buckets son archivos y una función hash determina el bucket al que se asigna un registro. Un conjunto de datos agrupado en buckets tendrá uno o más archivos por bucket y partición. El bucket al que pertenece un archivo está codificado en el nombre del archivo. ## Beneficios de la asignación de buckets La asignación de buckets es útil cuando un conjunto de datos está agrupado en buckets según una propiedad específica y se desean recuperar registros en los que esa propiedad tiene un valor determinado. Como los datos están agrupados en buckets, Athena puede utilizar el valor para determinar los archivos que se van a examinar. Por ejemplo, supongamos que un conjunto de datos está agrupado en buckets por `customer_id` y que usted desea buscar todos los registros de un cliente específico. Athena determina el bucket que contiene esos registros y solo lee los archivos de ese bucket. Las columnas que presentan una alta cardinalidad (es decir, tienen muchos valores distintos), están distribuidas de manera uniforme y se consultan en busca de valores específicos con frecuencia, se consideran buenas candidatas para la asignación de datos. **nota** Athena no admite el uso de `INSERT INTO` para agregar nuevos registros a tablas agrupadas en buckets. ## Tipos de datos admitidos para filtrado en columnas en buckets Puede agregar filtros en columnas agrupadas en buckets con determinados tipos de datos. Athena admite el filtrado en columnas agrupadas en buckets con los siguientes tipos de datos: + BOOLEANO + BYTE + DATE + DOUBLE + FLOAT + INT + LONG + SHORT + STRING + VARCHAR ## Soporte para Hive y Spark La versión 2 del motor de Athena admite conjuntos de datos agrupados en buckets mediante el algoritmo de bucket Hive, y la versión 3 del motor de Athena también admite el algoritmo de bucket Apache Spark. Hive es el bucket predeterminado. Si el conjunto de datos está agrupado en buckets mediante el algoritmo Spark, use la cláusula `TBLPROPERTIES` para establecer el valor de la propiedad `bucketing_format` en `spark`. **nota** Athena tiene un límite de 100 particiones por consulta `CREATE TABLE AS SELECT` ([CTAS](ctas.md)). Del mismo modo, solo puede agregar un máximo de 100 particiones a una tabla de destino con una instrucción [INSERT INTO](insert-into.md). Si supera esta limitación, es posible que reciba el mensaje de error HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS: Exceeded limit of 100 open writers for partitions/buckets (HIVE\$1TOO\$1MANY\$1OPEN\$1PARTITIONS: Se ha superado el límite de 100 autores abiertos para particiones/buckets). Para evitar esta limitación, puede utilizar una instrucción CTAS y una serie de instrucciones `INSERT INTO` que crean o insertan hasta 100 particiones cada una. Para obtener más información, consulte [Uso de CTAS e INSERT INTO para evitar el límite de 100 particiones](ctas-insert-into.md). ## Ejemplo de asignación de buckets con CREATE TABLE Si desea crear una tabla para un conjunto de datos agrupado en buckets existente, use la cláusula `CLUSTERED BY (column)` seguida de la cláusula `INTO N BUCKETS`. La cláusula `INTO N BUCKETS` especifica el número de buckets en los que se agrupan los datos. En el siguiente ejemplo `CREATE TABLE`, el conjunto de datos `sales` se agrupa por `customer_id` en 8 buckets mediante el algoritmo Spark. La instrucción `CREATE TABLE` usa las cláusulas `CLUSTERED BY` y `TBLPROPERTIES` para establecer las propiedades en consecuencia. ``` CREATE EXTERNAL TABLE sales (...) ... CLUSTERED BY (`customer_id`) INTO 8 BUCKETS ... TBLPROPERTIES ( 'bucketing_format' = 'spark' ) ``` ## Ejemplo de asignación de buckets con CREATE TABLE AS (CTAS) Para especificar la asignación de buckets con `CREATE TABLE AS`, utilice los parámetros `bucketed_by` y `bucket_count`, como en el siguiente ejemplo. ``` CREATE TABLE sales WITH ( ... bucketed_by = ARRAY['customer_id'], bucket_count = 8 ) AS SELECT ... ``` ## Ejemplo de consulta de asignación de buckets En el siguiente ejemplo de consulta, se buscan los nombres de los productos que un cliente específico ha comprado en el transcurso de una semana. ``` SELECT DISTINCT product_name FROM sales WHERE sales_date BETWEEN '2023-02-27' AND '2023-03-05' AND customer_id = 'c123' ``` Si esta tabla está particionada por `sales_date` y agrupada en buckets por `customer_id`, Athena puede calcular el bucket en el que se encuentran los registros del cliente. Como máximo, Athena lee un archivo por partición. # Recursos adicionales + Para ver un ejemplo de `CREATE TABLE AS` en el que se crean tablas agrupadas en buckets y particionadas, consulte [Ejemplo: creación de tablas agrupadas en buckets y particionadas](https://docs.aws.amazon.com/athena/latest/ug/ctas-examples.html#ctas-example-bucketed). + Para obtener información sobre cómo implementar el uso de buckets en lagos de datos de AWS, incluido el uso de una instrucción CTAS de Athena, AWS Glue para Apache Spark y el uso de buckets para tablas de Apache Iceberg, consulte la publicación en el blog de Big Data de AWS [Optimizar la disposición de datos mediante el uso de buckets con Amazon Athena y AWS Glue para acelerar las consultas posteriores](https://aws.amazon.com/blogs/big-data/optimize-data-layout-by-bucketing-with-amazon-athena-and-aws-glue-to-accelerate-downstream-queries/). # Partición de datos La partición de los datos le permite restringir el volumen de datos que explora cada consulta, lo que mejora el rendimiento y reduce los costos. Puede particionar los datos por cualquier clave. Una práctica común consiste en particionar los datos en función del tiempo, lo que a menudo conduce a un esquema de partición de varios niveles. Por ejemplo, si un cliente recibe datos cada hora, podría elegir una partición por año, mes, día y hora. Otro cliente, que recibe datos procedentes de muchos orígenes distintos, pero que solo se cargan una vez al día, puede basar la partición en un identificador del origen de datos y en la fecha. Athena puede utilizar particiones de estilo de Apache Hive, cuyas rutas de datos contienen pares de valores de clave conectados por signos de igual (por ejemplo, `country=us/...` o `year=2021/month=01/day=26/...`). Por lo tanto, las rutas incluyen los nombres de las claves de partición y los valores que representa cada ruta. Para cargar nuevas particiones de Hive en una tabla particionada, puede utilizar el comando [MSCK REPAIR TABLE](msck-repair-table.md), que solo funciona con particiones de estilo de Hive. Athena también puede utilizar esquemas de partición de estilos que no son de Hive. Por ejemplo, los registros de CloudTrail y los flujos de entrega de Firehose utilizan componentes de ruta independientes para partes de fecha, como `data/2021/01/26/us/6fc7845e.json`. Para aquellas particiones que no son del estilo de Hive, se utiliza [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) para agregar las particiones manualmente. ## Consideraciones y limitaciones Al usar la partición, tenga en cuenta los siguientes puntos: + Si consulta una tabla con particiones y especifica la partición en la cláusula `WHERE`, Athena analiza los datos solo de esa partición. + Si efectúa consultas de los buckets de Amazon S3 con un gran número de objetos y los datos no están particionados, dichas consultas pueden afectar los límites de tasa de solicitudes `GET` en Amazon S3 y dar lugar a excepciones de Amazon S3. Para evitar errores, divida los datos. Plantéese también ajustar las tasas de solicitud de Amazon S3. Para obtener más información, consulte [Patrones de diseño de prácticas recomendadas: optimización del rendimiento de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/request-rate-perf-considerations.html). + Las ubicaciones de partición que se van a utilizar con Athena deben utilizar el protocolo `s3` (por ejemplo, `s3://amzn-s3-demo-bucket/folder/`). En Athena, las ubicaciones que utilizan otros protocolos (por ejemplo, `s3a://amzn-s3-demo-bucket/folder/`) producirán errores de consulta cuando se ejecuten consultas `MSCK REPAIR TABLE` en las tablas que contienen. + Asegúrese de que la ruta de Amazon S3 esté en minúsculas, en lugar de usar también mayúsculas en la inicial (por ejemplo, `userid` en lugar de `userId`). Si la ruta de S3 usa mayúsculas en la inicial, `MSCK REPAIR TABLE` no agrega las particiones a AWS Glue Data Catalog. Para obtener más información, consulte [MSCK REPAIR TABLE](msck-repair-table.md). + Dado que `MSCK REPAIR TABLE` analiza una carpeta y sus subcarpetas para encontrar un esquema de partición coincidente, asegúrese de mantener los datos de tablas separadas en jerarquías de carpetas separadas. Por ejemplo, supongamos que tiene los datos de la tabla 1 en `s3://amzn-s3-demo-bucket1` y los datos de la tabla 2 en `s3://amzn-s3-demo-bucket1/table-2-data`. Si ambas tablas están particionadas por cadena, `MSCK REPAIR TABLE` agregará las particiones de la tabla 2 a la tabla 1. Para evitarlo, utilice estructuras de carpetas independientes, como `s3://amzn-s3-demo-bucket1` y `s3://amzn-s3-demo-bucket2` en su lugar. Tenga en cuenta que este comportamiento es coherente con Amazon EMR y Apache Hive. + Si actualmente utiliza AWS Glue Data Catalog con Athena, consulte los [puntos de conexión y cuotas de AWS Glue](https://docs.aws.amazon.com/general/latest/gr/glue.html) para ver las cuotas de servicio de las particiones por cuenta y por tabla. + Aunque Athena admite consultas de tablas de AWS Glue que tienen 10 millones de particiones, no puede leer más de 1 millón de particiones en un solo escaneo. En estos escenarios, la indexación de particiones puede ser beneficiosa. Para obtener más información, consulte el artículo del Blog de macrodatos de AWS [Improve Amazon Athena query performance using AWS Glue Data Catalog partition indexes](https://aws.amazon.com/blogs/big-data/improve-amazon-athena-query-performance-using-aws-glue-data-catalog-partition-indexes/). + Para solicitar un aumento de la cuota de particiones si está utilizando el AWS Glue Data Catalog, vaya a la [consola de Service Quotas de AWS Glue](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/glue/quotas). ## Creación y carga de una tabla con datos con particiones Para crear una tabla que utiliza particiones, utilice la cláusula `PARTITIONED BY` de la instrucción [CREATE TABLE](create-table.md). La cláusula `PARTITIONED BY` define las claves en las que se llevará a cabo la partición de los datos, como en el siguiente ejemplo. La cláusula `LOCATION` especifica la ubicación raíz de los datos particionados. ``` CREATE EXTERNAL TABLE users ( first string, last string, username string ) PARTITIONED BY (id string) STORED AS parquet LOCATION 's3://amzn-s3-demo-bucket' ``` Después de crear la tabla, cargará los datos en las particiones para poder consultarlos. Para las particiones de estilo Hive, se ejecuta [MSCK REPAIR TABLE](msck-repair-table.md). Para las particiones que no son del estilo de Hive, se utiliza [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) para agregar las particiones manualmente. ## Preparación de datos de estilo de Hive y no compatibles con Hive para consultas En las siguientes secciones, se muestra cómo preparar datos de estilo de Hive y no compatibles con Hive para consultas en Athena. ### Escenario 1: datos almacenados en Amazon S3 en formato Hive En este escenario, las particiones están almacenadas en Amazon S3 en carpetas distintas. Por ejemplo, esta es una lista parcial de muestras de impresiones de anuncios que genera el comando [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/s3/ls.html), que enumera los objetos de S3 con un prefijo especificado: ``` aws s3 ls s3://elasticmapreduce/samples/hive-ads/tables/impressions/ PRE dt=2009-04-12-13-00/ PRE dt=2009-04-12-13-05/ PRE dt=2009-04-12-13-10/ PRE dt=2009-04-12-13-15/ PRE dt=2009-04-12-13-20/ PRE dt=2009-04-12-14-00/ PRE dt=2009-04-12-14-05/ PRE dt=2009-04-12-14-10/ PRE dt=2009-04-12-14-15/ PRE dt=2009-04-12-14-20/ PRE dt=2009-04-12-15-00/ PRE dt=2009-04-12-15-05/ ``` Aquí los registros se almacenan con el nombre de columna (dt) definido según incrementos de fecha, hora y minuto. Cuando se especifica DDL con la ubicación de la carpeta principal, el esquema y el nombre de la columna particionada, Athena puede consultar los datos de las subcarpetas. #### Creación de la tabla Para obtener una tabla de estos datos, cree una partición basada en “dt”, como en la siguiente instrucción DDL de Athena: ``` CREATE EXTERNAL TABLE impressions ( requestBeginTime string, adId string, impressionId string, referrer string, userAgent string, userCookie string, ip string, number string, processId string, browserCookie string, requestEndTime string, timers struct, threadId string, hostname string, sessionId string) PARTITIONED BY (dt string) ROW FORMAT serde 'org.apache.hive.hcatalog.data.JsonSerDe' LOCATION 's3://elasticmapreduce/samples/hive-ads/tables/impressions/' ; ``` Esta tabla utiliza el serializador-deserializador JSON nativo de Hive para leer los datos JSON almacenados en Amazon S3. Para obtener más información acerca de los formatos admitidos, consulte [Elección de un valor de SerDe para los datos](supported-serdes.md). #### Ejecución de MSCK REPAIR TABLE Después de ejecutar la consulta `CREATE TABLE`, ejecute el comando `MSCK REPAIR TABLE` del editor de consultas de Athena para cargar las particiones, como en el siguiente ejemplo. ``` MSCK REPAIR TABLE impressions ``` Cuando ejecuta este comando, los datos están listos para consultarlos. #### Consulta de los datos Consulte los datos de la tabla de impresiones utilizando la columna de partición. A continuación se muestra un ejemplo: ``` SELECT dt,impressionid FROM impressions WHERE dt<'2009-04-12-14-00' and dt>='2009-04-12-13-00' ORDER BY dt DESC LIMIT 100 ``` La consulta deberá mostrar resultados similares a los siguientes: ``` 2009-04-12-13-20 ap3HcVKAWfXtgIPu6WpuUfAfL0DQEc 2009-04-12-13-20 17uchtodoS9kdeQP1x0XThKl5IuRsV 2009-04-12-13-20 JOUf1SCtRwviGw8sVcghqE5h0nkgtp 2009-04-12-13-20 NQ2XP0J0dvVbCXJ0pb4XvqJ5A4QxxH 2009-04-12-13-20 fFAItiBMsgqro9kRdIwbeX60SROaxr 2009-04-12-13-20 V4og4R9W6G3QjHHwF7gI1cSqig5D1G 2009-04-12-13-20 hPEPtBwk45msmwWTxPVVo1kVu4v11b 2009-04-12-13-20 v0SkfxegheD90gp31UCr6FplnKpx6i 2009-04-12-13-20 1iD9odVgOIi4QWkwHMcOhmwTkWDKfj 2009-04-12-13-20 b31tJiIA25CK8eDHQrHnbcknfSndUk ``` ### Escenario 2: Los datos no están particionados en formato Hive En el siguiente ejemplo, el comando `aws s3 ls` muestra registros de [ELB](elasticloadbalancer-classic-logs.md) almacenados en Amazon S3. Tenga en cuenta que el diseño de datos no utiliza pares `key=value` y, por lo tanto, no está en formato Hive. (La opción `--recursive` para el comando `aws s3 ls` especifica que se enumeran todos los objetos o archivos del directorio especificado o con el prefijo indicado). ``` aws s3 ls s3://athena-examples-myregion/elb/plaintext/ --recursive 2016-11-23 17:54:46 11789573 elb/plaintext/2015/01/01/part-r-00000-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 8776899 elb/plaintext/2015/01/01/part-r-00001-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 9309800 elb/plaintext/2015/01/01/part-r-00002-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 9412570 elb/plaintext/2015/01/01/part-r-00003-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 10725938 elb/plaintext/2015/01/01/part-r-00004-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:46 9439710 elb/plaintext/2015/01/01/part-r-00005-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 0 elb/plaintext/2015/01/01_$folder$ 2016-11-23 17:54:47 9012723 elb/plaintext/2015/01/02/part-r-00006-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 7571816 elb/plaintext/2015/01/02/part-r-00007-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:47 9673393 elb/plaintext/2015/01/02/part-r-00008-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 11979218 elb/plaintext/2015/01/02/part-r-00009-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 9546833 elb/plaintext/2015/01/02/part-r-00010-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 10960865 elb/plaintext/2015/01/02/part-r-00011-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 0 elb/plaintext/2015/01/02_$folder$ 2016-11-23 17:54:48 11360522 elb/plaintext/2015/01/03/part-r-00012-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 11211291 elb/plaintext/2015/01/03/part-r-00013-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:48 8633768 elb/plaintext/2015/01/03/part-r-00014-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 11891626 elb/plaintext/2015/01/03/part-r-00015-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 9173813 elb/plaintext/2015/01/03/part-r-00016-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 11899582 elb/plaintext/2015/01/03/part-r-00017-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:49 0 elb/plaintext/2015/01/03_$folder$ 2016-11-23 17:54:50 8612843 elb/plaintext/2015/01/04/part-r-00018-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 10731284 elb/plaintext/2015/01/04/part-r-00019-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 9984735 elb/plaintext/2015/01/04/part-r-00020-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 9290089 elb/plaintext/2015/01/04/part-r-00021-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:50 7896339 elb/plaintext/2015/01/04/part-r-00022-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8321364 elb/plaintext/2015/01/04/part-r-00023-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 0 elb/plaintext/2015/01/04_$folder$ 2016-11-23 17:54:51 7641062 elb/plaintext/2015/01/05/part-r-00024-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 10253377 elb/plaintext/2015/01/05/part-r-00025-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8502765 elb/plaintext/2015/01/05/part-r-00026-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 11518464 elb/plaintext/2015/01/05/part-r-00027-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 7945189 elb/plaintext/2015/01/05/part-r-00028-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 7864475 elb/plaintext/2015/01/05/part-r-00029-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 0 elb/plaintext/2015/01/05_$folder$ 2016-11-23 17:54:51 11342140 elb/plaintext/2015/01/06/part-r-00030-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:51 8063755 elb/plaintext/2015/01/06/part-r-00031-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9387508 elb/plaintext/2015/01/06/part-r-00032-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9732343 elb/plaintext/2015/01/06/part-r-00033-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 11510326 elb/plaintext/2015/01/06/part-r-00034-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 9148117 elb/plaintext/2015/01/06/part-r-00035-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 0 elb/plaintext/2015/01/06_$folder$ 2016-11-23 17:54:52 8402024 elb/plaintext/2015/01/07/part-r-00036-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 8282860 elb/plaintext/2015/01/07/part-r-00037-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:52 11575283 elb/plaintext/2015/01/07/part-r-00038-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 8149059 elb/plaintext/2015/01/07/part-r-00039-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 10037269 elb/plaintext/2015/01/07/part-r-00040-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 10019678 elb/plaintext/2015/01/07/part-r-00041-ce65fca5-d6c6-40e6-b1f9-190cc4f93814.txt 2016-11-23 17:54:53 0 elb/plaintext/2015/01/07_$folder$ 2016-11-23 17:54:53 0 elb/plaintext/2015/01_$folder$ 2016-11-23 17:54:53 0 elb/plaintext/2015_$folder$ ``` #### Ejecución de ALTER TABLE ADD PARTITION Dado que los datos no están en formato Hive, no se puede utilizar el comando `MSCK REPAIR TABLE` para agregar las particiones a la tabla después de crearla. Como alternativa, puede usar el comando [ALTER TABLE ADD PARTITION](alter-table-add-partition.md) para agregar cada partición manualmente. Por ejemplo, para cargar los datos en s3://athena-examples-*myregion*/elb/plaintext/2015/01/01/, puede ejecutar la siguiente consulta. Tenga en cuenta que no se requiere una columna de partición independiente para cada carpeta de Amazon S3 y que el valor de la clave de partición puede ser diferente de la clave de Amazon S3. ``` ALTER TABLE elb_logs_raw_native_part ADD PARTITION (dt='2015-01-01') location 's3://athena-examples-us-west-1/elb/plaintext/2015/01/01/' ``` Si ya existe una partición, recibirá el error La partición ya existe. Para evitar este error, puede usar la cláusula `IF NOT EXISTS`. Para obtener más información, consulte [ALTER TABLE ADD PARTITION](alter-table-add-partition.md). Para eliminar una partición, puede utilizar [ALTER TABLE DROP PARTITION](alter-table-drop-partition.md). ## Consideración de la proyección de particiones Para evitar tener que administrar particiones por cuenta propia, puede usar la proyección de particiones. La proyección de particiones es una opción para tablas divididas en muchas partes cuya estructura se conoce de antemano. En la proyección de particiones, los valores de partición y las ubicaciones se calculan a partir de las propiedades de tabla que configure, en lugar de leerlos desde un repositorio de metadatos. Dado que los cálculos hechos en la memoria son más rápidos que la búsqueda remota, el uso de la proyección de particiones puede reducir significativamente los tiempos de ejecución de las consultas. Para obtener más información, consulte [Uso de proyección de particiones con Amazon Athena](partition-projection.md). ## Recursos adicionales + Para obtener información sobre las opciones de partición de datos de Firehose, consulte [Ejemplo de Amazon Data Firehose](partition-projection-kinesis-firehose-example.md). + También puede automatizar la adición de particiones con el [controlador JDBC](connect-with-jdbc.md). + Puede utilizar CTAS e INSERT INTO para particionar un conjunto de datos. Para obtener más información, consulte [Uso de CTAS e INSERT INTO en ETL y análisis de datos](ctas-insert-into-etl.md). # Uso de proyección de particiones con Amazon Athena Puede utilizar la proyección de particiones en Athena para acelerar el procesamiento de consultas de tablas altamente particionadas y automatizar la administración de particiones. En la proyección de particiones, Athena calcula los valores de partición y las ubicaciones utilizando las propiedades de tabla que configure directamente en la tabla de AWS Glue. Las propiedades de la tabla permiten a Athena “proyectar” o determinar la información de partición necesaria en lugar de tener que realizar una búsqueda de metadatos en el AWS Glue Data Catalog que consume más tiempo. Dado que las operaciones en memoria suelen ser más rápidas que las operaciones remotas, la proyección de particiones puede reducir el tiempo de ejecución de las consultas en tablas altamente particionadas. Dependiendo de las características específicas de la consulta y los datos subyacentes, la proyección de particiones puede reducir significativamente el tiempo de ejecución de la consulta para las consultas que están restringidas en la recuperación de metadatos de partición. ## Información de la eliminación de particiones frente a la proyección de particiones La poda de partición recopila metadatos y los “poda” solo en las particiones que se aplican a su consulta. Por lo general, esto acelera las consultas. Athena utiliza la poda de particiones para todas las tablas con columnas de partición, incluidas las tablas configuradas para la proyección de particiones. Normalmente, al procesar consultas, Athena realiza una llamada `GetPartitions` al AWS Glue Data Catalog antes de realizar la poda de partición. Si una tabla tiene un gran número de particiones, el uso de `GetPartitions` puede afectar negativamente el rendimiento. Para evitar esto, puede usar la proyección de particiones. La proyección de particiones permite a Athena evitar llamadas a `GetPartitions` porque la configuración de proyección de particiones proporciona a Athena toda la información necesaria para construir las particiones en sí. ## Procedimientos para usar la proyección de particiones Para utilizar la proyección de particiones, especifique los intervalos de valores de partición y tipos de proyección para cada columna de partición en las propiedades de tabla en el AWS Glue Data Catalog o en el [metaalmacén externo de Hive](connect-to-data-source-hive.md). Estas propiedades personalizadas en la tabla le permiten a Athena saber qué patrones de partición esperar cuando ejecuta una consulta en la tabla. Durante la ejecución de la consulta, Athena utiliza esta información para proyectar los valores de partición en lugar de recuperarlos desde el metaalmacén externo de Hive o AWS Glue Data Catalog. Esto no solo reduce el tiempo de ejecución de la consulta, sino que también automatiza la administración de particiones, ya que elimina la necesidad de crear manualmente particiones en Athena, el metaalmacén externo de Hive o AWS Glue. **importante** Habilitar la proyección de particiones en una tabla hace que Athena ignore los metadatos de partición registrados en la tabla en el metaalmacén externo de Hive o AWS Glue Data Catalog. ## Algunos casos de uso Entre los escenarios en los que la proyección de particiones es útil se incluyen los siguientes: + Las consultas contra una tabla altamente particionada no se completan tan rápido como le gustaría. + Las particiones se agregan regularmente a las tablas a medida que se crean nuevas particiones de fecha u hora en los datos. Con la proyección de particiones, puede configurar intervalos de fechas relativos que se pueden utilizar a medida que llegan nuevos datos. + Tiene datos altamente particionados en Amazon S3. Los datos no son prácticos para modelar en su metaalmacén AWS Glue Data Catalog o Hive, y sus consultas solo leen pequeñas partes de ellos. ### Estructuras de partición proyectables La proyección de particiones se configura más fácilmente cuando las particiones siguen un patrón predecible como, entre otros, los siguientes: + **Enteros**: cualquier secuencia continua de enteros como `[1, 2, 3, 4, ..., 1000]` o `[0500, 0550, 0600, ..., 2500]`. + **Fechas**: cualquier secuencia continua de fechas o fechas y horas como `[20200101, 20200102, ..., 20201231]` o `[1-1-2020 00:00:00, 1-1-2020 01:00:00, ..., 12-31-2020 23:00:00]`. + **Valores enumerados**: un conjunto finito de valores enumerados como códigos de aeropuertos o Regiones de AWS. + **Registros de Servicio de AWS**: normalmente, los registros de Servicio de AWS tienen una estructura conocida cuyo esquema de particiones puede especificar en AWS Glue y que, por lo tanto, Athena puede utilizar para la proyección de particiones. ### Procedimientos para personalizar la plantilla de ruta de partición De forma predeterminada, Athena crea ubicaciones de partición utilizando el formulario `s3://amzn-s3-demo-bucket//partition-col-1=/partition-col-2=/`, pero si sus datos están organizados de manera diferente, Athena ofrece un mecanismo para personalizar esta plantilla de ruta. Para ver los pasos, consulte [Procedimientos para especificar ubicaciones de almacenamiento de S3 personalizadas](partition-projection-setting-up.md#partition-projection-specifying-custom-s3-storage-locations). ## Consideraciones y limitaciones Tenga en cuenta las siguientes consideraciones: + La proyección de particiones elimina la necesidad de especificar particiones manualmente en AWS Glue o en un metaalmacén externo de Hive. + Cuando habilita la proyección de particiones en una tabla, Athena ignora los metadatos de partición en AWS Glue Data Catalog o el metaalmacén externo de Hive de esa tabla. + Si una partición proyectada no existe en Amazon S3, Athena seguirá proyectando la partición. Athena no arroja un error, pero no se devuelve ningún dato. Sin embargo, si hay demasiadas particiones vacías, el rendimiento puede ser más lento en comparación con las particiones de AWS Glue tradicionales. Si más de la mitad de las particiones proyectadas están vacías, se recomienda utilizar particiones tradicionales. + Las consultas de valores que están más allá de los límites de intervalos definidos para la proyección de particiones no devuelven ningún error. En su lugar, la consulta se ejecuta, pero devuelve cero filas. Por ejemplo, si tiene datos relacionados con el tiempo que comienzan en 2020 y se definen como `'projection.timestamp.range'='2020/01/01,NOW'`, una consulta como `SELECT * FROM table-name WHERE timestamp = '2019/02/02'` se completará correctamente, pero devolverá cero filas. + La proyección de particiones solo se puede utilizar cuando se consulta la tabla a través de Athena. Si se lee la misma tabla a través de otro servicio, como Amazon Redshift Spectrum, Athena para Spark o Amazon EMR, se utilizan los metadatos de partición estándar. + Dado que la proyección de particiones es una característica de solo DML, `SHOW PARTITIONS` no enumera las particiones proyectadas por Athena pero no registradas en el catálogo de AWS Glue o en el metaalmacén externo de Hive. + Athena no utiliza las propiedades de tabla de vistas como configuración para la proyección de particiones. Para evitar esta limitación, configure y habilite la proyección de particiones en las propiedades de tabla para las tablas a las que hacen referencia las vistas. ## Video En el siguiente video se muestra cómo utilizar la proyección de particiones para mejorar el rendimiento de las consultas en Athena. [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/iUD5pPpcyZk/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/iUD5pPpcyZk) **Topics** + [Información de la eliminación de particiones frente a la proyección de particiones](#partition-projection-pruning-vs-projection) + [Procedimientos para usar la proyección de particiones](#partition-projection-using) + [Algunos casos de uso](#partition-projection-use-cases) + [Consideraciones y limitaciones](#partition-projection-considerations-and-limitations) + [Video](#partition-projection-video) + [Configuración de la proyección de particiones](partition-projection-setting-up.md) + [Tipos admitidos para la proyección de particiones](partition-projection-supported-types.md) + [Uso de partición de ID dinámica](partition-projection-dynamic-id-partitioning.md) + [Ejemplo de Amazon Data Firehose](partition-projection-kinesis-firehose-example.md) # Configuración de la proyección de particiones Configurar la proyección de particiones en las propiedades de una tabla es un proceso de dos pasos: 1. Especifique los intervalos de datos y los patrones relevantes para cada columna de partición, o utilice una plantilla personalizada. 1. Habilite la proyección de particiones para la tabla. **nota** Antes de agregar propiedades de proyección de particiones a una tabla existente, la columna de partición para la que va a configurar las propiedades de proyección de particiones ya debe existir en el esquema de la tabla. Si la columna de partición aún no existe, debe agregar una columna de partición a la tabla existente manualmente. AWS Glue no realiza este paso automáticamente. En esta sección se muestra cómo establecer estas propiedades de tabla para AWS Glue. Para configurarlas, puede utilizar la consola de AWS Glue, las consultas [CREATE TABLE](create-table.md) de Athena o las operaciones de [AWS Glue API](https://docs.aws.amazon.com/glue/latest/dg/aws-glue-api.html). El siguiente procedimiento muestra cómo establecer las propiedades en la consola de AWS Glue. **: cómo configurar y habilitar la proyección de particiones mediante la consola de AWS Glue** 1. Inicie sesión en la Consola de administración de AWS y abra la consola de AWS Glue en [https://console.aws.amazon.com/glue/](https://console.aws.amazon.com/glue/). 1. Seleccione la pestaña **Tablas**. En la pestaña **Tablas** puede editar tablas existentes o elegir **Agregar tablas** para crear otras nuevas. Para obtener información sobre cómo agregar tablas manualmente o con un rastreador, consulte [Trabajo con tablas en la consola de AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/console-tables.html) en la *Guía para desarrolladores de AWS Glue*. 1. En la lista de tablas, elija el vínculo de la tabla que desea editar. ![\[En la consola de AWS Glue, elija una tabla para editar.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/partition-projection-1.png) 1. Seleccione **Acciones**, **Editar la tabla**. 1. En la página **Editar la tabla**, en la sección **Propiedades de la tabla**, agregue el siguiente par de clave-valor en cada columna particionada: 1. En **Clave**, añada `projection.columnName.type`. 1. En **Valor**, añada uno de los tipos admitidos: `enum`, `integer`, `date`, o `injected`. Para obtener más información, consulte [Tipos admitidos para la proyección de particiones](partition-projection-supported-types.md). 1. Siguiendo las instrucciones de [Tipos admitidos para la proyección de particiones](partition-projection-supported-types.md), añada pares clave-valor adicionales de acuerdo con sus requisitos de configuración. La siguiente configuración de tabla de ejemplo configura la columna `year` para la proyección de particiones, lo que restringe los valores que se pueden devolver a un intervalo comprendido entre 2010 y 2016. ![\[Configuración de la proyección de particiones para una columna de partición en las propiedades de la tabla de la consola de AWS Glue.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/partition-projection-3.png) 1. Añada un par clave-valor para habilitar la proyección de particiones. En **Clave**, escriba `projection.enabled`, y en su **Valor**, escriba `true`. **nota** Puede deshabilitar la proyección de particiones en esta tabla en cualquier momento estableciendo `projection.enabled` como `false`. 1. Cuando termine de actualizar las etiquetas, elija **Guardar**. 1. En el Editor de consultas de Athena, pruebe la consulta de las columnas que configuró para la tabla. La siguiente consulta de ejemplo utiliza `SELECT DISTINCT` para devolver los valores únicos de la columna `year`. La base de datos contiene datos de 1987 a 2016, pero la propiedad `projection.year.range` restringe los valores devueltos a los años 2010 a 2016. ![\[Consultar una columna que utiliza la proyección de particiones.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/partition-projection-5.png) **nota** Si establece `projection.enabled` como `true` pero no puede configurar una o más columnas de partición, recibirá un mensaje de error como el siguiente: `HIVE_METASTORE_ERROR: Table database_name.table_name is configured for partition projection, but the following partition columns are missing projection configuration: [column_name] (table database_name.table_name)`. ## Procedimientos para especificar ubicaciones de almacenamiento de S3 personalizadas Al editar propiedades de tabla en AWS Glue, también puede especificar una plantilla de ruta de Amazon S3 personalizada para las particiones proyectadas. Una plantilla personalizada permite a Athena asignar correctamente valores de partición a ubicaciones de archivos de Amazon S3 personalizadas que no siguen un patrón `.../column=value/...` típico. El uso de una plantilla personalizada es opcional. Sin embargo, si utiliza una plantilla personalizada, la plantilla debe contener un marcador de posición para cada columna de partición. Las ubicaciones con plantilla deben terminar con una barra diagonal para que los archivos de datos particionados se alojen en una “carpeta” por partición. **Para especificar una plantilla de ubicación de partición personalizada** 1. Siguiendo los pasos para [configurar y habilitar la proyección de particiones mediante la consola de AWS Glue](#partition-projection-setting-up-procedure), agregue un par clave-valor adicional que especifique una plantilla personalizada de la siguiente manera: 1. En **Clave**, escriba `storage.location.template`. 1. En **Valor**, especifique una ubicación que incluya un marcador de posición para cada columna de partición. Asegúrese de que cada marcador de posición (y la ruta de S3 en sí) termine con una sola barra diagonal. En los siguientes valores de plantilla de ejemplo se asume una tabla con columnas de partición `a`, `b` y `c`. ``` s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/${c}/ ``` ``` s3://amzn-s3-demo-bucket/table_root/c=${c}/${b}/some_static_subdirectory/${a}/${b}/${c}/${c}/ ``` En la misma tabla, el siguiente valor de plantilla de ejemplo no es válido porque no contiene marcador de posición para la columna `c`. ``` s3://amzn-s3-demo-bucket/table_root/a=${a}/${b}/some_static_subdirectory/ ``` 1. Seleccione **Aplicar**. # Tipos admitidos para la proyección de particiones Una tabla puede tener cualquier combinación de tipos de columna de partición `enum`, `integer`, `date,` o `injected`. ## Tipo enum Utilice el tipo `enum` para las columnas de partición cuyos valores sean miembros de un conjunto enumerado (por ejemplo, códigos de aeropuerto o Regiones de AWS). Defina las propiedades de partición en la tabla de la siguiente manera: **** | Nombre de la propiedad | Valores de ejemplo | Descripción | | --- | --- | --- | | projection.columnName.type | `enum` | Obligatorio. El tipo de proyección que se va a utilizar en la columna columnName. El valor debe ser enum (sin distinción mayúsculas y minúsculas) para indicar el uso del tipo enum. Se permite un espacio en blanco inicial y final. | | projection.columnName.values | `A,B,C,D,E,F,G,Unknown` | Obligatorio. Lista separada por comas de los valores de partición enumerados para la columna columnName. Cualquier espacio en blanco se considera parte de un valor enum. | **nota** Como práctica recomendada, sugerimos limitar el uso de proyecciones de partición basadas en `enum` a unas pocas docenas o menos. Si bien no hay un límite específico para las proyecciones `enum`, el tamaño total de los metadatos de la tabla no puede superar el límite de AWS Glue de aproximadamente 1 MB cuando se comprime a gzip. Tenga en cuenta que este límite se comparte entre partes clave de la tabla, como nombres de columna, ubicación, formato de almacenamiento y otros. Si utiliza más de unas cuantas docenas de identificadores únicos en la proyección `enum`, considere un enfoque alternativo, como la asignación de buckets en un número menor de valores únicos en un campo sustituto. Al intercambiar cardinalidad, puede controlar el número de valores únicos en `enum`. ## Tipo entero Utilice el tipo entero para las columnas de partición cuyos valores posibles sean interpretables como enteros dentro de un intervalo definido. Las columnas enteras proyectadas se limitan actualmente al intervalo de un Java con signo largo (-263 a 263-1 inclusive). **** | Nombre de la propiedad | Valores de ejemplo | Descripción | | --- | --- | --- | | projection.columnName.type | `integer` | Obligatorio. El tipo de proyección que se va a utilizar en la columna columnName. El valor debe ser integer (sin distinción entre mayúsculas y minúsculas) para indicar el uso del tipo entero. Se permite un espacio en blanco inicial y final. | | projection.columnName.range | `0,10` `-1,8675309` `0001,9999` | Obligatorio. Lista separada por comas de dos elementos que proporciona los valores de intervalo mínimo y máximo que deben devolver las consultas de la columna columnName. Tenga en cuenta que los valores deben estar separados por una coma, no por un guion. Estos valores son inclusivos, pueden ser negativos y pueden tener ceros a la izquierda. Se permite un espacio en blanco inicial y final. | | projection.columnName.interval | `1` `5` | Opcional. Un entero positivo que especifica el intervalo entre los valores de partición sucesivos en la columna columnName. Por ejemplo, un valor range de “1,3” con un valor interval de “1” produce los valores 1, 2 y 3. El mismo valor range con un valor interval de “2” produce los valores 1 y 3, omitiendo 2. Se permite un espacio en blanco inicial y final. El valor predeterminado es 1. | | projection.columnName.digits | `1` `5` | Opcional. Un entero positivo que especifica el número de dígitos que se incluirán en la representación final del valor de partición de la columna columnName. Por ejemplo, un valor de range de “1,3” que tiene un valor de digits de “1” produce los valores 1, 2 y 3. El mismo valor de range con un valor de digits de “2” produce los valores 01, 02 y 03. Se permite un espacio en blanco inicial y final. Por defecto, no hay número estático de dígitos ni ceros a la izquierda. | ## Tipo de fecha Utilice el tipo de fecha para las columnas de partición cuyos valores se pueden interpretar como fechas (con horas opcionales) dentro de un rango definido. **importante** Las columnas de fecha proyectada se generan en hora universal coordinada (UTC) en el momento de ejecución de la consulta. **** | Nombre de la propiedad | Valores de ejemplo | Descripción | | --- | --- | --- | | projection.columnName.type | `date` | Obligatorio. El tipo de proyección que se va a utilizar en la columna columnName. El valor debe ser date (sin distinción entre mayúsculas y minúsculas) para indicar el uso del tipo de fecha. Se permite un espacio en blanco inicial y final. | | projection.columnName.range | `201701,201812` `01-01-2010,12-31-2018` `NOW-3YEARS,NOW` `201801,NOW+1MONTH` | Obligatorio. Lista separada por comas de dos elementos que proporciona los valores `range` mínimo y máximo de la columna *columnName*. Estos valores son inclusivos y pueden utilizar cualquier formato compatible con los tipos de fechas `java.time.*` de Java. Tanto los valores mínimo como máximo deben utilizar el mismo formato. El formato especificado en la propiedad `.format` debe ser el formato utilizado para estos valores. Esta columna también puede contener cadenas de fecha relativas, con el formato de este patrón de expresión regular: `\s*NOW\s*(([\+\-])\s*([0-9]+)\s*(YEARS?\|MONTHS?\|WEEKS?\|DAYS?\|HOURS?\|MINUTES?\|SECONDS?)\s*)?` Se permiten espacios en blanco, pero los literales de fecha se consideran parte de las cadenas de fecha. | | projection.columnName.format | `yyyyMM` `dd-MM-yyyy` `dd-MM-yyyy-HH-mm-ss` | Obligatorio. Una cadena de formato de fecha basada en el formato de fecha Java [DateTimeFormatter](https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html). Puede ser cualquier tipo de Java.time.\$1 compatible. | | projection.columnName.interval | `1` `5` | Un entero positivo que especifica el intervalo entre los valores de partición sucesivos de la columna *columnName*. Por ejemplo, un valor de `range` de `2017-01,2018-12` con un valor de `interval` de `1` y un valor de `interval.unit` de `MONTHS` produce los valores 2017-01, 2017-02, 2017-03, etc. El mismo valor de `range` con un valor de `interval` de `2` y un valor de `interval.unit` de `MONTHS` produce los valores 2017-01, 2017-03, 2017-05, etc. Se permite un espacio en blanco inicial y final. Cuando las fechas proporcionadas tienen una precisión de un solo día o de un mes, la `interval` es opcional y el valor predeterminado es 1 día o 1 mes, respectivamente. De lo contrario, se requiere el `interval`. | | projection.columnName.interval.unit | `YEARS` `MONTHS` `WEEKS` `DAYS` `HOURS` `MINUTES` `SECONDS` `MILLIS` | Palabra de unidad de tiempo que representa la forma serializada de una [ChronoUnit](https://docs.oracle.com/javase/8/docs/api/java/time/temporal/ChronoUnit.html). Los valores posibles son `YEARS`, `MONTHS`, `WEEKS`, `DAYS`, `HOURS`, `MINUTES`, `SECONDS` o `MILLIS`. Los valores no distinguen entre mayúsculas y minúsculas. Cuando las fechas proporcionadas tienen una precisión de un solo día o de un mes, la `interval.unit` es opcional y el valor predeterminado es 1 día o 1 mes, respectivamente. De lo contrario, se requiere la `interval.unit`. | **Example – Partición por mes** La siguiente tabla de configuración de ejemplo divide los datos por mes desde 2015 hasta la actualidad. ``` 'projection.month.type'='date', 'projection.month.format'='yyyy-MM', 'projection.month.interval'='1', 'projection.month.interval.unit'='MONTHS', 'projection.month.range'='2015-01,NOW', ... ``` ## Tipo inyectado Utilice el tipo inyectado para columnas de partición con valores posibles que no se pueden generar procesalmente dentro de algún intervalo lógico pero que se proporcionan en una cláusula `WHERE` de la consulta como un solo valor. Es importante tener en cuenta los siguientes puntos: + Las consultas sobre columnas inyectadas fallan si no se proporciona una expresión de filtro para cada columna inyectada. + Las consultas con múltiples valores para una expresión de filtro en una columna inyectada solo funcionan si los valores están separados. + Solo se admiten las columnas de tipo `string`. + Cuando utiliza la cláusula `WHERE IN` con una columna de partición inyectada, hay un límite de 1000 valores que se pueden especificar en la lista `IN`. Para consultar un conjunto de datos con más de 1000 particiones para una columna inyectada, divida la consulta en múltiples consultas más pequeñas, cada una con hasta 1000 valores en la cláusula `WHERE IN`, y luego agregue los resultados. **** | Nombre de la propiedad | Valor | Descripción | | --- | --- | --- | | projection.columnName.type | `injected` | Obligatorio. El tipo de proyección que se va a utilizar en la columna columnName. Solo se admite el tipo string. El valor especificado debe ser injected (sin distinción entre mayúsculas y minúsculas). Se permite un espacio en blanco inicial y final. | Para obtener más información, consulte [Cuándo usar el tipo de proyección de `injected`](partition-projection-dynamic-id-partitioning.md#partition-projection-injection). # Uso de partición de ID dinámica Si los datos están divididos por una propiedad con cardinalidad alta o cuando los valores no se pueden conocer de antemano, puede utilizar el tipo de proyección `injected`. Algunos ejemplos de estas propiedades son los nombres de usuario y los ID de dispositivos o productos. Cuando se utiliza el tipo de proyección `injected` para configurar una clave de partición, Athena utiliza los valores de la propia consulta para calcular el conjunto de particiones que se leerán. Para que Athena pueda ejecutar una consulta en una tabla que tenga una clave de partición configurada con el tipo de proyección `injected`, debe cumplirse lo siguiente: + La consulta debe incluir al menos un valor para la clave de partición. + Los valores deben ser literales o expresiones que se puedan evaluar sin leer ningún dato. Si no se cumple alguno de estos criterios, la consulta fallará y mostrará el siguiente error: CONSTRAINT\$1VIOLATION: En el caso de la columna de partición proyectada inyectada *column\$1name*, la cláusula WHERE debe contener únicamente condiciones de igualdad estáticas, y al menos una de estas condiciones debe estar presente. ## Cuándo usar el tipo de proyección de `injected` Imagine que tiene un conjunto de datos que consta de eventos de dispositivos de IoT, particionados en los ID de los dispositivos. Este conjunto de datos incluye las siguientes características: + Los ID de los dispositivos se generan de forma aleatoria. + Los dispositivos nuevos se aprovisionan con frecuencia. + Actualmente, hay cientos de miles de dispositivos y en el futuro habrá millones. Este conjunto de datos es difícil de administrar con los metaalmacenes tradicionales. Es difícil mantener las particiones sincronizadas entre el almacenamiento de datos y el metaalmacén, y el filtrado de las particiones puede resultar ser lento durante la planificación de las consultas. Sin embargo, si configura una tabla para usar la proyección de particiones y usa el tipo de proyección `injected`, tiene dos ventajas: no tiene que administrar las particiones en el metaalmacén y sus consultas no tienen que buscar los metadatos de las particiones. En el siguiente ejemplo de `CREATE TABLE`, se crea una tabla para el conjunto de datos de eventos del dispositivo que se acaba de describir. La tabla utiliza el tipo de proyección inyectada. ``` CREATE EXTERNAL TABLE device_events ( event_time TIMESTAMP, data STRING, battery_level INT ) PARTITIONED BY ( device_id STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.device_id.type" = "injected", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${device_id}" ) ``` La siguiente consulta de ejemplo busca el número de eventos recibidos de tres dispositivos específicos en el transcurso de 12 horas. ``` SELECT device_id, COUNT(*) AS events FROM device_events WHERE device_id IN ( '4a770164-0392-4a41-8565-40ed8cec737e', 'f71d12cf-f01f-4877-875d-128c23cbde17', '763421d8-b005-47c3-ba32-cc747ab32f9a' ) AND event_time BETWEEN TIMESTAMP '2023-11-01 20:00' AND TIMESTAMP '2023-11-02 08:00' GROUP BY device_id ``` Al ejecutar esta consulta, Athena ve los tres valores de la clave de partición `device_id` y los usa para calcular las ubicaciones de las particiones. Athena utiliza el valor de la propiedad `storage.location.template` para generar las siguientes ubicaciones: + `s3://amzn-s3-demo-bucket/prefix/4a770164-0392-4a41-8565-40ed8cec737e` + `s3://amzn-s3-demo-bucket/prefix/f71d12cf-f01f-4877-875d-128c23cbde17` + `s3://amzn-s3-demo-bucket/prefix/763421d8-b005-47c3-ba32-cc747ab32f9a` Si omite la propiedad `storage.location.template` en la configuración de proyección de la partición, Athena utiliza la partición tipo Hive para proyectar las ubicaciones de las particiones en función del valor de `LOCATION` (por ejemplo, `s3://amzn-s3-demo-bucket/prefix/device_id=4a770164-0392-4a41-8565-40ed8cec737e`). # Ejemplo de Amazon Data Firehose Cuando se usa Firehose para entregar datos a Amazon S3, la configuración predeterminada escribe objetos con claves que se parecen al siguiente ejemplo: ``` s3://amzn-s3-demo-bucket/prefix/yyyy/MM/dd/HH/file.extension ``` Para crear una tabla de Athena que encuentre las particiones de forma automática en el momento de la consulta, en lugar de tener que agregarlas al catálogo de datos de AWS Glue Data Catalog a medida que llegan nuevos datos, puede usar la proyección de particiones. En el siguiente ejemplo de `CREATE TABLE` se usa la configuración predeterminada de Firehose. ``` CREATE EXTERNAL TABLE my_ingested_data ( ... ) ... PARTITIONED BY ( datehour STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.datehour.type" = "date", "projection.datehour.format" = "yyyy/MM/dd/HH", "projection.datehour.range" = "2021/01/01/00,NOW", "projection.datehour.interval" = "1", "projection.datehour.interval.unit" = "HOURS", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${datehour}/" ) ``` La cláusula `TBLPROPERTIES` de la instrucción `CREATE TABLE` indica a Athena lo siguiente: + Usar la proyección de la partición al consultar la tabla + La clave de partición `datehour` es de tipo `date` (que incluye una hora opcional) + Cómo se formatean las fechas + El rango de fechas y horas. Tenga en cuenta que los valores deben estar separados por una coma, no por un guion. + Dónde encontrar los datos en Amazon S3. Al consultar la tabla, Athena calcula los valores de `datehour` y usa la plantilla de ubicación de almacenamiento para generar una lista de ubicaciones de partición. **Topics** + [Cómo usar el tipo `date`](partition-projection-kinesis-firehose-example-using-the-date-type.md) + [Cómo elegir las claves de partición](partition-projection-kinesis-firehose-example-choosing-partition-keys.md) + [Cómo utilizar los prefijos personalizados y las particiones dinámicas](partition-projection-kinesis-firehose-example-using-custom-prefixes-and-dynamic-partitioning.md) # Cómo usar el tipo `date` Cuando se usa el tipo `date` para una clave de partición proyectada, se debe especificar un rango. Como no tiene datos para fechas anteriores a la creación del flujo de entrega de Firehose, puede usar la fecha de creación como inicio. Y como no tiene datos para fechas en el futuro, puede usar el token especial `NOW` como fin. En el ejemplo de `CREATE TABLE`, la fecha de inicio se especifica como 1 de enero de 2021 a medianoche UTC. **nota** Configure un rango que se ajuste lo más posible a sus datos para que Athena busque solo las particiones existentes. Cuando se ejecuta una consulta en la tabla de ejemplo, Athena usa las condiciones de la clave de partición `datehour` en combinación con el rango para generar valores. Analice la siguiente consulta: ``` SELECT * FROM my_ingested_data WHERE datehour >= '2020/12/15/00' AND datehour < '2021/02/03/15' ``` La primera condición de la consulta `SELECT` usa una fecha que es anterior al inicio del rango de fechas especificado por la instrucción `CREATE TABLE`. Como la configuración de la proyección de la partición especifica que no hay particiones para las fechas anteriores al 1 de enero de 2021, Athena busca datos solo en las siguientes ubicaciones, e ignora las fechas anteriores a la consulta. ``` s3://amzn-s3-demo-bucket/prefix/2021/01/01/00/ s3://amzn-s3-demo-bucket/prefix/2021/01/01/01/ s3://amzn-s3-demo-bucket/prefix/2021/01/01/02/ ... s3://amzn-s3-demo-bucket/prefix/2021/02/03/12/ s3://amzn-s3-demo-bucket/prefix/2021/02/03/13/ s3://amzn-s3-demo-bucket/prefix/2021/02/03/14/ ``` Del mismo modo, si la consulta se ejecuta en una fecha y hora anteriores al 3 de febrero de 2021 a las 15:00 h, la última partición reflejaría la fecha y hora actuales, no la fecha y hora de la condición de consulta. Si quiere consultar los datos más recientes, puede aprovechar el hecho de que Athena no genera fechas futuras y especificar solo una `datehour` de inicio, como en el siguiente ejemplo. ``` SELECT * FROM my_ingested_data WHERE datehour >= '2021/11/09/00' ``` # Cómo elegir las claves de partición Puede especificar cómo la proyección de particiones asigna las ubicaciones de las particiones a las claves de partición. En el ejemplo de `CREATE TABLE` de la sección anterior, la fecha y la hora se han combinado en una clave de partición denominada datehour, pero se pueden usar otros esquemas. Por ejemplo, también podría configurar una tabla con claves de partición separadas para el año, el mes, el día y la hora. No obstante, si se dividen las fechas en año, mes y día no se puede utilizar el tipo de proyección de particiones `date`. Una alternativa es separar la fecha de la hora para seguir aprovechando el tipo de proyección de particiones `date`, pero realizar consultas que especifiquen intervalos de horas más fáciles de leer. Con esto en mente, el siguiente ejemplo `CREATE TABLE` separa la fecha de la hora. Debido a que `date` es una palabra reservada en SQL, en el ejemplo se utiliza `day` como nombre para la clave de partición que representa la fecha. ``` CREATE EXTERNAL TABLE my_ingested_data2 ( ... ) ... PARTITIONED BY ( day STRING, hour INT ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.format" = "yyyy/MM/dd", "projection.day.range" = "2021/01/01,NOW", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "projection.hour.type" = "integer", "projection.hour.range" = "0,23", "projection.hour.digits" = "2", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${hour}/" ) ``` En la instrucción `CREATE TABLE` del ejemplo, la hora es una clave de partición independiente, configurada como un número entero. La configuración de la clave de partición de la hora especifica el rango de 0 a 23, y que la hora debe formatearse con dos dígitos cuando Athena genera las ubicaciones de la partición. Una consulta para la tabla `my_ingested_data2` podría verse así: ``` SELECT * FROM my_ingested_data2 WHERE day = '2021/11/09' AND hour > 3 ``` ## Descripción de los tipos de datos de claves de particiones y proyección de particiones Tenga en cuenta que la clave `datehour` en el primer ejemplo `CREATE TABLE` está configurada como `date` en la configuración de la proyección de particiones, pero el tipo de la clave de partición es `string`. Lo mismo ocurre con `day` en el segundo ejemplo. Los tipos de configuración de proyección de particiones solo le dicen a Athena cómo formatear los valores cuando genera las ubicaciones de las particiones. Los tipos que se especifican no cambian el tipo de la clave de partición: en las consultas, `datehour` y `day` son de tipo `string`. Cuando una consulta incluye una condición como `day = '2021/11/09'`, Athena analiza la cadena a la derecha de la expresión con el formato de fecha especificado en la configuración de la proyección de particiones. Después de que Athena verifique que la fecha está dentro del rango configurado, usa de nuevo el formato de fecha para insertar la fecha como una cadena en la plantilla del almacén. De forma similar, para una condición de consulta como `day > '2021/11/09'`, Athena analiza el lado derecho y genera una lista de todas las fechas coincidentes dentro del rango configurado. A continuación, usa el formato de fecha para insertar cada fecha en la plantilla de ubicación de almacenamiento para crear la lista de ubicaciones de partición. Escribir la misma condición como día `day > '2021-11-09'` o día `day > DATE '2021-11-09'` no funciona. En el primer caso, el formato de la fecha no coincide (observe los guiones en lugar de las barras inclinadas), y en el segundo caso, los tipos de datos no coinciden. # Cómo utilizar los prefijos personalizados y las particiones dinámicas Firehose puede configurarse con [prefijos personalizados](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html) y [partición dinámica](https://docs.aws.amazon.com/firehose/latest/dev/dynamic-partitioning.html). Mediante estas características, puede configurar las claves de Amazon S3 y establecer esquemas de partición más compatibles con su caso de uso. También puede usar la proyección de particiones con estos esquemas de partición y configurarlos en consecuencia. Por ejemplo, puede usar la característica de prefijo personalizado para obtener claves de Amazon S3 que tengan fechas con formato ISO en lugar del esquema predeterminado `yyyy/MM/dd/HH`. También puede combinar los prefijos personalizados con el particionamiento dinámico para extraer una propiedad como `customer_id` de los mensajes de Firehose, como en el siguiente ejemplo. ``` prefix/!{timestamp:yyyy}-!{timestamp:MM}-!{timestamp:dd}/!{partitionKeyFromQuery:customer_id}/ ``` Con ese prefijo de Amazon S3, el flujo de entrega de Firehose escribiría objetos en claves como `s3://amzn-s3-demo-bucket/prefix/2021-11-01/customer-1234/file.extension`. Para una propiedad como `customer_id`, cuyos valores pueden no conocerse de antemano, se puede usar el tipo de proyección de particiones `injected` y usar una instrucción `CREATE TABLE` como la siguiente: ``` CREATE EXTERNAL TABLE my_ingested_data3 ( ... ) ... PARTITIONED BY ( day STRING, customer_id STRING ) LOCATION "s3://amzn-s3-demo-bucket/prefix/" TBLPROPERTIES ( "projection.enabled" = "true", "projection.day.type" = "date", "projection.day.format" = "yyyy-MM-dd", "projection.day.range" = "2021-01-01,NOW", "projection.day.interval" = "1", "projection.day.interval.unit" = "DAYS", "projection.customer_id.type" = "injected", "storage.location.template" = "s3://amzn-s3-demo-bucket/prefix/${day}/${customer_id}/" ) ``` Cuando se consulta una tabla que tiene una clave de partición de tipo `injected`, la consulta debe incluir un valor para esa clave de partición. Una consulta para la tabla `my_ingested_data3` podría verse así: ``` SELECT * FROM my_ingested_data3 WHERE day BETWEEN '2021-11-01' AND '2021-11-30' AND customer_id = 'customer-1234' ``` ## Uso del tipo DATE para la clave de partición diaria Ya que los valores de la clave de partición `day` tienen formato ISO, también puede usar el tipo `DATE` para la clave de partición del día en lugar de `STRING`, como en el siguiente ejemplo: ``` PARTITIONED BY (day DATE, customer_id STRING) ``` Cuando se consulta, esta estrategia permite usar las funciones de fecha en la clave de partición sin analizar ni iniciar, como en el siguiente ejemplo: ``` SELECT * FROM my_ingested_data3 WHERE day > CURRENT_DATE - INTERVAL '7' DAY AND customer_id = 'customer-1234' ``` **nota** Al especificar una clave de partición del tipo `DATE`, se supone que ha utilizado la característica de [prefijo personalizado](https://docs.aws.amazon.com/firehose/latest/dev/s3-prefixes.html) para crear claves de Amazon S3 con fechas con formato ISO. Si utiliza el formato predeterminado de Firehose de `yyyy/MM/dd/HH`, debe especificar la clave de partición como tipo `string` aunque la propiedad de la tabla correspondiente sea de tipo `date`, como en el siguiente ejemplo: ``` PARTITIONED BY ( `mydate` string) TBLPROPERTIES ( 'projection.enabled'='true', ... 'projection.mydate.type'='date', 'storage.location.template'='s3://amzn-s3-demo-bucket/prefix/${mydate}') ``` # Evitar la limitación de Amazon S3 La limitación es el proceso de limitar la velocidad a la que se utiliza un servicio, una aplicación o un sistema. En AWS, se puede utilizar la limitación para evitar el uso excesivo del servicio Amazon S3 y aumentar la disponibilidad y la capacidad de respuesta de Amazon S3 para todos los usuarios. Sin embargo, dado que la limitación limita la velocidad a la que se pueden transferir los datos hacia Amazon S3 o desde este, es importante considerar la posibilidad de evitar que se limiten las interacciones. Como se señaló en el capítulo sobre el [ajuste del rendimiento](performance-tuning.md), las optimizaciones pueden depender de las decisiones para cada servicio, de la forma en que se estructuran las tablas y los datos y de la forma en que se escriben las consultas. **Topics** + [Reduzca las limitaciones a nivel de servicio](performance-tuning-s3-throttling-reduce-throttling-at-the-service-level.md) + [Optimización de las tablas](performance-tuning-s3-throttling-optimizing-your-tables.md) + [Optimización de las consultas](performance-tuning-s3-throttling-optimizing-queries.md) # Reduzca las limitaciones a nivel de servicio Para evitar que Amazon S3 se limite a nivel de servicio, puede supervisar el uso y ajustar las [cuotas de servicio](https://docs.aws.amazon.com/general/latest/gr/s3.html#limits_s3), o bien utilizar determinadas técnicas, como las particiones. A continuación, se detallan algunas de las condiciones que pueden provocar la limitación: + **Superar los límites de solicitudes de la API de su cuenta**: Amazon S3 tiene límites de solicitudes de API predeterminados que se basan en el tipo de cuenta y el uso. Si supera el número máximo de solicitudes por segundo para un solo prefijo, es posible que sus solicitudes se limiten para evitar la sobrecarga del servicio Amazon S3. + **Partición insuficiente de los datos**: si no particiona correctamente los datos y transfiere una gran cantidad de datos, Amazon S3 puede limitar sus solicitudes. Para obtener más información sobre las particiones, consulte la sección [Utilice particiones](performance-tuning-s3-throttling-optimizing-your-tables.md#performance-tuning-s3-throttling-use-partitioning) mencionada en este documento. + **Gran cantidad de objetos pequeños**: si es posible, evite tener una gran cantidad de archivos pequeños. Amazon S3 tiene un límite de [5500 solicitudes GET](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html) por segundo por prefijo particionado y las consultas de Athena tienen este mismo límite. Si analiza millones de objetos pequeños en una sola consulta, Amazon S3 puede limitar la consulta. Para evitar un análisis excesivo, utilice ETL de AWS Glue para compactar periódicamente los archivos o particionar la tabla y agregar filtros de clave de partición. Para obtener más información, consulte los siguientes recursos. + [¿Cómo puedo configurar un trabajo de ETL en AWS Glue para generar archivos más grandes?](https://aws.amazon.com/premiumsupport/knowledge-center/glue-job-output-large-files/) (*AWS Centro de conocimientos de*) + [Lectura de archivos de entrada en grupos más grandes](https://docs.aws.amazon.com/glue/latest/dg/grouping-input-files.html) (*Guía para desarrolladores de AWS Glue*) # Optimización de las tablas Si tiene problemas de limitación, es importante que estructure los datos. Si bien Amazon S3 puede gestionar grandes cantidades de datos, a veces se produce una limitación debido a la forma en que están estructurados los datos. En las siguientes secciones se ofrecen algunas sugerencias sobre cómo estructurar los datos en Amazon S3 para evitar problemas de limitación. ## Utilice particiones Puede utilizar las particiones para reducir la limitación al limitar la cantidad de datos a los que se puede acceder en cualquier momento. Al dividir los datos en columnas específicas, puede distribuir las solicitudes de manera uniforme entre varios objetos y reducir el número de solicitudes de un solo objeto. Al reducir la cantidad de datos que se deben analizar, el rendimiento de las consultas mejora y los costos se reducen. Al crear una tabla, puede definir particiones, que actúan como columnas virtuales. Para crear una tabla con particiones en una instrucción `CREATE TABLE`, utilice la cláusula `PARTITIONED BY (column_name data_type)` a fin de definir las claves para dividir los datos. Para restringir las particiones analizadas en una consulta, puede especificarlas como predicados en una cláusula `WHERE` de la consulta. De esta manera, las columnas que se utilizan con frecuencia como filtros son buenas candidatas para la creación de particiones. Una práctica común consiste en particionar los datos en función de intervalos de tiempo, lo que puede dar lugar a un esquema de particiones de varios niveles. Tenga en cuenta que la creación de particiones también tiene un costo. Al aumentar el número de particiones de la tabla, también aumenta el tiempo necesario para recuperar y procesar los metadatos de las particiones. Por lo tanto, la sobrepartición puede eliminar los beneficios que se obtienen al particionar con un mejor criterio. Si sus datos están muy sesgados hacia un valor de partición y la mayoría de las consultas utilizan ese valor, es posible que incurra en una sobrecarga adicional. Para obtener más información sobre la creación de particiones en Athena, consulte [¿Qué es la creación de particiones?](ctas-partitioning-and-bucketing-what-is-partitioning.md). ## Organice los datos en buckets Otra forma de particionar los datos consiste en organizarlos en buckets en una sola partición. Al organizar los datos en buckets, especifica una o más columnas que contienen las filas que desea agrupar. A continuación, pone esas filas en varios buckets. De esta forma, solo consulta el bucket que debe leerse, lo que reduce el número de filas de datos que deben analizarse. Al seleccionar una columna para utilizarla en los buckets, seleccione la columna que tenga una cardinalidad alta (es decir, que tenga muchos valores distintos), que esté distribuida de manera uniforme y que se utilice con frecuencia para filtrar los datos. Un ejemplo de una buena columna que se puede usar para organizar datos en buckets es una clave principal, como una columna de ID. Para obtener más información acerca de la asignación de buckets en Athena, consulte [¿Qué es la asignación de buckets?](ctas-partitioning-and-bucketing-what-is-bucketing.md). ## Utilice índices de particiones de AWS Glue Puede usar índices de partición de AWS Glue para organizar los datos de una tabla en función de los valores de una o más particiones. Los índices de partición de AWS Glue pueden reducir el número de transferencias de datos, la cantidad de procesamiento de datos y el tiempo de procesamiento de las consultas. Un índice de particiones de AWS Glue es un archivo de metadatos que contiene información sobre las particiones de la tabla, incluidas las claves de partición y sus valores. El índice de particiones se almacena en un bucket de Amazon S3 y AWS Glue lo actualiza automáticamente a medida que se agregan nuevas particiones a la tabla. Cuando un índice de particiones de AWS Glue está presente, las consultas pueden recuperar un subconjunto de las particiones en lugar de cargar todas las particiones de la tabla. Las consultas solo se ejecutan en el subconjunto de datos que es relevante para la consulta. Al crear una tabla en AWS Glue, puede crear un índice de particiones en cualquier combinación de claves de partición definidas en la tabla. Tras crear uno o más índices de partición en una tabla, debe agregar una propiedad a la tabla que permita el filtrado de particiones. A continuación, puede consultar la tabla desde Athena. Para obtener información acerca de cómo crear índices de particiones en AWS Glue, consulte [Trabajar con índices de partición en AWS Glue](https://docs.aws.amazon.com/glue/latest/dg/partition-indexes.html) en la *Guía para desarrolladores de AWS Glue*. Para obtener información sobre cómo agregar una propiedad de tabla para habilitar el filtrado de particiones, consulte [Optimización de las consultas con indexación y filtrado de particiones de AWS Glue](glue-best-practices-partition-index.md). ## Utilice la compresión de datos y la división de archivos La compresión de datos puede acelerar de forma significativa las consultas si los archivos tienen el tamaño óptimo o si se pueden dividir en grupos lógicos. Por lo general, las relaciones de compresión más altas requieren más ciclos de CPU para comprimir y descomprimir los datos. Para Athena, se recomienda utilizar Apache Parquet o Apache ORC, que comprimen los datos de forma predeterminada. Para obtener información sobre la compresión de datos en Athena, consulte [Uso de la compresión en Athena](compression-formats.md). La división de archivos aumenta el paralelismo al permitir que Athena distribuya la tarea de leer un solo archivo entre varios lectores. Si un único archivo no se puede dividir, solo un único lector puede leerlo mientras los demás lectores permanecen inactivos. Apache Parquet y Apache ORC también admiten la división de archivos. ## Utilice almacenes de datos en columnas optimizados El rendimiento de las consultas de Athena mejora de forma significativa si convierte los datos a un formato de columnas. Al generar archivos en columnas, una técnica de optimización a tener en cuenta es ordenar los datos en función de la clave de partición. Apache Parquet y Apache ORC son almacenes de datos en columnas de código abierto cuyo uso está generalizado. Para obtener información sobre cómo convertir un origen de datos de Amazon S3 existente a uno de estos formatos, consulte [Conversión a formatos de columnas](columnar-storage.md#convert-to-columnar). ### Utilice un tamaño de bloque de Parquet o de banda de ORC más grande Parquet y ORC tienen parámetros de almacenamiento de datos que puede ajustar para su optimización. En Parquet, puede optimizar el tamaño del bloque. En ORC, puede optimizar el tamaño de las bandas. Cuanto más grande sea el bloque o la banda, más filas podrá almacenar en cada uno. De forma predeterminada, el tamaño del bloque de Parquet es de 128 MB y el tamaño de la banda de ORC es de 64 MB. Si una banda de ORC ocupa menos de 8 MB (el valor predeterminado de `hive.orc.max_buffer_size`), Athena lee toda la banda de ORC. Esta es la compensación que Athena hace entre la selectividad de columnas y las operaciones de entrada/salida por segundo para bandas más pequeñas. Si tiene tablas con un gran número de columnas, un tamaño de bloque o banda pequeño puede provocar que se analicen más datos de los necesarios. En estos casos, un tamaño de bloque más grande puede ser más eficiente. ### Utilice ORC para tipos complejos Actualmente, cuando se consultan columnas almacenadas en Parquet con tipos de datos complejos (por ejemplo, `array`, `map` o `struct`), Athena lee toda una fila de datos, en lugar de leer solo de manera selectiva las columnas especificadas. Este es un problema conocido en Athena. Como solución, considere usar ORC. ### Elija un algoritmo de compresión Otro parámetro que puede configurar es el algoritmo de compresión de los bloques de datos. Para obtener información sobre los algoritmos de compresión compatibles con Parquet y ORC en Athena, consulte [Compatibilidad con la compresión de Athena](https://docs.aws.amazon.com/athena/latest/ug/compression-formats.html). Para obtener más información sobre la optimización de los formatos de almacenamiento en columnas en Athena, consulte la sección “Optimizar la generación de almacenes de datos en columnas” en la publicación del Blog de macrodatos de AWS [Top 10 Performance Tuning Tips for Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/) (Los 10 mejores consejos para ajustar el rendimiento de Amazon Athena). ## Utilice tablas de Iceberg Apache Iceberg es un formato de tabla de código abierto para conjuntos de datos analíticos de gran tamaño diseñado para el uso optimizado en Amazon S3. Puede usar tablas de Iceberg para ayudar a reducir las limitaciones en Amazon S3. Las tablas de Iceberg ofrecen las siguientes ventajas: + Puede dividir las tablas de Iceberg en una o más columnas. Esto optimiza el acceso a los datos y reduce la cantidad de datos que se deben analizar en las consultas. + Como el modo de almacenamiento de objetos de Iceberg optimiza las tablas de Iceberg para que funcionen con Amazon S3, puede procesar grandes volúmenes de datos y cargas de trabajo de consultas pesadas. + Las tablas de Iceberg en el modo de almacenamiento de objetos son escalables, tolerantes a errores y duraderas, lo que puede ayudar a reducir las limitaciones. + La compatibilidad con transacciones ACID significa que varios usuarios pueden agregar y eliminar objetos de Amazon S3 de forma atómica. Para obtener más información sobre Apache Iceberg, consulte [Apache Iceberg](https://iceberg.apache.org/). Para obtener información acerca del uso de tablas de Apache Iceberg en Athena, consulte [Utilización de tablas de Iceberg](https://docs.aws.amazon.com/athena/latest/ug/querying-iceberg.html). # Optimización de las consultas Utilice las sugerencias de esta sección para optimizar sus consultas SQL en Athena. ## Utilice LIMIT con la cláusula ORDER BY La cláusula `ORDER BY` devuelve los datos en un orden clasificado Esto requiere que Athena envíe todas las filas de datos a un único nodo de trabajo y luego las ordene. Este tipo de consulta puede ejecutarse durante mucho tiempo o, incluso, fallar. Para aumentar la eficacia de las consultas, observe los valores *N* en la parte superior o inferior y utilice también una cláusula `LIMIT`. Esto reduce de forma significativa el costo de la clasificación, ya que tanto la clasificación como la limitación recaen en nodos de trabajo individuales en lugar de en un solo trabajo. ## Optimice las cláusulas JOIN Al unir dos tablas, Athena distribuye la tabla de la derecha entre los nodos de trabajo y luego incluye la tabla de la izquierda para realizar la unión. Por este motivo, especifique la tabla más grande en el lado izquierdo de la unión y la tabla más pequeña en el lado derecho de la unión. De esta forma, Athena utiliza menos memoria y ejecuta la consulta con una latencia menor. También tenga en cuenta los siguientes puntos: + Cuando utilice varios comandos `JOIN`, especifique las tablas de mayor a menor. + Evite las uniones cruzadas a menos que la consulta las requiera. ## Optimice las cláusulas GROUP BY El operador `GROUP BY` distribuye las filas en función de las columnas `GROUP BY` a los nodos de trabajo. Se hace referencia a estas columnas en la memoria y los valores se comparan a medida que se ingieren las filas. Los valores se agregan cuando la columna `GROUP BY` coincide. Teniendo en cuenta la forma en que funciona este proceso, se recomienda ordenar las columnas desde la cardinalidad más alta hasta la más baja. ## Utilice números en lugar de cadenas Como los números requieren menos memoria y son más rápidos de procesar en comparación con las cadenas, utilice números en lugar de cadenas siempre que sea posible. ## Limite el número de columnas A fin de reducir la cantidad total de memoria necesaria para almacenar los datos, limite el número de columnas especificado en la instrucción `SELECT`. ## Utilice expresiones comunes en lugar de LIKE Las consultas que incluyen cláusulas como `LIKE '%string%'` en cadenas grandes pueden ser muy exigentes desde el punto de vista computacional. Al filtrar varios valores en una columna de cadena, utilice la función [regexp\$1like()](https://trino.io/docs/current/functions/regexp.html#regexp_like) y una expresión común en su lugar. Esto resulta muy útil cuando se compara una lista larga de valores. ## Utilice la cláusula LIMIT En lugar de seleccionar todas las columnas al ejecutar una consulta, utilice la cláusula `LIMIT` para devolver solo las columnas que necesite. Esto reduce el tamaño del conjunto de datos que se procesa a través de la canalización de ejecución de la consulta. Las cláusulas `LIMIT` son más útiles cuando se consultan tablas que tienen un gran número de columnas basadas en cadenas. Las cláusulas `LIMIT` también son útiles cuando se realizan múltiples uniones o agregaciones en cualquier consulta. # Recursos adicionales de Para obtener información adicional acerca del ajuste de rendimiento en Athena, tenga en cuenta los siguientes recursos: + Publicación en AWS Big Data Blog: [Top 10 performance tuning tips for Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/). + Publicación en AWS Big Data Blog: [Run queries 3x faster with up to 70% cost savings on the latest Amazon Athena engine](https://aws.amazon.com/blogs/big-data/run-queries-3x-faster-with-up-to-70-cost-savings-on-the-latest-amazon-athena-engine/) en *AWS Big Data Blog*. + Publicación en AWS Big Data Blog: [Improve federated queries with predicate pushdown in Amazon Athena](https://aws.amazon.com/blogs/big-data/improve-federated-queries-with-predicate-pushdown-in-amazon-athena/). + Guía del usuario de Amazon Simple Storage Service: [Prácticas recomendadas para patrones de diseño: optimizar el rendimiento de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance.html). + Otras [publicaciones sobre Athena en AWS Big Data Blog](https://aws.amazon.com/blogs/big-data/tag/amazon-athena/). + Haga una pregunta en [AWS re:Post](https://repost.aws/tags/TA78iVOM7gR62_QqDe2-CmiA/amazon-athena) con la etiqueta **Amazon Athena**. + Consulte los [temas sobre Athena en el Centro de conocimientos de AWS](https://aws.amazon.com/premiumsupport/knowledge-center/#Amazon_Athena). + Póngase en contacto con AWS Support (en la Consola de administración de AWS, haga clic en **Soporte**, **Centro de asistencia**. # Uso de la compresión en Athena Athena admite una variedad de formatos de compresión para leer y escribir datos, como la lectura de una tabla que utiliza varios formatos de compresión. Por ejemplo, Athena puede leer correctamente los datos de una tabla que utiliza el formato de archivo Parquet cuando algunos archivos Parquet se comprimen con Snappy y otros archivos Parquet se comprimen con GZIP. El mismo principio se aplica a los formatos de almacenamiento ORC, archivo de texto y JSON. ## Formatos de compresión compatibles Athena es compatible con los siguientes formatos de compresión: + **BZIP2**: formato que utiliza el algoritmo Burrows-Wheeler. + **DEFLATE**: algoritmo de compresión basado en [LZSS](https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Storer%E2%80%93Szymanski) y [codificación Huffman](https://en.wikipedia.org/wiki/Huffman_coding). [Deflate](https://en.wikipedia.org/wiki/Deflate) solo es relevante para el formato de archivo Avro. + **GZIP**: algoritmo de compresión basado en Deflate. Para las tablas de Hive en las versiones 2 y 3 del motor Athena y las tablas de Iceberg en la versión 2 del motor Athena, GZIP es el formato de compresión de escritura predeterminado para los archivos con formato de almacenamiento de archivo de texto y Parquet. Los archivos con el formato `tar.gz` no son compatibles. + **LZ4**: este miembro de la familia Lempel-Ziv 77 (LZ7) también se centra en la velocidad de compresión y descompresión en lugar de la máxima compresión de los datos. LZ4 tiene los siguientes formatos de encuadre: + **LZ4 Raw/Unframed** (LZ4 sin formato o sin encuadre): una implementación estándar y sin encuadre del formato de compresión de bloques LZ4. Para obtener más información, consulte [Descripción del formato de bloques LZ4](https://github.com/lz4/lz4/blob/dev/doc/lz4_Block_format.md) en GitHub. + **LZ4 framed** (LZ4 con encuadre): la implementación con el encuadre habitual de LZ4. Para obtener más información, consulte [Descripción del formato de encuadre LZ4](https://github.com/lz4/lz4/blob/dev/doc/lz4_Frame_format.md) en GitHub. + **LZ4 hadoop-compatible** (LZ4 compatible con Hadoop): la implementación con Apache Hadoop de LZ4. Esta implementación completa la compresión LZ4 con la clase [BlockCompressorStream.java](https://github.com/apache/hadoop/blob/f67237cbe7bc48a1b9088e990800b37529f1db2a/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/compress/BlockCompressorStream.java). + **LZO**: formato que utiliza el algoritmo Lempel–Ziv–Oberhumer, que se centra en la alta velocidad de compresión y descompresión en lugar de la compresión máxima de datos. LZO tiene dos implementaciones: + **LZO estándar**: para obtener más información, consulte el [resumen](http://www.oberhumer.com/opensource/lzo/#abstract) sobre LZO en el sitio web de Oberhumer. + **LZO hadoop-compatible** (LZO compatible con Hadoop): esta implementación completa el algoritmo de LZO con la clase [BlockCompressorStream.java](https://github.com/apache/hadoop/blob/f67237cbe7bc48a1b9088e990800b37529f1db2a/hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/io/compress/BlockCompressorStream.java). + **SNAPPY**: algoritmo de compresión que forma parte de la familia Lempel-Ziv 77 (LZ7). Snappy se centra en la alta velocidad de compresión y descompresión en lugar de la máxima compresión de datos. + **ZLIB**: basado en Deflate, ZLIB es el formato de compresión de escritura predeterminado para archivos con el formato de almacenamiento de datos ORC. Para obtener más información, consulte la página [zlib](https://github.com/madler/zlib) en GitHub. + **ZSTD**: el [algoritmo de compresión de datos en tiempo real Zstandard](http://facebook.github.io/zstd/) es un algoritmo de compresión rápida que proporciona ratios altas de compresión. La biblioteca Zstandard (ZSTD) se proporciona como software de código abierto mediante una licencia BSD. ZSTD es la compresión predeterminada para las tablas de Iceberg. Cuando se escriben datos comprimidos con ZSTD, Athena utiliza el nivel 3 de compresión Zstandard. Para obtener información sobre el uso de los niveles de compresión ZSTD en Athena, consulte [Uso de niveles de compresión de ZSTD](compression-support-zstd-levels.md). **nota** Athena no admite la escritura de archivos Parquet comprimidos con los formatos LZ4 o LZO. La lectura de estos formatos de compresión es compatible. ## Especificación de los formatos de compresión Al escribir instrucciones CREATE TABLE o CTAS, puede especificar las propiedades de compresión que especifican el tipo de compresión que se utilizará cuando Athena escriba en esas tablas. + Para CTAS, consulte [Propiedades de la tabla CTAS](create-table-as.md#ctas-table-properties). Para ver ejemplos, consulte [Ejemplos de consultas CTAS](ctas-examples.md). + Para obtener información sobre CREATE TABLE, consulte [ALTER TABLE SET TBLPROPERTIES](alter-table-set-tblproperties.md) para obtener una lista de las propiedades de la tabla de compresión. ## Especificación sin compresión Las declaraciones CREATE TABLE permiten escribir archivos sin comprimir. Para escribir archivos sin comprimir, utilice la siguiente sintaxis: + CREATE TABLE (archivo de texto o JSON): en `TBLPROPERTIES`, especifique `write.compression = NONE`. + CREATE TABLE (Parquet): en `TBLPROPERTIES`, especifique `parquet.compression = UNCOMPRESSED`. + CREATE TABLE (ORC): en `TBLPROPERTIES`, especifique `orc.compress = NONE`. ## Notas y recursos + Actualmente, Athena no reconoce las extensiones de archivo en mayúsculas, como `.GZ` o `.BZIP2`. Evite utilizar conjuntos de datos con extensiones de archivo en mayúsculas o cambie el nombre de las extensiones de archivo de datos a minúsculas. + Para datos en CSV, TSV y JSON, Athena determina el tipo de compresión a partir de la extensión de archivo. Si no hay ninguna extensión de archivo, Athena trata los datos como texto sin formato y sin comprimir. Si los datos están comprimidos, asegúrese de que el nombre de archivo incluye la extensión de compresión como, por ejemplo, `gz`. + No se admite el formato de archivo ZIP. + Para consultar registros de Amazon Data Firehose desde Athena, los formatos admitidos incluyen la compresión GZIP o archivos ORC con compresión SNAPPY. + Para obtener más información sobre el uso de la compresión, consulte la sección 3, (“Comprimir y dividir archivos”), de la publicación del Blog de macrodatos de AWS [Los 10 consejos más importantes sobre el ajuste de rendimiento de Amazon Athena](https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/). **Topics** + [Especificación de los formatos de compresión](#compression-support-specifying-compression-formats) + [Especificación sin compresión](#compression-support-specifying-no-compression) + [Notas y recursos](#compression-support-notes-and-resources) + [Compresión de tablas de Hive](compression-support-hive.md) + [Compresión de tablas de Iceberg](compression-support-iceberg.md) + [Niveles de compresión ZSTD](compression-support-zstd-levels.md) # Uso de compresión de tablas de Hive Las opciones de compresión de las tablas de Hive en Athena varían según la versión del motor y el formato de archivo. ## Compatibilidad de compresión para Hive en la versión 3 del motor Athena En la siguiente tabla se resume la compatibilidad con formatos de compresión de la versión 3 del motor Athena para los formatos de archivo de almacenamiento de Apache Hive. El formato de archivo de texto incluye TSV, CSV, JSON y SerDes personalizado para texto. Los términos “Yes” (Sí) o “No” de una celda se aplican por igual a las operaciones de lectura y escritura, excepto donde se indique lo contrario. A los efectos de esta tabla, CREATE TABLE, CTAS e INSERT INTO se consideran operaciones de escritura. Para obtener información sobre el uso de los niveles de compresión ZSTD en Athena, consulte [Uso de niveles de compresión de ZSTD](compression-support-zstd-levels.md). **** | | Avro | Ion | ORC | Parquet | Archivo de texto | | --- | --- | --- | --- | --- | --- | | BZIP2 | Sí | Sí | No | No | Sí | | DEFLATE | Sí | No | No | No | No | | GZIP | No | Sí | No | Sí | Sí | | LZ4 | No | Sí | Sí | Escritura: no Lectura: sí | Sí | | LZO | No | Escritura: no Lectura: sí | No | Escritura: no Lectura: sí | Escritura: no Lectura: sí | | SNAPPY | Sí | Sí | Sí | Sí | Sí | | ZLIB | No | No | Sí | No | No | | ZSTD | Sí | Sí | Sí | Sí | Sí | | NONE | Sí | Sí | Sí | Sí | Sí | # Uso de la compresión de tablas de Iceberg Las opciones de compresión de las tablas de Iceberg en Athena varían según la versión del motor y el formato de archivo. ## Compatibilidad de compresión para Iceberg en la versión 3 del motor Athena En la siguiente tabla se resume la compatibilidad con formatos de compresión de la versión 3 del motor Athena para los formatos de archivo de almacenamiento de Apache Iceberg. Los términos “Yes” (Sí) o “No” de una celda se aplican por igual a las operaciones de lectura y escritura, excepto donde se indique lo contrario. A los efectos de esta tabla, CREATE TABLE, CTAS e INSERT INTO se consideran operaciones de escritura. El formato de almacenamiento predeterminado para Iceberg en la versión 3 del motor de Athena es Parquet. El formato de compresión predeterminado para Iceberg en la versión 3 del motor de Athena es ZSTD. Para obtener información sobre el uso de los niveles de compresión ZSTD en Athena, consulte [Uso de niveles de compresión de ZSTD](compression-support-zstd-levels.md). **** | | Avro | ORC | Parquet (predeterminado) | | --- | --- | --- | --- | | BZIP2 | No | No | No | | GZIP | Sí | No | Sí | | LZ4 | No | Sí | No | | SNAPPY | Sí | Sí | Sí | | ZLIB | No | Sí | No | | ZSTD | Sí | Sí | Sí (predeterminado) | | NONE | Sí (especifique None o Deflate) | Sí | Sí (especifique None o Uncompressed) | # Uso de niveles de compresión de ZSTD El [algoritmo de compresión de datos en tiempo real Zstandard](http://facebook.github.io/zstd/) es un algoritmo de compresión rápida que proporciona relaciones de compresión elevadas. La biblioteca Zstandard (ZSTD) es software de código abierto y utiliza una licencia BSD. Athena es compatible con la lectura y la escritura de datos de archivos de texto, Parquet y ORC comprimidos con ZSTD. Puede utilizar los niveles de compresión ZSTD para ajustar la relación y velocidad de compresión de acuerdo con sus requisitos. La biblioteca ZSTD admite niveles de compresión comprendidos entre 1 y 22. Athena utiliza el nivel 3 de compresión ZSTD de manera predeterminada. Los niveles de compresión permiten conseguir un equilibrio preciso entre la velocidad de compresión y la cantidad de compresión lograda. Los niveles de compresión más bajos proporcionan más velocidad, pero también tamaños de archivo más mayores. Por ejemplo, se puede utilizar el nivel 1 si la velocidad es la prioridad, y el nivel 22 si el tamaño es lo más importante. El nivel 3 es adecuado para muchos casos de uso, y es el predeterminado. Utilice los niveles superiores a 19 con precaución, ya que requieren más memoria. La biblioteca ZSTD también ofrece niveles de compresión negativos que amplían el intervalo de velocidades y relaciones de compresión. Para obtener más información, consulte el [documento RFC sobre compresión Zstandard](https://datatracker.ietf.org/doc/html/rfc8478). La abundancia de niveles de compresión ofrece importantes posibilidades de realizar ajustes precisos. No obstante, asegúrese de medir los datos y tener en cuenta las ventajas y desventajas a la hora de decidir el nivel de compresión. Se recomienda utilizar el nivel predeterminado 3 o un nivel comprendido entre 6 y 9 para lograr un equilibrio razonable entre la velocidad de compresión y el tamaño de los datos comprimidos. Reserve los niveles de 20 y posteriores para aquellos casos en que el tamaño sea lo más importante y la velocidad de compresión no suponga un problema. ## Consideraciones y limitaciones Cuando utilice los niveles de compresión ZSTD en Athena, tenga en cuenta los siguientes puntos. + La propiedad `compression_level` de ZSTD solo es compatible con la versión 3 del motor Athena. + La propiedad `compression_level` de ZSTD es compatible con las instrucciones `ALTER TABLE`, `CREATE TABLE` y `CREATE TABLE AS` (CTAS), y `UNLOAD`. + La propiedad `compression_level` es opcional. + La propiedad `compression_level` solo es compatible con la compresión ZSTD. + Los niveles de compresión posibles están comprendidos entre 1 y 22. + El nivel de compresión predeterminado es 3. Para obtener información sobre la compatibilidad de compresión para Apache Hive ZSTD en Athena, consulte [Uso de compresión de tablas de Hive](compression-support-hive.md). Para obtener información sobre la compatibilidad de compresión para Apache Iceberg ZSTD en Athena, consulte [Uso de la compresión de tablas de Iceberg](compression-support-iceberg.md). ## Especificación de los niveles de compresión de ZSTD Para especificar el nivel de compresión ZSTD de las instrucciones `ALTER TABLE`, `CREATE TABLE`, `CREATE TABLE AS` y `UNLOAD`, utilice la propiedad `compression_level`. Para especificar la compresión ZSTD propiamente dicha, debe utilizar la propiedad de compresión individual que utilice la sintaxis de la instrucción. ### ALTER TABLE SET TBLPROPERTIES En la cláusula `SET TBLPROPERTIES` de la instrucción [ALTER TABLE SET TBLPROPERTIES](alter-table-set-tblproperties.md), especifique la compresión ZSTD mediante `'write.compression' = ' ZSTD'` o `'parquet.compression' = 'ZSTD'`. Después, utilice la propiedad `compression_level` para especificar un valor comprendido entre 1 y 22 (por ejemplo, '`compression_level' = '5'`). Si no especifica ninguna propiedad de nivel de compresión, el nivel de compresión se establece en 3 de manera predeterminada. #### Ejemplo En el siguiente ejemplo se modifica la tabla `existing_table` para que utilice el formato de archivo Parquet con compresión ZSTD y nivel 4 de compresión ZSTD. En la cláusula `TBLPROPERTIES`, el valor del nivel de compresión debe introducirse como una cadena y no como un entero y, por lo tanto, debe introducirse entre comillas simples o dobles. ``` ALTER TABLE existing_table SET TBLPROPERTIES ('parquet.compression' = 'ZSTD', 'compression_level' = '4') ``` ### CREATE TABLE En la cláusula `TBLPROPERTIES` de la instrucción [CREATE TABLE](create-table.md), especifique '`write.compression' = 'ZSTD'` o `'parquet.compression' = 'ZSTD'` y, a continuación, utilice `compression_level = compression_level` y especifique un valor comprendido entre 1 y 22 como una cadena. Si no se especifica la propiedad `compression_level`, el nivel de compresión predeterminado es 3. #### Ejemplo En el siguiente ejemplo se crea una tabla con formato de archivo Parquet mediante compresión ZSTD y el nivel 4 de compresión ZSTD. ``` CREATE EXTERNAL TABLE new_table ( `col0` string COMMENT '', `col1` string COMMENT '' ) STORED AS PARQUET LOCATION 's3://amzn-s3-demo-bucket/' TBLPROPERTIES ('write.compression' = 'ZSTD', 'compression_level' = '4') ``` ### CREATE TABLE AS (CTAS) En la cláusula `WITH` de la instrucción [CREATE TABLE AS](create-table-as.md), especifique `write_compression = 'ZSTD'` o `parquet_compression = 'ZSTD'` y, a continuación, utilice `compression_level = compression_level` y especifique un valor comprendido entre 1 y 22 como un entero. Si no se especifica la propiedad `compression_level`, el nivel de compresión predeterminado es 3. #### Ejemplo En el siguiente ejemplo de CTAS se especifica Parquet como formato de archivo mediante compresión ZSTD con un nivel de compresión 4. En la cláusula `WITH`, el valor del nivel de compresión debe especificarse como un entero, no como una cadena. ``` CREATE TABLE new_table WITH ( format = 'PARQUET', write_compression = 'ZSTD', compression_level = 4) AS SELECT * FROM old_table ``` ### UNLOAD En la cláusula `WITH` de la instrucción [UNLOAD](unload.md), especifique `compression = 'ZSTD'` y, a continuación, utilice `compression_level = compression_level` y especifique un valor comprendido entre 1 y 22 como un entero. Si no se especifica la propiedad `compression_level`, el nivel de compresión predeterminado es 3. #### Ejemplo En el siguiente ejemplo se descargan los resultados de la consulta en la ubicación especificada mediante el formato de archivo Parquet, compresión ZSTD y el nivel 4 de compresión ZSTD. ``` UNLOAD (SELECT * FROM old_table) TO 's3://amzn-s3-demo-bucket/' WITH (format = 'PARQUET', compression = 'ZSTD', compression_level = 4) ``` # Etiquetado de recursos de Athena Una etiqueta consta de una clave y un valor, ambos definidos por el usuario. Cuando etiqueta un recurso de Athena, le asigna metadatos personalizados. Puede utilizar etiquetas para clasificar los recursos de AWS de diversas maneras, por ejemplo, según su finalidad, propietario o entorno. En Athena, los recursos como los grupos de trabajo, los catálogos de datos y las reservas de capacidad son recursos que se pueden etiquetar. Por ejemplo, puede crear un conjunto de etiquetas para grupos de trabajo en su cuenta que le ayude a realizar un seguimiento de los propietarios de grupos de trabajo o identificar grupos por su finalidad. Si también habilita las etiquetas como etiquetas de asignación de costos en la consola de Administración de facturación y costos, los costos asociados con la ejecución de consultas aparecen en el Informe de costos y usos con esa etiqueta de asignación de costos. Se recomienda seguir las [prácticas recomendadas de etiquetado](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html) de AWS para crear un conjunto de etiquetas coherente que satisfaga los requisitos de la organización. Puede trabajar con etiquetas mediante la consola de Athena o las operaciones de la API. **Topics** + [Conceptos básicos de etiquetas](#tag-basics) + [Restricciones de las etiquetas](#tag-restrictions) + [Trabajo con etiquetas para grupos de trabajo](tags-console.md) + [Uso de operaciones de etiquetas de la AWS CLI y API](tags-operations.md) + [Uso de políticas de control de acceso de IAM basado en etiquetas](tags-access-control.md) ## Conceptos básicos de etiquetas Una etiqueta es una marca que se asigna a un recurso de Athena. Cada etiqueta está formada por una clave y un valor opcional, ambos definidos por el usuario. Las etiquetas le permiten clasificar los recursos de AWS de diversas maneras. Por ejemplo, puede definir un conjunto de etiquetas para los grupos de trabajo de su cuenta que le ayude a realizar un seguimiento del propietario de cada grupo de trabajo o finalidad. Puede agregar etiquetas al crear un grupo de trabajo de Athena nuevo o catálogo de datos, o puede agregar, editar o eliminar etiquetas de los mismos. Puede editar una etiqueta en la consola. Para utilizar las operaciones de la API para editar una etiqueta, elimine la etiqueta antigua y agregue una nueva. Si elimina un recurso, también se eliminará cualquier etiqueta asignada a dicho recurso. Athena no asigna automáticamente etiquetas a los recursos. Puede editar las claves y los valores de las etiquetas y también puede eliminar etiquetas de un recurso en cualquier momento. Puede establecer el valor de una etiqueta como una cadena vacía, pero no puede asignarle un valor nulo. No agregue claves de etiqueta duplicadas al mismo recurso. Si lo hace, Athena emite un mensaje de error. Si utiliza la acción **TagResource** para etiquetar un recurso con una clave de etiqueta existente, el nuevo valor de etiqueta sobrescribe el valor anterior. En IAM puede controlar qué usuarios de la cuenta de Amazon Web Services tienen permiso para crear, editar, eliminar o enumerar etiquetas. Para obtener más información, consulte [Uso de políticas de control de acceso de IAM basado en etiquetas](tags-access-control.md). Para obtener una lista completa de las acciones de etiquetas de Amazon Athena, consulte los nombres de acciones de la API en la [Referencia de API de Amazon Athena](https://docs.aws.amazon.com/athena/latest/APIReference/). Puede usar etiquetas para la facturación. Para obtener más información, consulte [Uso de etiquetas para facturación](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/custom-tags.html) en la *Guía del usuario de Administración de facturación y costos de AWS*. Para obtener más información, consulte [Restricciones de las etiquetas](#tag-restrictions). ## Restricciones de las etiquetas Las etiquetas tienen las siguientes restricciones: + En Athena, puede etiquetar grupos de trabajo, catálogos de datos y reservas de capacidad. No puede etiquetar consultas. + El número máximo de etiquetas por recurso es 50. Para no sobrepasar el límite, revise y elimine las etiquetas sin usar. + Para cada recurso, cada clave de etiqueta debe ser única y solo puede tener un valor. No agregue claves de etiquetas duplicadas al mismo tiempo al mismo recurso. Si lo hace, Athena emite un mensaje de error. Si etiqueta un recurso mediante una clave de etiqueta existente en una acción `TagResource` separada, el valor de la etiqueta nueva sobrescribe el valor antiguo. + La longitud de la clave de etiqueta es de 1-128 caracteres Unicode en UTF-8. + La longitud del valor de etiqueta es de 0-256 caracteres Unicode en UTF-8. Las operaciones de etiquetado, como, por ejemplo, agregar, editar, eliminar o enumerar etiquetas, requieren que especifique un ARN para el recurso de grupo de trabajo. + Athena le permite utilizar letras, números, espacios representados en UTF-8 y los siguientes caracteres: \$1 - = . \$1 : / @. + Las claves y los valores de las etiquetas distinguen entre mayúsculas y minúsculas. + El prefijo `"aws:"` de las claves de etiqueta está reservado para el uso de AWS. Las claves de etiquetas que tienen este prefijo no se pueden editar ni eliminar. Las etiquetas que tengan este prefijo no cuentan para el límite de etiquetas por recurso. + Las etiquetas que asigne solo están disponibles para su cuenta de Amazon Web Services. # Trabajo con etiquetas para grupos de trabajo Con la consola de Athena, puede ver qué etiquetas están en uso en cada grupo de trabajo en su cuenta. Puede ver etiquetas solo por grupo de trabajo. También puede utilizar la consola de Athena para aplicar, editar o eliminar etiquetas en un grupo de trabajo a la vez. Puede buscar grupos de trabajo utilizando las etiquetas que ha creado. **Topics** + [Visualización de etiquetas para los grupos de trabajo individuales](#tags-display) + [Adición y eliminación de etiquetas en un grupo de trabajo individual](#tags-add-delete) ## Visualización de etiquetas para los grupos de trabajo individuales **Para mostrar las etiquetas de un grupo de trabajo individual en la consola de Athena** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. Si el panel de navegación de la consola no está visible, elija el menú de expansión de la izquierda. ![\[Elija el menú de expansión.\]](http://docs.aws.amazon.com/es_es/athena/latest/ug/images/nav-pane-expansion.png) 1. En el menú de navegación, elija **Workgroups** (Grupos de trabajo) y, a continuación, elija el grupo de trabajo que quiere. 1. Realice una de las siguientes acciones: + Elija la pestaña **Etiquetas**. Si la lista de etiquetas es larga, utilice el cuadro de búsqueda. + Elija **Edit** (Editar) y, a continuación, desplácese hacia abajo hasta la sección **Tags** (Etiquetas). ## Adición y eliminación de etiquetas en un grupo de trabajo individual Puede administrar las etiquetas para un grupo de trabajo individual directamente desde la pestaña **Workgroups (Grupos de trabajo)**. **nota** Si desea que los usuarios agreguen etiquetas cuando creen un grupo de trabajo en la consola o pasen etiquetas cuando utilicen la acción **CreateWorkGroup**, asegúrese de conceder permisos de IAM a los usuarios para las acciones **TagResource** y **CreateWorkGroup**. **Para agregar una etiqueta se crea un nuevo grupo de trabajo** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. En el menú de navegación, elija **Workgroups** (Grupos de trabajo). 1. Elija **Create workgroup** (Crear grupo de trabajo) y rellene los valores según sea necesario. Para ver los pasos detallados, consulte [Creación de un grupo de trabajo](creating-workgroups.md). 1. En la sección **Tags** (Etiquetas), agregue una o varias etiquetas. Para ello, especifique las claves y los valores. No añada claves de etiquetas duplicadas al mismo tiempo en el mismo grupo de trabajo. Si lo hace, Athena emite un mensaje de error. Para obtener más información, consulte [Restricciones de las etiquetas](tags.md#tag-restrictions). 1. Cuando haya terminado, elija **Create Workgroup** (Crear grupo de trabajo). **Para añadir una etiqueta a un grupo de trabajo existente o editarla** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. En el panel de navegación, elija **Workgroups** (Redes globales). 1. Elija el grupo de trabajo que quiere modificar. 1. Realice una de las siguientes acciones: + Elija la pestaña **Etiquetas** y, a continuación, elija **Administrar etiquetas**. + Elija **Edit** (Editar) y, a continuación, desplácese hacia abajo hasta la sección **Tags** (Etiquetas). 1. Especifique una clave y valor para cada etiqueta. Para obtener más información, consulte [Restricciones de las etiquetas](tags.md#tag-restrictions). 1. Seleccione **Save**. **Para eliminar una etiqueta de un grupo de trabajo individual** 1. Abra la consola de Athena en [https://console.aws.amazon.com/athena/](https://console.aws.amazon.com/athena/home). 1. En el panel de navegación, elija **Workgroups** (Redes globales). 1. Elija el grupo de trabajo que quiere modificar. 1. Realice una de las siguientes acciones: + Elija la pestaña **Etiquetas** y, a continuación, elija **Administrar etiquetas**. + Elija **Edit** (Editar) y, a continuación, desplácese hacia abajo hasta la sección **Tags** (Etiquetas). 1. En la lista de etiquetas, elija **Remove** (Quitar) de la etiqueta que quiera eliminar y, a continuación, elija **Save** (Guardar). # Uso de operaciones de etiquetas de la AWS CLI y API Utilice las siguientes operaciones de etiquetas para agregar, quitar o enumerar etiquetas en un recurso. **** | API | CLI | Descripción de la acción | | --- | --- | --- | | TagResource | tag-resource | Agregue o sobrescriba una o más etiquetas en el recurso que tiene el ARN especificado. | | UntagResource | untag-resource | Elimine una o más etiquetas del recurso que tiene el ARN especificado. | | ListTagsForResource | list‑tags‑for‑resource | Enumere una o más etiquetas para el recurso que tiene el ARN especificado. | **Adición de etiquetas al crear un recurso** Para agregar etiquetas al crear un grupo de trabajo o un catálogo de datos, utilice el parámetro `tags` con las operaciones de API `CreateWorkGroup` o `CreateDataCatalog` o con los comandos AWS CLI o `create-work-group` de la `create-data-catalog`. ## Administración de etiquetas con acciones de la API En los ejemplos siguientes se muestra cómo utilizar acciones de API de etiquetas para administrar las etiquetas en los grupos de trabajo y los catálogos de datos. Los ejemplos están en el lenguaje de programación Java. ### Ejemplo: TagResource En el ejemplo siguiente se agregan dos etiquetas al grupo de trabajo `workgroupA`: ``` List tags = new ArrayList<>(); tags.add(new Tag().withKey("tagKey1").withValue("tagValue1")); tags.add(new Tag().withKey("tagKey2").withValue("tagValue2")); TagResourceRequest request = new TagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA") .withTags(tags); client.tagResource(request); ``` En el ejemplo siguiente se agregan dos etiquetas al catálogo de datos `datacatalogA`: ``` List tags = new ArrayList<>(); tags.add(new Tag().withKey("tagKey1").withValue("tagValue1")); tags.add(new Tag().withKey("tagKey2").withValue("tagValue2")); TagResourceRequest request = new TagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA") .withTags(tags); client.tagResource(request); ``` **nota** No agregue claves de etiqueta duplicadas al mismo recurso. Si lo hace, Athena emite un mensaje de error. Si etiqueta un recurso mediante una clave de etiqueta existente en una acción `TagResource` separada, el valor de la etiqueta nueva sobrescribe el valor antiguo. ### Ejemplo: UntagResource En el ejemplo siguiente se quita `tagKey2` del grupo de trabajo `workgroupA`: ``` List tagKeys = new ArrayList<>(); tagKeys.add("tagKey2"); UntagResourceRequest request = new UntagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA") .withTagKeys(tagKeys); client.untagResource(request); ``` En el ejemplo siguiente se quita `tagKey2` del catálogo de datos `datacatalogA`: ``` List tagKeys = new ArrayList<>(); tagKeys.add("tagKey2"); UntagResourceRequest request = new UntagResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA") .withTagKeys(tagKeys); client.untagResource(request); ``` ### Ejemplo: ListTagsForResource En el ejemplo siguiente se enumeran las etiquetas del grupo de trabajo `workgroupA`: ``` ListTagsForResourceRequest request = new ListTagsForResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA"); ListTagsForResourceResult result = client.listTagsForResource(request); List resultTags = result.getTags(); ``` En el ejemplo siguiente se enumeran las etiquetas del catálogo de datos `datacatalogA`: ``` ListTagsForResourceRequest request = new ListTagsForResourceRequest() .withResourceARN("arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA"); ListTagsForResourceResult result = client.listTagsForResource(request); List resultTags = result.getTags(); ``` ## Administración de las etiquetas mediante la AWS CLI En los ejemplos siguientes se muestra cómo utilizar la AWS CLI para crear y administrar etiquetas en catálogos de datos. ### Adición de etiquetas a un recurso: tag-resource El comando `tag-resource` agrega una o varias etiquetas a un recurso especificado. **Sintaxis** `aws athena tag-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name --tags Key=string,Value=string Key=string,Value=string` El parámetro `--resource-arn` especifica el recurso al que se agregan las etiquetas. El parámetro `--tags` especifica una lista de pares clave-valor separados por espacios para agregar como etiquetas al recurso. **Example** En el ejemplo siguiente se agregan etiquetas al catálogo de datos `mydatacatalog`. ``` aws athena tag-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog --tags Key=Color,Value=Orange Key=Time,Value=Now ``` Para mostrar el resultado, use el comando `list-tags-for-resource`. Para obtener información sobre cómo agregar etiquetas al utilizar el comando `create-data-catalog`, consulte [Registro de un catálogo: create-data-catalog](datastores-hive-cli.md#datastores-hive-cli-registering-a-catalog). ### Descripción de las etiquetas de un recurso: list-tags-for-resource El comando `list-tags-for-resource` enumera las etiquetas del recurso especificado. **Sintaxis** `aws athena list-tags-for-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name` El parámetro `--resource-arn` especifica el recurso para el que se enumeran las etiquetas. En el ejemplo siguiente se enumeran las etiquetas del catálogo de datos `mydatacatalog`. ``` aws athena list-tags-for-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog ``` El siguiente resultado de ejemplo está en formato JSON. ``` { "Tags": [ { "Key": "Time", "Value": "Now" }, { "Key": "Color", "Value": "Orange" } ] } ``` ### Eliminación de las etiquetas de un recurso: untag-resource: untag-resource El comando `untag-resource` quita las claves de etiqueta especificadas y sus valores asociados del recurso especificado. **Sintaxis** `aws athena untag-resource --resource-arn arn:aws:athena:region:account_id:datacatalog/catalog_name --tag-keys key_name [key_name ...]` El parámetro `--resource-arn` especifica el recurso del que se quitan las etiquetas. El parámetro `--tag-keys` toma una lista separada por espacios de nombres de las clave. Para cada nombre de clave especificado, el comando `untag-resource` elimina tanto la clave como su valor. En el ejemplo siguiente se quitan las claves `Color` y `Time` y sus valores del recurso de catálogo `mydatacatalog`. ``` aws athena untag-resource --resource-arn arn:aws:athena:us-east-1:111122223333:datacatalog/mydatacatalog --tag-keys Color Time ``` # Uso de políticas de control de acceso de IAM basado en etiquetas Tener etiquetas le permite escribir una política de IAM que incluya el bloque `Condition` para controlar el acceso a un recurso en función de sus etiquetas. En esta sección se incluyen ejemplos de las políticas de etiquetas para los recursos de los grupos de trabajo y los catálogos de datos. ## Ejemplos de política de etiquetas para grupos de trabajo ### Ejemplo: política de etiquetado básica La siguiente política de IAM le permite ejecutar las consultas e interactuar con etiquetas para el grupo de trabajo llamado `workgroupA`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListWorkGroups", "athena:ListEngineVersions", "athena:ListDataCatalogs", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "athena:GetWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery", "athena:CreatePreparedStatement", "athena:GetPreparedStatement", "athena:ListPreparedStatements", "athena:UpdatePreparedStatement", "athena:DeletePreparedStatement" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/workgroupA" } ] } ``` ------ ### Ejemplo: bloqueo de política que deniega acciones en un grupo de trabajo en función de un par de claves de etiqueta y valores de etiqueta Las etiquetas que están asociadas a un recurso como un grupo de trabajo se denominan etiquetas de recursos. Las etiquetas de recursos le permiten escribir bloques de política como los siguientes que deniegan las acciones enumeradas en cualquier grupo de trabajo etiquetado con un par clave-valor como `stack`, `production`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "athena:GetWorkGroup", "athena:UpdateWorkGroup", "athena:DeleteWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery", "athena:CreatePreparedStatement", "athena:GetPreparedStatement", "athena:ListPreparedStatements", "athena:UpdatePreparedStatement", "athena:DeletePreparedStatement" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/*", "Condition": { "StringEquals": { "aws:ResourceTag/stack": "production" } } } ] } ``` ------ ### Ejemplo: bloqueo de política que restringe las solicitudes de acciones de cambio de etiqueta a etiquetas especificadas Las etiquetas que se pasan como parámetros a operaciones que cambian etiquetas (por ejemplo, `TagResource`, `UntagResource` o `CreateWorkGroup` con etiquetas) se denominan etiquetas de solicitud. El siguiente bloque de política de ejemplo permite la operación `CreateWorkGroup` solo si una de las etiquetas pasadas tiene la clave `costcenter` y el valor `1`, `2` o `3`. **nota** Si desea permitir que un rol de IAM pase etiquetas como parte de una operación `CreateWorkGroup`, asegúrese de conceder permisos al rol para las acciones `TagResource` y `CreateWorkGroup`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:CreateWorkGroup", "athena:TagResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:workgroup/*", "Condition": { "StringEquals": { "aws:RequestTag/costcenter": [ "1", "2", "3" ] } } } ] } ``` ------ ## Ejemplos de política de etiquetas para catálogos de datos ### Ejemplo: política de etiquetado básica La siguiente política de IAM le permite interactuar con etiquetas para el catálogo de datos denominado `datacatalogA`: ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:ListWorkGroups", "athena:ListEngineVersions", "athena:ListDataCatalogs", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "athena:GetWorkGroup", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource", "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:BatchGetQueryExecution", "athena:ListQueryExecutions", "athena:StopQueryExecution", "athena:GetQueryResults", "athena:GetQueryResultsStream", "athena:CreateNamedQuery", "athena:GetNamedQuery", "athena:BatchGetNamedQuery", "athena:ListNamedQueries", "athena:DeleteNamedQuery" ], "Resource": [ "arn:aws:athena:us-east-1:123456789012:workgroup/*" ] }, { "Effect": "Allow", "Action": [ "athena:CreateDataCatalog", "athena:GetDataCatalog", "athena:UpdateDataCatalog", "athena:DeleteDataCatalog", "athena:ListDatabases", "athena:GetDatabase", "athena:ListTableMetadata", "athena:GetTableMetadata", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/datacatalogA" } ] } ``` ------ ### Ejemplo: bloqueo de política que deniega acciones en un Catálogo de datos en función de un par de claves de etiqueta y valores de etiqueta Puede utilizar etiquetas de recursos para escribir bloques de política que denieguen acciones específicas en catálogos de datos etiquetados con pares clave-valor de etiqueta específicos. La siguiente política de ejemplo deniega acciones en catálogos de datos que tienen el par clave-valor de etiqueta `stack`, `production`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Deny", "Action": [ "athena:CreateDataCatalog", "athena:GetDataCatalog", "athena:UpdateDataCatalog", "athena:DeleteDataCatalog", "athena:GetDatabase", "athena:ListDatabases", "athena:GetTableMetadata", "athena:ListTableMetadata", "athena:StartQueryExecution", "athena:TagResource", "athena:UntagResource", "athena:ListTagsForResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/*", "Condition": { "StringEquals": { "aws:ResourceTag/stack": "production" } } } ] } ``` ------ ### Ejemplo: bloqueo de política que restringe las solicitudes de acciones de cambio de etiqueta a etiquetas especificadas Las etiquetas que se pasan como parámetros a operaciones que cambian etiquetas (por ejemplo, `TagResource`, `UntagResource` o `CreateDataCatalog` con etiquetas) se denominan etiquetas de solicitud. El siguiente bloque de política de ejemplo permite la operación `CreateDataCatalog` solo si una de las etiquetas pasadas tiene la clave `costcenter` y el valor `1`, `2` o `3`. **nota** Si desea permitir que un rol de IAM pase etiquetas como parte de una operación `CreateDataCatalog`, asegúrese de conceder permisos al rol para las acciones `TagResource` y `CreateDataCatalog`. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "athena:CreateDataCatalog", "athena:TagResource" ], "Resource": "arn:aws:athena:us-east-1:123456789012:datacatalog/*", "Condition": { "StringEquals": { "aws:RequestTag/costcenter": [ "1", "2", "3" ] } } } ] } ``` ------ # Service Quotas **nota** La consola de Service Quotas proporciona información sobre las cuotas de Amazon Athena. También puede utilizar la consola de Service Quotas a fin de [solicitar aumentos de cuota](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas) para las cuotas ajustables. Para conocer las limitaciones del esquema relacionadas con AWS Glue, consulte la página de [puntos de conexión y cuotas de AWS Glue](https://docs.aws.amazon.com/general/latest/gr/glue.html). Para obtener información general sobre AWS Service Quotas, consulte [AWS Service Quotas](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html) en la *Referencia general de AWS*. ## Consultas Su cuenta tiene las siguientes cuotas relacionadas con consultas para Amazon Athena. Para obtener más información, consulte la página de [puntos de conexión y cuotas de Amazon Athena](https://docs.aws.amazon.com/general/latest/gr/athena.html#amazon-athena-limits) de la Referencia general de AWS. + **Consultas DDL activas**: cantidad de consultas DDL activas. Las consultas DDL incluyen consultas `CREATE TABLE` y `ALTER TABLE ADD PARTITION`. + **DDL query timeout** (Tiempo de espera de consulta DDL): intervalo máximo de tiempo en minutos durante el que se puede ejecutar una consulta DDL antes de que se cancele. + **Active DML queries** (Consultas DML activas): cantidad de consultas DML activas. Las consultas DML incluyen consultas `SELECT`, `CREATE TABLE AS` (CTAS) y `INSERT INTO`. Las cuotas específicas varían según la región de AWS. + **Tiempo de espera de consulta DML**: intervalo máximo de tiempo en minutos durante el que se puede ejecutar una consulta DML antes de que se cancele. Puede solicitar un aumento de este tiempo de espera hasta un máximo de 240 minutos. Para solicitar el aumento de una cuota, puede utilizar la consola de [Athena Service Quotas](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas). Athena procesa las consultas mediante la asignación de recursos en función de la carga general del servicio y el número de solicitudes entrantes. Es posible que las consultas se pongan en cola temporalmente antes de que se ejecuten. Los procesos asíncronos recogen las consultas de las colas y las ejecutan en recursos físicos tan pronto como los recursos están disponibles y durante el tiempo que la configuración de la cuenta lo permita. Las cuotas de consultas DML activas y consultas DDL activas incluyen tanto las consultas en ejecución como en cola. Por ejemplo, si la cuota de consultas DML activas es de 25 y el total de consultas ejecutadas y en cola es 26, la consulta 26 generará un error TooManyRequestsException. **nota** Si desea controlar la simultaneidad de forma directa para las consultas que ejecuta en Athena, puede utilizar las reservas de capacidad. Para obtener más información, consulte [Administración de la capacidad de procesamiento de consultas](capacity-management.md). ### Longitud de cadena de consulta La longitud máxima permitida de la cadena de consulta es 262144 bytes, donde las cadenas se codifican en UTF-8. No se trata de una cuota ajustable. Sin embargo, puede evitar esta limitación al dividir las consultas largas en varias consultas más pequeñas. Para obtener más información, consulte [¿Cómo puedo aumentar la longitud máxima de cadena de consulta en Athena?](https://aws.amazon.com/premiumsupport/knowledge-center/athena-query-string-length/) en el Centro de conocimientos de AWS. ## Grupos de trabajo Cuando trabaje con grupos de trabajo de Athena, recuerde los siguientes puntos: + Las cuotas de servicio de Athena se comparten entre todos los grupos de trabajo de una cuenta. + El número máximo de grupos de trabajo que puede crear por región en una cuenta es 1000. + El número máximo de instrucciones preparadas en un grupo de trabajo es 1000. + El número máximo de etiquetas por grupo de trabajo es 50. Para obtener más información, consulte [Restricciones de las etiquetas](tags.md#tag-restrictions). ## Bases de datos, tablas y particiones Athena usa el AWS Glue Data Catalog. Para Service Quotas en tablas, bases de datos y particiones (por ejemplo, el número máximo de bases de datos o de tablas por cuenta) consulte [Puntos de conexión y cuotas de AWS Glue](https://docs.aws.amazon.com/general/latest/gr/glue.html). Tenga en cuenta que, aunque Athena admite consultas de tablas de AWS Glue que tienen 10 millones de particiones, no puede leer más de 1 millón de particiones en un solo escaneo. ## Buckets de Amazon S3 Cuando trabaje con buckets de Amazon S3, recuerde los siguientes puntos: + Amazon S3 tiene una cuota de servicio predeterminada de 10 000 buckets por cuenta. + Athena necesita un bucket independiente para registrar los resultados. + Puede solicitar un aumento de cuota de hasta un millón de buckets de Amazon S3 por cuenta de AWS. ## Cuotas de llamadas a la API por cuenta Las API de Athena tienen cuotas predeterminadas para el número de llamadas a la API por cuenta (no por consulta). Para obtener una lista completa de las cuotas predeterminadas, consulte la tabla [Service Quotas](https://docs.aws.amazon.com/general/latest/gr/athena.html#amazon-athena-limits) en la guía de Referencia general de AWS. Si utiliza cualquiera de estas API y supera la cuota predeterminada del número de llamadas por segundo o la capacidad de ampliación de su cuenta, la API de Athena genera un error similar al siguiente: “ClientError: An error occurred (ThrottlingException) when calling the ** operation: Rate exceeded”. Reduzca el número de llamadas por segundo o la capacidad de ampliación para la API para esta cuenta. La cuota de Athena para llamadas a la API por cuenta se puede cambiar en la [consola de Service Quotas de Athena](https://console.aws.amazon.com/servicequotas/home?region=us-east-1#!/services/athena/quotas).