Tutorial de Aggregate Awareness

Para obtener más información, consulta la página de documentación Conciencia agregada.

Introducción

En esta página se explica cómo implementar la función de reconocimiento de agregaciones en un caso práctico, lo que incluye identificar oportunidades de implementación, el valor que aporta esta función y un flujo de trabajo sencillo para implementarla en un modelo real. En esta página no se explica en detalle todas las funciones de conocimiento agregado ni todos los casos límite, ni tampoco se ofrece un catálogo exhaustivo de todas sus funciones.

¿Qué es la notoriedad agregada?

En Looker, las consultas se realizan principalmente en tablas o vistas sin procesar de tu base de datos. A veces, se trata de tablas derivadas persistentes (PDTs) de Looker.

A menudo, te encontrarás con conjuntos de datos o tablas muy grandes que, para ofrecer un buen rendimiento, requieren tablas de agregación o resúmenes.

Normalmente, puede crear tablas de agregación, como una orders_daily que contenga una dimensionalidad limitada. Estos datos deben tratarse y modelarse por separado en Explorar, y no encajan bien en el modelo. Estas limitaciones provocan experiencias de usuario deficientes cuando el usuario tiene que elegir entre varias Exploraciones para los mismos datos.

Ahora, con la función de agregación de Looker, puedes preconstruir tablas agregadas con varios niveles de granularidad, dimensionalidad y agregación, e indicar a Looker cómo usarlas en Exploraciones. Las consultas utilizarán estas tablas de resumen cuando Looker lo considere oportuno, sin que el usuario tenga que hacer nada. De esta forma, se reducirá el tamaño de las consultas, los tiempos de espera y se mejorará la experiencia de los usuarios.

NOTA: Las tablas agregadas de Looker son un tipo de tabla derivada persistente (PDT). Esto significa que las tablas agregadas tienen los mismos requisitos de base de datos y conexión que las PDTs.

Para saber si tu dialecto de base de datos y tu conexión de Looker admiten PDTs, consulta los requisitos que se indican en la página de documentación Tablas derivadas en Looker.

Para saber si tu dialecto de base de datos admite la función de reconocimiento de agregaciones, consulta la página de documentación Reconocimiento de agregaciones.

El valor de la notoriedad agregada

Hay varias propuestas de valor significativas que ofrecen una mayor notoriedad para obtener más valor de tu modelo de Looker:

• Mejora del rendimiento: al implementar la agregación de la notoriedad, las consultas de los usuarios serán más rápidas. Looker usará una tabla más pequeña si contiene los datos necesarios para completar la consulta del usuario.
• Ahorro de costes: algunos dialectos cobran por el tamaño de la consulta según un modelo de consumo. Si Looker consulta tablas más pequeñas, el coste por consulta de usuario será menor.
• Mejora de la experiencia de usuario: además de ofrecer una experiencia mejorada que obtiene respuestas más rápido, la consolidación elimina la creación redundante de Exploraciones.
• Menor espacio de LookML: al sustituir las estrategias de conocimiento de agregaciones basadas en Liquid por una implementación nativa y flexible, se consigue una mayor resiliencia y se producen menos errores.
• Aprovechar el LookML que ya tiene: las tablas agregadas usan el objeto query, que reutiliza la lógica modelada en lugar de duplicarla con SQL personalizado explícito.

Ejemplo básico

A continuación, se muestra una implementación muy sencilla en un modelo de Looker para demostrar lo ligero que puede ser el reconocimiento de agregaciones. Dada una tabla flights hipotética en la base de datos con una fila por cada vuelo registrado en la FAA, podemos modelar esta tabla en Looker con su propia vista y Exploración. A continuación, se muestra el código LookML de una tabla de datos agregados que podemos definir para la Exploración:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Con esta tabla agregada, un usuario puede consultar la flights exploración y Looker aprovechará automáticamente la tabla agregada definida en LookML y la usará para responder a las consultas. El usuario no tendrá que informar a Looker de ninguna condición especial: si la tabla se ajusta a los campos que selecciona el usuario, Looker la usará.

Los usuarios con permisos de see_sql pueden usar los comentarios de la pestaña SQL de un Exploración para ver qué tabla agregada se usará en una consulta. Aquí tienes un ejemplo de la pestaña SQL de Looker de una consulta que usa la tabla agregada flights:flights_by_week_and_carrier in teach_scratch:

Consulta la página de documentación Conciencia de agregación para obtener información sobre cómo determinar si se usan tablas agregadas en una consulta.

Identificar oportunidades

Para maximizar los beneficios de la notoriedad agregada, debe identificar en qué casos puede influir en la optimización o en el valor de la notoriedad agregada.

Identificar los paneles de control con un tiempo de ejecución elevado

Una buena oportunidad para aumentar la visibilidad agregada es crear tablas agregadas para los paneles de control que se usan mucho y que tienen un tiempo de ejecución muy alto. Es posible que tus usuarios te informen de que los paneles de control van lentos, pero si tienes see_system_activity, también puedes usar la función Explorar historial de actividad del sistema de Looker para encontrar los paneles de control que tienen un tiempo de ejecución más lento que la media. Para ir más rápido, puedes abrir este enlace de Exploración del historial de actividad del sistema en un navegador y, a continuación, sustituir "hostname" en la URL por el nombre de tu instancia de Looker. Verás una visualización Explorar con datos sobre los paneles de control de tu instancia, como Título, Historial, Número de exploraciones, Relación entre caché y base de datos y ¿El rendimiento es peor que la media?

En este ejemplo, hay varios paneles de control con un uso elevado que tienen un rendimiento inferior a la media, como el panel Visualizaciones de ejemplo. El panel Visualizaciones de ejemplo usa dos Exploraciones, por lo que una buena estrategia sería crear tablas agregadas para ambas Exploraciones.

Identificar las Exploraciones que son lentas y que los usuarios consultan con frecuencia

Otra oportunidad para aumentar la concienciación agregada son las Exploraciones que los usuarios consultan con frecuencia y que tienen una respuesta de consulta inferior a la media.

Puede usar el Historial de actividad del sistema Exploraciones como punto de partida para identificar oportunidades de optimización de Exploraciones. Como alternativa, puedes abrir el enlace Explorar del historial de actividad del sistema en un navegador y, a continuación, sustituir "hostname" en la URL por el nombre de tu instancia de Looker. Verás una visualización Exploración con datos sobre las Exploraciones de tu instancia, como Exploración, Modelo, Número de ejecuciones de consultas, Número de usuarios y Tiempo de ejecución medio en segundos:

En Exploraciones del historial, puede identificar los siguientes tipos de Exploraciones en su instancia:

• Exploraciones consultadas por los usuarios (en lugar de consultas de la API o consultas de entregas programadas)
• Exploraciones que se consultan a menudo
• Exploraciones con un rendimiento bajo (en comparación con otras Exploraciones)

En el ejemplo anterior de Exploraciones del historial de actividad del sistema, las Exploraciones flights y order_items son candidatas probables para la implementación de la agregación.

Identificar los campos que se usan mucho en las consultas

Por último, puede identificar otras oportunidades a nivel de datos si sabe qué campos suelen incluir los usuarios en las consultas y los filtros.

Usa la exploración Uso de campos de actividad del sistema para identificar los campos que se seleccionan con frecuencia en las exploraciones que has identificado como lentas y con un uso elevado. Como alternativa, puedes abrir este enlace de Exploración de uso de campos de actividad del sistema en un navegador y, a continuación, sustituir "hostname" en la URL por el nombre de tu instancia de Looker. Sustituye los filtros según corresponda. Verá una exploración con una visualización de gráfico de barras que indica el número de veces que se ha usado un campo en una consulta:

En el ejemplo de Exploración de actividad del sistema que se muestra en la imagen, puedes ver que flights.count y flights.depart_week son los dos campos que se seleccionan con más frecuencia en la exploración. Por lo tanto, estos campos son buenos candidatos para incluirlos en las tablas agregadas.

Los datos concretos como estos son útiles, pero hay elementos subjetivos que guiarán tus criterios de selección. Por ejemplo, si observa los cuatro campos anteriores, puede suponer que los usuarios suelen consultar el número de vuelos programados y el número de vuelos cancelados, y que quieren desglosar esos datos por semana y por aerolínea. Este es un ejemplo de una combinación clara, lógica y real de campos y métricas.

Resumen

Los pasos que se indican en esta página de documentación deberían servirte de guía para encontrar los paneles, los Exploraciones y los campos que se deben tener en cuenta para la optimización. También es importante tener en cuenta que los tres pueden ser mutuamente excluyentes: es posible que los paneles problemáticos no se basen en las Exploraciones problemáticas y que la creación de tablas agregadas con los campos que se usan habitualmente no ayude en absoluto a esos paneles. Es posible que se trate de tres implementaciones de la notoriedad agregada independientes.

Diseñar tablas de datos agregados

Una vez que haya identificado las oportunidades de concienciación agregada, puede diseñar tablas agregadas que se adapten mejor a estas oportunidades. Consulta la página de documentación Conocimiento agregado para obtener información sobre los campos, las métricas y los periodos admitidos en las tablas agregadas, así como otras directrices para diseñar tablas agregadas.

NOTA: No es necesario que las tablas agregadas coincidan exactamente con su consulta para que se puedan usar. Si tu consulta tiene una granularidad semanal y tienes una tabla de acumulación diaria, Looker usará tu tabla agregada en lugar de tu tabla sin procesar a nivel de marca de tiempo. Del mismo modo, si tiene una tabla agregada que se ha acumulado hasta el nivel brand y date y un usuario hace una consulta solo a nivel de brand, esa tabla sigue siendo apta para que Looker la use para la detección de agregaciones.

Se admite la agregación de la notoriedad en las siguientes métricas:

• Métricas estándar: métricas de tipo SUM, COUNT, AVERAGE, MIN y MAX.
• Métricas compuestas: métricas de tipo NUMBER, STRING, YESNO y DATE
• Medidas de recuento de valores distintos aproximado: dialectos que pueden usar la función HyperLogLog

No se admite la agregación de la visibilidad en las siguientes métricas:

• Métricas distintas: como la distinción solo se puede calcular en datos atómicos no agregados, las métricas *_DISTINCT no se admiten fuera de estas aproximaciones que usan HyperLogLog.
• Medidas basadas en la cardinalidad: al igual que las medidas distintas, las medianas y los percentiles no se pueden preagregar y no se admiten. 

NOTA: Si conoce una posible consulta de usuario con tipos de medida que no son compatibles con la función de conocimiento agregado, puede crear una tabla agregada que coincida exactamente con una consulta. Se puede usar una tabla agregada que coincida exactamente con la consulta para responder a una consulta con tipos de medida que, de lo contrario, no se admitirían para el reconocimiento agregado.

Granularidad de la tabla de datos agregados

Antes de crear tablas para combinaciones de dimensiones y medidas, debes determinar los patrones de uso y la selección de campos habituales para crear tablas agregadas que se usen con la mayor frecuencia posible y que tengan el mayor impacto. Ten en cuenta que todos los campos utilizados en la consulta (ya sean seleccionados o filtrados) deben estar en la tabla agregada para que se pueda usar en la consulta. Sin embargo, como se ha indicado anteriormente, la tabla agregada no tiene que coincidir exactamente con una consulta para poder usarse en ella. Puedes responder a muchas consultas de usuarios potenciales en una sola tabla agregada y seguir disfrutando de grandes mejoras en el rendimiento.

En el ejemplo de identificación de los campos que se usan mucho en las consultas, hay dos dimensiones (flights.depart_week y flights.carrier) que se seleccionan con mucha frecuencia, así como dos métricas (flights.count y flights.cancelled_count). Por lo tanto, sería lógico crear una tabla agregada que use los cuatro campos. Además, si crea una sola tabla agregada para flights_by_week_and_carrier, se usará con más frecuencia que si crea dos tablas agregadas diferentes para las tablas flights_by_week y flights_by_carrier.

Aquí tienes un ejemplo de tabla agregada que podríamos crear para las consultas de los campos comunes:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Los usuarios de tu empresa, las pruebas anecdóticas y los datos de la actividad del sistema de Looker pueden ayudarte a tomar decisiones.

Equilibrar la aplicabilidad y el rendimiento

En el siguiente ejemplo se muestra una consulta de Exploración de los campos Semana de salida de los vuelos, Detalles de la aerolínea de los vuelos, Número de vuelos y Número de vuelos cancelados detallado de la tabla agregada flights_by_week_and_carrier:

Ejecutar esta consulta desde la tabla de base de datos original llevó 15,8 segundos y se analizaron 38 millones de filas sin ninguna combinación mediante Amazon Redshift. Cambiar la consulta, que sería una operación normal del usuario, ha llevado 29,5 segundos.

Después de implementar la tabla agregada flights_by_week_and_carrier, la consulta posterior tardó 7,2 segundos y analizó 4592 filas. Esto supone una reducción del 99,98% en el tamaño de la tabla. La consulta tardó 9,8 segundos en cambiar.

En la exploración "Uso de campos de actividad del sistema", podemos ver con qué frecuencia incluyen nuestros usuarios estos campos en las consultas. En este ejemplo, flights.count se ha usado 47.848 veces, flights.depart_week, 18.169 veces, flights.cancelled_count, 16.570 veces y flights.carrier, 13.517 veces.

Aunque estimáramos de forma muy modesta que el 25% de estas consultas usaban los cuatro campos de la forma más sencilla (una selección simple, sin tabla dinámica), 3379 × 8, 6 segundos = 8 horas y 4 minutos de tiempo de espera total de los usuarios.

NOTA: El modelo de ejemplo que se usa aquí es muy básico. Estos resultados no deben usarse como referencia para tu modelo.

Después de aplicar el mismo flujo a nuestro modelo de comercio electrónico order_items — la Exploración más utilizada en la instancia—, los resultados son los siguientes:

Los campos usados en la consulta y en la tabla agregada posterior fueron brand, created_date, orders_count y total_revenue, con dos combinaciones. Los campos se habían usado un total de 11.000 veces. Si se estima el mismo uso combinado de aproximadamente el 25%, el ahorro total para los usuarios sería de 6 horas y 6 minutos (8 s * 2750 = 22.000 s). La tabla de datos agregados ha tardado 17,9 segundos en crearse.

Si analizamos estos resultados, merece la pena dedicar un momento a reflexionar y evaluar los beneficios que se pueden obtener de lo siguiente:

• Optimizar modelos o Exploraciones más grandes y complejos que tengan un rendimiento "aceptable" y que puedan mejorar su rendimiento con mejores prácticas de modelización

frente a

• Usar la información agregada para optimizar modelos más sencillos que se usan con más frecuencia y que tienen un rendimiento bajo

Verá rendimientos decrecientes a medida que intente obtener el último bit de rendimiento de Looker y su base de datos. Siempre debes tener en cuenta las expectativas de rendimiento básicas, sobre todo las de los usuarios empresariales, y las limitaciones impuestas por tu base de datos (como la simultaneidad, los umbrales de consulta, los costes, etc.). No esperes que la notoriedad agregada supere estas limitaciones.

Además, al diseñar una tabla agregada, recuerda que cuantos más campos tenga, más grande y lenta será. Las tablas más grandes pueden optimizar más consultas y, por lo tanto, se pueden usar en más situaciones, pero no serán tan rápidas como las tablas más pequeñas y sencillas.

Por ejemplo:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week,flights.distance, flights.arrival_week,flights.cancelled]
        measures: [cancelled_count, count, flights.average_distance, flights.total_distance]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

De esta forma, la tabla agregada se usará para cualquier combinación de dimensiones que se muestre y para cualquiera de las medidas incluidas, por lo que se podrá usar para responder a muchas consultas de usuarios diferentes. Sin embargo, para usar esta tabla en una consulta SELECT sencilla de carrier y count, se necesitaría analizar una tabla de 885.000 filas. Por el contrario, la misma consulta solo requeriría un análisis de 4592 filas si la tabla se basara en dos dimensiones. La tabla de 885.000 filas sigue siendo una reducción del 97% en el tamaño de la tabla (de las 38 millones de filas anteriores), pero al añadir una dimensión más, el tamaño de la tabla aumenta a 20 millones de filas. Por lo tanto, los resultados son cada vez menores a medida que incluye más campos en la tabla agregada para aumentar su aplicabilidad a más consultas.

Crear tablas de datos agregados

Tomando como ejemplo la función Vuelos, que hemos identificado como una oportunidad de optimización, la mejor estrategia sería crear tres tablas agregadas diferentes:

• flights_by_week_and_carrier
• flights_by_month_and_distance
• flights_by_year

La forma más sencilla de crear estas tablas de datos agregados es obtener el LookML de la tabla de datos agregados de una consulta Explorar o de un panel de control y añadir el LookML a los archivos de tu proyecto de Looker.

Una vez que añadas las tablas agregadas a tu proyecto de LookML y despliegues las actualizaciones en producción, tus Exploraciones aprovecharán las tablas agregadas para las consultas de tus usuarios.

Persistencia

Para que se puedan usar en las estadísticas agregadas, las tablas agregadas deben conservarse en tu base de datos. Te recomendamos que alinees la regeneración automática de estas tablas agregadas con tu política de almacenamiento en caché aprovechando los grupos de datos. Debe usar el mismo grupo de datos para una tabla agregada que se utilice en la exploración asociada. Si no puedes usar grupos de datos, puedes usar el parámetro sql_trigger_value. A continuación, se muestra un valor genérico basado en la fecha de sql_trigger_value:

sql_trigger_value: SELECT CURRENT_DATE() ;;

De esta forma, las tablas agregadas se crearán automáticamente cada día a medianoche.

Lógica de plazos

Cuando Looker crea una tabla agregada, incluye los datos hasta el momento en que se creó la tabla agregada. Los datos que se hayan añadido posteriormente a la tabla base de la base de datos normalmente se excluirían de los resultados de una consulta que use esa tabla agregada.

En este diagrama se muestra la cronología de cuándo se recibieron los pedidos y se registraron en la base de datos en comparación con el momento en el que se creó la tabla agregada Pedidos. Hoy se han recibido dos pedidos que no aparecerán en la tabla agregada Pedidos, ya que se han recibido después de que se creara la tabla agregada:

Sin embargo, Looker puede UNIR datos recientes a la tabla agregada cuando un usuario consulta un periodo que se solapa con la tabla agregada, tal como se muestra en el mismo diagrama cronológico:

Como Looker puede unir datos actualizados a una tabla agregada, si un usuario filtra por un periodo que se solapa con el final de la tabla agregada y de la tabla base, los pedidos recibidos después de crear la tabla agregada se incluirán en los resultados del usuario. Consulte la página de documentación Conciencia agregada para obtener información sobre las condiciones que deben cumplirse para unir datos recientes a las consultas de tablas agregadas.

Resumen

En resumen, para crear una implementación de notoriedad total, hay tres pasos fundamentales:

1. Identifica las oportunidades en las que la optimización mediante tablas agregadas es adecuada y tiene un gran impacto.
2. Diseña tablas conjuntas que ofrezcan la mayor cobertura posible para las consultas de usuario habituales, pero que sigan siendo lo suficientemente pequeñas como para reducir el tamaño de esas consultas.
3. Crea las tablas agregadas en el modelo de Looker, emparejando la persistencia de la tabla con la persistencia de la caché de Exploración.