Conocimiento total

Descripción general

Looker usa la lógica de reconocimiento de agregados 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 de datos agregados más pequeñas, agrupadas por varias combinaciones de atributos. Las tablas agregadas actúan como tablas de resumen o de consolidación 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 varios ó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. En esta base de datos, puedes crear una tabla agregada con los totales de ventas diarias. Si tu sitio web recibe 1,000 pedidos todos los días, tu tabla agregada diaria representará cada día con 999 filas menos que tu tabla original. Puedes crear otra tabla de agregación con los totales de ventas mensuales que será aún más eficiente. Por lo tanto, ahora, si un usuario ejecuta una consulta sobre 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 agregación anual, Looker usará la siguiente mejor opción, que, en este ejemplo, es la tabla de agregación de ventas mensuales.

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

Con la lógica de reconocimiento agregado, Looker consultará la tabla agregada más pequeña posible para responder las preguntas de 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 agregación.

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 del Explorar para acceder a la mejor tabla agregada para la consulta. Esto significa que tus exploraciones detalladas se mantienen y las Exploraciones se pueden consolidar. Con el conocimiento agregado, un Explorar puede aprovechar automáticamente las tablas agregadas, pero también 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 agregadas estratégicas que minimicen la cantidad de consultas necesarias en las tablas grandes de una base de datos. Las tablas de agregación deben persistirse en tu base de datos para que se pueda acceder a ellas para la agregación. Por lo tanto, las tablas de agregación 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.

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 conjunta, puedes escribir el LookML desde cero o obtener el LookML de la tabla conjunta desde Explorar 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ña tablas de datos agregados

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

• Los campos de la consulta de Explorar son un subconjunto de los campos de la tabla de agregación (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 derivar 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 medidas compatibles con el conocimiento agregado (consulta la sección Factores del tipo de medida en esta página) o tiene una tabla agregada que coincide exactamente (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 Explore coincide con la zona horaria 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 agregada pueda proporcionar datos precisos para una consulta de Explorar es crear una tabla agregada que coincida exactamente con una consulta de Explorar. 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 pueda usar en una consulta de Explore, 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 Explore. Si una consulta de Explorar contiene una dimensión o una medida que no se encuentra en una tabla de agregados, Looker no podrá usar la tabla de 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 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 la consulta de Explorar para ser viable para la optimización. La única excepción son las dimensiones de período, ya que los períodos con un nivel de detalle más grueso se pueden derivar de los que tienen un nivel de detalle más fino.

Debido a estas consideraciones de campo, una tabla agregada es específica de la exploración en la que se define. Una tabla agregada 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 agregada para una consulta siempre que el período de la tabla agregada tenga una granularidad más fina (o igual) que la de la consulta de Explorar. Por ejemplo, se puede usar una tabla agregada basada en datos diarios para una consulta de Explorar que requiera otros períodos, como consultas de datos diarios, mensuales y anuales, o incluso datos de día del mes, día del año y semana del año. Sin embargo, no se puede usar una tabla agregada anual para una consulta de Explorar que requiere datos por hora, ya que los datos de la tabla agregada no tienen la suficiente granularidad para la consulta de Explorar.

Lo mismo se aplica a los subconjuntos de períodos. Por ejemplo, si tienes una tabla agregada 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 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 que el período de la tabla agregada 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 agregada que tenga una dimensión de período diario para una consulta de Explorar que filtre por día, semana o mes.

Factores del tipo de medición

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

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

• Medidas con tipos de medidas admitidos
• Medidas definidas por expresiones SQL
• Medidas que no se definen con ${TABLE}
• Medidas que aproximan los recuentos distintos

Si una consulta de Explore usa cualquier otro tipo de medida, Looker usará la tabla original, no la tabla agregada, para devolver los resultados. La única excepción es si la consulta de Explorar coincide exactamente con 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.

Medidas con tipos de medidas admitidos

La agregación de la conciencia se puede usar para las consultas de Explorar que utilizan medidas con estos tipos de medidas:

• sum
• count
• min
• max
• average

Para usar una tabla agregada en una consulta de Explore, Looker debe poder operar con las medidas de la tabla agregada para proporcionar datos precisos en la consulta de Explore. Por ejemplo, una métrica con type: sum se puede usar para la conciencia agregada, ya que puedes sumar varias sumas: se puede sumar una tabla agregada de sumas semanales para obtener una suma mensual precisa. Del mismo modo, se puede usar una medida con type: max, ya que se puede usar una tabla agregada de máximos diarios para encontrar el máximo semanal preciso.

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 de SQL

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

• number
• date
• string
• yesno

Se admite el conocimiento agregado para las métricas que se definen como combinaciones de otras métricas, como en este ejemplo:

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

El conocimiento de la agregación también se admite para las 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) ;;
}

Además, se admite el conocimiento de la agregación para las medidas en las que se definen las operaciones MIN, MAX y COUNT 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 de LookML

Cuando se usan expresiones sql en las medidas, la función de reconocimiento de agregaciones admite los siguientes tipos de referencias de campos:

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

La función de reconocimiento de agregaciones no se admite para las medidas definidas con el formato ${TABLE}.column_name, que indica una columna en una tabla. (Consulta la página de documentación Incorporar objetos de 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 agregada, ya que usa el formato ${TABLE}.column_name:

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

Si deseas incluir esta medida en una tabla agregada, puedes crear una dimensión definida con el formato ${TABLE}.column_name y, luego, crear una medida que haga referencia a la dimensión, 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 de agregación.

Medidas que aproximan los recuentos distintos

En general, los recuentos de valores distintos no se admiten con la función de reconocimiento de agregaciones, ya que no se pueden obtener datos precisos si intentas 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. Por ejemplo, si intentaste 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 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 de esta página. Cuando la consulta de Explore y la consulta de la tabla agregada son las mismas, las medidas de recuento de valores distintos proporcionan datos precisos, por lo que se pueden usar para la detección de agregaciones.

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

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 confirmen que está bien usar datos aproximados para la medida, 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 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 la consulta, 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 y seleccionar zonas horarias de forma individual. En este caso, las consultas se convierten de la zona horaria de la base de datos a la zona horaria del usuario individual.

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

Estos conceptos son importantes para comprender el reconocimiento de agregados, ya que, 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 el parámetro de 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 tu conexión de base de datos está configurada en la misma zona horaria que la zona horaria de la base de datos.
• Tu conexión a la base de datos no tiene una zona horaria de consulta especificada ni zonas horarias específicas del usuario. Si este es el caso, la conexión a la base de datos usará la zona horaria de la base de datos.

Si alguna de estas opciones se aplica a tu caso, puedes omitir el parámetro timezone para tus tablas agregadas.

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

• Si tu conexión de base de datos usa una sola zona horaria de consulta, debes hacer coincidir el valor timezone de tu tabla de agregados con el valor de la zona horaria de consulta.
• Si tu 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 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 de agregados. Los filtros en una tabla de agregación pueden reducir los resultados hasta el punto en que la tabla de agregación se vuelve inutilizable. Por ejemplo, supongamos que creas una tabla de 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 los recuentos diarios de pedidos de gafas de sol en todo el mundo, Looker no puede usar la tabla agregada para esa consulta de Explorar, ya que la tabla agregada solo tiene los datos de Australia. La tabla agregada 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 Explorar, 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 consulta de 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 Explorar.

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

Por ejemplo, aquí se muestra un Explorar 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 este Explorar, 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 de 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 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 búsquedas de Explore que usan una tabla derivada nativa configurada con bind_filters. El parámetro bind_filters pasa los filtros especificados de una consulta de Explorar a la subconsulta de la tabla derivada nativa. En el caso del conocimiento de agregaciones, si tu consulta de Explorar requiere una tabla derivada nativa que use bind_filters, la consulta de Explorar solo puede usar una tabla de agregación 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 agregación.

Crea tablas de agregación que coincidan exactamente con las consultas de Explorar

Una forma de asegurarte de que se puede usar una tabla agregada para una consulta de Explorar es crear una tabla agregada que coincida exactamente con la consulta de Explorar. Si la consulta 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 consulta de Explorar. Si una tabla agregada coincide exactamente con una consulta de Explorar, Looker puede usar tablas agregadas que incluyan cualquier tipo de medida.

Puedes crear una tabla agregada 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.

Cómo determinar qué tabla de agregación se usa para una consulta

Los usuarios con permisos de see_sql pueden usar los comentarios de la pestaña SQL de un Explorar 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, 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 agregación mensual de ejemplo que se mostró anteriormente, puedes ir a Explorar 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 agregada que usó para la consulta.

En los siguientes comentarios de la pestaña SQL, podemos ver que Looker usa la tabla de agregados sales_monthly para esta consulta y la información sobre por qué no se usaron otras tablas de 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 procesamiento 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 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 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 conjuntas con filtros de tiempo, Looker puede unir datos nuevos en tu tabla conjunta. Es posible que tengas una tabla de agregación 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 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 agregada para la consulta, ya que ejecutará una consulta sobre 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 de agregados en las siguientes circunstancias:

• La tabla de agregación tiene un filtro de tiempo.
• La tabla de agregados 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 nuevos con los de la tabla agregada. 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 un Explorar para ver la tabla agregada 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 agregada.

Las tablas conjuntas deben persistir

Para que sea accesible para el conocimiento agregado, tu tabla de agregados debe persistirse en tu base de datos. La estrategia de persistencia se especifica en el parámetro materialization de la tabla agregada. Dado que las tablas de agregación 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 detalles.

Puedes crear PDT incrementales en tu proyecto si tu dialecto los admite. Looker compila PDT incrementales agregando datos recientes a la tabla, en lugar de recompilar la tabla en su totalidad. Dado que las tablas de agregación son un tipo de PDT, también puedes crear tablas de agregación incrementales. Consulta la página de documentación sobre los PDT incrementales para obtener más información. Consulta la página de documentación del parámetro increment_key para ver un ejemplo de una tabla de agregados incremental.

Un usuario con permiso de develop puede anular la configuración de persistencia y volver a compilar todas las tablas agregadas para una consulta y 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 de Acciones de Explorar.

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 de agregación, 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 compilar las tablas antes de cargar los resultados. Las consultas de otros usuarios seguirán usando las tablas existentes. Una vez que se vuelvan a compilar las tablas persistentes, todos los usuarios las usarán.

Consulta la página de documentación 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 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 de agregación que no se usan, el comentario comenzará con lo siguiente:

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

Por ejemplo, aquí hay un comentario sobre por qué no se usó la tabla agregada sales_daily definida en el Explorar 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 de agregación.

En la siguiente tabla, se muestran otros posibles motivos por los que no se puede usar una tabla de agregación, junto con los pasos que puedes seguir para aumentar su utilidad.

Aspectos para tener en cuenta

Agregaciones simétricas para las Exploraciones con uniones

Una cuestión importante que se debe tener en cuenta es que, en un Explore que une 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 en la expansión. Por ejemplo, una medida count se renderiza como un tipo de medida count_distinct. Esto se hace para evitar errores de cálculo de la expansión en las uniones y forma parte de la funcionalidad de agregados simétricos 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.

En el caso de los tipos de medidas admitidos por el conocimiento de agregaciones, esto se aplica a sum, count y average. Looker renderizará estos tipos de medidas como DISTINCT si se cumplen las siguientes condiciones:

• La medida proviene de la vista "uno" de una combinación de varios a uno o de uno a varios.
• La medida proviene de cualquiera de las vistas de una unión de varios a varios.

Consulta la página de documentación del parámetro relationship para obtener una explicación sobre 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 medidas en una exploración con uniones. Consulta la sección Crea tablas de agregación 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 bocetos de HyperLogLog, puedes 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 conocimiento agregado, 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.

Compatibilidad con dialectos para el reconocimiento agregado

La capacidad de usar la agregación 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 agregaciones:

Compatibilidad con dialectos para crear tablas de agregación de forma incremental

Para que Looker admita tablas agregadas incrementales en tu proyecto de Looker, tu dialecto de 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: