Reconocimiento total

Para obtener una guía sobre cómo implementar el reconocimiento agregado, también puede consultar nuestro artículo del Centro de ayuda sobre el instructivo de reconocimiento agregado.

Descripción general

Looker usa una lógica de reconocimiento agregada para encontrar la tabla más pequeña y eficiente disponible en su base de datos a fin de ejecutar una consulta y, al mismo tiempo, mantener la exactitud.

Para tablas muy grandes en tu base de datos, los desarrolladores de Looker pueden crear tablas de datos agregadas más pequeñas, agrupadas por varias combinaciones de atributos. Las tablas agregadas funcionan como tablas de resumen o de resumen que Looker puede usar para las consultas siempre que sea posible, en lugar de la tabla grande original. Cuando se implementan de forma estratégica, el conocimiento agregado puede acelerar la búsqueda promedio en órdenes de magnitud.

Por ejemplo, puede tener una tabla de datos a escala de petabytes con una fila para cada pedido que se haya realizado en su sitio web. Desde esta base de datos, puede crear una tabla agregada con sus totales de ventas diarias. Si su sitio web recibe 1.000 pedidos todos los días, la tabla conjunta diaria representaría cada día con 999 filas menos que su tabla original. Puede crear otra tabla agregada con totales de ventas mensuales que serán aún más eficientes. Por lo tanto, si un usuario ejecuta una consulta para ventas diarias o semanales, Looker usará la tabla de ventas totales diarias. Si un usuario ejecuta una consulta sobre las ventas anuales y no tienes una tabla agregada anual, Looker usará la siguiente opción, que es la tabla de agregación de ventas mensual en este ejemplo.

En esta imagen, se muestra cómo Looker responde las preguntas de los usuarios con tablas agregadas siempre que sea posible:

• Para una consulta sobre las ventas mensuales totales, Looker usa la tabla agregada basada en las ventas mensuales (sales_monthly_aggregate_table).
• Para una consulta sobre el total de cada venta en un día, no hay una tabla agregada con ese nivel de detalle, por lo que Looker obtiene los resultados de la consulta de la tabla de la base de datos original (orders_database). (Sin embargo, si los usuarios ejecutan este tipo de consulta con frecuencia, podrías crear fácilmente una tabla agregada para ella).
• Para una consulta sobre ventas semanales, no hay una tabla agregada semanal, por lo que Looker usa la siguiente mejor tabla, que es la basada en las ventas diarias (sales_daily_aggregate_table).

Con la lógica de reconocimiento agregado, Looker consultará la tabla agregada más pequeña posible para responder las preguntas de los usuarios. La tabla original solo se usaría para consultas que requieran un nivel de detalle mayor que el que pueden proporcionar las tablas agregadas.

No es necesario unir o agregar tablas agregadas a Explorar por separado. En su lugar, Looker ajusta de forma dinámica la cláusula FROM de la consulta Explorar a fin de acceder a la mejor tabla agregada para la consulta. Esto significa que se mantienen los talares y se pueden consolidar las exploraciones. Gracias al reconocimiento agregado, una herramienta Explorar puede aprovechar automáticamente las tablas agregadas, pero se analizarán datos detallados si es necesario.

También puedes aprovechar las tablas agregadas para mejorar drásticamente el rendimiento de los paneles, en especial en los mosaicos que consultan grandes conjuntos de datos. Para obtener más información, consulta la sección Obtén información sobre la tabla agregada de un panel en la página de documentación del parámetro aggregate_table.

Agrega tablas agregadas a tu proyecto

Para poder acceder al conocimiento agregado, las tablas agregadas deben ser persistentes en tu base de datos. Debido a que las tablas agregadas son un tipo de tabla derivada persistente (PDT), las tablas agregadas tienen los mismos requisitos que los PDT. Consulta la página de documentación Tablas derivadas en Looker para obtener más detalles.

Los desarrolladores de Looker pueden crear tablas agregadas estratégicas que minimizarán la cantidad de consultas requeridas en las tablas grandes de una base de datos. Las tablas agregadas deben persistir en tu base de datos a fin de que pueda accederse a ellas para generar reconocimiento agregado. Por lo tanto, las tablas agregadas son un tipo de tabla derivada persistente (PDT).

Una tabla agregada se define mediante el parámetro aggregate_table en un parámetro explore en tu proyecto de LookML.

Aquí tienes un ejemplo de un explore con una tabla agregada en LookML:

explore: orders {
  label: "Sales Totals"
  join: order_items {
    sql_on: ${orders.id} = ${order_items.id} ;;
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [created_month]
      measures: [order_items.total_sales]
    }
  }
  # other explore parameters
}

Para crear una tabla agregada, puedes escribir el LookML desde cero o puedes obtener un conjunto de LookML desde un panel o desde un panel. Consulta la página de documentación del parámetro aggregate_table para conocer las características específicas del parámetro aggregate_table y sus subparámetros.

Cómo diseñar tablas agregadas

Para que una consulta de exploración use una tabla agregada, la tabla agregada debe poder proporcionar datos precisos para la consulta de Explorar. Looker puede usar una tabla agregada para una consulta de Explorar si se cumplen todas las condiciones que figuran a continuación:

• Los campos de consulta de Explorar son un subconjunto de los campos de la tabla agregada (consulta la sección Factores de campo en esta página). O bien, para los períodos, los períodos de la consulta Explorar se pueden derivar de los períodos en la tabla agregada (consulta la sección Factores de tiempo en esta página).
• La consulta Explorar contiene tipos de medición admitidos por el conocimiento agregado (consulte la sección Factores de tipo de medición en esta página) o la consulta Explorar tiene una tabla agregada que es una concordancia exacta (consulte la sección Cómo crear tablas agregadas que coinciden exactamente con las consultas de Explorar en esta página).
• La zona horaria de consulta de exploración coincide con la zona horaria que utiliza la tabla agregada (consulte la sección Factores de zona horaria en esta página).
• Los campos de referencia de los filtros de las consultas de exploración que están disponibles como dimensiones en la tabla agregada o en cada uno de los filtros de la consulta de exploración coinciden con un filtro en la tabla agregada (consulta la sección Factores de filtro en esta página).

Una forma de garantizar que una tabla agregada pueda proporcionar datos precisos para una consulta de Explorar es simplemente crear una tabla agregada que coincida exactamente con una de Explorar. Para obtener más información, consulta la sección Crea tablas agregadas que coincidan exactamente con las consultas de Explorar en esta página.

Factores de campo

Para que se pueda usar en una consulta de Explorar, una tabla agregada debe tener todas las dimensiones y medidas necesarias para esa consulta de exploración, incluidos los campos usados para los filtros en la consulta de Explorar. Si una consulta Explorar contiene una dimensión o medida que no está en una tabla agregada, Looker no podrá usar la tabla agregada y usará la tabla base en su lugar.

Por ejemplo, si una consulta agrupa por dimensiones A y B, agrega por medida C y filtra por la dimensión D, la tabla agregada debe tener, como mínimo, A, B y D como dimensiones y C como medida.

La tabla agregada también puede tener otros campos, pero debe tener al menos los campos de consulta de Explorar a fin de ser viable para la optimización. La única excepción son las dimensiones de los plazos, ya que los plazos más detallados se pueden derivar de otros más detallados.

Debido a estas consideraciones sobre los campos, una tabla agregada es específica de la pestaña Explorar en la que se definió. No se usará una tabla agregada definida en Explorar para las consultas de otro Explorar.

Factores de período de tiempo

La lógica agregada de reconocimiento de Looker puede derivar de un período de tiempo desde otro. Se puede usar una tabla agregada para una consulta siempre que el período de la tabla agregada tenga un nivel de detalle más fino (o igual) que la consulta Explorar. Por ejemplo, una tabla agregada basada en datos diarios se puede utilizar para una consulta de Explorar que requiere otros períodos, como los datos diarios, mensuales y anuales, o incluso los datos de día del mes, día del año y semana del año. Sin embargo, no se puede usar una tabla agregada anual para una consulta de Explorar que requiere datos por hora, ya que los datos de la tabla agregada no tienen el nivel de detalle suficiente para la consulta de Explorar.

Lo mismo se aplica a los subconjuntos de intervalos de tiempo. Por ejemplo, si tiene una tabla agregada que se filtró durante los últimos tres meses y un usuario consulta los datos con un filtro para los últimos dos meses, Looker podrá usar la tabla agregada para esa consulta.

Además, se aplica la misma lógica para las consultas con filtros de período: se puede usar una tabla agregada para una consulta con un filtro de período de tiempo, siempre que el período de la tabla agregada tenga un nivel de detalle más (o igual) que el filtro de período que se usa en la consulta Explorar. Por ejemplo, una tabla agregada que tiene una dimensión de período diario se puede usar para una consulta de Explorar que filtra por día, semana o mes.

Medir factores de tipo

Para que una consulta de Explorar use una tabla agregada, las medidas de la tabla agregada deben poder proporcionar datos precisos para la consulta de Explorar.

Por este motivo, solo se admiten ciertos tipos de medidas, como se describe en las siguientes secciones:

• Medidas con tipos de medición admitidos
• Medidas definidas por expresiones de SQL
• Medidas que no están definidas con ${TABLE}
• Medidas que se aproximan a recuentos distintos

Si una consulta Explorar usa cualquier otro tipo de medida, Looker usará la tabla original, no la tabla agregada, para mostrar resultados. La única excepción es si la consulta Explorar es una coincidencia exacta de una consulta de tabla agregada, como se describe en la sección Crea tablas agregadas que coincidan exactamente con las consultas de Explorar.

De lo contrario, Looker usará la tabla original, no la tabla agregada, para mostrar resultados.

Medidas con tipos de medición admitidos

El reconocimiento agregado se puede usar para las consultas de Explorar que usan medidas con estos tipos de medición:

• ponderada
• count
• min
• max
• promedio

Si una pestaña Explorar se une a varias tablas de base de datos, Looker puede procesar medidas de tipo SUM, COUNT y AVERAGE como SUM DISTINCT, COUNT DISTINCT y AVERAGE DISTINCT, respectivamente. Looker hace esto para evitar errores de distribución, como se describe en la sección Agregados simétricos para las exploraciones con combinaciones en esta página.

A fin de usar una tabla agregada para una consulta de Explorar, Looker debe poder operar en las medidas de la tabla agregada a fin de proporcionar datos precisos en la consulta de Explorar. Por ejemplo, se puede usar una medida con type: sum para aumentar el reconocimiento porque puedes sumar varias sumas: se puede sumar una tabla agregada de sumas semanales a fin de obtener una suma mensual precisa. Del mismo modo, se puede usar una medida con type: max porque se puede usar una tabla agregada de máximos diarios para encontrar el máximo semanal exacto.

En el caso de las medidas con type: average, se admite el reconocimiento agregado porque Looker usa datos de suma y recuento para obtener valores promedio de las tablas agregadas de forma precisa.

Medidas definidas con expresiones SQL

El reconocimiento agregado también se puede usar con medidas que se definen con expresiones en el parámetro sql. Cuando se definen con expresiones de SQL, también se admiten los siguientes tipos de medición:

• número
• date
• string
• sí

El reconocimiento agregado es compatible con las medidas que se definen como combinaciones de otras, como este ejemplo:

measure: total_revenue_in_dollars {
  type: number
  sql: ${total_revenue_in_dollars} - ${inventory_item.total_cost_in_dollars} ;;
}

El reconocimiento agregado también es compatible con medidas en las que los cálculos se definen en el parámetro sql, como esta medida:

measure: wholesale_value {
  type: number
    sql: (${order_items.total_sale_price} * 0.60) ;;
}

Además, el reconocimiento agregado es compatible con medidas en las que las operaciones MIN, MAX y COUNT se definen en el parámetro sql, como esta:

measure: most_recent_order_date {
  type: date
  sql: MAX(${users.created_at_raw})
}

El reconocimiento agregado solo es compatible con las operaciones MIN(), MAX() y COUNT(). Si quieres usar una medida promedio o una suma en tu tabla agregada, puedes crear una medida type: average o type: sum, que son compatibles para el reconocimiento agregado.

Medidas que hacen referencia a los campos de LookML

Cuando se usan expresiones sql en las mediciones, el reconocimiento agregado admite los siguientes tipos de referencias de campo:

• Referencias que usan el formato ${view_name.field_name}, que indica campos en otras vistas
• Referencias que usan el formato ${field_name}, que indica campos en la misma vista

El reconocimiento agregado no es compatible con las medidas definidas con el formato ${TABLE}.column_name, que indica una columna en una tabla. (Consulta la página de documentación Incorpora SQL y haz referencia a objetos de LookML para obtener una descripción general del uso de referencias en LookML).

Por ejemplo, una medida definida con este parámetro sql no se admitiría en una tabla agregada, ya que usa el formato ${TABLE}.column_name:

measure: wholesale_value {
  type: number
  sql: (${TABLE}.total_sale_price * 0.60) ;;
}

Si deseas incluir esta medida en una tabla agregada, puedes crear una dimensión definida con el formato ${TABLE}.column_name y, luego, crear una medida que haga referencia a la dimensión, de esta manera:

 dimension: total_sale_price {
    sql: (${TABLE}.total_sale_price) ;;
  }

  measure: wholesale_value {
    type: number
    sql: (${total_sale_price} * 0.60) ;;
}

Ahora puedes usar la medida wholesale_value en tu tabla agregada.

Medidas que se aproximan a recuentos distintos

En general, los recuentos distintos no son compatibles con el reconocimiento agregado porque no puedes obtener datos precisos si intentas agregar recuentos distintos. Por ejemplo, si cuenta a los distintos usuarios de un sitio web, podría haber un usuario que visitó el sitio dos veces, con tres semanas de diferencia. Si intentara aplicar una tabla agregada semanal para obtener un recuento mensual de usuarios distintos en su sitio web, ese usuario se contaría dos veces en su consulta de recuento distinto mensual y los datos serían incorrectos.

Una solución alternativa para esto es crear una tabla agregada que coincida exactamente con una consulta de Explorar, como se describe en la sección Crea tablas agregadas que coincidan exactamente con las consultas de Explorar en esta página. Cuando la consulta Explorar y una consulta de tabla agregada son iguales, las distintas medidas de recuento proporcionan datos precisos, por lo que se pueden usar para el reconocimiento agregado.

Otra opción es utilizar aproximaciones para distintos recuentos. En el caso de los dialectos que admiten bocetos de HyperLogLog, Looker puede aprovechar el algoritmo HyperLogLog para calcular recuentos distintos aproximados de las tablas agregadas.

Se sabe que el algoritmo HyperLogLog tiene un error de alrededor del 2%. El parámetro allow_approximate_optimization: yes requiere que los desarrolladores de Looker reconozcan que está bien usar datos aproximados para la medida, de modo que la medida se pueda calcular aproximadamente a partir de tablas agregadas.

Consulta la página de documentación del parámetro allow_approximate_optimization para obtener más información y la lista de dialectos que admiten un recuento distinto mediante HyperLogLog.

Factores de zona horaria

En muchos casos, los administradores de bases de datos usan UTC como la zona horaria para las bases de datos. Sin embargo, es posible que muchos usuarios no se encuentren en la zona horaria UTC. Looker tiene varias opciones para convertir zonas horarias, de modo que sus usuarios obtengan resultados de consultas en su propia zona horaria:

• Zona horaria de consulta, una configuración que se aplica a todas las consultas en la conexión de base de datos. Si todos tus usuarios están en la misma zona horaria, puedes establecer una sola zona horaria de consulta para que todas las consultas se conviertan de la base de datos de la base de datos a la zona horaria de consulta.
• Zonas horarias específicas de los usuarios, en las que se pueden asignar usuarios y seleccionar zonas horarias individuales En este caso, las consultas se convierten de la zona horaria de la base de datos a la zona horaria del usuario individual.

Consulta la página de documentación Configuración de la zona horaria para obtener más información sobre estas opciones.

Estos conceptos son importantes para comprender el reconocimiento agregado porque, para que una tabla agregada se use en una consulta con dimensiones de fecha o filtros de fecha, la zona horaria de la tabla agregada debe coincidir con la configuración de zona horaria que se usó para la consulta original.

Las tablas agregadas usan la zona horaria de la base de datos si no se especifica un valor timezone. La conexión de tu base de datos también usará la zona horaria de la base de datos si se cumple alguna de las siguientes condiciones:

• Tu base de datos no admite zonas horarias.
• La zona horaria de consulta de su conexión de base de datos se establece en la misma zona horaria que la de base de datos.
• La conexión de la base de datos no tiene una zona horaria de consulta específica ni zonas horarias específicas del usuario. Si este es el caso, la conexión de la base de datos usará la zona horaria de la base de datos.

Si alguno de estos es verdadero, puedes omitir el parámetro timezone para tus tablas agregadas.

De lo contrario, se debe definir la zona horaria de la tabla agregada para que coincida con las consultas posibles, de modo que sea más probable que se use la tabla agregada:

• Si la conexión de la base de datos usa una sola zona horaria de consulta, debes hacer que el valor timezone de tu tabla agregada coincida con el valor de zona horaria de consulta.
• Si la conexión de tu base de datos usa zonas horarias específicas del usuario, debes crear tablas agregadas idénticas, cada una con un valor timezone diferente para que coincida con las posibles zonas horarias de tus usuarios.

Looker no puede usar una tabla agregada para una consulta de Explorar si la zona horaria de la tabla agregada no coincide con la de la consulta. Si la conexión de tu base de datos tiene zonas horarias específicas del usuario, significa que necesitas una tabla agregada independiente para cada una de las zonas horarias de tu usuario.

Filtrar factores

Ten cuidado cuando incluyas filtros en la tabla agregada. Los filtros en una tabla agregada pueden limitar los resultados al punto en que la tabla agregada no se puede usar. Por ejemplo, supongamos que crea una tabla agregada para los recuentos de pedidos diarios y la tabla agregada filtra solo los pedidos de anteojos de sol provenientes de Australia. Si un usuario ejecuta una consulta de Explorar para obtener los recuentos de pedidos diarios de gafas de sol en todo el mundo, Looker no puede usar la tabla agregada para esa consulta de Explorar, ya que la tabla agregada solo tiene los datos de Australia. La tabla agregada filtra los datos de forma demasiado limitada para que la use la consulta Explorar.

Además, ten en cuenta los filtros que tus desarrolladores de Looker podrían haber incorporado a tu Explorar, como los siguientes:

• access_filters: Aplica restricciones de datos específicas del usuario.
• always_filter: Requiere que los usuarios incluyan un conjunto determinado de filtros para una consulta de Explorar. Los usuarios pueden cambiar el valor de filtro predeterminado para su consulta, pero no pueden quitar el filtro por completo.
• conditionally_filter: Define un conjunto de filtros predeterminados que los usuarios pueden anular si aplican al menos un filtro de una segunda lista que también se define en Explorar.

Estos tipos de filtros se basan en campos específicos. Si tu exploración tiene estos filtros, debes incluir sus campos en el parámetro dimensions de aggregate_table.

Por ejemplo, esta es una exploración con un filtro de acceso que se basa en el campo orders.region:

explore: orders {
  access_filter: {
    field: orders.region
    user_attribute: region
  }
}

Para crear una tabla agregada que se usaría en Explorar, la tabla agregada debe incluir el campo en el que se basa el filtro de acceso. En el siguiente ejemplo, el filtro de acceso se basa en el campo orders.region, y este mismo campo se incluye como una dimensión en la tabla agregada:

explore: orders {
  access_filter: {
    field: orders.region  # <-- orders.region field
    user_attribute: region
  }
  aggregate_table: sales_monthly {
    materialization: {
      datagroup_trigger: orders_datagroup
    }
    query: {
      dimensions: [orders.created_day, orders.region] # <-- orders.region field
      measures: [orders.total_sales]
      timezone: America/Los_Angeles
    }
  }
}

Debido a que la consulta de tabla agregada incluye la dimensión orders.region, Looker puede filtrar de forma dinámica los datos en la tabla agregada para que coincidan con el filtro de la consulta Explorar. Por lo tanto, Looker puede seguir usando la tabla agregada para las consultas de Explorar, aunque Explorar tenga un filtro de acceso.

Esto también se aplica a las consultas de Explorar que usan una tabla derivada nativa configurada con bind_filters. El parámetro bind_filters pasa los filtros especificados de una consulta Explorar a la subconsulta de tabla derivada nativa. En el caso del reconocimiento agregado, si tu consulta de Explorar requiere una tabla derivada nativa que use bind_filters, la consulta de Explorar puede usar una tabla agregada solo si todos los campos usados en el parámetro bind_filters de tabla derivada nativa tienen exactamente los mismos valores de filtro en la consulta de exploración que en la tabla agregada.

Crea tablas agregadas que coincidan exactamente con las consultas de Explorar

Una forma de asegurarse de que una tabla agregada se pueda usar para una consulta de Explorar es simplemente crear una tabla agregada que coincida exactamente con la consulta de Explorar. Si la consulta Explorar y la tabla agregada usan las mismas medidas, dimensiones, filtros, zonas horarias y otros parámetros, los resultados de la tabla agregada se aplicarán a la consulta de Explorar por definición. Si una tabla agregada es una coincidencia exacta de una consulta de Explorar, Looker puede usar tablas agregadas que incluyan cualquier tipo de medida.

Puede crear una tabla agregada a partir de Explorar con la opción Obtener LookML del menú de ajustes de Explorar. También puedes crear coincidencias exactas para todos los mosaicos en un panel mediante la opción Obtener LookML en el menú de ajustes de un panel.

Determina qué tabla agregada se usa para una consulta

Los usuarios con permisos see_sql pueden usar los comentarios de la pestaña SQL de Explorar para ver qué tabla agregada se usará en una consulta. Los comentarios de la pestaña SQL también se muestran en el modo de desarrollo, por lo que los desarrolladores pueden probar nuevas tablas agregadas para ver cómo Looker las usa antes de enviar nuevas tablas a producción.

Por ejemplo, en función de la tabla de agregación mensual de ejemplo que se mostró anteriormente, podemos ir a Explorar y ejecutar una consulta para ver los totales de ventas anuales. Luego, podemos hacer clic en la pestaña SQL para ver los detalles de la consulta que creó Looker. Si está en modo de desarrollo, Looker muestra comentarios para indicar la tabla agregada que usó para la consulta:

En los comentarios de la pestaña SQL, podemos ver que Looker usa la tabla agregada sales_monthly para esta consulta y también información sobre por qué no se usaron otras tablas agregadas en la consulta:

-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date

Consulta la sección Solución de problemas de esta página para conocer los posibles comentarios que podrían aparecer en la pestaña SQL y sugerencias para resolverlos.

Estimaciones de ahorro en la computación para aumentar el conocimiento de la marca

Si la conexión de tu base de datos admite estimaciones de costos y se puede usar una tabla agregada para una consulta, la ventana Explorar mostrará los ahorros de procesamiento de usar la tabla agregada en lugar de consultar la base de datos directamente. El ahorro total de reconocimiento se muestra a la izquierda del botón Ejecutar en Explorar antes de que se ejecute la consulta:

Antes de ejecutar la consulta, si desea ver qué tabla agregada se utilizará para la consulta, puede hacer clic en la pestaña SQL, como se describe en la sección Cómo determinar qué tabla agregada se usa para una consulta de esta página de documentación.

Después de ejecutar la consulta, la ventana Explorar mostrará qué tabla agregada se usó para responder la consulta:

Se muestra el ahorro total de reconocimiento para las conexiones de bases de datos habilitadas para estimaciones de costos. Consulta la página de documentación Explora datos en Looker para obtener más información.

Looker une datos nuevos con sus tablas agregadas

Para las tablas agregadas con filtros de tiempo, Looker puede unir datos nuevos en su tabla agregada. Es posible que tenga una tabla agregada que incluya datos de los últimos tres días, pero que podría haberse creado ayer. Falta la información de hoy en la tabla agregada, por lo que no debería usarla para realizar una consulta de Explorar sobre la información diaria más reciente.

Sin embargo, Looker aún puede usar los datos de esa tabla agregada para la consulta porque Looker ejecutará una consulta sobre los datos más recientes y, luego, unirá esos resultados en los resultados de la tabla agregada.

Looker puede unir datos nuevos con los datos de su tabla agregada en las siguientes circunstancias:

• La tabla agregada tiene un filtro de tiempo.
• La tabla agregada incluye una dimensión basada en el mismo campo de tiempo que el filtro de tiempo.

Por ejemplo, la siguiente tabla agregada tiene una dimensión basada en el campo orders.created_date y tiene un filtro de tiempo ("3 days") basado en el mismo campo:

aggregate_table: sales_last_3_days {
  query:  {
    dimensions: [orders.created_date]
    measures: [order_items.total_sales]
    filters: [orders.created_date: "3 days"]  # <-- time filter
    timezone: America/Los_Angeles
  }
  ...
}

Si esta tabla agregada se compiló ayer, Looker recuperará los datos más recientes que aún no se hayan incluido en ella y, luego, unirá los resultados nuevos con los de la tabla agregada. Esto significa que sus usuarios obtendrán los datos más recientes y, al mismo tiempo, optimizarán el rendimiento con el reconocimiento agregado.

Si está en modo de desarrollo, puede hacer clic en la pestaña SQL de Explorar para ver la tabla agregada que Looker usó para la consulta, y la declaración UNION que Looker usó para incorporar los datos más recientes que no se incluyeron en la tabla agregada.

Actualmente, si Looker no puede unir datos nuevos con su tabla agregada, Looker utilizará los datos existentes de la tabla agregada.

Las tablas agregadas deben ser persistentes

Para poder acceder al conocimiento agregado, tu tabla agregada debe persistir en tu base de datos. La estrategia de persistencia se especifica en el parámetro materialization de la tabla agregada. Debido a que las tablas agregadas son un tipo de tabla derivada persistente (PDT), las tablas agregadas tienen los mismos requisitos que los PDT. Consulta la página de documentación Tablas derivadas en Looker para obtener más detalles.

Puedes crear PDT incrementales en el proyecto si el dialecto los admite. Looker agrega datos actualizados a la tabla para compilar PDT incrementales, en lugar de volver a compilarla por completo. Dado que las tablas agregadas son un tipo de PDT, también puede crear tablas agregadas incrementales. Consulte la página de documentación de PDT incrementales para obtener más información sobre los PDT incrementales. Consulta la página de documentación del parámetro increment_key para ver un ejemplo de una tabla agregada incremental.

Un usuario con el permiso develop puede anular la configuración de persistencia y volver a compilar todas las tablas agregadas de una consulta para obtener los datos más actualizados. Si deseas volver a compilar las tablas para una consulta, usa la opción Rebuild Derived Tables & Run del menú Explorar:

Debe esperar a que se cargue la consulta Explorar antes de que esta opción esté disponible.

La opción Rebuild Derived Tables &Run; Run volverá a compilar todas las tablas derivadas a las que se hace referencia en la consulta, así como las tablas derivadas de las que dependen las tablas en la consulta. Esto incluye tablas agregadas, que son un tipo de tabla derivada persistente.

Para el usuario que inicia la opción Volver a compilar tablas derivadas y ejecutar, la consulta esperará a que las tablas se vuelvan a compilar antes de cargar los resultados. Las consultas de otros usuarios seguirán usando las tablas existentes. Una vez que se vuelven a compilar las tablas persistentes, todos los usuarios las usarán.

Consulta la página de documentación Tablas derivadas en Looker para obtener más detalles sobre la opción Volver a compilar tablas derivadas y ejecutar.

Soluciona problemas

Como se describe en la sección Cómo determinar qué tabla agregada se usa para una consulta, si te encuentras en Modo de desarrollo, puedes ejecutar consultas en Explorar y hacer clic en la pestaña SQL para ver los comentarios sobre la tabla agregada que se usa para la consulta, si corresponde.

La pestaña SQL también incluye comentarios sobre por qué no se utilizaron las tablas agregadas para una consulta, si ese es el caso. Para las tablas agregadas que no se utilizan, el comentario comienza con:

Did not use [explore name]::[aggregate table name];

Por ejemplo, a continuación, se muestra un comentario sobre por qué no se usó la tabla agregada sales_daily definida en la exploración de order_items para una consulta:

-- Did not use order_items::sales_daily; query contained the following filters
that were neither included as fields nor exactly matched by filters in the aggregate table:
order_items.created_year.

En este caso, los filtros de la consulta evitaron que se usara la tabla agregada.

En la siguiente tabla, se muestran otros motivos posibles por los que no se puede usar una tabla agregada, junto con los pasos que puede seguir para aumentar la usabilidad de la tabla agregada.

Motivo para no usar la tabla agregada	Explicación y pasos posibles
No existe ese campo en Explorar.	Hay un error de tipo de validación de LookML. Es probable que esto se deba a que la tabla agregada no se definió correctamente o a que se produjo un error de ortografía en el LookML para su tabla agregada. Un posible culpable es un nombre de campo incorrecto, o algo similar. Para resolver esto, verifica que las dimensiones y medidas de la tabla agregada coincidan con los nombres de campo en Explorar. Consulta la página de documentación del parámetro aggregate_table para obtener más información sobre cómo definir una tabla agregada.
La tabla agregada no incluye los siguientes campos en la consulta.	Para que se pueda usar en una consulta de Explorar, una tabla agregada debe tener todas las dimensiones y medidas necesarias para esa consulta de exploración, incluidos los campos usados para los filtros en la consulta de Explorar. Si una consulta Explorar contiene una dimensión o medida que no está en una tabla agregada, Looker no podrá usar la tabla agregada y usará la tabla base en su lugar. Consulta la sección Factores de campo en esta página para obtener más detalles. La única excepción son las dimensiones de los plazos, ya que los plazos más detallados se pueden derivar de otros más detallados. Para resolver esto, verifica que los campos de consulta de exploración se incluyan en la definición de la tabla agregada.
La consulta incluyó los siguientes filtros que no estaban incluidos como campos ni coincidían exactamente con los filtros de la tabla agregada.	Los filtros de la consulta Explorar evitan que Looker use la tabla agregada. Para solucionar este problema, puedes realizar una de las siguientes acciones: Agrega el mismo filtro a la tabla agregada. Agrega el campo que usa el filtro a la tabla agregada. Quita los filtros de la consulta Explorar. Consulta la sección Factores de filtro en esta página para obtener más detalles.
La consulta contiene las siguientes medidas que no se pueden agrupar.	La consulta contiene uno o más tipos de medición no admitidos para el reconocimiento agregado, como el recuento distinto, la mediana o el percentil. Para resolver esto, verifica el tipo de cada medida en la consulta y asegúrate de que sea uno de los tipos de medición admitidos. Además, si tu pestaña Explorar tiene uniones, verifica que tus mediciones no se conviertan en medidas distintas (agregados simétricos) mediante un fan-out. Consulta la sección Agregados simétricos para exploraciones con combinaciones en esta página a fin de obtener una explicación.
Una tabla agregada diferente era más adecuada para la optimización.	Había varias tablas agregadas viables para la consulta, y Looker encontró una tabla agregada más óptima para usar. No es necesario que realice ninguna acción en este caso.
Looker no realizó ninguna agrupación (debido a un parámetro primary_key o cancel_grouping_fields) y, por lo tanto, no se puede agrupar la consulta.	La consulta hace referencia a una dimensión que impide que tenga una cláusula GROUP BY y, por lo tanto, Looker no puede usar ninguna tabla agregada para la consulta. Para solucionar este problema, verifica que el parámetro primary_key de la vista y el parámetro Explorar cancel_grouping_fields estén configurados de forma correcta.
La tabla agregada contenía filtros que no estaban en la consulta.	La tabla agregada tiene un filtro no temporal que no está en la consulta. Para resolver este problema, puedes quitar el filtro de la tabla agregada. Consulta la sección Factores de filtro en esta página para obtener más detalles.
Un campo se define como un campo de filtro en la consulta de Explorar, pero se enumera en el parámetro dimensions de la tabla agregada.	El parámetro dimensions de la tabla agregada enumera un campo que se define solo como un campo filter en la consulta Explorar. Para resolver esto, quita el campo de la lista dimensions de la tabla agregada. Si este campo es necesario para la tabla agregada, agrégalo a la lista filters en la consulta de la tabla agregada.
El optimizador no puede determinar por qué no se utilizó la tabla agregada.	Este comentario está reservado para casos excepcionales. Si ve esto para una consulta de Explorar que se usa con frecuencia, puede crear una tabla agregada que coincida exactamente con la consulta de Explorar. Puedes obtener fácilmente una tabla agregada de LookML desde Explorar, como se describe en la página de parámetros aggregate_table.

Aspectos para tener en cuenta

Agregaciones simétricas para las exploraciones con uniones

Un aspecto importante que se debe tener en cuenta es que en una exploración que une varias tablas de base de datos, Looker puede renderizar medidas de tipo SUM, COUNT y AVERAGE como SUM DISTINCT, COUNT DISTINCT y AVERAGE DISTINCT, respectivamente. Looker hace esto para evitar errores de distribución. Por ejemplo, una medida count se renderiza como un tipo de medición count_distinct. Esto es para evitar errores de distribución en las uniones y es parte de la funcionalidad de agregados simétricos de Looker. Consulte el artículo del Centro de ayuda sobre los agregados simétricos para obtener una explicación sobre esta función de Looker.

La funcionalidad de agregados simétricos evita errores de cálculo, pero también puede evitar que sus tablas agregadas se usen en ciertos casos, por lo que es importante comprenderlo.

En el caso de los tipos de medición que admite el reconocimiento agregado, esto se aplica a sum, count y average. Looker renderizará estos tipos de medidas como DISTINCT si:

• La medida proviene de la vista de una unión de varios a uno o de uno a varios.
• La medida proviene de cualquiera de las vistas de una unión varios a varios.

Consulta la página de documentación del parámetro relationship para obtener una explicación de estos tipos de uniones.

Si descubre que su tabla agregada no se utiliza por este motivo, puede crear una tabla agregada que coincida exactamente con una consulta de Explorar a fin de usar estos tipos de medición para una exploración con uniones. Para obtener más información, consulta la sección Crea tablas agregadas que coincidan exactamente con las consultas de Explorar en esta página.

Además, si tienes un dialecto de SQL que admite bocetos de HyperLogLog, puedes agregar el parámetro allow_approximate_optimization: yes a la medida. Cuando se define una medida de recuento con allow_approximate_optimization: yes, Looker puede usarla para el reconocimiento agregado, incluso si se procesa como un recuento distinto.

Consulta la página de documentación del parámetro allow_approximate_optimization para obtener detalles y una lista de qué dialectos de SQL admiten esbozos de HyperLogLog.

Compatibilidad de dialectos para el reconocimiento agregado

La capacidad de usar el reconocimiento agregado depende del dialecto de la base de datos que usa tu conexión de Looker. En la versión más reciente de Looker, los siguientes dialectos admiten el reconocimiento agregado:

El SQL heredado de Google BigQuery admite el conocimiento agregado, pero no admite la unión de datos nuevos con los datos agregados en su tabla.

Compatibilidad de dialectos para compilar tablas agregadas de forma incremental

Para que Looker admita tablas agregadas incrementales en tu proyecto de Looker, tu dialecto de base de datos también debe admitirlas. En la siguiente tabla, se muestra qué dialectos admiten tablas agregadas y PDT de compilación incremental en la versión más reciente de Looker: