Conocimiento total

Descripción general

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

Para tablas muy grandes en tu base de datos, los desarrolladores de Looker pueden crear tablas de agregaciones más pequeñas de datos, agrupados según varias combinaciones de atributos. Las tablas de datos agregados actúan como integraciones 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 reconocimiento agregado puede acelerar una consulta típica en órdenes de magnitud.

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

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

  • Para una consulta sobre las ventas mensuales totales, Looker usa la tabla de datos agregados basada en las ventas mensuales (sales_monthly_aggregate_table).
  • Para una consulta sobre el total de cada venta en un día, no hay una tabla de datos agregados con esa granularidad, por lo que Looker obtiene los resultados de la consulta de la tabla de la base de datos original (orders_database). (Sin embargo, si tus usuarios ejecutan este tipo de consultas con frecuencia, podrías crear una tabla de datos agregados para ello).
  • Para una consulta sobre las ventas semanales, no hay una tabla de datos agregados semanales, por lo que Looker usa la siguiente mejor opción, que es la tabla de datos agregados basada en las ventas diarias (sales_daily_aggregate_table).

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

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

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

Cómo agregar tablas agregadas a tu proyecto

Los desarrolladores de Looker pueden crear tablas de agregación estratégicas que minimicen la cantidad de consultas necesarias en las tablas grandes de una base de datos. Las tablas agregadas deben persistir en su base de datos para que puedan ser accesibles para el conocimiento agregado. Por lo tanto, las tablas de datos agregados son un tipo de tabla derivada persistente (PDT).

Una tabla de datos agregados se define utilizando el parámetro aggregate_table bajo un parámetro explore en su proyecto de LookML.

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

Diseño de tablas agregadas

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

  • Los campos de la consulta de Exploración son un subconjunto de los campos de la tabla de datos agregados (consulta la sección Factores de campo en esta página). O bien, para los intervalos de tiempo, los intervalos de tiempo de la consulta de exploración se pueden derivar de los intervalos de tiempo en la tabla de datos agregados (consulte la sección Factores de intervalo de tiempo en esta página).
  • La consulta de Explorar contiene tipos de medidas compatibles con el reconocimiento de agregaciones (consulta la sección Factores del tipo de medida en esta página) o tiene una tabla de datos agregados que coincide exactamente (consulta la sección Cómo crear tablas de datos agregados que coincidan exactamente con las consultas de Explorar en esta página).
  • La zona horaria de la consulta de Explore coincide con la zona horaria que usa la tabla de datos agregados (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 de datos agregados, o bien cada uno de los filtros de la consulta de Explorar coincide con un filtro de la tabla de datos agregados (consulta la sección Factores de filtro en esta página).

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

Factores de campo

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

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

La tabla de datos agregados también puede tener otros campos, pero debe tener al menos los campos de la consulta de Explorar para que sea viable para la optimización. La única excepción son las dimensiones de período, ya que los períodos de granularidad más gruesa se pueden derivar de los de granularidad más fina.

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

Factores de período

La lógica de reconocimiento de agregados de Looker puede derivar un período de otro. Se puede usar una tabla de datos agregados para una consulta siempre y cuando el período de la tabla tenga una granularidad más precisa (o igual) que la de la consulta de Explorar. Por ejemplo, se puede usar una tabla de datos agregados basada en datos diarios para una consulta de Explorar que requiera otros períodos, como consultas de datos diarios, mensuales y anuales, o incluso datos del día del mes, el día del año y la semana del año. Sin embargo, no se puede usar una tabla de datos agregados anual para una consulta de Explorar que requiera datos por hora, ya que los datos de la tabla de datos agregados 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 de datos agregados que se filtra para los últimos tres meses y un usuario consulta los datos con un filtro para los últimos dos meses, Looker podrá usar la tabla de datos agregados para esa consulta.

Además, la misma lógica se aplica a las consultas con filtros de período: se puede usar una tabla de datos agregados para una consulta con un filtro de período siempre que el período de la tabla de datos agregados tenga una granularidad más fina (o igual) que el filtro de período que se usa en la consulta de Explorar. Por ejemplo, se puede usar una tabla de datos agregados que tenga una dimensión de período diario para una consulta de exploración que filtre por día, semana o mes.

Factores del tipo de medición

Para que una consulta de Explorar use una tabla de datos agregados, las medidas de la tabla de datos agregados deben poder proporcionar datos precisos para la consulta de Explorar.

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

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

De lo contrario, Looker utilizará la tabla original, no la tabla agregada, para devolver los resultados.

Medidas con tipos de medidas compatibles

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

Para utilizar una tabla agregada en una consulta Explore, Looker debe poder operar con las medidas de la tabla agregada para proporcionar datos precisos en la consulta Explore. Por ejemplo, una medición con type: sum se puede usar para tener una idea agregada porque se pueden sumar varias sumas: una tabla de datos agregados de sumas semanales se puede sumar para obtener una suma mensual precisa. De manera similar, se puede utilizar una medición con type: max porque se puede utilizar una tabla de datos agregados de máximos diarios para encontrar el máximo semanal exacto.

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

Medidas definidas con expresiones SQL

La conciencia agregada también se puede utilizar 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:

Se admite la conciencia agregada para 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} ;;
}

También se admite la agregación de datos para medidas en las que los cálculos se definen en el parámetro sql, como esta medida:

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

Y se admite la conciencia agregada para medidas donde 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 campos LookML

Cuando se utilizan expresiones sql en medidas, la función de agregación admite los siguientes tipos de referencias de campo :

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

No se admite la agregación de datos para las medidas que se definen utilizando el formato ${TABLE}.column_name, que indica una columna en una tabla. (Consulta la página de documentación Incorporar SQL y hacer referencia a objetos de LookML para obtener una descripción general del uso de referencias en LookML).

Por ejemplo, una métrica definida con este parámetro sql no 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 desea incluir esta medición en una tabla de datos agregados, puede crear una dimensión definida con el formato ${TABLE}.column_name y, a continuación, crear una medición que haga referencia a la dimensión, como esta:


 dimension: total_sale_price {
    sql: (${TABLE}.total_sale_price) ;;
  }

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

Ahora puede utilizar la medida wholesale_value en su tabla de datos agregados.

Medidas que aproximan los recuentos distintos

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

Una solución alternativa para esto es crear una tabla de datos agregados que coincida exactamente con una consulta de exploración, como se describe en la sección Creación de tablas de datos agregados que coincidan exactamente con consultas de exploración de esta página. Cuando la consulta Explore y una consulta de tabla agregada son iguales, las medidas de recuento distintas proporcionan datos precisos, por lo que pueden utilizarse para obtener información agregada.

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

Se sabe que el algoritmo HyperLogLog tiene un margen de error de aproximadamente el 2%. El parámetro allow_approximate_optimization: yes requiere que sus desarrolladores de Looker reconozcan que está bien usar datos aproximados para la medida para que la medida se pueda calcular aproximadamente a partir de tablas agregadas.

Consulte la página de documentación del parámetro allow_approximate_optimization para obtener más información y para la lista de dialectos que admiten count distinct usando HyperLogLog.

factores de zona horaria

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

  • Zona horaria de consulta, una configuración que se aplica a todas las consultas en la conexión de la base de datos. Si todos tus usuarios se encuentran en la misma zona horaria, puedes establecer una sola zona horaria de consulta para que todas las consultas se conviertan de la zona horaria de la base de datos a la zona horaria de consulta.
  • Zonas horarias específicas del usuario, donde se pueden asignar y seleccionar zonas horarias individualmente a los usuarios. En este caso, las consultas se convierten de la zona horaria de la base de datos a la zona horaria del usuario individual.

Consulte la página de documentación Uso de la configuración de zona horaria para obtener más información sobre estas opciones.

Estos conceptos son importantes para comprender la agregación de datos, ya que, para que una tabla de datos agregados pueda utilizarse en una consulta con dimensiones de fecha o filtros de fecha, la zona horaria de la tabla de datos agregados debe coincidir con la configuración de zona horaria utilizada para la consulta original.

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

  • Su base de datos no admite zonas horarias.
  • La zona horaria de consulta de su conexión a la base de datos está configurada en la misma zona horaria que la zona horaria de la base de datos .
  • Su conexión a la base de datos no tiene especificada ninguna zona horaria de consulta ni zonas horarias específicas para el usuario. En ese caso, la conexión a la base de datos utilizará la zona horaria de la base de datos.

Si alguna de estas condiciones es verdadera, puede omitir el parámetro timezone para sus tablas agregadas.

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

  • Si su conexión a la base de datos utiliza una única zona horaria de consulta, debe hacer coincidir el valor timezone de su tabla agregada con el valor de la zona horaria de consulta.
  • Si su conexión a la base de datos utiliza zonas horarias específicas del usuario, debe crear tablas agregadas idénticas, cada una con un valor timezone diferente para que coincida con las posibles zonas horarias de sus usuarios.

Factores de filtro

Tenga cuidado al incluir filtros en su tabla agregada. Los filtros aplicados a una tabla de datos agregados pueden reducir los resultados hasta el punto de que la tabla de datos agregados resulte inutilizable. Por ejemplo, supongamos que creas una tabla de datos agregados para los recuentos de pedidos diarios, y esta tabla filtra solo los pedidos de anteojos de sol provenientes de Australia. Si un usuario ejecuta una consulta de Explorar para obtener el recuento diario de pedidos de gafas de sol en todo el mundo, Looker no puede utilizar la tabla agregada para esa consulta de Explorar, ya que la tabla agregada solo contiene los datos de Australia. La tabla de datos agregados filtra los datos de forma demasiado limitada para que la consulta de Explorar la use.

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

  • access_filters: Aplica restricciones de datos específicas del usuario.
  • always_filter: Exige a los usuarios que incluyan un determinado conjunto de filtros para una búsqueda en Explorar. Los usuarios pueden cambiar el valor predeterminado del filtro para su búsqueda, pero no pueden quitar el filtro por completo.
  • conditionally_filter: Define un conjunto de filtros predeterminados que los usuarios pueden anular si aplican al menos un filtro de una segunda lista que también se define en la Exploración.

Estos tipos de filtros se basan en campos específicos. Si tu exploración tiene estos filtros, debes incluir sus campos en el parámetro dimensions del objeto 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 de datos agregados que se usaría para esta exploración, la tabla de datos agregados 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 dimensión en la tabla de datos agregados:

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

Debido a que la consulta de la tabla de datos agregados incluye la dimensión orders.region, Looker puede filtrar de forma dinámica los datos de la tabla de datos agregados para que coincidan con el filtro de la consulta de exploración. Por lo tanto, Looker aún puede usar la tabla de datos agregados para las consultas de la Exploración, aunque esta tenga un filtro de acceso.

Esto también se aplica a las consultas de Explorar que usan una tabla derivada nativa configurada con bind_filters. El parámetro bind_filters pasa los filtros especificados de una consulta de exploración a la subconsulta de la tabla derivada nativa. En el caso del conocimiento de los datos agregados, si tu consulta de Explorar requiere una tabla derivada nativa que use bind_filters, la consulta de Explorar solo puede usar una tabla de datos agregados si todos los campos que se usan en el parámetro bind_filters de la tabla derivada nativa tienen los mismos valores de filtro en la consulta de Explorar que en la tabla de datos agregados.

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

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

Puedes crear una tabla de datos agregados a partir de una Exploración con la opción Obtener LookML del menú de ajustes de una Exploración. También puedes crear coincidencias exactas para todos los mosaicos de un panel con la opción Obtener LookML del menú de ajustes de un panel.

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

Los usuarios con permisos de see_sql pueden usar los comentarios de la pestaña SQL de una exploración para ver qué tabla de datos agregados se usará para una consulta. Los comentarios de la pestaña SQL también se muestran en el modo de desarrollo, por lo que los desarrolladores pueden probar nuevas tablas agregadas para ver cómo las usa Looker antes de que envíes las tablas nuevas a producción.

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

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

-- use existing orders::sales_monthly in sandbox_scratch.LR$LB4151619827209021_orders$sales_monthly
-- Did not use orders::sales_weekly; it does not include the following fields in the query: orders.created_month
-- Did not use orders::sales_daily; orders::sales_monthly was a better fit for optimization.
-- Did not use orders::sales_last_3_days; contained filters not in the query: orders.created_date

Consulta la sección Solución de problemas en esta página para ver los posibles comentarios que puedes ver en la pestaña SQL y sugerencias para resolverlos.

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

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

Antes de ejecutar la consulta, si deseas ver qué tabla de datos agregados 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 de datos agregados se usa para una consulta de esta página de documentación.

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

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

Looker une los datos nuevos a tus tablas de agregados

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

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

Looker puede unir datos nuevos con los datos de tu tabla de agregaciones en las siguientes circunstancias:

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

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

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

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

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

Las tablas agregadas deben persistirse.

Para que sea accesible para la conciencia agregada, su tabla agregada debe estar persistida en su base de datos. La estrategia de persistencia se especifica en el parámetro materialization de la tabla agregada. Debido a que las tablas agregadas son un tipo de tabla derivada persistente (PDT), las tablas agregadas tienen los mismos requisitos que las PDT. Consulte 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 los admite. Looker crea tablas de datos parciales incrementales añadiendo datos nuevos a la tabla, en lugar de reconstruirla por completo. Dado que las tablas de datos agregados son un tipo de PDT, también puedes crear tablas de datos agregados incrementales. Consulte la página de documentación PDT incrementales para obtener más información sobre los PDT incrementales. Consulte la página de documentación del parámetro increment_key para ver un ejemplo de una tabla agregada incremental.

Un usuario con permisos develop puede anular la configuración de persistencia y reconstruir todas las tablas agregadas para una consulta para obtener los datos más actualizados. Para reconstruir las tablas de una consulta, seleccione la opción Reconstruir tablas derivadas y ejecutar del menú de engranajes Explorar acciones.

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

La opción Reconstruir tablas derivadas y ejecutar reconstruye todas las tablas derivadas a las que se hace referencia en la consulta, así como cualquier tabla derivada de la que dependan las tablas de la consulta. Esto incluye las tablas agregadas, que a su vez son un tipo de tabla derivada persistente.

Para el usuario que inicia la opción Reconstruir tablas derivadas y ejecutar, la consulta esperará a que las tablas se reconstruyan antes de cargar los resultados. Las consultas de otros usuarios seguirán utilizando las tablas existentes. Una vez reconstruidas las tablas persistentes, todos los usuarios utilizarán las tablas reconstruidas.

Consulte la página de documentación Tablas derivadas en Looker para obtener más detalles sobre la opción Reconstruir tablas derivadas y ejecutar.

Soluciona problemas

Como se describe en la sección Determinar qué tabla agregada se utiliza para una consulta, si está en Modo de desarrollo, puede ejecutar consultas en el Explorador y hacer clic en la pestaña SQL para ver comentarios sobre la tabla agregada utilizada para la consulta, si los hay.

La pestaña SQL también incluye comentarios sobre por qué no se utilizaron tablas agregadas para una consulta, si ese es el caso. Para las tablas agregadas que no se utilizan, el comentario comenzará con:

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

Por ejemplo, aquí hay un comentario sobre por qué la tabla agregada sales_daily definida en la exploración order_items no se utilizó 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 utilizara la tabla agregada.

La siguiente tabla muestra otras posibles razones por las que no se puede utilizar una tabla agregada, junto con los pasos que puede seguir para aumentar la utilidad de la tabla agregada.

Motivo por el cual no se utiliza la tabla agregada Explicación y posibles pasos
No existe tal campo en la sección Explorar. Se ha producido un error de validación de tipo LookML. Lo más probable es que esto se deba a que la tabla agregada no se definió correctamente o a que había un error tipográfico en el código LookML de la tabla agregada. Una posible causa es un nombre de campo incorrecto, o algo similar.

Para resolver esto, verifique que las dimensiones y medidas en la tabla agregada coincidan con los nombres de los campos en la función Explorar. Consulte la página de documentación del parámetro aggregate_table para obtener más información sobre cómo definir una tabla agregada.
La tabla agregada no incluye los siguientes campos en la consulta. Para que se use en una consulta de Explorar, una tabla de datos agregados debe tener todas las dimensiones y medidas necesarias para esa consulta, incluidos los campos que se usan para los filtros en la consulta de Explorar. Si una consulta de Explorar contiene una dimensión o una medida que no está en una tabla de datos agregados, Looker no puede usar la tabla de datos agregados y, en su lugar, usará la tabla base. Consulte 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 granularidad más gruesa se pueden derivar de los de granularidad más fina.

Para solucionar esto, verifique que los campos de la consulta Explore estén incluidos en la definición de la tabla agregada.
La consulta contenía los siguientes filtros que no estaban incluidos como campos ni coincidían exactamente con los filtros de la tabla agregada. Los filtros de la consulta Explore impiden que Looker utilice la tabla agregada.

Para resolver esto, puede hacer una de las siguientes cosas:
  • Agregue el mismo filtro a su tabla agregada.
  • Agregue el campo que utiliza el filtro a su tabla agregada.
  • Quita los filtros de la consulta de Explorar.
Consulta la sección Factores de filtrado en esta página para obtener más detalles.
La consulta contiene las siguientes medidas que no se pueden acumular. La consulta contiene uno o más tipos de medición que no se admiten para el reconocimiento de agregación, como recuento de valores distintos, mediana o percentil.

Para resolver este problema, verifica el tipo de cada medida en la consulta y asegúrate de que sea uno de los tipos de medidas admitidos. Además, si tu Explorar tiene uniones, verifica que tus medidas no se conviertan en medidas distintas (agregados simétricos) a través de uniones con expansión. Consulta la sección Agregados simétricos para Explorar con uniones en esta página para obtener una explicación.
Otra tabla de datos agregados se ajustaba mejor a la optimización. Había varias tablas de datos agregados viables para la consulta, y Looker encontró una tabla de datos agregados más óptima para usar en su lugar. No es necesario hacer nada en este caso.
Looker no realizó ningún agrupamiento (debido a un parámetro primary_key o cancel_grouping_fields) y, por lo tanto, no se puede resumir la consulta. La consulta hace referencia a una dimensión que impide que tenga una cláusula GROUP BY y, por lo tanto, Looker no puede usar ninguna tabla de datos agregados para la consulta.

Para resolver este problema, verifica que el parámetro primary_key de la vista y el parámetro cancel_grouping_fields de Explorar estén configurados correctamente.
La tabla de datos agregados contenía filtros que no estaban en la consulta. La tabla de datos agregados tiene un filtro que no es de tiempo y que no está en la consulta.

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

Para resolver este problema, quita el campo de la lista dimensions de la tabla de agregación. Si este campo es necesario para la tabla de datos agregados, agrégalo a la lista filters en la consulta de la tabla de datos agregados.
El optimizador no puede determinar por qué no se usó la tabla de datos agregados. Este comentario se reserva para situaciones limítrofes. Si ves este mensaje para una consulta de Explorar que se usa con frecuencia, puedes crear una tabla de datos agregados que coincida exactamente con la consulta de Explorar. Puede obtener la tabla de datos agregados LookML 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

Un aspecto importante a tener en cuenta es que en un Explore que joins múltiples tablas de base de datos, Looker puede representar medidas de tipo SUM, COUNT y AVERAGE como SUM DISTINCT, COUNT DISTINCT ​​y AVERAGE DISTINCT, respectivamente. Looker hace esto para evitar errores de cálculo en la expansión. Por ejemplo, una medida count se representa como un tipo de medida count_distinct. Esto sirve para evitar errores de cálculo en las uniones y forma parte de la funcionalidad de agregaciones simétricas de Looker. Consulta la página de prácticas recomendadas sobre los agregados simétricos para obtener una explicación de esta función de Looker.

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

Para los tipos de medidas compatibles con la conciencia agregada, esto se aplica a sum, count y average. Looker renderizará estos tipos de medidas como DISTINCT si se cumplen las siguientes condiciones:

Consulte la página de documentación del parámetro relationship para obtener una explicación de este tipo de uniones.

Si observa que su tabla de datos agregados no se está utilizando por este motivo, puede crear una tabla de datos agregados que coincida exactamente con una exploración para poder utilizar estos tipos de mediciones en una exploración con uniones. Consulte la sección Creación de tablas agregadas que coincidan exactamente con las consultas de Explore en esta página para obtener más información.

Además, si tiene un dialecto SQL que admite bocetos HyperLogLog, puede agregar el parámetro allow_approximate_optimization: yes a la medida. Cuando se define una medida de recuento con allow_approximate_optimization: yes, Looker puede usar la medida para el reconocimiento de agregados, incluso si se renderiza como un recuento de valores distintos.

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

Soporte dialectal para la comprensión agregada

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

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

Compatibilidad con dialectos para la creación incremental de tablas agregadas

Para que Looker admita tablas agregadas incrementales en su proyecto de Looker, su dialecto de base de datos también debe admitirlas. La siguiente tabla muestra qué dialectos admiten la construcción incremental de PDT en la última versión de Looker:

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