Instructivo sobre reconocimiento agregado

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

Introducción

Esta página es una guía para implementar el reconocimiento agregado en una situación práctica, incluida la identificación de oportunidades de implementación, las iniciativas de reconocimiento del valor agregado y un flujo de trabajo sencillo para implementarla en un modelo real. Esta página no brinda una explicación detallada de todas las funciones de reconocimiento agregadas o casos extremos, ni es un catálogo exhaustivo de todas sus funciones.

¿Qué es el reconocimiento agregado?

En Looker, lo que más haces es realizar consultas en tablas o vistas sin procesar de tu base de datos. A veces, estas son tablas derivadas persistentes (PDT) de Looker.

Es posible que encuentre conjuntos de datos o tablas muy grandes que, para tener un buen rendimiento, requieren tablas de agregación o datos integrados.

Por lo general, puedes crear tablas de agregación como una tabla orders_daily que contenga dimensionalidad limitada. Deben tratarse por separado y modelarse por separado en la exploración. Además, no deben ubicarse en el modelo de forma prolija. Estas limitaciones generan una mala experiencia del usuario cuando tiene que elegir entre varias exploraciones para los mismos datos.

Ahora, con el reconocimiento agregado de Looker, puedes crear previamente tablas conjuntas con varios niveles de detalle, dimensionalidad y agregación, y puedes informarle a Looker cómo usarlas en las 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 conjuntas 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 la 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 de Looker.

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

El valor del reconocimiento agregado

Hay varias propuestas de valor significativas en las ofertas de reconocimiento agregado para generar valor adicional a partir de tu modelo de Looker existente:

• Mejora del rendimiento: Implementar el reconocimiento agregado acelerará las consultas de los usuarios. Looker usará una tabla más pequeña si contiene datos necesarios para completar la consulta del usuario.
• Ahorro de costos: Ciertos dialectos cobran según el tamaño de la consulta en un modelo de consumo. Si haces que Looker consulte tablas más pequeñas, tendrás un costo por consulta de usuario reducido.
• Mejora de la experiencia del usuario: Además de una experiencia mejorada que recupera las respuestas más rápido, la consolidación elimina la creación redundante de Explorar.
• Reducción en la huella de LookML: Reemplazar las estrategias existentes de reconocimiento agregado basadas en líquidos por una implementación nativa y flexible genera una mayor resiliencia y menos errores.
• Capacidad para aprovechar LookML existente: Las tablas conjuntas 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

Esta es una implementación muy simple en un modelo de Looker para demostrar lo ligero que puede ser el reconocimiento agregado. Dada una tabla flights hipotética en la base de datos con una fila para cada vuelo registrado a través del FAA, podemos modelar esta tabla en Looker con su propia vista y exploración. A continuación, se muestra 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 conjunta definida anteriormente y la utilizará para responder consultas. El usuario no tendrá que informar a Looker de ninguna condición especial. Looker solo usará esa tabla si se ajusta a los campos que seleccione el usuario.

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á para una consulta. A continuación, se muestra un ejemplo de pestaña de SQL de Looker para una consulta que usa la tabla conjunta flights:flights_by_week_and_carrier in teach_scratch:

Consulta la página de documentación Reconocimiento agregado para obtener detalles sobre cómo determinar si se usan tablas conjuntas para una consulta.

Identificar oportunidades

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

Identifica paneles con un entorno de ejecución alto

Una gran oportunidad para el reconocimiento global es crear tablas conjuntas para paneles muy usados con un tiempo de ejecución muy alto. Es posible que los usuarios te cuenten sobre los 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 acceso directo, puedes abrir este vínculo Explorar el Historial de actividad del sistema en un navegador y, luego, reemplazar “nombre de host” en la URL por el nombre de tu instancia de Looker. Verás una visualización de Explorar con datos sobre los paneles de la instancia, incluidos Título, Historial, Recuento de exploraciones, La proporción de la caché frente a la base de datos y El rendimiento es peor que el promedio:

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

Identifica las exploraciones que son lentas y que realizan muchas consultas por parte de los usuarios.

Otra oportunidad para generar reconocimiento agregado es con las exploraciones que reciben muchas consultas de los usuarios y que tienen una respuesta a las consultas inferior al promedio.

Puedes usar la función Exploración del historial de actividad del sistema como punto de partida para identificar oportunidades para optimizar las exploraciones. Como acceso directo, puedes abrir el vínculo Explorar el Historial de actividad del sistema en un navegador y, luego, reemplazar “nombre de host” 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, Recuento de ejecuciones de la consulta, Recuento de usuarios y Tiempo de ejecución promedio en segundos:

En Historial de exploraciones, 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 rendimiento bajo (en comparación con otras exploraciones)

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

Identificar los campos que se usan mucho en las consultas

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

Usa la Exploración del uso del campo de la actividad del sistema para comprender los campos que se seleccionan comúnmente en las exploraciones que identificaste anteriormente. Como acceso directo, puedes abrir este vínculo de exploración del uso del campo de la actividad del sistema en un navegador y, luego, reemplazar “nombre de host” en la URL por el nombre de tu instancia de Looker. Reemplaza los filtros según corresponda. Verás una visualización de un gráfico de barras de Explorar que indica la cantidad de veces que se usó un campo en una consulta:

En la exploración de la actividad del sistema que se muestra arriba, puedes ver que flights.count y flights.depart_week son los dos campos que se seleccionan con más frecuencia para la exploración. Por lo tanto, esos son buenos candidatos para los campos que se incluirán en las tablas conjuntas.

Los datos concretos como este 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 comúnmente consultan la cantidad de vuelos programados y la cantidad de vuelos que se cancelaron, 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 anteriores deberían servir como guía para encontrar paneles, exploraciones y campos que se deban considerar 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 que crear tablas conjuntas con los campos de uso común no ayude en absoluto a esos paneles. Es posible que se trate de tres implementaciones discretas de reconocimiento agregado.

Diseño de tablas conjuntas

Una vez que hayas identificado las oportunidades de reconocimiento agregado, puedes diseñar tablas conjuntas que las aborden de la mejor manera. Consulta la página de documentación Reconocimiento total para obtener información sobre los campos, las medidas y los períodos admitidos en las tablas conjuntas, además de otros lineamientos para diseñarlas.

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

El reconocimiento agregado se admite en las siguientes medidas:

• Medidas estándar: medidas de los tipos SUM, COUNT, AVERAGE, MIN y MAX
• Medidas compuestas: medidas de tipo NUMBER, STRING, YESNO y DATE
• Medidas distintas aproximadas: Los dialectos pueden usar la funcionalidad HyperLogLog.

No se admite el reconocimiento agregado para las siguientes medidas:

• Medidas distintas: Debido a que la distinción solo se puede calcular en datos atómicos no agregados, las mediciones de *_DISTINCT no se admiten fuera de estos valores aproximados que usan HyperLogLog.
• Medidas basadas en la cardinalidad: Al igual que con las mediciones distintas, las medianas y los percentiles no se pueden agregar previamente y no se admiten. 

NOTA: Si conoces una posible consulta de usuario con tipos de mediciones que no son compatibles con el reconocimiento agregado, este es un caso en el que te recomendamos crear una tabla conjunta que sea una concordancia exacta de una consulta. Se puede usar una tabla conjunta que coincide exactamente con la consulta para responder una consulta con tipos de mediciones que, de otro modo, no se admitirían para el reconocimiento agregado.

Nivel de detalle de la tabla conjunta

Antes de crear tablas para combinaciones de dimensiones y medidas, debes determinar patrones comunes de uso y selección de campos para crear tablas conjuntas que se usarán con la mayor frecuencia posible con el mayor impacto. Ten en cuenta que todos los campos que se usan en la consulta (ya sean seleccionados o filtrados) deben estar en la tabla conjunta para que la tabla pueda usarse en la consulta. Sin embargo, como ya se mencionó, no es necesario que la tabla conjunta tenga una coincidencia exacta para que una consulta se use en ella. Puedes abordar muchas consultas de usuarios potenciales en una sola tabla conjunta y seguir observando grandes mejoras en el rendimiento.

En el ejemplo anterior de identificación de campos que se usan mucho en las consultas, hay dos dimensiones seleccionadas con mucha frecuencia (flights.depart_week y flights.carrier), así como dos mediciones (flights.count y flights.cancelled_count). Por lo tanto, sería lógico crear una tabla conjunta que utilice estos cuatro campos. Además, la creación de una sola tabla conjunta para flights_by_week_and_carrier dará como resultado un uso más frecuente de la tabla conjunta que dos tablas conjuntas diferentes para las tablas flights_by_week y flights_by_carrier.

A continuación, se muestra un ejemplo de tabla conjunta que podríamos crear para las 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.

Equilibrio entre 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 vuelos de la empresa de transporte, Recuento de vuelos y Recuento detallado de vuelos cancelados de la tabla conjunta 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. La reorientación de 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 siguiente consulta tardó 7.2 segundos y analizó 4,592 filas. Esto representa una reducción del 99.98% en el tamaño de la tabla. La reorientación de la consulta tardó 9.8 segundos.

Desde la exploración del 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 calculamos con un nivel sencillo que el 25% de estas consultas usaron los 4 campos de la manera más simple (selección simple, sin dinámica), 3,379 x 8.6 segundos = 8 horas, 4 minutos de tiempo total de espera del usuario eliminado.

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

Después de aplicar exactamente el mismo flujo a nuestro modelo de comercio electrónico order_items, la exploración que se usa con más frecuencia en la instancia, los resultados son los siguientes:

Fuente	Tiempo de consulta	Filas analizadas
Mesa 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 en la tabla conjunta posterior fueron brand, created_date, orders_count y total_revenue, con dos uniones. Los campos se usaron 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, 6 minutos (8 s * 2,750 = 22,000). La compilación de la tabla conjunta tardó 17.9 segundos.

Al analizar estos resultados, vale la pena tomarse un momento para tomar distancia y evaluar los retornos potencialmente obtenidos gracias a los siguientes recursos:

• Optimizar modelos más grandes y complejos con exploraciones que tienen un rendimiento “aceptable” y pueden observar mejoras en el rendimiento a partir de mejores prácticas de modelado

versus

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

Verás que los retornos de tus iniciativas disminuyen a medida que intentas obtener el último rendimiento de Looker y tu base de datos. Siempre debes conocer las expectativas de rendimiento del modelo de referencia (especialmente para los usuarios empresariales) y las limitaciones impuestas por tu base de datos (como la simultaneidad, los umbrales de consulta, el costo, etcétera). No debes esperar que el reconocimiento agregado supere estas limitaciones.

Además, cuando diseñes una tabla conjunta, recuerda que tener más campos dará como resultado una tabla de agregación más grande y más lenta. Las tablas más grandes pueden optimizar más consultas y, por lo tanto, se pueden usar en más situaciones, pero las tablas grandes 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;;
      }
    }
  }

Como resultado, la tabla conjunta se utilizará para cualquier combinación de dimensiones que se muestra y para cualquiera de las mediciones incluidas, de modo que esta tabla puede usarse para responder muchas consultas diferentes de los usuarios. Sin embargo, usar esta tabla para una consulta simple de SELECT de carrier y count requeriría el análisis de una tabla de 885,000 filas. En cambio, 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 los 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, el retorno disminuye a medida que incluyes más campos en la tabla conjunta para aumentar su aplicabilidad a más consultas.

Cómo crear tablas conjuntas

Si tomamos nuestro ejemplo de vuelos de Explorar que identificamos como una oportunidad para optimizar, la mejor estrategia sería crear tres tablas conjuntas diferentes para esta:

• 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 la tabla conjunta LookML de una consulta de Explorar o de un panel y agregar LookML a los archivos del proyecto de Looker.

Una vez que agregues las tablas conjuntas a tu proyecto de LookML y implementes las actualizaciones en la producción, las exploraciones aprovecharán las tablas conjuntas de las consultas de tus usuarios.

Persistencia

A fin de que se pueda acceder a ellas para el reconocimiento global, las tablas conjuntas deben ser persistentes en tu base de datos. Una práctica recomendada es alinear la regeneración automática de estas tablas conjuntas con tu política de almacenamiento en caché aprovechando los grupos de datos. Debes usar el mismo grupo de datos para una tabla conjunta que se usa para la exploración asociada. Si no puedes usar grupos de datos, una opción es usar el parámetro sql_trigger_value en su lugar. A continuación, se muestra un valor genérico basado en la fecha para sql_trigger_value:

sql_trigger_value: SELECT CURRENT_DATE() ;;

De este modo, tus tablas conjuntas se compilarán automáticamente a la medianoche todos los días.

Lógica del período

Cuando Looker crea una tabla conjunta, esta incluirá datos hasta el momento en que se creó. Cualquier dato que se haya agregado posteriormente a la tabla base de la base de datos normalmente se excluiría de los resultados de una consulta que utiliza esa tabla conjunta.

En este diagrama, se muestra el cronograma de cuándo se recibieron y registraron los pedidos en la base de datos, en comparación con el momento en que se creó la tabla conjunta Pedidos. Hay dos pedidos recibidos hoy que no estarán presentes en la tabla conjunta Pedidos, ya que los pedidos se recibieron después de que se creó la tabla conjunta:

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

Debido a que Looker puede unir los datos actualizados a una tabla conjunta, si un usuario filtra por un período que se superpone con el final de la tabla global y la base, los pedidos recibidos después de que se creó la tabla conjunta se incluirán en los resultados del usuario. Consulta la página de documentación Reconocimiento agregado a fin de obtener detalles y las condiciones que deben cumplirse para unir los datos recientes con las consultas de tablas agregadas.

Resumen

En resumen, hay tres pasos fundamentales para crear una implementación global del reconocimiento de la marca:

1. Identifica oportunidades en las que la optimización mediante el uso de tablas conjuntas sea adecuada y tenga un impacto.
2. Diseña tablas conjuntas que brinden la mayor cobertura para las consultas comunes de los usuarios sin dejar de ser lo suficientemente pequeñas como para reducir lo suficiente el tamaño de esas consultas.
3. Crear las tablas conjuntas en el modelo de Looker mediante la vinculación de la persistencia de la tabla con la persistencia de la caché de la exploración