Reconocimiento agregado

Descripción general

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

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 resumen o de datos integrados que Looker puede usar para consultas siempre que sea posible, en lugar de la tabla grande original. Cuando se implementa de manera estratégica, el reconocimiento agregado puede acelerar la consulta promedio en varios órdenes de magnitud.

Por ejemplo, imagina que tienes 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 conjunta con los totales de tus ventas diarias. Si tu sitio web recibe 1,000 pedidos todos los días, tu tabla conjunta diaria representaría cada día con 999 filas menos que en tu tabla original. Puedes crear otra tabla conjunta con los totales de ventas mensuales que será aún más eficiente. Así que ahora, si un usuario ejecuta una consulta para ventas diarias o semanales, Looker usará la tabla de totales de ventas diarias. Si un usuario ejecuta una consulta sobre ventas anuales y tú no tienes una tabla conjunta anual, Looker usará la mejor opción, que es la tabla conjunta de ventas mensuales de este ejemplo.

Looker responde las preguntas de los 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 existe una tabla conjunta con ese nivel de detalle, por lo que Looker obtiene los resultados de la tabla de la base de datos original (orders_database). Sin embargo, si los usuarios ejecutan este tipo de consultas a menudo, podrías crear una tabla conjunta para ella.
  • Para una consulta sobre las ventas semanales, no hay una tabla conjunta semanal, por lo que Looker usa la mejor opción, que es la tabla conjunta basada en las ventas diarias (sales_daily_aggregate_table).

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

No es necesario unir ni agregar tablas conjuntas a una exploración separada. En cambio, Looker ajusta de forma dinámica la cláusula FROM de la consulta Explorar para acceder a la mejor tabla conjunta para la consulta. Esto significa que se mantienen tus desgloses 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 los datos detallados si es necesario.

También puedes aprovechar las tablas conjuntas para mejorar drásticamente el rendimiento de los paneles, especialmente para las tarjetas que consultan enormes conjuntos de datos. Para obtener más información, consulta la sección Cómo obtener LookML de tabla conjunta de un panel en la página de documentación del parámetro 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 tener mantenencia en la base de datos, de modo que sea posible acceder a ellas para el reconocimiento agregado. Por lo tanto, las tablas conjuntas son un tipo de tabla derivada persistente (PDT).

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

Aquí hay un ejemplo de 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 LookML desde cero o puedes obtener la tabla conjunta de LookML 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ño de tablas conjuntas

Para que una consulta de exploración use una tabla conjunta, esta debe poder proporcionar datos precisos a esa consulta. 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 en esta página). En el caso de los períodos, los de la consulta Explorar pueden derivar de los períodos de la tabla conjunta (consulta la sección Factores del período en esta página).
  • La consulta Explorar contiene tipos de medición compatibles con el reconocimiento agregado (consulta la sección Factores de tipo de medición en esta página), o bien 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 Explorar coincide con la que usa la tabla conjunta (consulta la sección Factores de zona horaria de esta página).
  • Los campos de referencia de los filtros de la consulta Explorar que están disponibles como dimensiones en la tabla conjunta o que cada uno de los filtros de esta función 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. Para obtener más información, consulta la sección Crea tablas conjuntas que coincidan exactamente con las consultas de Explorar en esta página.

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, incluidos los campos que se usan en los filtros de esa consulta. Si una consulta de exploración contiene una dimensión o medida que no está en una tabla conjunta, Looker no puede usar la tabla conjunta, sino la tabla base.

Por ejemplo, si una consulta se agrupa por las dimensiones A y B, agrega por medida C y filtra en la dimensión D, la tabla conjunta debe tener mínimamente 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 la optimización. La única excepción son las dimensiones de período, ya que los períodos de mayor nivel de detalle pueden derivar de aquellos con mayor nivel de detalle.

Debido a las consideraciones de estos campos, una tabla conjunta es específica para la exploración en la que se define. No se usará una tabla conjunta definida en una exploración para realizar consultas en otra exploración.

Factores del período

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

Lo mismo se aplica a los subconjuntos de intervalos de tiempo. Por ejemplo, si tienes una tabla conjunta que se filtró por los últimos tres meses y un usuario consulta los datos con un filtro durante 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 más fino (o igual) que el filtro de período que se usa en la consulta 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.

Medir factores de tipo

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

Por esta razón, solo se admiten ciertos tipos de medidas, como se describe en las siguientes secciones:

Si una consulta de exploración usa cualquier otro tipo de medición, Looker usará la tabla original, no la tabla conjunta, para mostrar los resultados. La única excepción se da cuando la consulta Explorar coincide exactamente con una consulta de tabla conjunta, como se describe en la sección Cómo crear tablas conjuntas que coincidan exactamente con las consultas Explorar.

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

Mediciones con tipos de medición compatibles

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

Para usar una tabla conjunta en una consulta de exploración, Looker debe poder operar en las medidas de la tabla conjunta para proporcionar datos precisos en esa consulta. Por ejemplo, se puede usar una medida con type: sum para el reconocimiento agregado, ya que puedes sumar varias sumas: se puede sumar una tabla conjunta de las sumas semanales para obtener una suma mensual precisa. De manera similar, se puede usar una medición con type: max, ya que se puede usar una tabla conjunta 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 los 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 que se definen con expresiones en el parámetro sql. Cuando se definen con expresiones de SQL, también se admiten los siguientes tipos de medición:

El reconocimiento agregado se admite en medidas que se definen como combinaciones de otras medidas, como en 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 se admite en las mediciones donde los cálculos se definen en el parámetro sql, como la siguiente:

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 esta medida:

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

Medidas que hacen referencia a los campos de LookML

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

  • Referencias 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

No se admite el reconocimiento agregado para 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 Incorporación de SQL y consulta de 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 conjunta, 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 conjunta, puedes crear una dimensión definida con el formato ${TABLE}.column_name y, luego, crear una medición 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 porque no puedes obtener datos precisos si intentas agregar recuentos distintos. Por ejemplo, si estás contando los distintos usuarios de un sitio web, puede haber un usuario que visitó el sitio web dos veces, con tres semanas de diferencia. Si intentaras aplicar una tabla conjunta semanal para obtener un recuento mensual de los distintos usuarios de tu sitio web, ese usuario se contaría dos veces en tu consulta mensual de recuento distinto, y los datos serían incorrectos.

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

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

Se sabe que el algoritmo HyperLogLog tiene aproximadamente un error 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 aproximadamente 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 la zona horaria

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

  • Zona horaria de la consulta, una 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 convertir todas las consultas de la zona horaria de la base de datos a la zona horaria de la consulta.
  • Zonas horarias específicas del usuario, donde se pueden asignar usuarios y seleccionar zonas horarias de forma individual En este caso, las consultas se convierten de la zona horaria de la base de datos en la zona horaria del usuario individual.

Consulta la página de documentación Usa 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 use en una consulta con dimensiones de fecha o filtros de fecha, la zona horaria de la tabla conjunta 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 base de datos está configurada en la misma zona que la zona horaria de la base de datos.
  • La conexión de tu 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 de tu base de datos usará la zona horaria de la base de datos.

Si alguna de estas opciones es verdadera, puedes omitir el parámetro timezone para tus tablas conjuntas.

De lo contrario, se debe definir la zona horaria de la tabla conjunta para que coincida con las posibles búsquedas, 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 la tabla conjunta con el valor de la zona horaria de la consulta.
  • Si la conexión de tu base de datos usa zonas horarias específicas del usuario, 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 conjunta. Los filtros de una tabla conjunta pueden limitar los resultados al punto en que la tabla conjunta no se puede utilizar. Por ejemplo, supongamos que creas una tabla conjunta para los recuentos diarios de pedidos y que la tabla conjunta filtra solo los pedidos de lentes 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, ya que la tabla conjunta solo tiene los datos de Australia. La tabla conjunta filtra los datos de forma muy limitada para que los use la consulta Explorar.

Además, ten en cuenta los filtros que podrían haber compilado los desarrolladores de Looker en la 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 realizar una consulta de exploración. 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 se define 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, esta es una exploración con un filtro de acceso que se basa en el campo orders.region:

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

Para crear una tabla conjunta que se usará en esta exploración, la tabla conjunta 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 tabla conjunta incluye la dimensión orders.region, Looker puede filtrar de forma dinámica los datos de la tabla conjunta para que coincidan con el filtro de la consulta Explorar. Por lo tanto, Looker puede usar la tabla conjunta para las consultas de la exploración, aunque esta tenga un filtro de acceso.

Esto también se aplica a las consultas de exploración 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 tabla derivada nativa. En el caso del reconocimiento agregado, si tu consulta de exploración requiere una tabla derivada nativa que use bind_filters, esta consulta solo puede usar una tabla conjunta 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 desde la exploración que en la tabla conjunta.

Crea 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 la consulta de exploración. Si la consulta Explorar y la tabla conjunta usan las mismas medidas, dimensiones, filtros, zonas horarias y otros parámetros, por definición, los resultados de la tabla conjunta se aplicarán a la consulta Explorar. Si una tabla conjunta coincide exactamente con una consulta de Explorar, Looker puede usar tablas conjuntas que incluyan cualquier tipo de medición.

Puedes crear una tabla conjunta a partir de una exploración usando la opción Obtener LookML del menú de ajustes de una Explorar. También puedes crear coincidencias exactas para todas las tarjetas en un panel con la opción Obtener LookML del menú de ajustes de un panel.

Determina qué tabla conjunta 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 nuevas tablas conjuntas para ver cómo las usa Looker antes de enviar las nuevas tablas 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 los totales de las 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 Modo de desarrollo, Looker muestra comentarios para indicar la tabla conjunta que usó para la consulta.

En los siguientes comentarios de la pestaña SQL, podemos ver que Looker está usando la tabla conjunta sales_monthly para esta consulta, además de información sobre por qué no se usaron otras tablas conjuntas 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 ver posibles comentarios que puedas ver en la pestaña SQL y sugerencias para resolverlos.

Estimaciones de ahorros en cálculos para el reconocimiento agregado

Si la conexión de tu base de datos admite estimaciones de costos y si se puede usar una tabla conjunta para una consulta, la ventana Explorar mostrará el ahorro de procesamiento que se obtiene de usar la tabla conjunta en lugar de consultar directamente la base de datos. El ahorro total por 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 quieres ver qué tabla conjunta se usará para la consulta, 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 Cómo explorar datos en Looker para obtener más información.

Looker une los datos nuevos a tus tablas conjuntas

Para las tablas conjuntas con filtros de tiempo, Looker puede unir datos recientes en tu tabla conjunta. Es posible que tengas una tabla conjunta que incluye datos de los últimos tres días, pero que esa tabla conjunta se haya creado ayer. A la tabla conjunta le faltaría la información de hoy, por lo que no esperarías usarla para una consulta de exploración en la información diaria más reciente.

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

Looker puede unir datos recientes con los datos de tu tabla conjunta según las siguientes circunstancias:

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

Por ejemplo, la siguiente tabla conjunta 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 conjunta se creó ayer, Looker recuperará los datos más recientes que aún no se hayan incluido en la tabla conjunta y, luego, unirá los resultados nuevos con los de la tabla conjunta. Esto significa que los usuarios obtendrán los datos más recientes sin dejar de optimizar el rendimiento mediante 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 usó Looker para la consulta y la sentencia UNION que usó 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 generar reconocimiento agregado, la tabla conjunta debe tener mantenencia en la base de datos. La estrategia de persistencia se especifica en el parámetro materialization de la tabla conjunta. 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 detalles.

Puedes crear PDT incrementales en tu proyecto si tu dialecto las admite. Looker agrega datos nuevos a la tabla para compilar PDT incrementales, en lugar de volver a compilarla por completo. Debido a 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 sobre las PDT incrementales. Consulta la página de documentación del parámetro increment_key para ver un ejemplo de una tabla conjunta incremental.

Un usuario con el permiso develop puede anular la configuración de persistencia y volver a compilar todas las tablas conjuntas para que una consulta obtenga los datos más recientes. Para volver a compilar las tablas para una consulta, selecciona la opción Volver a compilar tablas derivadas y ejecutar del menú de ajustes Explorar acciones.

Debes esperar a que se cargue la consulta Explorar 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 todas las tablas derivadas de las que dependen las tablas de la consulta. Esto incluye las tablas conjuntas, que en sí son un tipo de tabla derivada persistente.

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

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

Soluciona problemas

Como se describe en la sección Cómo determinar qué tabla conjunta 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 sobre la tabla conjunta 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. Para las tablas conjuntas que no se usan, el comentario comenzará con lo siguiente:

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

Por ejemplo, este es un comentario sobre por qué no se usó la tabla conjunta sales_daily definida en la exploración 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 en la consulta evitaron que se usara la tabla conjunta.

En la siguiente tabla, se muestran algunos 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 conjunta Explicación y pasos posibles
Ese campo no aparece en Explorar. Hay un error del 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. Una posible causa es un nombre de campo incorrecto o similar.

Para resolver esto, verifica que las dimensiones y medidas 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 conjunta.
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, incluidos los campos que se usan en los filtros de esa consulta. Si una consulta de exploración contiene una dimensión o medida que no está en una tabla conjunta, Looker no puede usar la tabla conjunta, sino 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 de mayor nivel de detalle pueden derivar de aquellos con mayor nivel de detalle.

Para resolver esto, verifica que los campos de la consulta Explorar estén incluidos en la definición de la tabla conjunta.
La consulta contenía los siguientes filtros que no se incluyeron como campos ni coincidieron de manera exacta con los filtros en la tabla conjunta. Los filtros en 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 consulta Explorar.
Consulta la sección Factores de filtro en esta página para obtener más detalles.
La consulta contiene las siguientes mediciones que no se pueden agrupar. La consulta contiene uno o más tipos de medición que no son compatibles con el reconocimiento agregado, como recuento distinto, mediana o percentil.

Para resolver este problema, verifica el tipo de cada medición en la consulta y asegúrate de que sea uno de los tipos de medición compatibles. Además, si tu exploración tiene uniones, verifica que tus mediciones no se conviertan en medidas distintas (agregados simétricos) a través de uniones distribuidas. Consulta la sección Agregaciones simétricas para exploraciones con uniones en esta página si deseas obtener una explicación.
Una tabla conjunta diferente era una mejor opción para la optimización. Hubo múltiples tablas conjuntas viables para la consulta y Looker descubrió una tabla conjunta más óptima para usar en su lugar. En este caso, no es necesario realizar ninguna acción.
Looker no realizó ninguna agrupación (debido a un parámetro primary_key o cancel_grouping_fields) y, por lo tanto, no se puede agrupar la consulta. La consulta hace referencia a una dimensión que impide que tenga una cláusula GROUP BY, por lo que Looker no puede usar ninguna tabla conjunta para la consulta.

Para resolver esto, 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 corresponde a la hora y que no está en la consulta.

Para resolver este problema, puedes quitar el filtro de la tabla conjunta. Consulta la sección Factores de filtro en esta página para obtener más detalles.
Un campo se define como un campo de solo filtro en la consulta Explorar, pero aparece en el parámetro dimensions de la tabla conjunta. El parámetro dimensions de la tabla conjunta incluye un campo que se define solo como un campo filter en la consulta Explorar.

Para resolver esto, quita el campo de la lista dimensions de la tabla conjunta. Si este campo es necesario para la tabla conjunta, agrégalo a la lista filters en la consulta de la tabla conjunta.
El optimizador no puede determinar por qué no se usó la tabla conjunta. 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 la consulta de exploración. Puedes obtener fácilmente LookML de tabla conjunta a partir de una exploración, como se describe en la página del parámetro aggregate_table.

Aspectos para tener en cuenta

Agregados simétricos para exploraciones con uniones

Un aspecto importante a tener en cuenta es que, en una exploración que une varias tablas de bases de datos, Looker puede renderizar mediciones de tipo SUM, COUNT y AVERAGE como SUM DISTINCT, COUNT DISTINCT y AVERAGE DISTINCT, respectivamente. Looker realiza esta acción para evitar errores de cálculo de distribución. Por ejemplo, una medida count se renderiza como un tipo de medición count_distinct. Esto sirve para evitar cálculos erróneos de fanout de las uniones y forma parte de la funcionalidad de agregaciones simétricas de Looker. Consulta la página de prácticas recomendadas sobre agregaciones simétricas para obtener una explicación de esta función de Looker.

La funcionalidad de agregaciones simétricas evita errores de cálculo, pero también puede impedir que se usen tus tablas conjuntas en ciertos casos, por lo que es importante entenderla.

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

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 conjunta no se usa por este motivo, puedes crear una tabla conjunta que coincida de manera exacta con una consulta de exploración y usar estos tipos de mediciones para una exploración con uniones. Consulta la sección Crea tablas conjuntas 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 compatible con los bocetos de HyperLogLog, puedes agregar el parámetro allow_approximate_optimization: yes a la medición. Cuando una medida de recuento se define con allow_approximate_optimization: yes, Looker puede usar la medida 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 compatibles con los bocetos de HyperLogLog.

Compatibilidad con dialectos para el reconocimiento agregado

La capacidad de usar el reconocimiento agregado depende del dialecto de 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 Drued 0.18 y versiones posteriores
No
Apache Hive 2.3 o versiones posteriores
Sí
Apache Hive 3.1.2 o 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 Native Drive
Sí
Cloudera Impala con Native Driver
Sí
DataVirtuality
No
Databricks
Sí
Denodo 7
No
Denodo 8
No
Dremio
No
Dremio 11 y versiones posteriores
No
Exasol
Sí
Rayo de fuego
No
SQL heredado de Google BigQuery
Sí
SQL estándar de Google BigQuery
Sí
Google Cloud PostgreSQL
Sí
Google Cloud SQL
No
Google Spanner
No
Ciruela verde
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 o versiones posteriores
Sí
Oracle
Sí
ADWC de Oracle
Sí
PostgreSQL 9.5 y versiones posteriores
Sí
PostgreSQL anterior a la 9.5
Sí
PrestoDB
Sí
PrestoSQL
Sí
SAP HANA 2 y versiones posteriores
Sí
SingleStore
Sí
SingleStore 7+
Sí
Snowflake
Sí
Teradata
Sí
Trino
Sí
Vector
Sí
Vertica
Sí

Compatibilidad con dialectos para crear tablas conjuntas de forma incremental

Para que Looker admita tablas conjuntas 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 Drued 0.18 y versiones posteriores
No
Apache Hive 2.3 o versiones posteriores
No
Apache Hive 3.1.2 o 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 Native Drive
No
Cloudera Impala con Native Driver
No
DataVirtuality
No
Databricks
Sí
Denodo 7
No
Denodo 8
No
Dremio
No
Dremio 11 y versiones posteriores
No
Exasol
No
Rayo de fuego
No
SQL heredado de Google BigQuery
No
SQL estándar de Google BigQuery
Sí
Google Cloud PostgreSQL
Sí
Google Cloud SQL
No
Google Spanner
No
Ciruela verde
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 o versiones posteriores
Sí
Oracle
No
ADWC de Oracle
No
PostgreSQL 9.5 y versiones posteriores
Sí
PostgreSQL anterior a la 9.5
Sí
PrestoDB
No
PrestoSQL
No
SAP HANA 2 y versiones posteriores
No
SingleStore
No
SingleStore 7+
No
Snowflake
Sí
Teradata
No
Trino
No
Vector
No
Vertica
Sí