Instructivo de reconocimiento agregado

Para obtener detalles adicionales, 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, lo que incluye identificar oportunidades para la 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 agregadas de reconocimiento o casos extremos, ni es un catálogo exhaustivo de todas sus funciones.

¿Qué es el reconocimiento agregado?

En Looker, principalmente realizas consultas en tablas o vistas sin procesar en tu base de datos. A veces, estas son 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 reconocimiento agregado de Looker, puedes preconstruir tablas conjuntas con varios niveles de detalle, dimensionalidad y agregación, y también puedes informar 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 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 el dialecto de tu base de datos admite el reconocimiento agregado, consulta la página de documentación de Reconocimiento agregado.

El valor del reconocimiento agregado

Existen varias propuestas de valor significativas que agregan ofertas de reconocimiento para generar valor adicional a partir de tu modelo de Looker existente:

• Mejora del rendimiento: Implementar el reconocimiento total agilizará las búsquedas de los usuarios. 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 para aprovechar LookML existente: las tablas conjuntas usan el objeto query, que reutiliza la lógica modelada existente en lugar de la lógica duplicada 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 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 se define 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 una 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 las tablas conjuntas se utilizan para una búsqueda.

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 el reconocimiento agregado es crear tablas conjuntas para los paneles muy usados con un entorno de ejecución muy alto. Es posible que los usuarios te digan que los paneles son 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 de Explorar del 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 tu instancia, incluidos Title, History, Count of Exploras, Ration from Cache vs. Database y Is Performing Peorse than Media:

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 lentas y que los usuarios consultan en gran medida

Otra oportunidad para generar reconocimiento total es con las exploraciones, que son muy consultadas por los usuarios y tienen una respuesta de búsqueda inferior al promedio.

Puedes usar la 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 del 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 los datos sobre las exploraciones de tu instancia, incluidos Explorar, Modelo, Recuento de ejecuciones de consultas, Recuento de usuarios y Tiempo de ejecución promedio en segundos:

En la exploración del 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
• Las exploraciones que tienen un rendimiento bajo (en relació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 si comprendes los campos que los usuarios suelen incluir en las consultas y los filtros.

Usa la Exploración de uso en el campo de actividad del sistema para comprender los campos seleccionados de forma frecuente dentro de las exploraciones que identificaste como lentas y muy usadas. Como acceso directo, puedes abrir este vínculo para explorar el uso del campo de 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 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 la 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 mayor frecuencia para Explorar. Por lo tanto, esos campos son buenos candidatos para incluir campos en tablas conjuntas.

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 del mundo 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 paneles, exploraciones y campos que deben considerarse 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 se trate de tres implementaciones de reconocimiento de agregación discretas.

Diseña tablas conjuntas

Una vez que identifiques las oportunidades de reconocimiento agregado, 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 agregada a 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:

• Medidas estándar: medidas de tipo SUM, COUNT, AVERAGE, MIN y MAX
• Medidas compuestas: mediciones 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.
• Medidas basadas en cardinalidad: Al igual que con las mediciones distintas, las medianas y los percentiles no se pueden agregar previamente ni se admiten. 

NOTA: Si conoces una posible consulta de un usuario con tipos de mediciones que no son compatibles con el reconocimiento agregado, es posible que quieras crear una tabla conjunta que sea una concordancia 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 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 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 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 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, 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;;
      }
    }
  }

Tus usuarios empresariales, la evidencia anecdótica, así como 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. Convertir 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 utilizaron 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 se deben usar como comparativas o marcos 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 &dash, los resultados son los siguientes:

Origen	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 usados 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 que el uso combinado es de alrededor del 25%, el ahorro total para los usuarios sería de 6 horas, 6 minutos (8 s * 2,750 = 22,000 s). La compilación de la tabla conjunta tardó 17.9 segundos.

Si observas estos resultados, te recomendamos tomarte un momento para analizar los beneficios que podrías obtener con lo siguiente:

• Optimizar 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 reconocimiento agregado para optimizar modelos más simples que se usan con más frecuencia y tienen un rendimiento deficiente

Verás una reducción en los retornos de tus esfuerzos a medida que intentes obtener el último 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 se debe esperar que el reconocimiento global 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. 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 (con respecto a 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 crear estas tablas conjuntas es obtener la tabla conjunta LookML de una consulta de exploración o desde un panel y agregar LookML a los archivos de tu proyecto de Looker.

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

Persistencia

Para que se pueda acceder a ella para el reconocimiento agregado, las tablas agregadas deben conservarse 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 en una tabla conjunta que se usa para la Exploración asociada. Si no puedes usar grupos de datos, una opción alternativa es usar el parámetro sql_trigger_value en su lugar. A continuación, se muestra un valor genérico basado en una 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 cree una tabla conjunta, incluirá datos hasta el momento en que se creó la tabla. Cualquier dato que posteriormente se agregue a la tabla base en la base de datos normalmente se excluiría de los resultados de una consulta que use 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 de agregación Orders. 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 UNIONAR datos recientes 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 datos actualizados a una tabla conjunta, si un usuario filtra un período que se superpone con el final de la tabla conjunta 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 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 oportunidades en las que la optimización con tablas conjuntas es adecuada y tiene un gran impacto.
2. Diseña tablas conjuntas que proporcionen la mayor cobertura para las búsquedas comunes de los usuarios y que, a la vez, sean 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, vinculando la persistencia de la tabla con la persistencia de la caché de Explorar