Escritura de consultas federadas

Una vez que haya configurado uno o más conectores de datos y los haya implementado en su cuenta, podrá usarlos en sus consultas de Athena.

Consulta de un único origen de datos

En los ejemplos de esta sección se presupone que ha configurado e implementado el conector Athena CloudWatch en su cuenta. Utilice el mismo enfoque para realizar consultas cuando utilice otros conectores.

Para crear una consulta de Athena que utilice el conector CloudWatch

1. Abra la consola de Athena en https://console.aws.amazon.com/athena/.

2. En el editor de consultas de Athena, cree una consulta SQL que utilice la sintaxis siguiente en la cláusula FROM.

   MyCloudwatchCatalog.database_name.table_name       

Ejemplos

En el siguiente ejemplo, se utiliza el conector Athena CloudWatch para conectarse a la vista all_log_streams en el Grupo de registros de CloudWatch Logs /var/ecommerce-engine/order-processor. La vista all_log_streams es una vista de todas las secuencias de registro del grupo de registros. La consulta de ejemplo limita el número de filas devueltas a 100.

ejemplo

SELECT * FROM "MyCloudwatchCatalog"."/var/ecommerce-engine/order-processor".all_log_streams limit 100;

En el ejemplo siguiente se analiza la información de la misma vista que el ejemplo anterior. En el ejemplo se extrae el ID de pedido y el nivel de registro y se filtra cualquier mensaje que tenga el nivel INFO.

ejemplo

SELECT log_stream as ec2_instance,
                        Regexp_extract(message '.*orderId=(\d+) .*', 1) AS orderId,
                        message                                         AS
                        order_processor_log,
                        Regexp_extract(message, '(.*):.*', 1)           AS log_level
            FROM
                    "MyCloudwatchCatalog"."/var/ecommerce-engine/order-processor".all_log_streams
            WHERE Regexp_extract(message, '(.*):.*', 1) != 'INFO'

La siguiente imagen muestra un resultado de ejemplo.

nota

En este ejemplo se muestra una consulta en la que se ha registrado el origen de datos como catálogo con Athena. También puede hacer referencia a una función Lambda de conector de origen de datos mediante el formato lambda:MyLambdaFunctionName..

Consulta de varios orígenes de datos

Como ejemplo más complejo, imagine una empresa de comercio electrónico que tenga una infraestructura de aplicaciones como la que se muestra en el siguiente diagrama.

Las siguientes descripciones explican los elementos numerados del diagrama.

1. Procesamiento de pagos en una VPC segura con registros de transacciones almacenados en HBase en Amazon EMR

2. Redis para almacenar pedidos activos para que el motor de procesamiento pueda acceder a ellos rápidamente.

3. Amazon DocumentDB para datos de cuenta de cliente, como direcciones de correo electrónico y direcciones de envío

4. Un catálogo de productos en Amazon Aurora para un sitio de comercio electrónico que utiliza escalado automático en Fargate

5. CloudWatch Logs para alojar los eventos de registro del procesador de pedidos

6. Almacenamiento de datos de escritura única y lectura múltiple en Amazon RDS

7. DynamoDB para almacenar datos de seguimiento de envíos

Imagine que un analista de datos para esta aplicación de comercio electrónico detecta que se está informando del estado de algunos pedidos incorrectamente. Algunos pedidos se muestran como pendientes aunque se han entregado, mientras que otros se muestran como entregados, pero no se han enviado.

El analista quiere saber cuántos pedidos se van con retraso y qué tienen en común los pedidos afectados en toda la infraestructura de comercio electrónico. En lugar de investigar los orígenes de información por separado, el analista federa los orígenes de datos y recupera la información necesaria en una sola consulta. No es necesario extraer los datos en una sola ubicación.

La consulta del analista utiliza los siguientes conectores de datos de Athena:

• CloudWatch Logs: recupera registros del servicio de procesamiento de pedidos y utiliza la coincidencia y extracción de expresiones regulares para filtrar los pedidos con eventos WARN o ERROR.

• Redis: recupera los pedidos activos de la instancia Redis.

• CMDB: recupera el ID y el estado de la instancia de Amazon EC2 que ejecutó el servicio de procesamiento de pedidos y registró el mensaje WARN o ERROR.

• DocumentDB: recupera el correo electrónico y la dirección del cliente de Amazon DocumentDB para los pedidos afectados.

• DynamoDB: recupera el estado del envío y los detalles de seguimiento de la tabla de envíos para identificar posibles discrepancias entre el estado informado y el estado real.

• HBase: recupera el estado de pago de los pedidos afectados del servicio de procesamiento de pagos.

ejemplo

nota

En este ejemplo se muestra una consulta en la que se ha registrado el origen de datos como catálogo con Athena. También puede hacer referencia a una función Lambda de conector de origen de datos mediante el formato lambda:MyLambdaFunctionName..

--Sample query using multiple Athena data connectors.
WITH logs 
     AS (SELECT log_stream, 
                message                                          AS 
                order_processor_log, 
                Regexp_extract(message, '.*orderId=(\d+) .*', 1) AS orderId, 
                Regexp_extract(message, '(.*):.*', 1)            AS log_level 
         FROM 
     "MyCloudwatchCatalog"."/var/ecommerce-engine/order-processor".all_log_streams 
         WHERE  Regexp_extract(message, '(.*):.*', 1) != 'INFO'), 
     active_orders 
     AS (SELECT * 
         FROM   redis.redis_db.redis_customer_orders), 
     order_processors 
     AS (SELECT instanceid, 
                publicipaddress, 
                state.NAME 
         FROM   awscmdb.ec2.ec2_instances), 
     customer 
     AS (SELECT id, 
                email 
         FROM   docdb.customers.customer_info), 
     addresses 
     AS (SELECT id, 
                is_residential, 
                address.street AS street 
         FROM   docdb.customers.customer_addresses),
     shipments 
     AS ( SELECT order_id, 
                 shipment_id, 
                 from_unixtime(cast(shipped_date as double)) as shipment_time,
                 carrier
        FROM lambda_ddb.default.order_shipments),
     payments
     AS ( SELECT "summary:order_id", 
                 "summary:status", 
                 "summary:cc_id", 
                 "details:network" 
        FROM "hbase".hbase_payments.transactions)
         
SELECT _key_            AS redis_order_id, 
       customer_id, 
       customer.email   AS cust_email, 
       "summary:cc_id"  AS credit_card,
       "details:network" AS CC_type,
       "summary:status" AS payment_status,
       status           AS redis_status, 
       addresses.street AS street_address, 
       shipments.shipment_time as shipment_time,
       shipments.carrier as shipment_carrier,
       publicipaddress  AS ec2_order_processor, 
       NAME             AS ec2_state, 
       log_level, 
       order_processor_log 
FROM   active_orders 
       LEFT JOIN logs 
              ON logs.orderid = active_orders._key_ 
       LEFT JOIN order_processors 
              ON logs.log_stream = order_processors.instanceid 
       LEFT JOIN customer 
              ON customer.id = customer_id 
       LEFT JOIN addresses 
              ON addresses.id = address_id 
       LEFT JOIN shipments
              ON shipments.order_id = active_orders._key_
       LEFT JOIN payments
              ON payments."summary:order_id" = active_orders._key_

La siguiente imagen muestra resultados de ejemplo de la consulta.