Conocimiento total

Descripción general

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

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, podrías tener una tabla de datos a escala de petabytes con una fila para cada pedido que se realizó en tu sitio web. Desde esta base de datos, puedes crear una tabla agregada con los totales de tus ventas diarias. 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 agregada 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 no tienes una tabla agregada anual, Looker usará la siguiente mejor opción, que es la tabla agregada de ventas mensuales en este ejemplo.

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

  • Para una consulta sobre las ventas mensuales totales, Looker usa la tabla agregada basada en las ventas mensuales (sales_monthly_aggregate_table).
  • Para una consulta sobre el total de cada venta en un día, no hay una tabla agregada con esa granularidad, por lo que Looker obtiene los resultados de la consulta de la tabla de la base de datos original (orders_database). Sin embargo, si tus usuarios ejecutan este tipo de consulta con frecuencia, puedes crear una tabla agregada 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 conocimiento agregado, Looker consultará la tabla agregada más pequeña posible para responder las preguntas de tus usuarios. La tabla original se usaría solo para las consultas que requieran un nivel de detalle más fino que el que pueden proporcionar las tablas agregadas.

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 se mantienen tus prácticas 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 agregadas para mejorar de forma drástica el rendimiento de los paneles, en especial para las tarjetas que consultan conjuntos de datos enormes. Para obtener más información, consulta la sección Cómo obtener LookML de 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 agregadas estratégicas que minimicen la cantidad de consultas necesarias 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 conjunta se define con el parámetro aggregate_table en un parámetro explore de 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 código LookML desde cero o obtener el código LookML de la 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.

Cómo diseñar tablas conjuntas

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

  • Los campos de la consulta Explorar son un subconjunto de los campos de la tabla agregada (consulta la sección Factores de campo en esta página). O bien, en el caso de los períodos, los períodos de la búsqueda de Explorar se pueden obtener de los períodos de la tabla agregada (consulta la sección Factores de período en esta página).
  • La consulta de Explorar contiene tipos de medición compatibles con el conocimiento agregado (consulta la sección Factores de tipo de medición en esta página) o tiene una tabla agregada que es una concordancia exacta (consulta la sección Cómo crear tablas agregadas que coincidan exactamente con las consultas de Explorar en esta página).
  • La zona horaria de la consulta de Explorar coincide con la que usa la tabla agregada (consulta la sección Factores de zona horaria en esta página).
  • Los filtros de la consulta de Explorar hacen referencia a campos que están disponibles como dimensiones en la tabla agregada, o bien cada uno de los filtros de la consulta de Explorar coincide con un filtro de la tabla agregada (consulta la sección Factores de filtro en esta página).

Una forma de garantizar que una tabla conjunta pueda proporcionar datos precisos para una consulta de Explorar es crear una tabla conjunta que coincida exactamente con una consulta de Explorar. 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.

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 de Explorar contiene una dimensión o una métrica que no está en una tabla conjunta, Looker no puede usarla y, en su lugar, usará la tabla base.

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

La tabla agregada también puede tener otros campos, pero debe tener al menos los campos de 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 de mayor nivel de detalle se pueden derivar de los de menor nivel.

Debido a estas consideraciones de campo, una tabla conjunta es específica de la exploración en la que se define. 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 reconocimiento agregado de Looker puede derivar un período de otro. Se puede usar una tabla agregada para una consulta, siempre y cuando el período de la tabla agregada tenga un nivel de detalle más detallado (o igual) que la consulta de Explorar. Por ejemplo, una tabla agregada basada en datos diarios se puede usar 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 agregada anual para una consulta de Explorar que solicite datos por hora, ya que los datos de la tabla agregada no tienen la granularidad suficiente para la consulta de Explorar.

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

Además, se aplica la misma lógica para las consultas con filtros de período: se puede usar una tabla agregada para una consulta con un filtro de período, siempre y cuando el período de la tabla agregada 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 agregada que tiene una dimensión de período diario se puede usar para una consulta de Explorar que filtre por día, semana o mes.

Factores del tipo de medición

Para que una consulta de Explorar use una tabla 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:

Si una consulta de Explorar usa cualquier otro tipo de medida, Looker usará la tabla original, no la tabla agregada, para mostrar los 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 medición admitidos

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

Para usar una tabla agregada en una consulta de Explorar, Looker debe poder operar en las medidas de la tabla agregada para proporcionar datos precisos en la consulta de Explorar. 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 medidas con type: average, se admite el conocimiento agregado porque Looker usa datos de suma y recuento para obtener valores promedio con precisión de las tablas agregadas.

Medidas definidas con expresiones 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, la información agregada es compatible con las mediciones en las que se definen las operaciones MIN, MAX y COUNT en el parámetro sql, como esta medición:

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

Medidas que hacen referencia a campos de LookML

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

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

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

Por ejemplo, una 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 métrica en una tabla agregada, puedes crear una dimensión definida con el formato ${TABLE}.column_name y, luego, crear una métrica 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 agregada.

Medidas que aproximan 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 cuentas los usuarios distintos en un sitio web, es posible que haya un usuario que haya visitado el 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 registrará dos veces en tu consulta de recuento de usuarios distintos mensual, y los datos serán incorrectos.

Una solución alternativa para esto es crear una tabla agregada que coincida exactamente con una consulta de Explorar, como se describe en la sección Cómo crear tablas agregadas 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 la consulta: Es un parámetro de configuración que se aplica a todas las consultas de la conexión de la base de datos. Si todos tus usuarios se encuentran en la misma zona horaria, puedes establecer una sola zona horaria de consulta para que todas las consultas se conviertan de la zona horaria de la base de datos a la zona horaria de la consulta.
  • Zonas horarias específicas del usuario, en las que se pueden asignar zonas horarias y seleccionarlas de forma individual. En este caso, las consultas se convierten de la zona horaria de la base de datos a la zona horaria del usuario individual.

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

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

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

  • Tu base de datos no admite zonas horarias.
  • La zona horaria de la consulta de la conexión a la base de datos se establece 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 agregada para que coincida con las posibles consultas, de modo que sea más probable que se use la tabla agregada:

  • 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 consulta.
  • Si la conexión a la base de datos usa zonas horarias específicas del usuario, debes crear tablas agregadas idénticas, cada una con un valor timezone diferente para que coincidan 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 agregada para el recuento de pedidos diarios y que esta tabla solo filtra los pedidos de gafas de sol que provienen de Australia. Si un usuario ejecuta una consulta de Explorar para obtener recuentos de pedidos diarios de gafas de sol en todo el mundo, Looker no puede usar la tabla agregada para esa consulta de Explorar, ya que solo tiene los datos de Australia. La tabla agregada filtra los datos de forma demasiado limitada para que la consulta Explorar los use.

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 del filtro predeterminado de su consulta, pero no pueden quitarlo por completo.
  • conditionally_filter: Define un conjunto de filtros predeterminados que los usuarios pueden anular si aplican al menos un filtro de una segunda lista que también se define en Explorar.

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

Por ejemplo, aquí 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 agregada que se usaría para esta exploración, la tabla agregada debe incluir el campo en el que se basa el filtro de acceso. En el siguiente ejemplo, el filtro de acceso se basa en el campo orders.region, y este mismo campo se incluye como una dimensión en la tabla agregada:

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

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

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 búsqueda de 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 búsqueda de 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 a partir de una exploración con la opción Get LookML del menú de ajustes de una exploración. También puedes crear coincidencias exactas para todas las tarjetas de un panel con la opción Get LookML del menú de ajustes de un panel.

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, en función de la tabla de ejemplo de agregación mensual que se mostró anteriormente, puedes ir a Explorar y ejecutar una consulta para obtener 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 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 en esta página para ver los posibles comentarios que podrías ver en la pestaña SQL y las sugerencias para resolverlos.

Estimaciones de ahorro de procesamiento para el reconocimiento 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 al usar 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 la consulta, puedes hacer clic en la pestaña SQL, como se describe en la sección Cómo determinar qué tabla agregada se usa para una consulta de esta página de documentación.

Después de ejecutar la consulta, la ventana Explorar mostrará qué tabla agregada se usó para responderla junto al botón Ejecutar.

Los ahorros totales de conocimiento se muestran 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 agregada que incluya datos de los últimos tres días, pero que se haya creado ayer. A la tabla agregada le faltaría la información de hoy, por lo que no deberías usarla para una consulta de Explorar sobre la información diaria más reciente.

Sin embargo, Looker aún puede usar los datos de esa tabla 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 conjunta en las siguientes circunstancias:

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

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

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

Si esta tabla agregada se compiló ayer, Looker recuperará los datos más recientes que aún no se incluyen en la tabla agregada y, luego, unirá los resultados actualizados con los de la tabla agregada. Esto significa que tus usuarios obtendrán los datos más recientes y, al mismo tiempo, optimizarán el rendimiento con la visibilidad agregada.

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 persistir

Para que se pueda acceder a ella para la visibilidad agregada, la tabla agregada debe permanecer en la base de datos. La estrategia de persistencia se especifica en el parámetro materialization de la tabla agregada. Dado que las tablas agregadas son un tipo de tabla derivada persistente (PDT), tienen los mismos requisitos que las PDT. Consulta la página de documentación Tablas derivadas en Looker para obtener más 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 un tipo de PDT, también puedes crear tablas conjuntas incrementales. Consulta la página de documentación de PDT incrementales para obtener más información sobre los PDT incrementales. Consulta la página de documentación del parámetro increment_key para ver un ejemplo de una tabla agregada incremental.

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

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

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

En el caso del usuario que inicia la opción Rebuild Derived Tables & Run, la consulta esperará a que se vuelvan a crear las tablas antes de cargar los resultados. Las consultas de otros usuarios seguirán usando las tablas existentes. Una vez que se vuelvan a compilar las tablas persistentes, todos los usuarios las usarán.

Consulta la página de documentación Tablas derivadas en Looker para obtener más detalles sobre la opción Rebuild Derived Tables & Run.

Soluciona problemas

Como se describe en la sección Cómo determinar qué tabla agregada se usa para una consulta, si estás en el Modo de desarrollo, puedes ejecutar consultas en Explorar y hacer clic en la pestaña SQL para ver los comentarios sobre la tabla agregada que se usó 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 agregadas 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 agregada 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 de la consulta impidieron que se usara la tabla agregada.

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

Motivo por el que no se usa la tabla conjunta Explicación y posibles pasos
No hay ningún campo de este tipo 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 el código LookML de la 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 de Explorar contiene una dimensión o una métrica que no está en una tabla conjunta, Looker no puede usarla y, en su lugar, usará la tabla base. Consulta la sección Factores de campo de 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 se pueden derivar de los de menor nivel.

Para resolver este problema, verifica que los campos de la consulta de Explorar se incluyan en la definición de la tabla agregada.
La consulta contenía los siguientes filtros que no se incluyeron como campos ni coincidieron exactamente con los filtros de la tabla agregada. Los filtros de la consulta Explorar evitan que Looker use la tabla agregada.

Para resolver este problema, puedes realizar una de las siguientes acciones:
  • Agrega el mismo filtro a tu tabla agregada.
  • Agrega el campo que usa el filtro a tu tabla agregada.
  • 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 consolidar. 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 informe Explorar tiene uniones, verifica que tus medidas no se conviertan en medidas distintas (agrupaciones simétricas) a través de uniones en abanico. Consulta la sección Agrupaciones simétricas para Explorar con combinaciones en esta página para obtener una explicación.
Una tabla agregada 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 este problema, puedes quitar el filtro de la tabla agregada. Consulta la sección Factores de filtro de esta página para obtener más detalles.
Un campo se define como un campo solo de filtro en la consulta Explorar, pero aparece en el parámetro dimensions de la tabla agregada. El parámetro dimensions de la tabla agregada enumera un campo que se define solo como un campo filter en la consulta Explorar.

Para resolver este problema, quita el campo de la lista dimensions de la tabla agregada. Si este campo es necesario para la tabla agregada, agrégalo a la lista filters en la consulta de la tabla agregada.
El optimizador no puede determinar por qué no se usó la tabla agregada. Este comentario se reserva para casos extremos. Si ves este mensaje para una consulta de Explorar que se usa con frecuencia, puedes crear una tabla agregada que coincida exactamente con la consulta de Explorar. Puedes obtener fácilmente LookML de tabla conjunta desde una exploración, como se describe en la página del parámetro aggregate_table.

Aspectos que debes tener en cuenta

Agregaciones simétricas para Explorar 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 las agregaciones simétricas para obtener una explicación de esta función de Looker.

La funcionalidad de agregaciones simétricas 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.

En el caso de los tipos de medición compatibles con el conocimiento agregado, esto se aplica a sum, count y average. Looker renderizará estos tipos de medidas como DISTINCT en los siguientes casos:

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 agregada no se usa por este motivo, puedes crear una tabla agregada que coincida exactamente con una consulta de Explorar para usar estos tipos de métricas en una Explorar 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 esquemas HyperLogLog, puedes agregar el parámetro allow_approximate_optimization: yes a la medida. Cuando se define una métrica de recuento con allow_approximate_optimization: yes, Looker puede usarla para la visibilidad agregada, incluso si se renderiza como un recuento distinto.

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

Compatibilidad con dialectos para el conocimiento agregado

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

Dialecto ¿Es compatible?
Actian Avalanche
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 o 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 y versiones posteriores 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í
Firebolt
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í
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 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 tu base de datos también debe admitirlas. En la siguiente tabla, se muestran los dialectos que admiten la compilación incremental de PDT en la versión más reciente de Looker:

Dialecto ¿Es compatible?
Actian Avalanche
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 o 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 y versiones posteriores 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
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 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í