aggregate_table

Uso

explore: explore_name {
  aggregate_table: table_name {

    query:  {
      dimensions: [dimension1, dimension2, ... ]
      measures: [measure1, measure2, ... ]
      sorts: [field1: asc, field2: desc, ... ]
      filters: [field1: "value1", field2: "value2", ... ]
      timezone: timezone
    }

    materialization:  {
      ...
    }
  }

  ...

}

Jerarquía Archivo del modelo explore aggregate_table

Valor predeterminado Ninguno Acepta Un nombre para la tabla agregada, el subparámetro query para definir la tabla y el subparámetro materialization para definir la estrategia de persistencia de la tabla Reglas especiales El table_name debe ser único dentro de un explore determinado. En el subparámetro materialization, debes especificar una estrategia de persistencia para la tabla agregada.

Definición

El parámetro aggregate_table se usa para crear tablas agregadas que minimicen la cantidad de consultas necesarias para las tablas grandes de tu base de datos.

Looker utiliza la lógica de reconocimiento de agregaciones para encontrar la tabla de datos agregados más pequeña y eficiente disponible en tu base de datos para ejecutar una consulta y, al mismo tiempo, mantener la exactitud. (Consulta la página de documentación Aggregate awareness para obtener una descripción general y estrategias para crear tablas de agregación).

Para tablas muy grandes en tu base de datos, puedes crear tablas de agregaciones más pequeñas de datos agrupados según varias combinaciones de atributos. Las tablas agregadas actúan como tablas de resumen o de integración que Looker puede usar para las consultas siempre que sea posible, en lugar de la tabla grande original.

Nota: Para que sean accesibles para el reconocimiento de agregaciones, las tablas agregadas deben conservarse en tu base de datos. La estrategia de persistencia se especifica en el parámetro materialization de la tabla agregada. Además, como las tablas agregadas son un tipo de tabla derivada persistente (PDT), tienen los mismos requisitos de conexión y dialecto de base de datos que las PDT. Consulta la página de documentación Tablas derivadas en Looker para obtener más detalles.

Una vez que crees tus tablas de datos agregados, podrás ejecutar consultas en la exploración para ver cuáles de esas tablas son las que usa Looker. Para obtener más información, consulta la sección Cómo determinar qué tabla agregada se usa para una consulta en la página de documentación Conocimiento de los agregados.

Consulta la sección Solución de problemas en la página de documentación de Aggregate awareness para conocer los motivos comunes por los que no se usan las tablas agregadas.

Cómo definir una tabla de datos agregados en LookML

Nota: En lugar de crear el LookML desde cero, puedes usar una Exploración o un panel para crear el LookML de la tabla agregada por ti. Para obtener más información, consulta las secciones Cómo obtener el LookML de una tabla conjunta desde una exploración y Cómo obtener el LookML de una tabla conjunta desde un panel en esta página.

Cada parámetro aggregate_table debe tener un nombre único dentro de un explore determinado.

El parámetro aggregate_table tiene los subparámetros query y materialization.

query

El parámetro query define la consulta para la tabla agregada, incluidas las dimensiones y las medidas que se deben usar. El parámetro query incluye los siguientes subparámetros:

Nota: En esta sección, se hace referencia al parámetro query que forma parte de un aggregate_table.

query también se puede usar como parte de un explore, como se describe en la página de documentación del parámetro query.

Nombre del parámetro	Descripción	Ejemplo
dimensions	Es una lista separada por comas de las dimensiones de Explorar que se incluirán en tu tabla agregada. El campo dimensions usa este formato: dimensions: [dimension1, dimension2, ...] Cada dimensión de esta lista debe definirse como dimension en el archivo de vista de la Exploración de la consulta. Si deseas incluir un campo definido como un campo filter en la consulta de Explorar, puedes agregarlo a la lista filters en la consulta de la tabla de agregación.	dimensions:   [orders.created_month, orders.country]
measures	Es una lista separada por comas de las medidas de Explorar que se incluirán en tu tabla de agregación. El campo measures usa este formato: measures: [measure1, measure2, ...] Para obtener información sobre los tipos de medidas admitidos para el conocimiento agregado, consulta la sección Factores del tipo de medida en la página de documentación Conocimiento agregado.	measures:   [orders.count]
filters	De forma opcional, agrega un filtro a un query. Los filtros se agregan a la cláusula WHERE del SQL que genera la tabla de agregados. El campo filters usa este formato: filters: [field1: "value1", field2: "value2", ...] Para obtener información sobre cómo los filtros pueden impedir que se use tu tabla agregada, consulta la sección Factores de filtrado en la página de documentación de Conocimiento de la agregación.	filters: [orders.country: "United States", orders.state: "California"]
sorts	De forma opcional, especifica los campos de ordenamiento y la dirección de ordenamiento (ascendente o descendente) para query. El campo sorts usa este formato: sorts: [field1: asc|desc, field2: asc|desc, ...]	[orders.country: asc, orders.state: desc]
timezone	Establece la zona horaria para el query. Si no se especifica una zona horaria, la tabla agregada no realizará ninguna conversión de zona horaria y, en su lugar, usará la zona horaria de la base de datos. Para obtener información sobre cómo configurar la zona horaria de modo que tu tabla de agregación se use como fuente de consultas, consulta la sección Factores de zona horaria en la página de documentación de Conocimiento de agregaciones. El IDE sugiere automáticamente el valor de la zona horaria cuando escribes el parámetro timezone en el IDE. El IDE también muestra la lista de valores de zona horaria admitidos en el panel de ayuda rápida.	timezone: America/Los_Angeles

materialization

El parámetro materialization especifica la estrategia de persistencia para tu tabla de agregados, así como otras opciones de distribución, partición, indexación y agrupamiento que tu dialecto de SQL puede admitir.

Para que tu tabla agregada sea accesible para el reconocimiento de agregaciones, debe conservarse en tu base de datos. El parámetro materialization de tu tabla agregada debe tener uno de los siguientes subparámetros para especificar la estrategia de persistencia:

• datagroup_trigger
• sql_trigger_value
• persist_for (no recomendado)

Además, es posible que se admitan los siguientes parámetros secundarios de materialization para tu tabla agregada, según tu dialecto de SQL:

• cluster_keys
• distribution
• distribution_style
• indexes
• partition_keys
• publish_as_db_view
• sortkeys

Para crear una tabla de agregación incremental, usa los siguientes subparámetros de materialization:

• increment_key
• increment_offset

datagroup_trigger

Usa el parámetro datagroup_trigger para activar la regeneración de la tabla de datos agregados en función de un datagroup existente definido en el archivo del modelo:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      datagroup_trigger: order_datagroup
    }
    query: {
      ...
    }
  }
  ...
}

sql_trigger_value

Usa el parámetro sql_trigger_value para activar la regeneración de la tabla agregada en función de una instrucción de SQL que proporciones. Si el resultado de la instrucción de SQL es diferente del valor anterior, se vuelve a generar la tabla. Esta instrucción sql_trigger_value activará la regeneración cuando cambie la fecha:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      sql_trigger_value: SELECT CURDATE() ;;
    }
    query: {
      ...
    }
  }
  ...
}

persist_for

El parámetro persist_for también se admite para las tablas de agregación. Sin embargo, es posible que la estrategia persist_for no te brinde el mejor rendimiento para el reconocimiento agregado. Esto se debe a que, cuando un usuario ejecuta una consulta que se basa en una tabla persist_for, Looker verifica la antigüedad de la tabla en función del parámetro de configuración persist_for. Si la tabla es anterior al parámetro de configuración persist_for, se vuelve a generar antes de que se ejecute la consulta. Si la antigüedad es inferior al parámetro de configuración persist_for, se usa la tabla existente. Por lo tanto, a menos que un usuario ejecute una búsqueda dentro del período de persist_for, se debe volver a compilar la tabla agregada antes de que se pueda usar para la conciencia agregada.

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      persist_for: "90 minutes"
    }
    query: {
      ...
    }
  }
  ...
}

A menos que comprendas las limitaciones y tengas un caso de uso específico para la implementación de persist_for, es mejor usar datagroup_trigger o sql_trigger_value como estrategia de persistencia para las tablas de agregación.

cluster_keys

El parámetro cluster_keys te permite agregar una columna agrupada en clústeres a las tablas particionadas en BigQuery o Snowflake. El agrupamiento ordena los datos en una partición según los valores de las columnas agrupadas y organiza las columnas agrupadas en bloques de almacenamiento de tamaño óptimo.

Nota: En BigQuery, el agrupamiento en clústeres se admite en las tablas de agregación que también se particionan con el parámetro partition_keys.

Consulta la página de documentación del parámetro cluster_keys para obtener más información.

distribution

El parámetro distribution te permite especificar la columna de una tabla de agregación en la que se aplicará una clave de distribución. distribution solo funciona con las bases de datos de Redshift y Aster. Para otros dialectos de SQL (como MySQL y Postgres), usa indexes en su lugar.

Consulta la página de documentación del parámetro distribution para obtener más información.

distribution_style

El parámetro distribution_style te permite especificar cómo se distribuye la consulta de una tabla agregada entre los nodos de una base de datos de Redshift:

• distribution_style: all indica que todas las filas se copiaron por completo en cada nodo.
• distribution_style: even especifica una distribución uniforme, de modo que las filas se distribuyan a diferentes nodos de forma rotativa.

Nota: Para distribuir la consulta en función de valores únicos en una columna en particular (claves de distribución), puedes usar el parámetro distribution.

Consulta la página de documentación del parámetro distribution_style para obtener más información.

indexes

El parámetro indexes te permite aplicar índices a las columnas de una tabla de agregación.

Consulta la página de documentación del parámetro indexes para obtener más información.

partition_keys

El parámetro partition_keys define un array de columnas según las cuales se particionará la tabla de agregación. partition_keys admite dialectos de bases de datos que pueden particionar columnas. Cuando se ejecuta una consulta que se filtra en una columna particionada, la base de datos solo analizará las particiones que incluyen los datos filtrados, en lugar de analizar toda la tabla. partition_keys solo se admite con los dialectos de Presto y BigQuery.

Consulta la página de documentación del parámetro partition_keys para obtener más información.

publish_as_db_view

El parámetro publish_as_db_view te permite marcar una tabla agregada para realizar consultas fuera de Looker. En el caso de las tablas agregadas con publish_as_db_view configurado como yes, Looker crea una vista estable de la base de datos en la base de datos para la tabla agregada. La vista estable de la base de datos se crea en la propia base de datos, de modo que se pueda consultar fuera de Looker.

Consulta la página de documentación del parámetro publish_as_db_view para obtener más información.

sortkeys

El parámetro sortkeys te permite especificar una o más columnas de una tabla de agregación en las que se aplicará una clave de ordenamiento regular.

Consulta la página de documentación del parámetro sortkeys para obtener más información.

increment_key

Puedes crear PDT incrementales en tu proyecto si tu dialecto los admite. Una PDT incremental es una tabla derivada persistente (PDT) que Looker crea agregando datos recientes a la tabla, en lugar de volver a compilar la tabla en su totalidad. Consulta la página de documentación sobre las PDT incrementales para obtener más información.

Las tablas agregadas son un tipo de PDT y se pueden crear de forma incremental agregando el parámetro increment_key. El parámetro increment_key especifica el incremento de tiempo para el que se deben consultar los datos recientes y agregarlos a la tabla de agregados.

Consulta la página de documentación del parámetro increment_key para obtener más información.

increment_offset

El parámetro increment_offset define la cantidad de períodos anteriores (en la granularidad de la clave de incremento) que se volverán a generar cuando se agreguen datos a la tabla de agregados. El parámetro increment_offset es opcional para las PDT incrementales y las tablas de agregación.

Consulta la página de documentación del parámetro increment_offset para obtener más información.

Cómo obtener LookML de tablas conjuntas desde una Exploración

Como atajo, los desarrolladores de Looker pueden usar una consulta de Explorar para crear una tabla de datos agregados y, luego, copiar el código LookML en el proyecto de LookML:

1. En tu Explorar, selecciona todos los campos y filtros que quieras incluir en tu tabla agregada.
2. Haz clic en Ejecutar para obtener los resultados.
3. Selecciona Obtener LookML en el menú de ajustes de la Exploración. Esta opción solo está disponible para los desarrolladores de Looker.
4. Haz clic en la pestaña Tabla de agregación.
5. Looker proporciona el LookML para un perfeccionamiento de Explorar que agregará la tabla de datos agregados a Explorar. Copia el código de LookML y pégalo en el archivo del modelo asociado, que se indica en el comentario que precede al perfeccionamiento de la exploración. Si la exploración se define en un archivo de exploración independiente y no en un archivo de modelo, puedes agregar el perfeccionamiento al archivo de la exploración en lugar de al archivo de modelo. Cualquiera de las dos ubicaciones funcionará.

Nota: Looker le asigna a la tabla de datos agregados un nombre basado en las dimensiones de la función Explorar. Looker usará el mismo nombre para la tabla de datos agregados cada vez que proporcione el LookML de la tabla de datos agregados para la Exploración. Ten en cuenta otros ajustes que se hayan agregado anteriormente a la misma exploración. Si tú o algún otro desarrollador ya obtuvieron el LookML de la tabla conjunta de un Explorar, Looker le asignará el mismo nombre a la tabla conjunta. Si un Explore tiene varios ajustes, cada uno con tablas agregadas del mismo nombre, un ajuste anulará a los demás, como se describe en la sección Los ajustes se aplican en orden de la página de documentación de ajustes de LookML.

Si necesitas modificar el LookML de la tabla de datos agregados, puedes hacerlo con los parámetros que se describen en la sección Cómo definir una tabla de datos agregados en LookML de esta página. Puedes cambiar el nombre de la tabla agregada sin modificar su aplicabilidad a la consulta original de Explorar. Sin embargo, cualquier otro cambio en la tabla de datos agregados puede afectar la capacidad de Looker para usarla en la consulta de la exploración. Consulta la sección Diseña tablas agregadas de la página de documentación Reconocimiento de agregaciones para obtener sugerencias sobre cómo optimizar tus tablas agregadas y asegurarte de que se usen para el reconocimiento de agregaciones.

Cómo obtener el LookML de una tabla agregada desde un panel

Otra opción para los desarrolladores de Looker es obtener el LookML de la tabla agregada para todos los mosaicos de un panel y, luego, copiar el LookML en el proyecto de LookML.

Crear tablas de agregación puede mejorar drásticamente el rendimiento de un panel, en especial para las tarjetas que consultan conjuntos de datos enormes.

Si tienes permiso de develop, puedes obtener el LookML para crear tablas de datos agregados para un panel abriéndolo, seleccionando Obtener LookML en el menú de tres puntos del panel y eligiendo la pestaña Tablas de datos agregados:

Para cada tarjeta que aún no esté optimizada con el conocimiento de los datos agregados, Looker proporciona el código de LookML para una mejora de la exploración que agregará la tabla de datos agregados a la exploración. Si el panel incluye varios mosaicos de la misma exploración, Looker coloca todas las tablas de datos agregados en una sola versión mejorada de la exploración. Para reducir la cantidad de tablas de datos agregados generadas, Looker determina si una tabla de datos agregados generada se podría usar para más de una tarjeta y, si es así, descarta las tablas de datos agregados redundantes que se puedan usar para menos tarjetas.

Copia y pega cada refinamiento de Explore en el archivo del modelo asociado, que se indica en el comentario que precede al refinamiento de Explore. Si la exploración se define en un archivo de exploración independiente y no en un archivo de modelo, puedes agregar el perfeccionamiento al archivo de exploración en lugar de al archivo de modelo. Cualquiera de las dos ubicaciones funcionará.

Nota: Looker le asigna a cada tabla agregada un nombre basado en las dimensiones de la consulta del panel. Looker usará el mismo nombre para la tabla agregada cada vez que proporcione el LookML de la tabla agregada para la consulta de la tarjeta. Asegúrate de tener en cuenta otros ajustes que se hayan agregado anteriormente a la Exploración de la tarjeta. Si tú o algún otro desarrollador ya obtuvieron el LookML de la tabla conjunta a partir de la consulta del panel, Looker le asignará el mismo nombre a la tabla conjunta. Si un Explore tiene varios ajustes, cada uno con tablas agregadas del mismo nombre, un ajuste anulará a los demás, como se describe en la sección Los ajustes se aplican en orden de la página de documentación de ajustes de LookML.

Si se aplica un filtro del panel a una tarjeta, Looker agregará la dimensión del filtro a la tabla de agregados de la tarjeta para que se pueda usar en ella. Esto se debe a que las tablas de agregado solo se pueden usar para una consulta si los filtros de la consulta hacen referencia a campos que están disponibles como dimensiones en la tabla de agregado. Consulta la página de documentación Aggregate awareness para obtener más información.

Si necesitas modificar el LookML de la tabla de datos agregados, puedes hacerlo con los parámetros que se describen en la sección Cómo definir una tabla de datos agregados en LookML de esta página. Puedes cambiar el nombre de la tabla de datos agregados sin cambiar su aplicabilidad al panel original, pero cualquier otro cambio en la tabla de datos agregados puede afectar la capacidad de Looker para usarla en el panel. Consulta la sección Diseña tablas agregadas de la página de documentación Reconocimiento de agregaciones para obtener sugerencias sobre cómo optimizar tus tablas agregadas y asegurarte de que se usen para el reconocimiento de agregaciones.

Ejemplo

En el siguiente ejemplo, se crea una tabla de agregación monthly_orders para el Explorar event. La tabla de datos agregados crea un recuento mensual de los pedidos. Looker usará la tabla de datos agregados para las consultas de recuento de pedidos que puedan aprovechar el nivel de detalle mensual, como las consultas de recuentos de pedidos anuales, trimestrales y mensuales.

La tabla de agregación se configura con persistencia usando el orders_datagroup de datagroup. Además, la tabla agregada se define con publish_as_db_view: yes, lo que significa que Looker creará una vista estable de la base de datos en la base de datos para la tabla agregada.

La definición de la tabla agregada se ve de la siguiente manera:

explore: event {
  aggregate_table: monthly_orders {
    materialization: {
      datagroup_trigger: orders_datagroup
      publish_as_db_view: yes
    }
    query: {
      dimensions: [orders.created_month]
      measures: [orders.count]
      filters: [orders.created_date: "1 year", orders.status: "fulfilled"]
      timezone: America/Los_Angeles
    }
  }
}

Aspectos para tener en cuenta

Consulta la sección Diseño de tablas de agregación de la página de documentación Conocimiento de agregaciones para obtener sugerencias sobre cómo crear estratégicamente tus tablas de agregación:

• Factores de período
• Factores de zona horaria
• Factores de filtro
• Factores de campo
• Factores del tipo de medida

Compatibilidad con dialectos para el reconocimiento de agregaciones

La capacidad de usar la función de Aggregate Awareness 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:

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+
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 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
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