Ten en cuenta que estás viendo la documentación de Looker. Para ver la 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.

Para tablas muy grandes en tu base de datos, los desarrolladores de Looker pueden crear tablas conjuntas de datos más pequeñas, agrupadas por varias combinaciones de atributos. Las tablas conjuntas actúan como tablas de datos integrados o 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 reconocimiento agregado puede acelerar el promedio de consultas en órdenes de magnitud.

Por ejemplo, puedes tener una tabla de datos a escala de petabytes con una fila para cada pedido realizado 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 cada día, tu tabla conjunta 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. Entonces, si un usuario ejecuta una consulta sobre ventas diarias o semanales, Looker usará la tabla de ventas diarias totales. 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, podrías crear una tabla conjunta para ella).
Para una consulta sobre ventas semanales, no hay una tabla agregada semanal, por lo que Looker usa la siguiente mejor opción, que es la tabla conjunta 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 tus usuarios. 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 unir las tablas conjuntas ni agregarlas a una exploración separada. En cambio, 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 tus taladros se mantienen y se pueden consolidar las Exploraciones. Con el reconocimiento agregado, una exploración puede aprovechar automáticamente las tablas conjuntas, pero aun así profundizar en 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 Obtén LookML de tabla agregado a partir de un panel en la página de documentación de parámetros aggregate_table.

Agrega tablas conjuntas 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 conjuntas deben ser conservadas en tu base de datos, de modo que se pueda acceder a ellas para el reconocimiento de la agregación. 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 conjunta 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 obtener 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 Explorar hacen referencia a los campos que están disponibles como dimensiones en la tabla conjunta, o bien cada uno de los filtros de la consulta de Explorar coincide con un filtro de la tabla conjunta (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 usarla en una consulta de exploración, una tabla conjunta debe tener todas las dimensiones y medidas necesarias para esa consulta de exploración, incluidos los campos que se usan para los filtros en esa consulta. Si una consulta Explorar contiene una dimensión o medición 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 conjunta también puede tener otros campos, pero debe tener, al menos, los campos de consulta 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 aquellos 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 conjunta definida en una exploración no se usará para las consultas de otra exploración.

Factores del período

La lógica de reconocimiento 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 exploración 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 o 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 intervalos de tiempo. 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 para 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.

Cómo medir factores de tipo

Para que una consulta de exploración use una tabla conjunta, las mediciones de esta tabla deben poder proporcionar datos precisos para esa consulta.

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

Medidas con tipos de medición compatibles
Mediciones definidas por expresiones de SQL
Medidas que no están definidas con ${TABLE}
Son mediciones que se aproximan a 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 ocurre si la consulta de exploración es una coincidencia exacta de una consulta de tabla conjunta, como se describe en la sección Cómo crear tablas conjuntas que coinciden exactamente con las consultas de Explorar.

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

Mediciones con tipos de mediciones compatibles

El reconocimiento agregado se puede usar en las búsquedas de Explorar que utilizan mediciones con los siguientes tipos de mediciones:

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 medición con type: sum se puede usar para el reconocimiento total porque es posible sumar varias sumas: se puede sumar una tabla conjunta de sumas semanales para obtener una suma mensual precisa. De manera similar, se puede usar una medición 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.

Mediciones definidas con expresiones de SQL

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

El reconocimiento agregado se admite para las mediciones que se definen como combinaciones de otras mediciones, como el siguiente 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 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 de datos agregados, 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 conjunta.

Medidas que se aproximan a recuentos distintos

En general, los recuentos distintos no se admiten con el reconocimiento agregado, ya que no podrás 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 la 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 exploración y una de tabla conjunta son iguales, las distintas mediciones de recuento proporcionan datos precisos, por lo que se pueden usar para el reconocimiento agregado.

Otra opción es usar aproximaciones para recuentos distintos. Para los dialectos que admiten esbozos de HyperLogLog, Looker puede aprovechar el algoritmo HyperLogLog para aproximar recuentos distintos para 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 esta se pueda calcular de forma aproximada a partir de tablas conjuntas.

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 recuentos distintos 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 estén en la zona horaria UTC. Looker tiene varias opciones para convertir zonas horarias, de modo que los usuarios obtengan los resultados de las consultas 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. La conexión de 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.
La conexión de tu base de datos no tiene una zona horaria para la consulta ni zonas horarias específicas del usuario. Si este es el caso, la conexión de la base de datos usará su zona horaria.

Si alguna de estas opciones es verdadera, puedes omitir el parámetro timezone en 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.

Filtrar factores

Ten cuidado cuando incluyas filtros en tu tabla de datos agregados. Los filtros en una tabla conjunta pueden reducir los resultados al punto en que esta última 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 que los usuarios incluyan un conjunto determinado de filtros para una búsqueda 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 los 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 de datos agregados que se usará para 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 puede seguir usando la tabla de datos agregados para las consultas de Explorar, 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.

Crear tablas conjuntas que coincidan exactamente con las consultas de Explorar

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

Puedes crear una tabla conjunta a partir de una exploración con la opción Get LookML del menú de ajustes de una Explorar. También puedes crear coincidencias exactas para todos los mosaicos de un panel con la opción Get 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 una exploración para ver qué tabla conjunta se usará en una consulta. Los comentarios de la pestaña SQL también se muestran en Modo de desarrollo, por lo que los desarrolladores pueden probar tablas conjuntas nuevas 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 conjunta que usó para la consulta.

En los siguientes comentarios sobre la pestaña SQL, podemos ver que Looker está usando la tabla de datos agregados sales_monthly para esta consulta y también información sobre por qué no se usaron otras tablas conjuntas:

-- 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 en el procesamiento para el reconocimiento agregado

Si tu conexión de base de datos admite estimaciones de costos y si se puede usar una tabla conjunta para una consulta, en la ventana Explorar se mostrará el ahorro de procesamiento que se obtiene al usar la tabla conjunta 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 ejecutar la consulta.

Antes de ejecutar la consulta, si quieres 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 conjunta se usa para una consulta de esta página de documentación.

Una vez ejecutada la consulta, la ventana Explorar mostrará qué tabla conjunta se usó para responder la consulta 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 Explora datos en Looker para obtener más información.

Looker une datos nuevos en 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 porque la ejecutará en los datos más recientes y, luego, unirá esos resultados en la tabla conjunta.

Looker puede unir datos recientes con los 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, seguirán optimizando el rendimiento con el reconocimiento agregado.

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

Las tablas conjuntas deben ser persistentes

Para que se pueda acceder a ella para el reconocimiento agregado, debes conservar la 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 conjuntas son un tipo de tabla derivada persistente (PDT), las tablas conjuntas 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 el dialecto las admite. Looker crea PDT incrementales agregando datos actualizados a la tabla, en lugar de volver a compilarla 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 el permiso develop puede anular la configuración de persistencia y volver a compilar todas las tablas conjuntas de una consulta para obtener los datos más recientes. 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 Explorar acciones.

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

La opción Volver a compilar tablas derivadas y ejecutar 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 en la consulta. Esto incluye las tablas conjuntas, que son a su vez un tipo de tabla derivada persistente.

Para el usuario que inicie la opción Volver a compilar tablas derivadas y ejecutar, 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. Cuando se vuelvan a compilar las tablas persistentes, todos los usuarios usarán las tablas que se volvieron a compilar.

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 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 que se usó para la consulta, si corresponde.

La pestaña SQL también incluye comentarios sobre por qué no se usaron las tablas conjuntas para una consulta, en ese 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 conjunta.

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. Un probable culpable es un nombre de campo incorrecto, o algo similar. Para resolver este problema, verifica que las dimensiones y mediciones de la tabla conjunta 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 conjunta no incluye los siguientes campos en la consulta.	Para usarla en una consulta de exploración, una tabla conjunta debe tener todas las dimensiones y medidas necesarias para esa consulta de exploración, incluidos los campos que se usan para los filtros en esa consulta. Si una consulta Explorar contiene una dimensión o medición 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 esto, verifica que los campos de la consulta de exploración estén incluidos en la definición de tabla agregada.
La consulta contenía los siguientes filtros que no se incluían como campos ni coincidían exactamente con los filtros en la tabla conjunta.	Los filtros de la consulta Explorar evitan que Looker use la tabla conjunta. Para resolverlo, 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 consulta Explorar. Consulta la sección Filtrar factores de esta página para obtener más detalles.
La consulta contiene las siguientes medidas que no se pueden incluir en la lista.	La consulta contiene uno o más tipos de mediciones que no son compatibles con el reconocimiento agregado, como el recuento distinto, la mediana o el percentil. Para resolver esto, verifica el tipo de cada medición en la consulta y asegúrate de que sea uno de los tipos de mediciones 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 Agregaciones simétricas para exploraciones con uniones 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 óptima para usar en su lugar. No es necesario realizar ninguna acción en este caso.
Looker no hizo ninguna agrupación (debido a los parámetros `primary_key` o `cancel_grouping_fields`) y, por lo tanto, la consulta no se puede agrupar.	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 conjunta 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 la exploración estén configurados correctamente.
La tabla conjunta contenía filtros que no estaban en la consulta.	La tabla conjunta tiene un filtro que no es de tiempo y 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 conjunta. 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 lo hace para evitar cálculos erróneos de distribución. Por ejemplo, una medida count se renderiza como un tipo de medición count_distinct. Esto se hace para evitar cálculos erróneos de las uniones, y es parte de la funcionalidad de agregaciones simétricas 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 funcionalidad de las agregaciones simétricas evita los cálculos erróneos, pero también puede impedir que se usen tus tablas conjuntas 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 es desde la vista de “uno” de una unión de varios a uno o de 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 está usando 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 Crea tablas conjuntas que coincidan exactamente con las consultas de Explorar de 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 reconocimiento 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 en Google Cloud	Sí
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sí
HyperSQL	No
IBM Netezza	Sí
MariaDB	Sí
Microsoft Azure PostgreSQL	Sí
Base de datos de Microsoft Azure SQL	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 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 conjuntas 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?
Avalancha de Actian	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
Bola de fuego	No
SQL heredado de Google BigQuery	No
SQL estándar de Google BigQuery	Sí
PostgreSQL en Google Cloud	Sí
Google Cloud SQL	No
Google Spanner	No
Greenplum	Sí
HyperSQL	No
IBM Netezza	No
MariaDB	No
Microsoft Azure PostgreSQL	Sí
Base de datos de Microsoft Azure SQL	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 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í