Instructivo de conocimiento agregado

Para obtener más detalles, consulta la página de documentación sobre la Concienciación agregada.

Introducción

Esta página es una guía para implementar la visibilidad agregada en una situación práctica, lo que incluye identificar oportunidades de implementación, los valores que genera la visibilidad agregada y un flujo de trabajo simple para implementarla en un modelo real. Esta página no es una explicación detallada de todas las funciones de conocimiento agregado ni de los casos extremos, ni tampoco es un catálogo exhaustivo de todas sus funciones.

¿Qué es el conocimiento agregado?

En Looker, la mayoría de las consultas se realizan en tablas o vistas sin procesar de tu base de datos. A veces, se trata de tablas derivadas persistentes (PDT) de Looker.

A menudo, puedes encontrar conjuntos de datos o tablas muy grandes que, para tener un buen rendimiento, requieren tablas de agregación o resúmenes.

Por lo general, puedes crear tablas de agregación, como una tabla orders_daily, que contiene una dimensionalidad limitada. Estos deben tratarse y modelarse por separado en Explorar, y no se ubican en el modelo de forma ordenada. Estas limitaciones generan experiencias del usuario deficientes cuando el usuario debe elegir entre varios Explorar para los mismos datos.

Ahora, con el conocimiento agregado de Looker, puedes preconstruir tablas agregadas en varios niveles de detalle, dimensionalidad y agregación, y puedes informarle a Looker cómo usarlas en Exploraciones existentes. Luego, las consultas aprovecharán estas tablas de resumen cuando Looker lo considere apropiado, sin ninguna entrada del usuario. Esto reducirá el tamaño de la consulta, los tiempos de espera y mejorará la experiencia del usuario.

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

Para ver si el dialecto de tu base de datos y la conexión de Looker pueden admitir PDT, consulta los requisitos que se indican en la página de documentación Tablas derivadas en Looker.

Para ver si tu dialecto de base de datos admite el conocimiento agregado, consulta la página de documentación Conocimiento agregado.

El valor del reconocimiento agregado

Existen varias ofertas de conocimiento agregado de propuestas de valor significativas para generar valor adicional a partir de tu modelo existente de Looker:

• Mejora del rendimiento: La implementación del conocimiento agregado hará que las consultas de los usuarios sean más rápidas. Looker usará una tabla más pequeña si contiene los datos necesarios para completar la consulta del usuario.
• Ahorros en costos: Algunos dialectos cobran según el tamaño de la consulta en un modelo de consumo. Si permites que Looker consulte tablas más pequeñas, reducirás el costo por consulta del usuario.
• Mejora de la experiencia del usuario: Además de una experiencia mejorada que recupera respuestas más rápido, la consolidación elimina la creación redundante de Explorar.
• Menor huella de LookML: Reemplazar las estrategias de conocimiento agregado existentes basadas en Liquid por una implementación nativa y flexible genera una mayor resiliencia y menos errores.
• Capacidad de aprovechar LookML existente: Las tablas agregadas usan el objeto query, que reutiliza la lógica modelada existente en lugar de duplicar la lógica con SQL personalizado explícito.

Ejemplo básico

A continuación, se muestra una implementación muy simple en un modelo de Looker para demostrar lo ligera que puede ser la información agregada. Dada una tabla flights hipotética en la base de datos con una fila para cada vuelo registrado a través de la FAA, podemos modelar esta tabla en Looker con su propia vista y Explorar. Este es el código de LookML de una tabla conjunta 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 conjunta, un usuario puede consultar flights Explorar y Looker aprovechará automáticamente la tabla conjunta que se define en LookML y la usará para responder las consultas. El usuario no tendrá que informar a Looker sobre ninguna condición especial: si la tabla es adecuada para 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 una exploración para ver qué tabla agregada se usará para una consulta. Este es un ejemplo de la pestaña SQL de Looker para una consulta que usa la tabla agregada flights:flights_by_week_and_carrier in teach_scratch:

Consulta la página de documentación Aggregate awareness para obtener detalles sobre cómo determinar si se usan tablas agregadas para una consulta.

Identificación de oportunidades

Para maximizar los beneficios del reconocimiento agregado, debes identificar dónde puede desempeñar un papel en la optimización o en la generación del valor del reconocimiento agregado.

Identifica los paneles con un entorno de ejecución alto

Una gran oportunidad para aumentar la visibilidad de los datos agregados es crear tablas agregadas para paneles de uso intensivo con un tiempo de ejecución muy alto. Es posible que tus usuarios te informen sobre paneles lentos, pero si tienes see_system_activity, también puedes usar la Exploración del historial de actividad del sistema de Looker para encontrar paneles con un tiempo de ejecución más lento que el promedio. Como atajo, puedes abrir este vínculo de exploración del historial de actividad del sistema en un navegador y, luego, reemplazar "hostname" en la URL por el nombre de tu instancia de Looker. Verás una visualización de Explorar con datos sobre los paneles de tu instancia, incluidos Título, Historial, Cantidad de exploraciones, Proporción de caché en comparación con la base de datos y Rendimiento inferior al promedio:

En este ejemplo, hay varios paneles con un alto porcentaje de uso que tienen un rendimiento inferior al promedio, 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.

Identifica las exploraciones que son lentas y que los usuarios consultan con frecuencia

Otra oportunidad para aumentar la visibilidad agregada es con las Exploraciones que los usuarios consultan con frecuencia y que tienen una respuesta a la consulta inferior al promedio.

Puedes usar la Exploración del historial de actividad del sistema como punto de partida para identificar oportunidades de optimización de las exploraciones. Como atajo, puedes abrir el vínculo Explorar el historial de actividad del sistema en un navegador y, luego, reemplazar "hostname" en la URL por el nombre de tu instancia de Looker. Verás una visualización de Explorar con datos sobre las exploraciones de tu instancia, incluidos Explorar, Modelo, Cantidad de ejecuciones de consultas, Cantidad de usuarios y Tiempo de ejecución promedio en segundos:

En la exploración de historial, puedes identificar los siguientes tipos de exploraciones en tu instancia:

• Exploraciones que consultan los usuarios (en lugar de consultas de la API o de publicaciones programadas)
• Exploraciones que se consultan con frecuencia
• Exploraciones que tienen un bajo rendimiento (en comparación con otras exploraciones)

En el ejemplo anterior de Explorar historial de actividad del sistema, las exploraciones flights y order_items son posibles candidatos para la implementación de la divulgación agregada.

Identifica los campos que se usan mucho en las consultas

Por último, puedes identificar otras oportunidades a nivel de los datos si comprendes los campos que los usuarios suelen incluir en las consultas y los filtros.

Usa la exploración Uso de campos de actividad del sistema para comprender los campos seleccionados con mayor frecuencia en las exploraciones que identificaste como lentos y de gran uso. Como atajo, puedes abrir este vínculo de exploración de uso del campo de actividad del sistema en un navegador y, luego, reemplazar "hostname" en la URL por el nombre de tu instancia de Looker. Reemplaza los filtros según corresponda. Verás una exploración con una visualización de gráfico de barras que indica la cantidad de veces que se usó 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 más seleccionados para la exploración. Por lo tanto, esos campos son buenos candidatos para incluir 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 observas los cuatro campos anteriores, puedes suponer con seguridad que los usuarios suelen consultar la cantidad de vuelos programados y la cantidad de vuelos cancelados, y que quieren desglosar esos datos por semana y por empresa. 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 deben servir como guía para encontrar los paneles, las exploraciones y los campos que se deben tener en cuenta para la optimización. También es importante comprender que los tres pueden ser mutuamente excluyentes: es posible que los paneles problemáticos no se basen en Exploraciones problemáticas, y que crear tablas agregadas con los campos de uso general no ayude en absoluto a esos paneles. Es posible que estas sean tres implementaciones de reconocimiento agregado discreto.

Cómo diseñar tablas conjuntas

Después de identificar las oportunidades de reconocimiento agregado, puedes diseñar tablas agregadas que aborden mejor estas oportunidades. Consulta la página de documentación Conocimiento agregado para obtener información sobre los campos, las medidas y los períodos admitidos en las tablas agregadas, así como otros lineamientos para diseñarlas.

NOTA: Las tablas agregadas no tienen que ser una concordancia exacta para que se use tu consulta. Si tu consulta tiene el nivel de detalle de la semana y tienes una tabla de resumen diaria, Looker usará tu tabla agregada en lugar de tu tabla sin procesar a nivel de la marca de tiempo. Del mismo modo, si tienes una tabla agregada consolidada hasta el nivel brand y date, y un usuario realiza consultas solo a nivel de brand, esa tabla sigue siendo una candidata para que Looker la use para la visibilidad agregada.

La visibilidad agregada es compatible con las siguientes medidas:

• Métricas estándares: Métricas del tipo SUM, COUNT, AVERAGE, MIN y MAX
• Métricas compuestas: Métricas de tipo NUMBER, STRING, YESNO y DATE
• Mediciones distintas aproximadas: Son dialectos que pueden usar la funcionalidad de HyperLogLog.

La visibilidad agregada no es compatible con las siguientes medidas:

• Mediciones distintas: Debido a que la distinción solo se puede calcular en datos atómicos no agregados, las mediciones *_DISTINCT no se admiten fuera de estas aproximaciones que usan HyperLogLog.
• Métricas basadas en la cardinalidad: Al igual que con las medidas distintas, las medianas y los percentiles no se pueden agregar previamente y no son compatibles. 

NOTA: Si conoces una posible búsqueda del usuario con tipos de medición que no son compatibles con el conocimiento agregado, este es un caso en el que te recomendamos crear una tabla agregada que sea una concordancia exacta de una búsqueda. Se puede usar una tabla agregada que sea una concordancia exacta de la consulta para responder una consulta con tipos de medición que, de otro modo, no serían compatibles con el reconocimiento agregado.

Nivel de detalle de la tabla conjunta

Antes de crear tablas para combinaciones de dimensiones y medidas, debes determinar los patrones de uso y selección de campos comunes para crear tablas agregadas que se usen con la mayor frecuencia posible y con el mayor impacto. Ten en cuenta que todos los campos que se usan en la consulta (ya sea que se seleccionen o filtren) deben estar en la tabla agregada para que se use en la consulta. Sin embargo, como se señaló anteriormente, la tabla agregada no tiene que ser una coincidencia exacta para que se use en una consulta. Puedes abordar muchas consultas potenciales de los usuarios en una sola tabla agregada y, aun así, obtener grandes mejoras de rendimiento.

En el ejemplo de identificación de 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 medidas (flights.count y flights.cancelled_count). Por lo tanto, sería lógico crear una tabla agregada que use los cuatro campos. Además, crear una sola tabla agregada para flights_by_week_and_carrier generará un uso más frecuente de la tabla agregada que dos tablas agregadas diferentes para las tablas flights_by_week y flights_by_carrier.

Este es un ejemplo de una tabla agregada que podríamos crear para las consultas en 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, la evidencia anecdótica y los datos de la actividad del sistema de Looker pueden ayudarte a guiar tu proceso de toma de decisiones.

Equilibrar la aplicabilidad y el rendimiento

En el siguiente ejemplo, se muestra una consulta de Explorar de los campos Flights Depart Week, Flights Details Carrier, Flights Count y Flights Detailed Cancelled Count de la tabla agregada flights_by_week_and_carrier:

Ejecutar esta consulta desde la tabla de la base de datos original tardó 15.8 segundos y analizó 38 millones de filas sin ninguna unión con Amazon Redshift. Pivotar la consulta, que sería una operación normal del usuario, tardó 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 representa una reducción del 99.98% en el tamaño de la tabla. El giro de la consulta tardó 9.8 segundos.

En la exploración de uso del campo de actividad del sistema, podemos ver la frecuencia con la que nuestros usuarios incluyen estos campos en las consultas. En este ejemplo, flights.count se usó 47,848 veces, flights.depart_week se usó 18,169 veces, flights.cancelled_count se usó 16,570 veces y flights.carrier se usó 13,517 veces.

Incluso si estimamos de forma muy modesta que el 25% de estas consultas usaba los 4 campos de la forma más sencilla (selección simple, sin pivotar), 3379 × 8.6 segundos = 8 horas y 4 minutos en tiempo de espera total del usuario eliminado.

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

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

Fuente	Tiempo de consulta	Filas analizadas
Tabla base	13.1 segundos	285,000
Tabla conjunta	5.1 segundos	138,000
Delta	8 segundos	147,000

Los campos que se usaron en la consulta y 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 alrededor del 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 tardó 17.9 segundos en compilarse.

Si observas estos resultados, vale la pena tomarse un momento para evaluar los rendimientos que podrías obtener de las siguientes acciones:

• Optimiza modelos o Exploraciones más grandes y complejos que tienen un rendimiento "aceptable" y que pueden ver mejoras en el rendimiento a partir de mejores prácticas de modelado.

versus

• Usar el conocimiento agregado para optimizar modelos más simples que se usan con más frecuencia y tienen un rendimiento bajo

Verás rendimientos decrecientes a medida que intentes obtener el último porcentaje de rendimiento de Looker y tu base de datos. Siempre debes tener en cuenta las expectativas de rendimiento del modelo de referencia, en particular de los usuarios empresariales, y las limitaciones que impone tu base de datos (como la simultaneidad, los umbrales de consulta, el costo, etcétera). No debes esperar que la visibilidad agregada supere estas limitaciones.

Además, cuando diseñes una tabla agregada, recuerda que tener más campos generará una tabla agregada más grande y lenta. 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 simples.

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;;
      }
    }
  }

Esto hará que se use la tabla agregada para cualquier combinación de dimensiones que se muestre y para cualquiera de las medidas incluidas, de modo que se pueda usar para responder muchas consultas de los usuarios diferentes. Sin embargo, usar esta tabla para una consulta SELECT simple de carrier y count requeriría un análisis de una tabla de 885,000 filas. Por el contrario, la misma consulta solo requeriría un análisis de 4,592 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 agregar una dimensión más aumenta el tamaño de la tabla a 20 millones de filas. Por lo tanto, los rendimientos disminuyen a medida que incluyes más campos en tu tabla agregada para aumentar su aplicabilidad a más consultas.

Cómo compilar tablas conjuntas

Tomando nuestro ejemplo de exploración de Vuelos que identificamos como una oportunidad para optimizar, la mejor estrategia sería crear tres tablas agregadas diferentes para ella:

• flights_by_week_and_carrier
• flights_by_month_and_distance
• flights_by_year

La forma más fácil de compilar estas tablas conjuntas es obtener el código LookML de la tabla conjunta desde una consulta de Explorar o desde un panel y agregarlo a los archivos de tu proyecto de Looker.

Una vez que agregues 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 pueda acceder a ellas para la visibilidad agregada, las tablas agregadas deben persistir en tu base de datos. Se recomienda alinear la regeneración automática de estas tablas agregadas con tu política de almacenamiento en caché aprovechando los datagroups. Debes usar el mismo grupo de datos para una tabla agregada que se use para la exploración asociada. Si no puedes usar los grupos de datos, una opción alternativa es usar el parámetro sql_trigger_value. A continuación, se muestra un valor genérico basado en la fecha para sql_trigger_value:

sql_trigger_value: SELECT CURRENT_DATE() ;;

Esto compilará tus tablas agregadas automáticamente a la medianoche todos los días.

Lógica del período

Cuando Looker compila una tabla conjunta, incluirá datos hasta el momento en que se compiló. Por lo general, los datos que se agregaron posteriormente a la tabla base de la base de datos se excluyen de los resultados de una consulta que usa esa tabla agregada.

En este diagrama, se muestra el cronograma de los pedidos que se recibieron y registraron en la base de datos en comparación con el momento en que se compiló la tabla agregada Orders. Hoy se recibieron dos pedidos que no aparecerán en la tabla agregada Pedidos, ya que se recibieron después de que se compiló la tabla agregada:

Sin embargo, Looker puede UNIR datos actualizados a la tabla agregada cuando un usuario consulta un período que se superpone con la tabla agregada, como se muestra en el mismo diagrama de cronograma:

Debido a que Looker puede UNIR datos actualizados a una tabla agregada, si un usuario filtra un período que se superpone con el final de la tabla agregada y la tabla base, los pedidos recibidos después de que se compiló la tabla agregada se incluirán en los resultados del usuario. Consulta la página de documentación sobre conocimiento agregado para obtener detalles y las condiciones que se deben cumplir para unir datos actualizados a las consultas de tablas agregadas.

Resumen

En resumen, para crear una implementación de conocimiento agregado, hay tres pasos fundamentales:

1. Identifica las oportunidades en las que la optimización con tablas agregadas es apropiada y eficaz.
2. Diseña tablas agregadas que proporcionen la mayor cobertura para las consultas comunes de los usuarios y, al mismo tiempo, sean lo suficientemente pequeñas como para reducir el tamaño de esas consultas lo suficiente.
3. Compila las tablas agregadas en el modelo de Looker y vincula la persistencia de la tabla con la persistencia de la caché de Explorar.