Conocimiento total

Descripción general

Looker utiliza la lógica de reconocimiento de agregaciones para encontrar la tabla más pequeña y eficiente disponible en tu base de datos para 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 agregaciones más pequeñas de datos, agrupados según varias combinaciones de atributos. Las tablas agregadas actúan como tablas de resumen o de integración que Looker puede usar para las consultas siempre que sea posible, en lugar de la tabla grande original. Cuando se implementa de forma estratégica, el reconocimiento agregado puede acelerar una consulta típica en órdenes de magnitud.

Por ejemplo, podrías tener una tabla de datos a escala de petabytes con una fila para cada pedido que se realizó en tu sitio web. A partir de esta base de datos, puedes crear una tabla agregada con los totales de ventas diarias. Si tu sitio web recibe 1,000 pedidos todos los días, tu tabla agregada diaria representará cada día con 999 filas menos que tu tabla original. Puedes crear otra tabla agregada con los totales de ventas mensuales que será aún más eficiente. Por lo tanto, ahora, si un usuario ejecuta una consulta para obtener las ventas diarias o semanales, Looker usará la tabla de totales de ventas diarias. Si un usuario ejecuta una consulta sobre las ventas anuales y no tienes una tabla de datos agregados anuales, Looker usará la mejor opción siguiente, que, en este ejemplo, es la tabla de datos agregados de ventas mensuales.

Looker responde las preguntas de los usuarios con las tablas de datos agregados más pequeñas siempre que sea posible. Por ejemplo:

Para una consulta sobre las ventas mensuales totales, Looker usa la tabla de datos agregados 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 de datos agregados con esa granularidad, por lo que Looker obtiene los resultados de la consulta de la tabla de la base de datos original (orders_database). (Sin embargo, si tus usuarios ejecutan este tipo de consulta con frecuencia, podrías crear una tabla de datos agregados para ella).
Para una consulta sobre las ventas semanales, no hay una tabla de datos agregados semanales, por lo que Looker usa la siguiente mejor opción, que es la tabla de datos agregados basada en las ventas diarias (sales_daily_aggregate_table).

Con la lógica de reconocimiento de agregaciones, Looker consultará la tabla de datos agregados más pequeña posible para responder las preguntas de los usuarios. La tabla original solo se usaría para las consultas que requieren una granularidad más fina de la que pueden proporcionar las tablas agregadas.

No es necesario unir las tablas agregadas ni agregarlas a una exploración separada. En cambio, Looker ajusta de forma dinámica la cláusula FROM de la consulta de Explorar para acceder a la mejor tabla de agregación para la consulta. Esto significa que tus detalles se mantienen y los Explorar se pueden consolidar. Con el conocimiento agregado, una exploración puede aprovechar automáticamente las tablas agregadas, pero también profundizar en los datos detallados si es necesario.

También puedes aprovechar las tablas de agregación para mejorar drásticamente el rendimiento de los paneles, en especial para las tarjetas que consultan conjuntos de datos enormes. Para obtener más información, consulta la sección Cómo obtener LookML de tablas agregadas desde un panel en la página de documentación del parámetro aggregate_table.

Cómo agregar tablas agregadas a tu proyecto

Los desarrolladores de Looker pueden crear tablas agregadas estratégicas que minimicen la cantidad de consultas necesarias en las tablas grandes de una base de datos. Las tablas agregadas deben conservarse en tu base de datos para que puedan ser accesibles para el reconocimiento de agregaciones. Por lo tanto, las tablas agregadas son un tipo de tabla derivada persistente (PDT).

Una tabla de datos agregados se define con el parámetro aggregate_table en un parámetro explore de tu proyecto de LookML.

A continuación, se muestra 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 de datos agregados, puedes escribir el código LookML desde cero o obtener el código LookML de la tabla de datos agregados desde una Exploración o desde un panel. Consulta la página de documentación del parámetro aggregate_table para obtener detalles sobre el parámetro aggregate_table y sus subparámetros.

Diseña tablas de datos agregados

Para que una consulta de Explore use una tabla de datos agregados, esta debe poder proporcionar datos precisos para la consulta de Explore. Looker puede usar una tabla de datos agregados para una consulta de Explorar si se cumplen todas las siguientes condiciones:

Los campos de la consulta de Explorar son un subconjunto de los campos de la tabla de agregación (consulta la sección Factores de campo en esta página). O bien, en el caso de los períodos, los períodos de la consulta de Explorar se pueden derivar de los períodos de la tabla agregada (consulta la sección Factores de período en esta página).
La consulta de Explorar contiene tipos de medidas compatibles con el reconocimiento de agregaciones (consulta la sección Factores del tipo de medida en esta página) o tiene una tabla de agregación que es una coincidencia exacta (consulta la sección Cómo crear tablas de agregación que coincidan exactamente con las consultas de Explorar en esta página).
La zona horaria de la consulta de Explore coincide con la zona horaria que usa la tabla agregada (consulta la sección Factores de zona horaria en esta página).
Los filtros de la consulta de Explorar hacen referencia a campos que están disponibles como dimensiones en la tabla agregada, o bien cada uno de los filtros de la consulta de Explorar coincide con un filtro de la tabla agregada (consulta la sección Factores de filtro en esta página).

Una forma de garantizar que una tabla de datos agregados pueda proporcionar datos precisos para una consulta de Explorar es crear una tabla de datos agregados que coincida exactamente con una consulta de Explorar. Consulta la sección Cómo crear tablas de agregación que coincidan exactamente con las consultas de Explorar en esta página para obtener más detalles.

Factores de campo

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

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

La tabla agregada también puede tener otros campos, pero debe tener al menos los campos de la consulta de Explorar para que sea viable para la optimización. La única excepción son las dimensiones de período, ya que los períodos con un nivel de detalle más grueso se pueden derivar de los que tienen un nivel de detalle más fino.

Debido a estas consideraciones de campo, una tabla agregada es específica de la exploración en la que se define. Una tabla de datos agregados definida en una exploración no se usará para las consultas en otra exploración.

Factores de período

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

Lo mismo se aplica a los subconjuntos de períodos. Por ejemplo, si tienes una tabla agregada que se filtra para 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 siempre que el período de la tabla agregada tenga una granularidad más fina (o igual) que el filtro de período que se usa en la consulta de Explorar. Por ejemplo, se puede usar una tabla agregada que tenga una dimensión de período diario para una consulta de Explorar que filtre por día, semana o mes.

Factores del tipo de medición

Para que una consulta de Explorar use una tabla de datos agregados, las medidas de la tabla de datos agregados 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 medidas admitidos
Medidas definidas por expresiones SQL
Medidas que no se definen con ${TABLE}
Medidas que aproximan los recuentos distintos

Si una consulta de Explorar usa cualquier otro tipo de medida, Looker usará la tabla original, no la tabla de datos agregados, para devolver los resultados. La única excepción es si la consulta de Explorar coincide exactamente con una consulta de tabla de datos agregados, como se describe en la sección Cómo crear tablas de datos agregados que coincidan exactamente con las consultas de Explorar.

De lo contrario, Looker usará la tabla original, no la tabla de datos agregados, para devolver los resultados.

Medidas con tipos de medidas admitidos

El conocimiento de los datos agregados se puede usar para las consultas de Explorar que utilizan medidas con los siguientes tipos:

Para usar una tabla de datos agregados en una consulta de Explorar, Looker debe poder operar con las medidas de la tabla de datos agregados para proporcionar datos precisos en la consulta de Explorar. Por ejemplo, una métrica con type: sum se puede usar para la efectividad agregada, ya que puedes sumar varias sumas: se puede sumar una tabla agregada de sumas semanales para obtener una suma mensual precisa. Del mismo modo, se puede usar una medida con type: max, ya que se puede usar una tabla agregada de máximos diarios para encontrar el máximo semanal preciso.

En el caso de las medidas con type: average, se admite el conocimiento de la agregación porque Looker usa datos de suma y recuento para derivar con precisión los valores promedio de las tablas de agregación.

Medidas definidas con expresiones de SQL

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

Se admite el conocimiento agregado para las métricas que se definen como combinaciones de otras métricas, como en este ejemplo:

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

El conocimiento de la agregación también se admite para las 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, se admite el conocimiento de agregados para las medidas en las que se definen las operaciones MIN, MAX y COUNT en el parámetro sql, como esta medida:

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

Medidas que hacen referencia a campos de LookML

Cuando se usan expresiones sql en las medidas, el conocimiento de agregación admite los siguientes tipos de referencias de campos:

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 conocimiento de agregación no se admite para las medidas definidas con el formato ${TABLE}.column_name, que indica una columna en una tabla. (Consulta la página de documentación Incorporar SQL y hacer referencia a objetos de LookML para obtener una descripción general del uso de referencias en LookML).

Por ejemplo, una métrica definida con este parámetro sql no sería compatible con 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 la siguiente 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 de agregación.

Medidas que aproximan los recuentos distintos

En general, los recuentos de valores distintos no se admiten con la función de agregación, ya que no se pueden obtener datos precisos si se intenta agregar recuentos de valores distintos. Por ejemplo, si cuentas los usuarios distintos en un sitio web, es posible que haya un usuario que ingresó al sitio web dos veces, con tres semanas de diferencia. Si intentaras aplicar una tabla de agregación semanal para obtener un recuento mensual de usuarios distintos en tu sitio web, ese usuario se contaría dos veces en tu consulta de recuento mensual de usuarios distintos, y los datos serían incorrectos.

Una solución alternativa para esto es crear una tabla de datos agregados que coincida exactamente con una consulta de Explorar, como se describe en la sección Cómo crear tablas de datos agregados que coincidan exactamente con las consultas de Explorar de esta página. Cuando la consulta de Explorar y la consulta de una tabla de datos agregados son iguales, las medidas de recuento de valores distintos proporcionan datos precisos, por lo que se pueden usar para la detección de datos agregados.

Otra opción es usar aproximaciones para los recuentos distintos. En el caso de los dialectos que admiten bocetos de HyperLogLog, Looker puede aprovechar el algoritmo de HyperLogLog para aproximar los recuentos distintos de las tablas de agregación.

Se sabe que el algoritmo HyperLogLog tiene un error de alrededor del 2%. El parámetro allow_approximate_optimization: yes requiere que tus desarrolladores de Looker confirmen que está bien usar datos aproximados para la medida, de modo que esta se pueda calcular de forma aproximada 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 el recuento de valores distintos con HyperLogLog.

Factores de zona horaria

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

Zona horaria de la consulta, un parámetro de configuración que se aplica a todas las consultas de la conexión de la base de datos. Si todos tus usuarios se encuentran en la misma zona horaria, puedes establecer una sola zona horaria de consulta para que todas las consultas se conviertan de la zona horaria de la base de datos a la zona horaria de consulta.
Zonas horarias específicas del usuario, en las que se pueden asignar y seleccionar zonas horarias de forma individual. 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 Cómo usar la configuración de zona horaria para obtener más información sobre estas opciones.

Estos conceptos son importantes para comprender el conocimiento de los agregados, ya que, para que se use una tabla de agregado en una consulta con dimensiones de fecha o filtros de fecha, la zona horaria de la tabla de agregado debe coincidir con el parámetro de 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 ningún valor de timezone. Tu conexión a la 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 la consulta de tu conexión de base de datos está configurada en la misma zona horaria que la zona horaria de la base de datos.
Tu conexión a la base de datos no tiene una zona horaria de consulta especificada ni zonas horarias específicas del usuario. Si este es el caso, tu conexión a la base de datos usará la zona horaria de la base de datos.

Si alguna de estas opciones se aplica a tu caso, puedes omitir el parámetro timezone para tus tablas agregadas.

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

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

Factores de filtro

Ten cuidado cuando incluyas filtros en tu tabla de agregación. Los filtros en una tabla de agregación pueden reducir los resultados hasta el punto en que la tabla de agregación se vuelve inutilizable. Por ejemplo, supongamos que creas una tabla de agregados para los recuentos de pedidos diarios y que esta tabla filtra solo los pedidos de anteojos de sol provenientes de Australia. Si un usuario ejecuta una consulta de Explorar para obtener los recuentos diarios de pedidos de gafas de sol en todo el mundo, Looker no puede usar la tabla de datos agregados para esa consulta de Explorar, ya que la tabla de datos agregados solo tiene los datos de Australia. La tabla de datos agregados filtra los datos de forma demasiado limitada para que la consulta de Explorar la use.

Además, ten en cuenta los filtros que los 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: Exige a los usuarios que incluyan un determinado conjunto de filtros para una búsqueda en Explorar. Los usuarios pueden cambiar el valor predeterminado del filtro para su búsqueda, 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 la Exploración.

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

Por ejemplo, aquí se muestra un Explorar con un filtro de acceso basado en el campo orders.region:

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

Para crear una tabla de datos agregados que se usaría para esta exploración, la tabla 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 de agregados:

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

Dado que la consulta de la tabla agregada incluye la dimensión orders.region, Looker puede filtrar de forma dinámica los datos de la tabla agregada para que coincidan con el filtro de la consulta de Explorar. Por lo tanto, Looker puede seguir usando la tabla de datos agregados para las consultas de la Exploración, aunque esta 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 de exploración a la subconsulta de la tabla derivada nativa. En el caso del conocimiento de los datos agregados, si tu consulta de Explorar requiere una tabla derivada nativa que use bind_filters, la consulta de Explorar solo puede usar una tabla de datos agregados si todos los campos que se usan en el parámetro bind_filters de la tabla derivada nativa tienen los mismos valores de filtro en la consulta de Explorar que en la tabla de datos agregados.

Crea tablas de datos agregados que coincidan exactamente con las consultas de Explorar

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

Puedes crear una tabla de datos agregados a partir de una exploración con la opción Get LookML del menú de ajustes de una Exploración. También puedes crear coincidencias exactas para todas las tarjetas de un panel con la opción Get LookML del menú de ajustes de un panel.

Cómo determinar qué tabla de datos agregados se usa para una consulta

Los usuarios con permisos de see_sql pueden usar los comentarios de la pestaña SQL de una exploración para ver qué tabla de datos agregados se usará para 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 las usa Looker antes de enviar las tablas nuevas a producción.

Por ejemplo, según la tabla de datos agregados mensuales de ejemplo que se mostró anteriormente, puedes ir a la Exploración y ejecutar una consulta para obtener los totales de ventas anuales. Luego, puedes hacer clic en la pestaña SQL para ver los detalles de la consulta que creó Looker. Si estás en el modo de desarrollo, Looker muestra comentarios para indicar la tabla de datos agregados que usó para la consulta.

En los siguientes comentarios de la pestaña SQL, podemos ver que Looker usa la tabla agregada sales_monthly para esta consulta y la información sobre por qué no se usaron otras tablas agregadas para 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 en esta página para ver los posibles comentarios que puedes ver en la pestaña SQL y sugerencias para resolverlos.

Estimaciones de ahorro de la computación para el reconocimiento agregado

Si tu conexión de base de datos admite estimaciones de costos y si se puede usar una tabla agregada para una consulta, la ventana Explorar mostrará el ahorro de procesamiento que se obtiene al usar la tabla agregada en lugar de consultar la base de datos directamente. El ahorro total de la efectividad del reconocimiento se muestra junto al botón Ejecutar en Explorar antes de que se ejecute la búsqueda.

Antes de ejecutar la consulta, si deseas ver qué tabla agregada se usará para la consulta, puedes 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 de Explorar mostrará qué tabla de datos agregados se usó para responder la consulta junto al botón Ejecutar.

Los ahorros agregados en la conciencia de marca se muestran para las conexiones de bases de datos habilitadas para las estimaciones de costos. Consulta la página de documentación Explorar datos en Looker para obtener más información.

Looker une los datos nuevos a tus tablas de agregados

En el caso de las tablas de datos agregados con filtros de tiempo, Looker puede unir datos recientes en tu tabla de datos agregados. Es posible que tengas una tabla de agregación que incluya datos de los últimos tres días, pero que se haya creado ayer. A la tabla agregada le faltaría la información del día, por lo que no esperarías usarla para una consulta de Explorar sobre la información diaria más reciente.

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

Looker puede unir datos nuevos con los datos de tu tabla de agregaciones 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 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 de datos agregados se compiló ayer, Looker recuperará los datos más recientes que aún no se incluyen en la tabla de datos agregados y, luego, unirá los resultados nuevos con los de la tabla de datos agregados. Esto significa que tus usuarios obtendrán los datos más recientes y, al mismo tiempo, se optimizará el rendimiento con el conocimiento agregado.

Si estás en el modo de desarrollo, puedes hacer clic en la pestaña SQL de una exploración para ver la tabla de datos agregados que Looker usó para la consulta y la instrucción UNION que Looker usó para incorporar datos más recientes que no se incluyeron en la tabla de datos agregados.

Las tablas agregadas deben conservarse

Para que tu tabla agregada sea accesible para el reconocimiento de agregaciones, debe conservarse en tu base de datos. La estrategia de persistencia se especifica en el parámetro materialization de la tabla agregada. Dado que las tablas agregadas son un tipo de tabla derivada persistente (PDT), tienen los mismos requisitos que las PDT. Consulta la página de documentación Tablas derivadas en Looker para obtener más detalles.

Puedes crear PDT incrementales en tu proyecto si tu dialecto los admite. Looker crea PDT incrementales agregando datos recientes a la tabla, en lugar de volver a compilar la tabla en su totalidad. Dado que las tablas agregadas son un tipo de PDT, también puedes crear tablas agregadas incrementales. Consulta la página de documentación sobre las PDT incrementales para obtener más información. Consulta la página de documentación del parámetro increment_key para ver un ejemplo de una tabla de agregados incremental.

Un usuario con permiso de develop puede anular la configuración de persistencia y volver a compilar todas las tablas agregadas para una consulta y obtener los datos más actualizados. Para volver a compilar las tablas de una consulta, selecciona la opción Volver a compilar tablas derivadas y ejecutar en el menú de ajustes de Acciones de Explorar.

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

La opción Rebuild Derived Tables & Run vuelve 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 de la consulta. Esto incluye las tablas agregadas, que son un tipo de tabla derivada persistente.

En el caso del usuario que inicia la opción Rebuild Derived Tables & Run, la consulta esperará a que se vuelvan a compilar las tablas antes de cargar los resultados. Las consultas de otros usuarios seguirán usando las tablas existentes. Una vez que se vuelvan 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 Rebuild Derived Tables & Run.

Soluciona problemas

Como se describe en la sección Cómo determinar qué tabla de datos agregados se usa para una consulta, si estás en el modo de desarrollo, puedes ejecutar consultas en la exploración y hacer clic en la pestaña SQL para ver comentarios sobre la tabla de datos agregados que se usó para la consulta, si corresponde.

La pestaña SQL también incluye comentarios sobre por qué no se usaron tablas de agregación para una consulta, si ese es el caso. En el caso de las tablas agregadas que no se usan, el comentario comenzará con lo siguiente:

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

Por ejemplo, aquí hay un comentario sobre por qué no se usó la tabla de datos agregados sales_daily definida en el Explore 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 impidieron que se usara la tabla de agregación.

En la siguiente tabla, se muestran otros posibles motivos por los que no se puede usar una tabla de agregación, junto con los pasos que puedes seguir para aumentar su utilidad.

Motivo por el que no se usó la tabla de datos agregados	Explicación y posibles pasos
No existe ese campo en la función Explorar.	Hay un error de tipo de validación de LookML. Lo más probable es que la tabla conjunta no se haya definido correctamente o que haya un error tipográfico en el LookML de la tabla conjunta. Es probable que el problema se deba a un nombre de campo incorrecto o algo similar. Para resolver este problema, verifica que las dimensiones y las métricas de la tabla agregada coincidan con los nombres de los campos 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 use en una consulta de Explorar, una tabla de datos agregados debe tener todas las dimensiones y medidas necesarias para esa consulta, incluidos los campos que se usan para los filtros en la consulta de Explorar. Si una consulta de Explorar contiene una dimensión o una medida que no se encuentra en una tabla de datos agregados, Looker no podrá usar la tabla de datos agregados y, en su lugar, usará la tabla base. Consulta la sección Factores de campo en esta página para obtener más detalles. La única excepción son las dimensiones de período, ya que los períodos con un nivel de detalle más grueso se pueden derivar de los que tienen un nivel de detalle más fino. Para resolver este problema, verifica que los campos de la consulta de Explorar se incluyan en la definición de la tabla agregada.
La consulta contenía los siguientes filtros que no se incluyeron como campos ni coincidieron exactamente con los filtros de la tabla de agregación.	Los filtros de la consulta de Explorar impiden que Looker use la tabla de datos agregados. Para resolver este problema, puedes realizar una de las siguientes acciones: Agrega el mismo filtro a tu tabla de agregados. Agrega a tu tabla de agregación el campo que usa el filtro. Quita los filtros de la consulta de Explorar. Consulta la sección Factores de filtrado en esta página para obtener más detalles.
La consulta contiene las siguientes medidas que no se pueden acumular.	La consulta contiene uno o más tipos de medidas que no se admiten para el reconocimiento de agregaciones, como recuento de valores distintos, mediana o percentil. Para resolver este problema, verifica el tipo de cada medida en la consulta y asegúrate de que sea uno de los tipos de medidas admitidos. Además, si tu Explorar tiene uniones, verifica que tus medidas no se conviertan en medidas distintas (agregados simétricos) a través de uniones expandidas. Consulta la sección Agregaciones simétricas para Explorar con uniones en esta página para obtener una explicación.
Otra tabla agregada se ajustaba mejor a la optimización.	Había varias tablas agregadas viables para la consulta, y Looker encontró una tabla agregada más óptima para usar en su lugar. En este caso, no es necesario hacer nada.
Looker no realizó ningún agrupamiento (debido a un parámetro `primary_key` o `cancel_grouping_fields`) y, por lo tanto, no se puede resumir 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 de datos agregados para la consulta. Para resolver este problema, verifica que el parámetro `primary_key` de la vista y el parámetro `cancel_grouping_fields` de Explorar estén configurados correctamente.
La tabla agregada contenía filtros que no estaban en la consulta.	La tabla agregada tiene un filtro que no es de tiempo y que no está en la consulta. Para resolver este problema, puedes quitar el filtro de la tabla de agregados. Consulta la sección Factores de filtrado en esta página para obtener más detalles.
Un campo se define como un campo de solo filtro en la consulta de Explorar, pero se incluye en el parámetro `dimensions` de la tabla de datos agregados.	El parámetro `dimensions` de la tabla de datos agregados enumera un campo que se define solo como un campo `filter` en la consulta de Explorar. Para resolver este problema, quita el campo de la lista `dimensions` de la tabla de agregación. 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 usó la tabla agregada.	Este comentario se reserva para casos extremos. Si ves este mensaje para una consulta de Explorar que se usa con frecuencia, puedes crear una tabla de datos agregados que coincida exactamente con la consulta de Explorar. Puedes obtener el LookML de la tabla conjunta desde un Explore, como se describe en la página del parámetro `aggregate_table`.

Aspectos para tener en cuenta

Agregaciones simétricas para las exploraciones con uniones

Una cuestión importante que se debe tener en cuenta es que, en un Explore que une varias tablas de bases 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 cálculo en la expansión. Por ejemplo, una medida count se renderiza como un tipo de medida count_distinct. Esto se hace para evitar errores de cálculo en la expansión de las uniones y forma parte de la funcionalidad de agregados simétricos de Looker. Consulta la página de prácticas recomendadas sobre los agregados simétricos para obtener una explicación de esta función de Looker.

La funcionalidad de agregados simétricos evita los errores de cálculo, pero también puede impedir que se usen tus tablas de agregados en ciertos casos, por lo que es importante comprenderla.

En el caso de los tipos de medidas admitidos por la función de reconocimiento de agregaciones, esto se aplica a sum, count y average. Looker renderizará estos tipos de medidas como DISTINCT si se cumplen las siguientes condiciones:

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

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

Si descubres que tu tabla de datos agregados no se usa por este motivo, puedes crear una tabla de datos agregados que coincida exactamente con una consulta de Explorar para usar estos tipos de medidas en una exploración con uniones. Consulta la sección Crea tablas de agregación que coincidan exactamente con las consultas de Explorar en esta página para obtener más información.

Además, si tienes un dialecto de SQL que admite bocetos de HyperLogLog, puedes agregar el parámetro allow_approximate_optimization: yes a la métrica. Cuando se define una medición de recuento con allow_approximate_optimization: yes, Looker puede usar la medición para el conocimiento agregado, incluso si se renderiza como un recuento de valores distintos.

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

Compatibilidad con dialectos para el reconocimiento de agregaciones

La capacidad de usar la función de reconocimiento de agregados 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 conocimiento de agregaciones:

Dialecto	¿Es compatible?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13+
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

Compatibilidad con dialectos para la creación incremental de tablas de datos agregados

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 muestran los dialectos que admiten la compilación incremental de PDT en la versión más reciente de Looker:

Dialecto	¿Es compatible?
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13+
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica