En las arquitecturas de datos modernas, es común almacenar datos en múltiples fuentes de datos. Sin embargo, las organizaciones que adoptan este enfoque aún necesitan información de sus datos y requieren tecnologías que les ayuden a romper los silos de datos. Atenea amazónica es un servicio de consulta interactivo que facilita el análisis de datos estructurados, no estructurados y semiestructurados almacenados en Servicio de almacenamiento simple de Amazon (Amazon S3), además de orígenes de datos relacionales, no relacionales, de objetos y personalizados a través de sus capacidades de federación de consultas. Athena no tiene servidor, por lo que no hay infraestructura que administrar y solo paga por las consultas que ejecuta.

Las organizaciones que construyen una arquitectura de datos moderna quieren consultar datos en el lugar desde almacenes de datos creados específicamente sin construir canalizaciones complejas de extracción, transformación y carga (ETL). La función de consulta federada de Athena permite a las organizaciones lograr esto y facilita:

• Cree informes y paneles a partir de datos almacenados en orígenes de datos relacionales, no relacionales, de objetos y personalizados
• Ejecute análisis bajo demanda en datos distribuidos en múltiples sistemas de registro usando una sola herramienta y un solo dialecto SQL
• Unir múltiples fuentes de datos para producir nuevas funciones de entrada para flujos de trabajo de entrenamiento de modelos de aprendizaje automático

Sin embargo, al consultar y unir grandes cantidades de datos de diferentes almacenes de datos, es importante que las consultas se ejecuten rápidamente, a bajo costo y sin afectar los sistemas de origen. La inserción de predicados es compatible con muchos motores de consulta y es una técnica que puede reducir drásticamente el tiempo de procesamiento de consultas mediante el filtrado de datos en la fuente al principio del flujo de trabajo de procesamiento. En esta publicación, aprenderá cómo la inserción de predicados mejora el rendimiento de las consultas y cómo puede validar cuándo Athena aplica la inserción de predicados a las consultas federadas.

Beneficios de la inserción de predicados

Los beneficios clave de la inserción de predicados son los siguientes:

• Tiempo de ejecución de consultas mejorado
• Tráfico de red reducido entre Athena y la fuente de datos
• Carga reducida en la fuente de datos remota
• Costo reducido como resultado de escaneos de datos reducidos

Exploremos un escenario del mundo real para comprender cuándo se aplica la inserción de predicado a las consultas federadas en Athena.

Resumen de la solución

Imagine una empresa hipotética de comercio electrónico con datos almacenados en

Los recuentos de registros para estas tablas son los siguientes.

Nuestro requisito es consultar estas fuentes individualmente y unir los datos para realizar un seguimiento de la información de proveedores y precios y comparar datos recientes con datos históricos mediante consultas SQL con varios filtros aplicados. Usaremos consultas federadas de Athena para consultar y unir datos de estas fuentes para cumplir con este requisito.

El siguiente diagrama muestra cómo las consultas federadas de Athena utilizan conectores de fuentes de datos que se ejecutan como funciones de Lambda para consultar datos almacenados en fuentes distintas a Amazon S3.

Cuando se envía una consulta federada contra una fuente de datos, Athena invoca el conector de la fuente de datos para determinar cómo leer la tabla solicitada e identificar los predicados de filtro en la cláusula WHERE de la consulta que se pueden enviar a la fuente. Athena reduce automáticamente los filtros aplicables y tiene el efecto de omitir filas innecesarias al principio del flujo de trabajo de procesamiento de consultas y mejorar el tiempo general de ejecución de consultas.

Exploremos tres casos de uso para demostrar la reducción predicada para nuestra empresa de comercio electrónico que usa cada uno de estos servicios.

Requisitos previos

Como requisito previo, revise Uso de consultas federadas de Amazon Athena para obtener más información sobre las consultas federadas de Athena y cómo implementar estos conectores de origen de datos.

Caso de uso 1: Amazon Redshift

En nuestro primer escenario, ejecutamos una consulta federada de Athena en Amazon Redshift uniendo su Catalog_sales y Date_dim mesas. Hacemos esto para mostrar el número de pedidos de venta agrupados por fecha de pedido. La siguiente consulta obtiene la información requerida y toma aproximadamente 14 segundos escaneando aproximadamente 43 MB de datos:

SELECT "d_date" AS Order_date,
     count(1) AS Total_Orders
 FROM "lambda:redshift"."order_schema"."catalog_sales" l,
     "lambda:redshift"."order_schema"."date_dim" d
 WHERE l.cs_sold_date_sk = d_date_sk
     and cs_sold_date_sk between 2450815 and 2450822 --Date keys for first week of Jan 1998
 GROUP BY "d_date"
 order by "d_date" 

Athena envía los siguientes filtros a la fuente para su procesamiento:

• cs_sold_date_sk entre 2450815 y 2450822 para el Catalog_Sales tabla en Amazon Redshift.
• d_date_sk between 2450815 and 2450822; debido a la unión l.cs_sold_date_sk=d_date_sk en la consulta, el Date_dim la tabla también se filtra en el origen y solo los datos filtrados se mueven de Amazon Redshift a Athena.

Analicemos el plan de consulta mediante el uso publicado recientemente herramienta de explicación visual para confirmar que los predicados de filtro se envían a la fuente de datos:

Como se muestra arriba (solo se muestra la parte relevante del plan de explicación visual), debido a la inserción de predicados, el Catalog_sales y Date_dim las tablas tienen filtros aplicados en la fuente. Athena procesa solo los datos filtrados resultantes.

Usando la consola de Athena, podemos ver los detalles del procesamiento de consultas usando el recientemente lanzado consultar estadísticas para explorar de forma interactiva los detalles de procesamiento con pushdown de predicado en la etapa de consulta:

Mostrar solo las etapas de procesamiento de consultas relevantes, Catalog_sales table tiene aproximadamente 4.3 millones de registros, y Date_dim tiene aproximadamente 73,000 registros en Amazon Redshift. Sólo 11 millones de registros de la Catalog_sales (Etapa 4) y 8 registros de la Date_dim (Etapa 5) se pasan del origen a Athena, porque la inserción de predicado empuja las condiciones del filtro de consulta a los orígenes de datos. Esto filtra los registros innecesarios en el origen y solo trae las filas requeridas a Athena.

El uso de pushdown predicado resultó en escanear un 99.75% menos de datos de Catalog_sales y 99.99% menos datos de Date_dim. Esto da como resultado un tiempo de ejecución de consultas más rápido y un costo más bajo.

Caso de uso 2: Amazon Redshift y Aurora MySQL

En nuestro segundo caso de uso, ejecutamos una consulta federada de Athena en los almacenes de datos de Aurora MySQL y Amazon Redshift. Esta consulta se une a la Catalog_sales y Date_dim tablas en Amazon Redshift con el Customer en la base de datos MySQL de Aurora para obtener el número total de pedidos con el monto total gastado por cada cliente durante la primera semana de enero de 1998 para el segmento de mercado de AUTOMOBILE. La siguiente consulta obtiene la información requerida y tarda aproximadamente 35 segundos en escanear aproximadamente 337 MB de datos:

SELECT  cs_bill_customer_sk Customer_id ,"d_date" Order_Date 
 ,count("cs_order_number") Total_Orders ,sum(l.cs_net_paid_inc_ship_tax) AS Total_Amount
 FROM "lambda:mysql".sales.customer c,"lambda:redshift"."order_schema"."catalog_sales" l
 ,"lambda:redshift"."order_schema"."date_dim" d
 WHERE c_mktsegment = 'AUTOMOBILE'
 AND c_custkey = cs_bill_customer_sk
 AND l.cs_sold_date_sk=d_date_sk 
 AND cs_sold_date_sk between 2450815 and 2450822 --Date keys for first week of Jan 1998
 GROUP BY cs_bill_customer_sk,"d_date"  
 ORDER BY cs_bill_customer_sk,"d_date"

Athena envía los siguientes filtros a las fuentes de datos para su procesamiento:

• cs_sold_date_sk between 2450815 and 2450822 para Catalog_Sales tabla en Amazon Redshift.
• d_date_sk between 2450815 and 2450822; debido a la unión l.cs_sold_date_sk=d_date_sk en la consulta, el Date_dim la tabla también se filtra en el origen (Amazon Redshift) y solo los datos filtrados se mueven de Amazon Redshift a Athena.
• c_mktsegment = 'AUTOMOBILE' para Customer tabla en la base de datos Aurora MySQL.

Ahora consultemos el plan de explicación visual para que esta consulta muestre la inserción del predicado en la fuente para su procesamiento:

Como se muestra arriba (solo se muestra la parte relevante del plan de explicación visual), debido a la inserción de predicados, Catalog_sales y Date_dim tener el filtro de consulta aplicado en la fuente (Amazon Redshift), y el customer tabla tiene el segmento de mercado AUTOMOBILE filtro aplicado en la fuente (Aurora MySQL). Esto trae solo los datos filtrados a Athena.

Como antes, podemos ver los detalles del procesamiento de consultas usando el recientemente lanzado consultar estadísticas para explorar de forma interactiva los detalles de procesamiento con pushdown de predicado en la etapa de consulta:

Mostrar solo las etapas de procesamiento de consultas relevantes, Catalog_sales tiene 4.3 millones de registros, Date_Dim tiene 73,000 registros en Amazon Redshift, y Customer tiene 15,000 registros en Aurora MySQL. Sólo 11 millones de registros de Catalog_sales (Stage 6), 8 registros de Date_dim (Stage 7), y 3,000 registros de Customer (Stage 5) se pasan de las fuentes respectivas a Athena porque la inserción de predicado empuja las condiciones del filtro de consulta a las fuentes de datos. Esto filtra los registros innecesarios en el origen y solo trae las filas requeridas a Athena.

Aquí, la inserción de predicados resultó en escanear un 99.75 % menos de datos de Catalog_sales, 99.99% menos datos de Date_dim, y 79.91% de Customer. Además, esto da como resultado un tiempo de ejecución de consulta más rápido y un costo reducido.

Caso de uso 3: Amazon Redshift, Aurora MySQL y DynamoDB

Para nuestro tercer caso de uso, ejecutamos una consulta federada de Athena en almacenes de datos de Aurora MySQL, Amazon Redshift y DynamoDB. Esta consulta se une a la Part y Partsupp tablas en DynamoDB, la Catalog_sales y Date_dim tablas en Amazon Redshift, y el Supplier y Customer tablas en Aurora MySQL para obtener las cantidades disponibles en cada proveedor para los pedidos con mayores ingresos durante la primera semana de enero de 1998 para el segmento de mercado de AUTOMOBILE y piezas fabricadas por Manufacturer#1.

La siguiente consulta obtiene la información necesaria y tarda aproximadamente 33 segundos en escanear aproximadamente 428 MB de datos en Athena:

SELECT "d_date" Order_Date 
     ,c_mktsegment
     ,"cs_order_number"
     ,l.cs_item_sk Part_Key
     ,p.p_name Part_Name
     ,s.s_name Supplier_Name
     ,ps.ps_availqty Supplier_Avail_Qty
     ,l.cs_quantity Order_Qty
     ,l.cs_net_paid_inc_ship_tax Order_Total
 FROM "lambda:dynamo".default.part p, 
     "lambda:mysql".sales.supplier s, 
     "lambda:redshift"."order_schema"."catalog_sales" l, 
     "lambda:dynamo".default.partsupp ps, 
     "lambda:mysql".sales.customer c,
     "lambda:redshift"."order_schema"."date_dim" d
 WHERE 
     c_custkey = cs_bill_customer_sk
     AND l.cs_sold_date_sk=d_date_sk 
     AND c.c_mktsegment = 'AUTOMOBILE'
     AND cs_sold_date_sk between 2450815 and 2450822 --Date keys for first week of Jan 1998
     AND p.p_partkey=ps.ps_partkey
     AND s.s_suppkey=ps.ps_suppkey
     AND p.p_partkey=l.cs_item_sk
     AND p.p_mfgr='Manufacturer#1'

Athena envía los siguientes filtros a las fuentes de datos para su procesamiento:

• cs_sold_date_sk between 2450815 and 2450822 para Catalog_Sales tabla en Amazon Redshift.
• d_date_sk between 2450815 and 2450822; debido a la unión l.cs_sold_date_sk=d_date_sk en la consulta, el Date_dim la tabla también se filtra en el origen y solo los datos filtrados se mueven de Amazon Redshift a Athena.
• c_mktsegment = 'AUTOMOBILE' para Customer tabla en la base de datos Aurora MySQL.
• p.p_mfgr='Manufacturer#1' para Part tabla en DynamoDB.

Ahora ejecutemos el plan de explicación para esta consulta para confirmar que los predicados se envían a la fuente para su procesamiento:

Como se muestra arriba (que muestra solo la parte relevante del plan), debido a la inserción de predicados, Catalog_sales y Date_dim tener el filtro de consulta aplicado en la fuente (Amazon Redshift), el Customer tabla tiene el segmento de mercado AUTOMOBILE filtro aplicado en la fuente (Aurora MySQL), y el Part mesa tiene la pieza fabricada por Manufacturer#1 filtro aplicado en la fuente (DynamoDB).

Podemos analizar los detalles del procesamiento de consultas utilizando el recientemente publicado consultar estadísticas para explorar de forma interactiva los detalles de procesamiento con pushdown de predicado en la etapa de consulta:

Mostrar solo las etapas de procesamiento relevantes, Catalog_sales tiene 4.3 millones de registros, Date_Dim tiene 73,000 registros en Amazon Redshift, Customer tiene 15,000 registros en Aurora MySQL, y Part tiene 20,000 registros en DynamoDB. Sólo 11 millones de registros de Catalog_sales (Stage 5), 8 registros de Date_dim (Stage 9), 3,000 registros de Customer (Stage 8), y 4,000 registros de Part (Stage 4) se pasan de sus fuentes respectivas a Athena, porque la inserción de predicado empuja las condiciones del filtro de consulta a las fuentes de datos. Esto filtra los registros innecesarios en la fuente y solo trae las filas requeridas de las fuentes a Athena.

Consideraciones para la inserción de predicados

Cuando utilice Athena para consultar sus fuentes de datos, tenga en cuenta lo siguiente:

• Según el origen de datos, el conector del origen de datos y la complejidad de la consulta, Athena puede insertar predicados de filtro en el origen para su procesamiento. Las siguientes son algunas de las fuentes con las que Athena admite la inserción de predicados:
• Athena también realiza una inserción de predicados en los datos almacenados en un lago de datos S3. Y, con la inserción de predicados para fuentes admitidas, puede unir todas sus fuentes de datos en una consulta y lograr un rendimiento de consulta rápido.
• Puede usar el recientemente lanzado consultar estadísticas así como EXPLAIN y EXPLAIN ANALYZE en sus consultas para confirmar que los predicados se envían a la fuente.
• Es posible que las consultas no tengan predicados enviados al origen si la cláusula WHERE de la consulta utiliza funciones específicas de Athena (por ejemplo, WHERE log2(col)<10).

Conclusión

En esta publicación, demostramos tres escenarios de consultas federadas en Aurora MySQL, Amazon Redshift y DynamoDB para mostrar cómo la inserción de predicados mejora el rendimiento de las consultas federadas y reduce los costos y cómo puede validar cuándo se produce la inserción de predicados. Si la fuente de datos federada admite escaneos paralelos, la inserción de predicados permite lograr un rendimiento cercano al rendimiento de las consultas de Athena en los datos almacenados en Amazon S3. Puede utilizar los patrones y recomendaciones descritos en esta publicación al consultar fuentes de datos compatibles para mejorar el rendimiento general de las consultas y minimizar los datos escaneados.

Sobre los autores

rohit-bansal es un arquitecto de soluciones especialista en análisis en AWS. Tiene casi dos décadas de experiencia ayudando a los clientes a modernizar sus plataformas de datos. Le apasiona ayudar a los clientes a crear soluciones de análisis y datos escalables y rentables en la nube. En su tiempo libre, disfruta pasar tiempo con su familia, viajar y andar en bicicleta.

Ruchir Tripathi es un arquitecto sénior de soluciones de análisis alineado con los servicios financieros globales en AWS. Le apasiona ayudar a las empresas a crear soluciones escalables, eficaces y rentables en la nube. Antes de unirse a AWS, Ruchir trabajó con las principales instituciones financieras y tiene su sede en la oficina de Nueva York.