Instructivo de conocimiento agregado

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

Introducción

Esta página es una guía para implementar el reconocimiento agregado en una situación práctica, lo que incluye identificar oportunidades de implementación, el valor que impulsa el reconocimiento agregado y un flujo de trabajo sencillo para implementarlo 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 en tu base de datos. A veces, se trata de tablas derivadas persistentes (PDT) de Looker.

Es posible que a menudo encuentres tablas o conjuntos de datos muy grandes que, para tener un buen rendimiento, requieran tablas de agregación o de datos integrados.

Por lo general, puedes crear tablas de agregación como una tabla orders_daily con una dimensionalidad limitada. Estos se deben tratar y modelar por separado en Explorar. Además, no forman parte del modelo de forma prolija. Estas limitaciones generan experiencias deficientes del usuario cuando este tiene que elegir entre varias exploraciones 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 informar a Looker cómo usarlas en Exploraciones existentes. Luego, las consultas aprovecharán estas tablas de datos integrados cuando Looker lo considere apropiado, sin ninguna entrada del usuario. Esto reducirá el tamaño de las búsquedas, reducirá 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 conjuntas tienen los mismos requisitos de base de datos y conexión que las 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 enumeran 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 conocimiento agregado

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

• 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.
• Ahorro de costos: Ciertos dialectos se cobran según el tamaño de la consulta en un modelo de consumo. Si Looker consulta 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.
• Impacto reducido de LookML: El reemplazo de las estrategias de reconocimiento agregadas basadas en líquidos 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 hipotética flights 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 exploración. A continuación, se muestra el 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 la exploración de flights y Looker aprovechará automáticamente la tabla de agregación que está definida en LookML y la usará para responder consultas. El usuario no tendrá que informar a Looker de ninguna condición especial: si la tabla es adecuada para los campos que el usuario selecciona, la utilizará.

Los usuarios con permisos see_sql pueden usar los comentarios de la pestaña SQL de una exploración para ver qué tabla conjunta se usará en 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 en qué áreas este reconocimiento puede tener un rol en la optimización o en el valor del reconocimiento agregado.

Identifica 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, Razón de caché en comparación con la base de datos y Tiene un rendimiento inferior al promedio:

En este ejemplo, hay una serie de paneles con un alto uso que tienen un rendimiento peor que la media, como el panel Visualizaciones de muestra. El panel de visualizaciones de muestra usa dos exploraciones, por lo que una buena estrategia sería crear tablas conjuntas para ambas exploraciones.

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

Otra oportunidad para aumentar la visibilidad general 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 acceso directo, puedes abrir el vínculo Explorar del historial de actividad del sistema en un navegador y, luego, reemplazar "nombre de host" en la URL con 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 (a diferencia de las consultas de la API o de las entregas 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 que se suelen seleccionar en las exploraciones que identificaste como lentos y de uso intensivo. 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 observar la cantidad de vuelos programados y la cantidad de vuelos cancelados, y que desean desglosar esos datos por semana y por empresa de transporte. 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 la 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 vale la pena comprender que los tres pueden ser mutuamente excluyentes: es posible que los paneles problemáticos no estén impulsados por las Exploraciones problemáticas, y crear tablas conjuntas con los campos de uso general puede no ayudar a esos paneles en absoluto. Es posible que estas sean tres implementaciones de reconocimiento agregado discreto.

Cómo diseñar tablas conjuntas

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

NOTA: No es necesario que las tablas conjuntas sean una concordancia exacta para que se use tu consulta. Si tu consulta está en el nivel de detalle semanal y tienes una tabla de datos integrados diaria, Looker usará la tabla conjunta en lugar de la tabla sin procesar a nivel de la marca de tiempo. Del mismo modo, si tienes una tabla conjunta completa en los niveles brand y date, y un usuario realiza búsquedas solo a nivel de brand, esa tabla sigue siendo candidata para que Looker la use para el reconocimiento agregado.

El reconocimiento agregado se admite en las siguientes mediciones:

• 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
• Medidas distintas aproximadas: Dialectos que pueden usar la funcionalidad HyperLogLog

No se admite el reconocimiento agregado para las siguientes mediciones:

• Medidas distintas: Debido a que la distinción se puede calcular solo en datos atómicos no agregados, las mediciones *_DISTINCT no se admiten fuera de estas aproximadas 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 consulta 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 coincidencia exacta de una consulta. Se puede usar una tabla conjunta que es una coincidencia exacta de la consulta para responder una consulta con tipos de mediciones que, de otro modo, no serían compatibles con el reconocimiento agregado.

Nivel de detalle agregado de la tabla

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 utilizados en la consulta (ya sean seleccionados o filtrados) deben estar en la tabla de datos agregados para que la tabla pueda usarse en la consulta. Sin embargo, como se mencionó antes, la tabla de datos agregados no tiene que ser una coincidencia exacta para una consulta que se use en ella. Puedes abordar muchas consultas de usuarios potenciales en una sola tabla conjunta y aun así observar grandes aumentos en el 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 conjunta para flights_by_week_and_carrier generará un uso de tabla conjunta más frecuente que dos tablas conjuntas diferentes en las tablas flights_by_week y flights_by_carrier.

A continuación, se muestra un ejemplo de una tabla conjunta que podemos crear para consultas sobre 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 exploración de los campos Flights Depart Week, Flights Details Carrier, Flights Count y Flights Detail Cancelled Count de la tabla global flights_by_week_and_carrier:

Ejecutar esta consulta desde la tabla de la base de datos original llevó 15.8 segundos y analizó 38 millones de filas sin uniones mediante Amazon Redshift. Cambiar la consulta, que sería una operación normal del usuario, tardó 29.5 segundos.

Después de implementar la tabla conjunta flights_by_week_and_carrier, la consulta posterior tardó 7.2 segundos y analizó 4,592 filas. Esta es 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 los 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 13,517 veces.

Incluso si estimamos de forma moderada que el 25% de estas consultas utilizó los 4 campos de la manera más sencilla (selección simple, sin dinamización), 3,379 x 8.6 segundos = 8 horas, 4 minutos de tiempo de espera total del usuario eliminados.

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 exploración más usada 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 compilación de la tabla conjunta tardó 17.9 segundos.

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 con mejores prácticas de modelado.

versus

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

Verás una disminución en los retornos de tus esfuerzos a medida que intentes aprovechar al máximo el rendimiento de Looker y tu base de datos. Siempre debes tener en cuenta las expectativas de rendimiento de referencia, en especial de los usuarios empresariales, y las limitaciones impuestas por tu base de datos (como la simultaneidad, los límites de consultas, 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 dará como resultado una tabla conjunta más grande y lenta. Las tablas más grandes pueden optimizar más consultas y, por lo tanto, usarse en más situaciones, pero las tablas grandes no serán tan rápidas como las 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;;
      }
    }
  }

Como resultado, la tabla conjunta se utilizará para cualquier combinación de dimensiones mostradas y para cualquiera de las mediciones incluidas, por lo que esta tabla se puede utilizar para responder muchas búsquedas diferentes de los usuarios. Sin embargo, usar esta tabla para una consulta simple SELECT 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, hay rendimientos decrecientes a medida que incluyes más campos en tu tabla agregada para aumentar su aplicabilidad a más búsquedas.

Cómo compilar tablas conjuntas

Si tomamos nuestro ejemplo de exploración de Vuelos que identificamos como una oportunidad de optimización, la mejor estrategia sería crear tres tablas conjuntas diferentes:

• 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 en una tabla conjunta que se usa 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 creará tus tablas conjuntas 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 creó 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 el reconocimiento agregado si deseas obtener detalles y conocer las condiciones que se deben cumplir para unir datos recientes y agregar consultas de tablas.

Resumen

En resumen, para crear una implementación global de reconocimiento, se deben seguir 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.