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.

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.

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.

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.

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 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.

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 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 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 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.

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.

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).

Las particiones se administran mejor de forma manual mediante las API del AWS Glue Data Catalog, ALTER TABLE ADD PARTITION o los rastreadores de AWS Glue. 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.

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. 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 y Descripción de los resultados de la instrucción EXPLAIN de Athena.

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:

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, 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.

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 ofrece buenas relaciones de compresión y es compatible con una amplia gama de herramientas y servicios. El formato 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, 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.

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.

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:

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.

Uso de SymlinkTextInputFormat solo cuando sea necesario

El uso de la técnica 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.