Notoriedad agregada

Información general

Looker usa 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 sin dejar de 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 que Looker puede usar para las consultas siempre que sea posible, en lugar de la tabla grande original. Si se implementa de forma estratégica, la agregación de la notoriedad puede acelerar la consulta media en órdenes de magnitud.

Por ejemplo, puede tener una tabla de datos a escala de petabytes con una fila por cada pedido que se haya realizado en su sitio web. A partir de esta base de datos, puedes crear una tabla agregada con los totales de ventas diarias. Si tu sitio web recibe 1000 pedidos al día, tu tabla agregada diaria representará cada día con 999 filas menos que la tabla original. Puedes crear otra tabla de datos agregados 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 hace 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 a las preguntas de tus 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).
• En el caso de una consulta sobre el total de cada venta en un día, no hay ninguna 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.
• En el caso de una consulta sobre las ventas semanales, no hay ninguna 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 a las preguntas de los usuarios. La tabla original solo se usaría para las consultas que requieran una granularidad más precisa que la que pueden proporcionar las tablas agregadas.

No es necesario combinar las tablas agregadas ni añadirlas 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 tus desglose se mantienen y que las exploraciones se pueden consolidar. Con la función de detección de agregaciones, una exploración puede aprovechar automáticamente las tablas de agregación, pero también puede profundizar en los datos granulares si es necesario.

También puedes usar tablas agregadas para mejorar drásticamente el rendimiento de los paneles de control, sobre todo en el caso de los gráficos que consultan conjuntos de datos enormes. Para obtener más información, consulta la sección Obtener LookML de tablas agregadas de un panel de control en la página de documentación del parámetro aggregate_table.

Añadir tablas agregadas a un proyecto

Los desarrolladores de Looker pueden crear tablas agregadas estratégicas que minimicen el número de consultas necesarias en las tablas grandes de una base de datos. Las tablas de agregación deben conservarse en tu base de datos para que se pueda acceder a ellas y se puedan usar para la agregación. Por lo tanto, las tablas de datos agregados son un tipo de tabla derivada persistente (PDT).

Las tablas de datos agregados se definen mediante 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 agregada 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 agregada, puedes escribir el LookML desde cero o obtenerlo de una Exploración o de un panel de control. Consulta la página de documentación del parámetro aggregate_table para obtener información específica sobre el parámetro aggregate_table y sus subparámetros.

Diseñar tablas de datos agregados

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

• Los campos de la consulta Explorar son un subconjunto de los campos de la tabla agregada (consulta la sección Factores de los campos de esta página). En el caso de los periodos, los de la consulta Explorar se pueden derivar de los de la tabla agregada (consulta la sección Factores de periodo de esta página).
• La consulta Explorar contiene tipos de medida compatibles con la visibilidad agregada (consulta la sección Factores del tipo de medida de esta página) o tiene una tabla agregada que es una coincidencia exacta (consulta la sección Crear tablas agregadas que coincidan exactamente con las consultas Explorar de 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 la zona horaria de esta página).
• Los filtros de la consulta 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 Explorar coincide con un filtro de la tabla agregada (consulte la sección Factores de filtro de esta página).

Una forma de asegurarse de 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. Para obtener más información, consulta la sección Crear tablas agregadas que coincidan exactamente con las consultas de Explorar de esta página.

Factores de campo

Para poder usarla 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 de la consulta de Explorar. Si una consulta de Exploración contiene una dimensión o una medida que no está en una tabla agregada, Looker no podrá usar la tabla agregada y usará la tabla base.

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

La tabla agregada también puede tener otros campos, pero debe tener al menos los campos de consulta Explorar para que se pueda optimizar. La única excepción son las dimensiones de periodo, ya que los periodos con una granularidad más gruesa se pueden derivar de los que tienen una granularidad más precisa.

Debido a estas consideraciones sobre los campos, una tabla agregada es específica del Explore en el que se define. Una tabla agregada definida en una exploración no se usará para las consultas de otra exploración.

Factores de plazos

La lógica de agregación de la notoriedad de Looker puede derivar un periodo de otro. Se puede usar una tabla agregada en una consulta siempre que el periodo de la tabla agregada tenga una granularidad más precisa (o igual) que la de la consulta de Explorar. Por ejemplo, una tabla agregada basada en datos diarios se puede usar en una consulta de Exploración que requiera otros periodos, como consultas de datos diarios, mensuales y anuales, o incluso datos del día del mes, del día del año y de la semana del año. Sin embargo, una tabla agregada anual no se puede usar en una consulta de Exploración que requiera datos por horas, ya que los datos de la tabla agregada no tienen la granularidad suficiente para la consulta de Exploración.

Lo mismo ocurre con los subconjuntos de intervalos de tiempo. Por ejemplo, si tiene una tabla agregada que se ha filtrado para los últimos tres meses y un usuario consulta los datos con un filtro de los últimos dos meses, Looker podrá usar la tabla agregada para esa consulta.

Además, se aplica la misma lógica a las consultas con filtros de periodo: se puede usar una tabla agregada en una consulta con un filtro de periodo siempre que el periodo de la tabla agregada tenga una granularidad más precisa (o igual) que el filtro de periodo usado en la consulta Explorar. Por ejemplo, una tabla agregada que tenga una dimensión de periodo diario se puede usar en una consulta de Exploración que filtre por día, semana o mes.

Factores del tipo de métrica

Para que una consulta de Explorar pueda usar 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 determinados tipos de métricas, tal como se describe en las siguientes secciones:

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

Si una consulta de Exploración 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, tal como se describe en la sección Crear tablas agregadas que coincidan exactamente con las consultas de Explorar.

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

Medidas con tipos de medida admitidos

La notoriedad agregada se puede usar en las consultas de Exploración que usan medidas con estos tipos de medidas:

• sum
• count
• min
• max
• average

Para usar una tabla agregada en una consulta Exploración, Looker debe poder operar en las medidas de la tabla agregada para proporcionar datos precisos en la consulta Exploración. Por ejemplo, una medida con type: sum se puede usar para la notoriedad agregada, ya que se pueden sumar varias sumas: se pueden sumar los valores de 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 la agregación de la notoriedad porque Looker usa datos de suma y recuento para obtener valores medios precisos de las tablas agregadas.

Medidas definidas con expresiones SQL

La agregación de la notoriedad también se puede usar con medidas definidas con expresiones en el parámetro sql. Cuando se definen con expresiones SQL, también se admiten los siguientes tipos de medidas:

• number
• date
• string
• yesno

La función de reconocimiento de agregaciones se admite en 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} ;;
}

También se admite la notoriedad agregada en las medidas en las que los cálculos se definen en el parámetro sql, como en esta medida:

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

Además, se admite la información sobre agregaciones en las medidas en las que se definen las operaciones MIN, MAX y COUNT en el parámetro sql, como en 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 de otras vistas
• Referencias que usan el formato ${field_name}, que indica campos de la misma vista

No se admite la notoriedad agregada en las medidas definidas con el formato ${TABLE}.column_name, que indica una columna de una tabla. (Consulta la página de documentación Incorporar SQL y hacer referencia a objetos LookML para ver 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 quiere incluir esta medida en una tabla agregada, puede crear una dimensión definida con el formato ${TABLE}.column_name y, a continuación, crear una medida 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 usar la medida wholesale_value en su tabla de agregación.

Métricas que aproximan recuentos distintos

Por lo general, los recuentos distintos no se admiten con la agregación porque no se pueden obtener datos precisos si se intenta agregar recuentos distintos. Por ejemplo, si está contando los usuarios únicos de un sitio web, puede que haya un usuario que haya visitado el sitio web dos veces con tres semanas de diferencia. Si intentaras aplicar una tabla agregada semanal para obtener un recuento mensual de usuarios únicos en tu sitio web, ese usuario se contabilizaría dos veces en tu consulta de recuento mensual de usuarios únicos y los datos serían incorrectos.

Una solución alternativa es crear una tabla agregada que coincida exactamente con una consulta de Exploración, tal como se describe en la sección Crear tablas agregadas que coincidan exactamente con las consultas de Exploración de esta página. Cuando la consulta de Explorar 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 obtener información agregada.

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

Se sabe que el algoritmo HyperLogLog tiene un error de aproximadamente el 2 %. El parámetro allow_approximate_optimization: yes requiere que los desarrolladores de Looker confirmen que se pueden 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 de los parámetros de allow_approximate_optimization para obtener más información y ver 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 la zona horaria UTC para las bases de datos. Sin embargo, es posible que muchos usuarios no estén en la zona horaria UTC. Looker ofrece varias opciones para convertir zonas horarias, de modo que los usuarios obtengan los resultados de las consultas en su propia zona horaria:

• Zona horaria de la consulta: un ajuste que se aplica a todas las consultas de la conexión de la base de datos. Si todos tus usuarios están en la misma zona horaria, puedes definir una única 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 de usuarios: los usuarios pueden tener asignadas zonas horarias y seleccionarlas individualmente. En este caso, las consultas se convierten de la zona horaria de la base de datos a la zona horaria de cada usuario.

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

Estos conceptos son importantes para entender la conciencia de agregación, ya que, para que se pueda usar una tabla de agregación en una consulta con dimensiones de fecha o filtros de fecha, la zona horaria de la tabla de agregación debe coincidir con la zona horaria utilizada en la consulta original.

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

• Tu base de datos no admite zonas horarias.
• La zona horaria de la consulta de la conexión de la base de datos es la misma que la zona horaria de la base de datos.
• Tu conexión de base de datos no tiene una zona horaria de consulta especificada ni zonas horarias específicas de usuario. En ese caso, la conexión de la base de datos usará la zona horaria de la base de datos.

Si se cumple alguna de estas condiciones, puede omitir el parámetro timezone en sus tablas agregadas.

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

• 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 agregación con el valor de la zona horaria de consulta.
• Si tu conexión de base de datos usa zonas horarias específicas de cada usuario, debes crear tablas agregadas idénticas, cada una con un valor de timezone diferente que coincida con las posibles zonas horarias de tus usuarios.

Factores de filtro

Tenga cuidado al incluir filtros en su tabla agregada. Los filtros de una tabla agregada pueden reducir los resultados hasta el punto de que la tabla agregada sea inutilizable. Por ejemplo, supongamos que crea una tabla agregada con los recuentos de pedidos diarios y que esta tabla solo incluye los pedidos de gafas de sol procedentes de Australia. Si un usuario ejecuta una consulta de Explorar para conocer el número de pedidos diarios de gafas de sol en todo el mundo, Looker no puede usar la tabla agregada para esa consulta, ya que solo tiene los datos de Australia. La tabla agregada filtra los datos de forma demasiado estricta para que la consulta Explorar pueda usarlos.

Además, ten en cuenta los filtros que los desarrolladores de Looker hayan podido crear en tu Exploración, como los siguientes:

• access_filters: aplica restricciones de datos específicas de cada usuario.
• always_filter: requiere que los usuarios incluyan un determinado conjunto de filtros en una consulta Exploración. Los usuarios pueden cambiar el valor predeterminado del filtro de su consulta, pero no pueden eliminarlo 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í tenemos 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 use en 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, que también se incluye como 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
    }
  }
}

Como la consulta de la tabla agregada incluye la dimensión orders.region, Looker puede filtrar dinámicamente los datos de la tabla agregada para que coincidan con el filtro de la consulta de Exploración. Por lo tanto, Looker puede seguir usando la tabla agregada para las consultas de 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 transfiere los filtros especificados de una consulta Explorar a la subconsulta de tabla derivada nativa. En el caso de la visibilidad agregada, si tu consulta Explorar requiere una tabla derivada nativa que use bind_filters, la consulta Explorar solo podrá usar una tabla agregada si todos los campos usados en el parámetro bind_filters de la tabla derivada nativa tienen exactamente los mismos valores de filtro en la consulta Explorar que en la tabla agregada.

Crear tablas agregadas que coincidan exactamente con las consultas de Explorar

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

Puedes crear una tabla agregada a partir de una instancia de Explore mediante la opción Obtener LookML del menú de la rueda dentada de una instancia de Explorar. También puedes crear coincidencias exactas para todos los elementos de un panel de control con la opción Obtener LookML del menú de la rueda dentada de un panel de control.

Determinar qué tabla agregada se usa en 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á en una consulta. Los comentarios de la pestaña SQL también se muestran en el modo Desarrollo, por lo que los desarrolladores pueden probar nuevas tablas agregadas para ver cómo las usa Looker antes de enviar nuevas tablas a producción.

Por ejemplo, basándote en la tabla de agregación mensual de ejemplo que se ha mostrado anteriormente, puedes ir a Explorar y ejecutar una consulta para obtener los totales de ventas anuales. A continuación, puedes hacer clic en la pestaña SQL para ver los detalles de la consulta que ha creado Looker. Si estás en el modo Desarrollo, Looker muestra comentarios para indicar la tabla agregada que ha usado en la consulta.

En los siguientes comentarios de la pestaña SQL, podemos ver que Looker está usando la tabla agregada sales_monthly para esta consulta, así como información sobre por qué no se han usado otras tablas agregadas en la consulta:

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

Consulta la sección Solución de problemas de esta página para ver los comentarios que pueden aparecer en la pestaña SQL y sugerencias sobre cómo resolverlos.

Estimaciones de ahorro de computación para la notoriedad agregada

Si tu conexión de base de datos admite estimaciones de costes y se puede usar una tabla agregada en una consulta, la ventana Explorar mostrará el ahorro de computación que supone usar la tabla agregada en lugar de consultar la base de datos directamente. El ahorro de notoriedad agregado se muestra junto al botón Ejecutar en Explorar antes de que se ejecute la consulta.

Antes de ejecutar la consulta, si quiere ver qué tabla agregada se usará, puede hacer clic en la pestaña SQL, tal como se describe en la sección Determinar qué tabla agregada se usa en una consulta de esta página de documentación.

Una vez que se haya ejecutado la consulta, en la ventana Explorar se mostrará la tabla agregada que se ha usado para responder a la consulta junto al botón Ejecutar.

El ahorro agregado por la concienciación se muestra en las conexiones de bases de datos que tienen habilitadas las estimaciones de costes. 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 agregadas

En las tablas agregadas con filtros de tiempo, Looker puede unir datos actualizados en tu tabla agregada. Puede que tengas una tabla agregada que incluya datos de los últimos tres días, pero que se haya creado ayer. La tabla agregada no incluiría la información de hoy, por lo que no sería útil para una consulta de Exploración sobre la información diaria más reciente.

Sin embargo, Looker puede seguir usando los datos de esa tabla agregada para la consulta, ya que ejecutará una consulta sobre los datos más recientes y, a continuación, unirá esos resultados con los de la tabla agregada.

Looker puede unir datos actualizados con los datos de tu tabla agregada en las siguientes circunstancias:

• La tabla de datos agregados 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 creó ayer, Looker recuperará los datos más recientes que aún no se hayan incluido en la tabla agregada y, a continuación, unirá los resultados actualizados con los resultados de la tabla agregada. Esto significa que sus usuarios obtendrán los datos más recientes y, al mismo tiempo, se optimizará el rendimiento mediante la concienciación agregada.

Si estás en el modo Desarrollo, puedes hacer clic en la pestaña SQL de un Exploración para ver la tabla agregada que ha usado Looker en la consulta y la instrucción UNION que ha usado Looker para incorporar datos más recientes que no se incluían en la tabla agregada.

Las tablas de datos agregados deben conservarse

Para que se pueda acceder a ella de forma agregada, la tabla agregada debe persistir en tu base de datos. La estrategia de persistencia se especifica en el parámetro materialization de la tabla de agregación. Como las tablas agregadas son un tipo de tabla derivada persistente (PDT), tienen los mismos requisitos que las PDTs. Para obtener más información, consulta la página de documentación Tablas derivadas en Looker.

Puedes crear PDTs incrementales en tu proyecto si tu dialecto los admite. Looker crea PDTs incrementales añadiendo datos nuevos a la tabla, en lugar de volver a crear la tabla por completo. Como las tablas agregadas son un tipo de PDT, también puedes crear tablas agregadas incrementales. Consulta la página de documentación sobre PDTs incrementales para obtener más información sobre este tipo de PDTs. Consulta la página de documentación del parámetro increment_key para ver un ejemplo de tabla de agregación incremental.

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

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

La opción Recompilar tablas derivadas y ejecutar recompila 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 Recompilar tablas derivadas y ejecutar, la consulta esperará a que se recompilen las tablas antes de cargar los resultados. Las consultas de otros usuarios seguirán usando las tablas actuales. Una vez que se hayan vuelto a crear las tablas persistentes, todos los usuarios utilizarán las tablas reconstruidas.

Consulta la página de documentación Tablas derivadas en Looker para obtener más información sobre la opción Recompilar tablas derivadas y ejecutar.

Solución de problemas

Como se describe en la sección Determinar qué tabla agregada se usa en una consulta, si estás en el modo Desarrollo, puedes ejecutar consultas en Explorar y hacer clic en la pestaña SQL para ver comentarios sobre la tabla agregada que se ha usado en la consulta, si la hay.

La pestaña SQL también incluye comentarios sobre por qué no se han usado tablas agregadas en una consulta, si es el caso. En las tablas agregadas que no se usen, el comentario empezará por lo siguiente:

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

Por ejemplo, aquí tienes un comentario sobre por qué no se ha usado en una consulta la tabla de agregación sales_daily definida en la sección order_items Explorar:

-- 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 han impedido que se usara la tabla agregada.

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 puede seguir para aumentar la usabilidad de la tabla de agregación.

Cuestiones que debes tener en cuenta

Agregados simétricos en Exploraciones con combinaciones

Es importante tener en cuenta que, en una Exploración que una varias tablas de bases de datos, Looker puede representar las medidas de tipo SUM, COUNT y AVERAGE como SUM DISTINCT, COUNT DISTINCT y AVERAGE DISTINCT, respectivamente. Looker lo hace para evitar errores de cálculo de la dispersión. Por ejemplo, una métrica count se representa como un tipo de métrica count_distinct. Esto se hace para evitar errores de cálculo de la dispersión en las combinaciones y forma parte de la función de agregaciones simétricas de Looker. Consulta la página de prácticas recomendadas sobre agregaciones simétricas para obtener una explicación de esta función de Looker.

La función de agregados simétricos evita que se produzcan errores de cálculo, pero también puede impedir que se usen las tablas de agregados en determinados casos, por lo que es importante entenderla.

En el caso de los tipos de métricas admitidos por la notoriedad agregada, esto se aplica a sum, count y average. Looker renderizará estos tipos de medidas como DISTINCT si se cumplen las siguientes condiciones:

• La medida procede de la vista "uno" de una combinación de muchos a uno o de uno a muchos.
• La medida se obtiene de cualquiera de las vistas de una unión de muchos a muchos.

Consulta la página de documentación del parámetro relationship para obtener una explicación de estos tipos de combinaciones.

Si detecta que su tabla agregada no se está usando por este motivo, puede crear una tabla agregada que coincida exactamente con una consulta de Explorar para usar estos tipos de medida en una exploración con combinaciones. Para obtener más información, consulta la sección Crear tablas agregadas que coincidan exactamente con las consultas de Explorar de esta página.

Además, si tiene un dialecto de SQL que admite bocetos de HyperLogLog, puede añadir el parámetro allow_approximate_optimization: yes a la medida. Cuando se define una medida de recuento con allow_approximate_optimization: yes, Looker puede usarla para la agregación, aunque se muestre como un recuento distinto.

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

Compatibilidad con dialectos para la concienciación agregada

La capacidad de usar la agregación depende del dialecto de la base de datos que utilice tu conexión de Looker. En la última versión de Looker, los siguientes dialectos admiten la agregación:

Compatibilidad con dialectos para crear tablas agregadas de forma incremental

Para que Looker admita las tablas agregadas incrementales en tu proyecto de Looker, tu dialecto de base de datos también debe admitirlas. En la siguiente tabla se muestra qué dialectos admiten la creación incremental de PDTs en la última versión de Looker: