Ten en cuenta que estás viendo la documentación de Looker. Para obtener documentación de Looker Studio, visita https://support.google.com/looker-studio.

Se usó la API de Cloud Translation para traducir esta página.

Reconocimiento agregado

Descripción general

Looker usa la lógica de reconocimiento agregado para encontrar la tabla más pequeña y eficiente disponible en tu base de datos para ejecutar una consulta y mantener la exactitud.

En el caso de las tablas muy grandes de tu base de datos, los desarrolladores de Looker pueden crear tablas agregadas de datos más pequeñas, agrupadas por varias combinaciones de atributos. Las tablas agregadas actúan como resúmenes o tablas de resumen 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 conocimiento agregado puede acelerar la consulta promedio en órdenes de magnitud.

Por ejemplo, puedes tener una tabla de datos a escala de petabytes con una fila para cada pedido que se haya producido en tu sitio web. A partir de esta base de datos, puedes crear una tabla conjunta con los totales diarios de las ventas. Si tu sitio web recibe 1,000 pedidos todos los días, tu tabla agregada diaria representaría cada día con 999 filas menos que tu tabla original. Puedes crear otra tabla conjunta con los totales de ventas mensuales que será aún más eficiente. Ahora, si un usuario ejecuta una consulta para 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 tú no tienes una tabla conjunta anual, Looker usará la siguiente mejor opción, que es la tabla de datos agregados de ventas mensuales en este ejemplo.

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

Para una consulta sobre las ventas mensuales totales, Looker usa la tabla conjunta 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 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, puedes crear una tabla conjunta para ella).
Para una consulta sobre las ventas semanales, no hay una tabla agregada semanal, por lo que Looker usa la siguiente mejor opción, que es la tabla agregada basada en las ventas diarias (sales_daily_aggregate_table).

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

No es necesario que las tablas agregadas se unan ni se agreguen a una función Explorar independiente. En su lugar, Looker ajusta de forma dinámica la cláusula FROM de la consulta Explorar para acceder a la mejor tabla agregada para la consulta. Esto significa que tus taladros se mantienen y se pueden consolidar las Exploraciones. Con el conocimiento agregado, una exploración puede aprovechar automáticamente las tablas agregadas, pero aún así profundizar en los datos detallados si es necesario.

También puedes aprovechar las tablas conjuntas para mejorar drásticamente el rendimiento de los paneles, en especial para los mosaicos que consultan enormes conjuntos de datos. Para obtener más información, consulta la sección Cómo obtener LookML de tabla agregada 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 conjuntas estratégicas que minimizarán la cantidad de consultas requeridas en las tablas grandes de una base de datos. Las tablas agregadas deben permanecer en tu base de datos para que se pueda acceder a ellas para la información agregada. Por lo tanto, las tablas conjuntas son un tipo de tabla derivada persistente (PDT).

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

Este es 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 conjunta, puedes escribir el LookML desde cero o puedes obtener LookML de tabla conjunta desde una exploración o desde un panel. Consulta la página de documentación del parámetro aggregate_table para conocer los detalles del parámetro aggregate_table y sus subparámetros.

Diseña tablas conjuntas

Para que una consulta de exploración use una tabla conjunta, esta debe poder proporcionar datos precisos para la consulta de exploración. Looker puede usar una tabla conjunta para una consulta de exploración si se cumplen las siguientes condiciones:

Los campos de la consulta Explorar son un subconjunto de los campos de la tabla conjunta (consulta la sección Factores de campo de esta página). En el caso de los períodos, los de la consulta de exploración se pueden derivar de los períodos de la tabla conjunta (consulta la sección Factores de los períodos en esta página).
La consulta Explorar contiene tipos de mediciones compatibles con el reconocimiento agregado (consulta la sección Factores del tipo de medición de esta página) o la consulta Explorar tiene una tabla conjunta que es una coincidencia exacta (consulta la sección Cómo crear tablas conjuntas que coincidan exactamente con las búsquedas de Explorar en esta página).
La zona horaria de la consulta de exploración coincide con la que utiliza la tabla conjunta (consulta la sección Factores de zona horaria en esta página).
Los filtros de la consulta de exploración hacen referencia a los campos que están disponibles como dimensiones en la tabla de datos agregados, o bien cada uno de los filtros de la consulta de exploración coincide con un filtro de la tabla de datos agregados (consulta la sección Factores de filtro en esta página).

Una forma de garantizar que una tabla conjunta pueda proporcionar datos precisos para una consulta de exploración es crear una tabla conjunta que coincida de manera exacta con una consulta de exploración. Consulta la sección Crea tablas conjuntas que coincidan exactamente con las consultas de Explorar de esta página para obtener más detalles.

Factores de campo

Para poder usarse en una consulta de Explorar, una tabla agregada 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 Explorar contiene una dimensión o medida que no está en una tabla conjunta, Looker no puede usar la tabla conjunta y, en su lugar, utilizará la tabla base.

Por ejemplo, si una consulta agrupa por las dimensiones A y B, agrega por la medida C y filtra por la dimensión D, entonces 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 para que sea viable para la optimización. La única excepción son las dimensiones de período, ya que los períodos con mayor nivel de detalle pueden derivar de períodos con mayor nivel de detalle.

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

Factores del período

La lógica de conocimiento agregado de Looker puede derivar un período de otro. Se puede usar una tabla conjunta para una consulta, siempre y cuando el período de la tabla tenga un nivel de detalle mayor (o igual) que el de la consulta 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, del año y de la semana del año. Sin embargo, no se puede usar una tabla conjunta anual para una consulta de exploración que solicite datos por hora, ya que los datos de la tabla conjunta no tienen un nivel de detalle lo suficientemente detallado para esta consulta.

Lo mismo se aplica a los subconjuntos de períodos. Por ejemplo, si tienes una tabla agregada que se filtró por los últimos tres meses y un usuario consulta los datos con un filtro de los últimos dos meses, Looker podrá usar la tabla conjunta para esa consulta.

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

Factores del tipo de medición

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 compatibles
Magnitudes 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 medición, Looker usará la tabla original, no la tabla conjunta, para mostrar resultados. La única excepción es si la consulta de Explorar es una concordancia exacta de una consulta de tabla agregada, como se describe en la sección Cómo crear tablas agregadas que coincidan exactamente con las consultas de Explorar.

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

Mediciones con tipos de mediciones compatibles

La visibilidad agregada se puede usar para las consultas de Explorar que usan medidas con estos tipos de medición:

Si quieres usar una tabla conjunta en una consulta de exploración, Looker debe poder operar con las medidas de esa tabla para proporcionar datos precisos en esa consulta. Por ejemplo, una medida con type: sum se puede usar para la visibilidad agregada, ya que puedes sumar varias sumas: se puede agregar una tabla agregada de sumas semanales para 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 mediciones con type: average, se admite el reconocimiento agregado porque Looker usa datos de suma y recuento para derivar con precisión los valores promedio de las tablas conjuntas.

Medidas definidas con expresiones de SQL

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

La visibilidad agregada es compatible con las medidas que se definen como combinaciones de otras medidas, como en este ejemplo:

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

La visibilidad agregada también es compatible con las mediciones en las que los cálculos se definen en el parámetro sql, como esta medición:

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

Además, el reconocimiento agregado es compatible con las mediciones en las que las operaciones MIN, MAX y COUNT se definen en el parámetro sql, como la siguiente 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 mediciones, el reconocimiento agregado admite los siguientes tipos de referencias de campo:

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

El reconocimiento agregado no es compatible con las mediciones que se definen con el formato ${TABLE}.column_name, que indica una columna en una tabla. (consulta la página de documentación Cómo incorporar SQL y consultar 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, como se muestra a continuación:


 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 conocimiento agregado porque no puedes obtener datos precisos si intentas agregar recuentos distintos. Por ejemplo, si estás contando los distintos usuarios en un sitio web, es posible que haya un usuario que haya llegado al sitio web dos veces, con tres semanas de diferencia. Si intentas aplicar una tabla agregada 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 distinto, y los datos serían incorrectos.

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

Otra opción es usar aproximaciones para recuentos distintos. En el caso de los dialectos que admiten esbozos HyperLogLog, Looker puede aprovechar el algoritmo HyperLogLog para aproximar los recuentos distintos 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 tus desarrolladores de Looker reconozcan que está bien usar datos aproximados para la métrica, 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 estén en la zona horaria UTC. Looker tiene varias opciones para convertir zonas horarias de modo que tus usuarios obtengan resultados de la consulta en su propia zona horaria:

Zona horaria de consulta, un parámetro de configuración que se aplica a todas las consultas en la conexión de la base de datos. Si todos los usuarios se encuentran en la misma zona horaria, puedes configurar una única zona horaria de consulta para que todas las consultas se conviertan de la zona horaria de la base de datos a la de la consulta.
Zonas horarias específicas del usuario, en las que se pueden asignar y seleccionar las 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 utilizar la configuración de 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 conjunta se pueda usar en una consulta con dimensiones o filtros de fecha, la zona horaria de la tabla debe coincidir con la configuración de zona horaria que se usó para la consulta original.

Las tablas conjuntas usan la zona horaria de la base de datos si no se especifica un valor 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 la conexión de la 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, la 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, se debe definir la zona horaria de la tabla conjunta para que coincida con las consultas posibles, de modo que sea más probable que se use la tabla conjunta:

Si la conexión de tu base de datos usa una sola zona horaria de consulta, debes hacer coincidir el valor timezone de tu tabla agregada con el valor de la zona horaria de la consulta.
Si la conexión de tu base de datos usa zonas horarias específicas de los usuarios, debes crear tablas conjuntas 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 agregada. Los filtros en una tabla agregada pueden reducir los resultados hasta el punto en que la tabla agregada no se puede usar. Por ejemplo, supongamos que creas una tabla conjunta para los recuentos de pedidos diarios y la tabla conjunta filtra solo los pedidos de gafas de sol que provienen de Australia. Si un usuario ejecuta una consulta de exploración para los recuentos diarios de pedidos de lentes de sol en todo el mundo, Looker no puede usar la tabla conjunta para esa consulta de exploración, ya que esta solo tiene los datos de Australia. La tabla conjunta filtra los datos demasiado poco para que los use la consulta Explorar.

Además, ten en cuenta los filtros que los desarrolladores de Looker podrían haber incorporado en tu exploración, como los siguientes:

access_filters: Aplica restricciones de datos específicas del usuario.
always_filter: Exige a los usuarios que incluyan un conjunto determinado de filtros para una consulta de Explorar. Los usuarios pueden cambiar el valor predeterminado del filtro 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 está definida en Explorar.

Estos tipos de filtro 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, a continuación, se muestra una exploración 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 conjunta que se usará en esta exploración, esta 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 conjunta:

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 tablas conjuntas incluye la dimensión orders.region, Looker puede filtrar de forma dinámica los datos en la tabla conjunta para que coincidan con el filtro de la consulta Explorar. Por lo tanto, Looker aún puede usar la tabla agregada 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 reconocimiento agregado, si tu consulta de exploración requiere una tabla derivada nativa que use bind_filters, la consulta de exploración puede usar una tabla conjunta solo si todos los campos utilizados en el parámetro bind_filters de la tabla derivada nativa tienen exactamente los mismos valores de filtro en la consulta de exploración que en la tabla conjunta.

Cómo crear tablas agregadas que coincidan exactamente con las consultas de Explorar

Una forma de asegurarse de que se pueda usar una tabla agregada para una consulta de Explorar es 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, por definición, los resultados de la tabla agregada se aplicarán a la consulta Explorar. Si una tabla agregada es una concordancia exacta de una consulta de Explorar, Looker puede usar tablas agregadas que incluyan cualquier tipo de medida.

Puedes crear una tabla conjunta desde una exploración usando 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.

Determina qué tabla agregada 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 agregada se usará para una consulta. Los comentarios de la pestaña SQL también se muestran en el Modo de desarrollo, de modo que los desarrolladores puedan probar nuevas tablas agregadas para ver cómo las usa Looker antes de enviarlas a producción.

Por ejemplo, según la tabla conjunta mensual de ejemplo que se mostró anteriormente, puedes ir a Explorar y ejecutar una consulta para ver los totales anuales de las ventas. Luego, puedes hacer clic en la pestaña SQL para ver los detalles de la consulta que creó Looker. Si estás en modo de desarrollo, Looker muestra comentarios para indicar la tabla agregada 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 de esta página para conocer los posibles comentarios que podrías ver en la pestaña SQL y las sugerencias para resolverlos.

Estimaciones de ahorro de procesamiento para el conocimiento agregado

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

Antes de ejecutar la consulta, si deseas ver qué tabla agregada se usará para ella, puedes hacer clic en la pestaña SQL, como se describe en la sección Determina 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 responderla junto al botón Ejecutar.

El ahorro total de reconocimiento se muestra para las conexiones de bases de datos que están 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 datos nuevos a tus tablas conjuntas.

En el caso de las tablas conjuntas con filtros de tiempo, Looker puede unir datos actualizados en tu tabla conjunta. Es posible que tengas una tabla conjunta que incluya datos de los últimos tres días, pero es posible que se haya creado ayer. Faltaría la información de hoy en la tabla conjunta, por lo que no esperarías usarla para una consulta de Explorar con la información diaria más reciente.

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

Looker puede unir datos actualizados con los datos de tu tabla agregada en las siguientes circunstancias:

La tabla conjunta tiene un filtro de tiempo.
La tabla de datos agregados incluye una dimensión basada en el mismo campo de hora que el filtro de hora.

Por ejemplo, la siguiente tabla conjunta 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 conjunta se creó ayer, Looker recuperará los datos más recientes que aún no están incluidos en la tabla conjunta y, luego, unirá los resultados nuevos con los de la tabla conjunta. Esto significa que tus usuarios obtendrán los datos más recientes y, al mismo tiempo, optimizarán el rendimiento con la visibilidad global.

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

Las tablas conjuntas deben ser persistentes

Para que se pueda acceder a ella para el reconocimiento agregado, se debe mantener una tabla conjunta 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), tienen los mismos requisitos que las PDT. Consulta la página de documentación de Tablas derivadas en Looker para obtener más información.

Puedes crear PDT incrementales en tu proyecto si tu dialecto los admite. Looker compila PDT incrementales agregando datos nuevos a la tabla, en lugar de volver a compilar la tabla por completo. Dado que las tablas conjuntas son en sí mismas un tipo de PDT, también puedes crear tablas conjuntas incrementales. Consulta la página de documentación sobre las PDT incrementales para obtener más información al respecto. Consulta la página de documentación del parámetro increment_key para ver un ejemplo de una tabla agregada incremental.

Un usuario con 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. Para volver a compilar las tablas para una consulta, selecciona Rebuild Derived Tables & Run en el menú de ajustes Explorar acciones.

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.

Para el usuario que inicia el módulo Recompilar tablas derivadas 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 de Tablas derivadas en Looker para obtener más detalles sobre Volver a compilar tablas derivadas y Run.

Soluciona problemas

Como se describe en la sección Determina qué tabla agregada se usa para una consulta, si estás en Modo de desarrollo, puedes ejecutar consultas en Explorar y hacer clic en la pestaña SQL para ver los comentarios acerca de la tabla agregada usada para la consulta, si corresponde.

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

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

Por ejemplo, a continuación, se muestra un comentario sobre por qué la tabla conjunta sales_daily definida en la exploración de order_items no se usó 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 agregada.

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

Motivo por el que no se usa la tabla de datos agregados	Explicación y posibles pasos
Este campo no existe en Explorar.	Hay un error de tipo de validación de LookML. Lo más probable es que esto se deba a que la tabla conjunta no se definió correctamente o a que hubo un error tipográfico en LookML de tu tabla conjunta. Es probable que el problema sea un nombre de campo incorrecto o algo similar. Para resolver este problema, verifica que las dimensiones y las medidas de la tabla agregada coincidan con los nombres de los campos de 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 poder usarse en una consulta de Explorar, una tabla agregada 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 Explorar contiene una dimensión o medida que no está en una tabla conjunta, Looker no puede usar la tabla conjunta y, en su lugar, utilizará la tabla base. Para obtener más información, consulta la sección Factores de campo de esta página. La única excepción son las dimensiones de período, ya que los períodos con mayor nivel de detalle pueden derivar de aquellos con mayor nivel de detalle. Para resolver este problema, verifica que los campos de la consulta Explorar estén incluidos 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 agregada.	Los filtros de la consulta Explorar evitan que Looker use la tabla conjunta. Para resolver este problema, puedes realizar una de las siguientes acciones: Agrega el mismo filtro a tu tabla conjunta. Agrega el campo que usa el filtro a tu tabla conjunta. Quita los filtros de la búsqueda de Explorar. Consulta la sección Factores de filtro en esta página para obtener más información.
La consulta contiene las siguientes medidas que no se pueden integrar.	La consulta contiene uno o más tipos de medición que no se admiten para la visibilidad agregada, como cantidad distinta, 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 exploración tiene uniones, verifica que las mediciones no se conviertan en medidas distintas (agregaciones simétricas) a través de uniones en distribución. Consulta la sección Agrupaciones simétricas para Explorar con combinaciones en esta página para obtener una explicación.
Una tabla conjunta diferente era más adecuada para la optimización.	Había varias tablas conjuntas viables para la consulta, y Looker encontró una tabla conjunta más óptima para usar. No es necesario hacer nada en este caso.
Looker no realizó ninguna agrupación (debido a un parámetro `primary_key` o `cancel_grouping_fields`) y, por lo tanto, la consulta no se puede consolidar.	La consulta hace referencia a una dimensión que le impide tener una cláusula `GROUP BY` y, por lo tanto, Looker no puede usar ninguna tabla agregada 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 conjunta contenía filtros que no estaban en la consulta.	La tabla agregada tiene un filtro que no es de tiempo que no está en la consulta. Para resolver esto, puedes quitar el filtro de la tabla conjunta. Para obtener más detalles, consulta la sección Filtrar factores de esta página.
Un campo se define como un campo de solo filtro en la consulta de exploración, pero aparece en el parámetro `dimensions` de la tabla conjunta.	El parámetro `dimensions` de la tabla conjunta enumera un campo que se define únicamente como `filter` en la consulta Explorar. Para resolver este problema, quita el campo de la lista `dimensions` de la tabla agregada. Si este campo es necesario para la tabla conjunta, agrégalo a la lista `filters` en la consulta de la tabla.
El optimizador no puede determinar por qué no se usó la tabla de datos agregados.	Este comentario está reservado para los casos límite. Si ves esto para una consulta de exploración que se usa con frecuencia, puedes crear una tabla conjunta que coincida exactamente con esa consulta. Puedes obtener fácilmente LookML de tabla conjunta desde una exploración, 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

Es importante tener en cuenta que, en una exploración que combina 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 de fanout. Por ejemplo, una medida count se renderiza como un tipo de medida count_distinct. Esto se hace para evitar errores de cálculo de fanout en las uniones y es parte de la funcionalidad de agregados simétricos de Looker. Consulta la página de prácticas recomendadas sobre los agregados simétricos para ver una explicación de esta función de Looker.

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

Para los tipos de mediciones admitidos en el reconocimiento agregado, esto se aplica a sum, count y average. Looker renderizará estos tipos de mediciones como DISTINCT si:

La medición proviene de la vista "uno" de una unión varios a uno o uno a varios.
La medición es desde cualquier vista de una unión de 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 descubres que tu tabla de datos agregados no se usa por este motivo, puedes crear una tabla conjunta para que coincida exactamente con una consulta de exploración y, así, usar estos tipos de mediciones en una exploración con uniones. Consulta la sección Cómo crear tablas agregadas 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 esbozos de HyperLogLog, puedes agregar el parámetro allow_approximate_optimization: yes a la medición. Cuando se define una medición de recuento con allow_approximate_optimization: yes, Looker puede usarla para el reconocimiento agregado, incluso si se renderiza como un recuento distinto.

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

Compatibilidad con dialectos para aumentar el reconocimiento global

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

Dialecto	¿Es compatible?
Avalancha de Actian	Sí
Amazon Athena	Sí
Amazon Aurora MySQL	Sí
Amazon Redshift	Sí
Apache Druid	No
Apache Druid 0.13 y versiones posteriores	No
Apache Druid 0.18 y versiones posteriores	No
Apache Hive 2.3 y versiones posteriores	Sí
Apache Hive 3.1.2 y versiones posteriores	Sí
Apache Spark 3 y versiones posteriores	Sí
ClickHouse	No
Cloudera Impala 3.1 y versiones posteriores	Sí
Cloudera Impala 3.1+ con controlador nativo	Sí
Cloudera Impala con controlador nativo	Sí
DataVirtuality	No
Databricks	Sí
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11 y versiones posteriores	No
Exasol	Sí
Bola de fuego	No
SQL heredado de Google BigQuery	Sí
SQL estándar de Google BigQuery	Sí
PostgreSQL de Google Cloud	Sí
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sí
HyperSQL	No
IBM Netezza	Sí
MariaDB	Sí
PostgreSQL de Microsoft Azure	Sí
Microsoft Azure SQL Database	Sí
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	Sí
Microsoft SQL Server 2012 y versiones posteriores	Sí
Microsoft SQL Server 2016	Sí
Microsoft SQL Server 2017 y versiones posteriores	Sí
MongoBI	No
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	Sí
Oracle ADWC	Sí
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la versión 9.5	Sí
PrestoDB	Sí
PrestoSQL	Sí
SAP HANA 2 y versiones posteriores	Sí
SingleStore	Sí
SingleStore 7 y versiones posteriores	Sí
Snowflake	Sí
Teradata	Sí
Trino	Sí
Vector	Sí
Vertica	Sí

Compatibilidad con dialectos para compilar tablas agregadas de forma incremental

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

Dialecto	¿Es compatible?
Actian Avalanche	No
Amazon Athena	No
Amazon Aurora MySQL	No
Amazon Redshift	Sí
Apache Druid	No
Apache Druid 0.13 y versiones posteriores	No
Apache Druid 0.18 y versiones posteriores	No
Apache Hive 2.3 y versiones posteriores	No
Apache Hive 3.1.2 y versiones posteriores	No
Apache Spark 3 y versiones posteriores	No
ClickHouse	No
Cloudera Impala 3.1 y versiones posteriores	No
Cloudera Impala 3.1+ con controlador nativo	No
Cloudera Impala con controlador nativo	No
DataVirtuality	No
Databricks	Sí
Denodo 7	No
Denodo 8	No
Dremio	No
Dremio 11 y versiones posteriores	No
Exasol	No
Firebolt	No
SQL heredado de Google BigQuery	No
SQL estándar de Google BigQuery	Sí
PostgreSQL de Google Cloud	Sí
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sí
HyperSQL	No
IBM Netezza	No
MariaDB	No
PostgreSQL de Microsoft Azure	Sí
Microsoft Azure SQL Database	No
Microsoft Azure Synapse Analytics	Sí
Microsoft SQL Server 2008 y versiones posteriores	No
Microsoft SQL Server 2012 y versiones posteriores	No
Microsoft SQL Server 2016	No
Microsoft SQL Server 2017 y versiones posteriores	No
MongoBI	No
MySQL	Sí
MySQL 8.0.12 y versiones posteriores	Sí
Oracle	No
Oracle ADWC	No
PostgreSQL 9.5 y versiones posteriores	Sí
PostgreSQL anterior a la versión 9.5	Sí
PrestoDB	No
PrestoSQL	No
SAP HANA 2 y versiones posteriores	No
SingleStore	No
SingleStore 7 y versiones posteriores	No
Snowflake	Sí
Teradata	No
Trino	No
Vector	No
Vertica	Sí