grupo de datos

Uso

datagroup: datagroup_name {
max_cache_age: "24 horas"
sql_trigger: SELECT max(id) FROM my_tablename ;;
interval_trigger: "12 horas"
label: """"""
Jerarquía
datagroup
Valor predeterminado
Ninguna

Acepta
Un identificador para tu grupo de datos, además de subparámetros que definen tus propiedades.

Definición

Usa datagroup para asignar una política de almacenamiento en caché a exploraciones o tablas derivadas persistentes (PDT). Si quieres diferentes políticas de almacenamiento en caché para diferentes exploraciones o PDT, usa un parámetro datagroup separado a fin de especificar cada política.

Puedes agregar una etiqueta y una descripción para el grupo de datos:

  • label: Especifica una etiqueta opcional para el grupo de datos. Para obtener más información, consulta las secciones label y description en esta página.
  • description: Especifica una descripción opcional del grupo de datos que se puede usar para explicar el propósito y el mecanismo del grupo de datos. Para obtener más información, consulta las secciones label y description en esta página.

Especifica los detalles de la política de almacenamiento en caché mediante los subparámetros datagroup:

  • max_cache_age: Especifica una string que define un período. Cuando la antigüedad de la caché de una consulta supera el período, Looker invalida la caché. La próxima vez que se emita la consulta, Looker la enviará a la base de datos para obtener resultados actualizados. Consulta la sección max_cache_age en esta página para obtener más información.
  • sql_trigger: Especifica una consulta de SQL que muestra una fila con una columna. Si el valor que muestra la consulta es diferente de los resultados anteriores de la consulta, el grupo de datos pasa a un estado activado. Consulta la sección sql_trigger en esta página para obtener más información.
  • interval_trigger: Especifica un programa para activar el grupo de datos, como "24 hours". Consulta la sección interval_trigger en esta página para obtener más información.

A menudo, la mejor solución es usar max_cache_age en combinación con sql_trigger o interval_trigger. Especifica un valor sql_trigger o interval_trigger que coincida con la carga de datos (ETL) en tu base de datos. Luego, especifica un valor max_cache_age que invalidará los datos antiguos si tu ETL falla. El parámetro max_cache_age garantiza que, si sql_trigger o interval_trigger no borran la caché de un grupo de datos, las entradas de caché vencerán en un momento determinado. De esa manera, el modo de falla de un grupo de datos será consultar la base de datos en lugar de entregar datos inactivos de la caché de Looker.

Un grupo de datos no puede tener los parámetros sql_trigger y interval_trigger. Si defines un grupo de datos con ambos parámetros, este usará el valor interval_trigger y omitirá el valor sql_trigger, ya que el parámetro sql_trigger requiere el uso de recursos de base de datos para consultar la base de datos.

En el caso de las conexiones que usan atributos de usuario para especificar los parámetros de conexión, debes crear una conexión independiente mediante los campos de anulación de PDT si quieres definir una política de almacenamiento en caché de grupos de datos mediante un activador de consultas de SQL.

Sin las anulaciones de PDT, puedes usar un grupo de datos para el modelo y sus exploraciones, siempre que definas la política de almacenamiento en caché del grupo de datos con solo max_cache_age, no con sql_trigger.

max_cache_age

El parámetro max_cache_age especifica una string que contiene un número entero seguido de “segundos”, “minutos” o “horas”. Este es el período máximo para que los resultados almacenados en caché se usen en las consultas de Explorar que usan el grupo de datos.

Cuando la antigüedad de la caché de una consulta supera el max_cache_age, Looker invalida la caché. La próxima vez que se emita la consulta, Looker la enviará a la base de datos para obtener resultados actualizados. Cuando la antigüedad de la caché de una consulta supera el max_cache_age, Looker invalida la caché. La próxima vez que se emita la consulta, Looker la enviará a la base de datos para obtener resultados actualizados. Consulta la página de documentación Consultas en caché y vuelve a compilar los PDT con grupos de datos para obtener información sobre cuánto tiempo se almacenan los datos en la caché.

Si la función Paneles instantáneos Looker Labs está habilitada, las consultas que se ejecutan desde un panel siempre se ejecutarán en la base de datos. Los datos de las ejecuciones anteriores se mostrarán en el panel hasta que se muestren los resultados de la consulta, independientemente del valor max_cache_age.

El parámetro max_cache_age solo define cuándo se invalida la caché. No activa la recompilación de PDT. Si defines un grupo de datos solo con max_cache_age, recibirás una advertencia de validación de LookML si se asignan tablas derivadas al grupo de datos. Si dejas una tabla derivada asignada a un grupo de datos con solo un parámetro max_cache_age, la tabla derivada se compilará cuando se consulte por primera vez, pero la tabla derivada se ubicará en el esquema desde cero de manera indefinida y nunca se volverá a compilar, incluso si se vuelve a consultar. Si deseas que una PDT se vuelva a compilar en un intervalo de tiempo específico, debes agregar un parámetro interval_trigger a tu grupo de datos para definir una programación de recompilación de PDT.

sql_trigger

Usa el parámetro sql_trigger para especificar una consulta de SQL que muestra exactamente una fila con una columna. Looker ejecuta la consulta de SQL a intervalos especificados en el campo PDT y Programa de mantenimiento de grupos de datos de la conexión de la base de datos. Si la consulta muestra un valor diferente al del resultado anterior, el grupo de datos pasa a un estado activado. Una vez que se activa el grupo de datos, Looker vuelve a compilar todos los PDT con ese grupo de datos especificado en su parámetro datagroup_trigger. Una vez que se completa la recompilación del PDT, el grupo de datos pasa a estar listo, y Looker invalida los resultados almacenados en caché de las exploraciones que usan ese grupo de datos.

Por lo general, sql_trigger especifica una consulta de SQL que indica cuándo se produjo una carga de datos (ETL) nueva, por ejemplo, mediante una consulta al max(ID) en una tabla. También puedes usar sql_trigger para especificar una hora del día determinada si consultas la fecha actual y agregas horas adicionales a esa marca de tiempo según sea necesario para alcanzar la hora que deseas, por ejemplo, 4 a.m.

Looker no realiza una conversión de zona horaria para sql_trigger. Si desea activar su grupo de datos a una hora específica del día, configure el activador en la zona horaria para la que está configurada su base de datos.

Consulta estos ejemplos del parámetro sql_trigger a fin de obtener ideas para configurar consultas de SQL a fin de activar un grupo de datos.

interval_trigger

Puedes usar el subparámetro opcional interval_trigger a fin de especificar un período para la recompilación. En el parámetro interval_trigger, debes pasar una string que contiene un número entero seguido de "segundos", "minutos" o "horas".

label y description

Puedes usar los subparámetros opcionales label y description para agregar una etiqueta personalizada y una descripción del grupo de datos. También puede localizar estos subparámetros mediante archivos de strings de configuración regional.

Estos subparámetros se muestran en la página Grupos de datos en la sección Base de datos del panel Administrador. Consulte la página de documentación Configuración del administrador: grupos de datos para obtener más información sobre cómo se muestran estos elementos.

Ejemplos

En los siguientes ejemplos, se destacan los casos de uso de datagroup, incluidos los siguientes:

Crear una política de almacenamiento en caché para recuperar resultados nuevos cuando haya datos nuevos disponibles o al menos cada 24 horas

Para crear una política de almacenamiento en caché que recupere resultados nuevos cuando haya datos nuevos disponibles o al menos cada 24 horas, haz lo siguiente:

  • Usa el grupo de datos orders_datagroup (en el archivo de modelo) para nombrar la política de almacenamiento en caché.
  • Usa el parámetro sql_trigger para especificar la consulta que indica que hay datos actualizados: select max(id) from my_tablename. Cada vez que se actualizan los datos, esta consulta muestra un número nuevo.
  • Usa la configuración max_cache_age para invalidar los datos si se almacenaron en caché durante 24 horas.
  • Usa los parámetros opcionales label y description para agregar una etiqueta personalizada y una descripción del grupo de datos.
datagroup: orders_datagroup {
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  max_cache_age: "24 hours"
  label: "ETL ID added"
  description: "Triggered when new ID is added to ETL log"
}

A fin de usar la política de almacenamiento en caché orders_datagroup como la configuración predeterminada para Explorar en un modelo, usa el parámetro persist_with a nivel de modelo y especifica el orders_datagroup:

persist_with: orders_datagroup

Para usar la política de almacenamiento en caché orders_datagroup en una exploración específica, agrega el parámetro persist_with en el parámetro explore y especifica el orders_datagroup. Si se especifica un grupo de datos predeterminado a nivel del modelo, puedes usar el parámetro persist_with en un explore para anular la configuración predeterminada.

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

Si deseas usar la política de almacenamiento en caché orders_datagroup del grupo de datos para volver a compilar un PDT, puedes agregar datagroup_trigger en el parámetro derived_table y especificar la orders_datagroup:

view: customer_order_facts {
  derived_table: {
    datagroup_trigger: orders_datagroup
    ...
  }
}

Crear un grupo de datos para programar entregas el último día de cada mes

Es posible que quieras crear una programación que envíe una publicación de contenido al final de cada mes. Sin embargo, no todos los meses tienen la misma cantidad de días. Puede crear un grupo de datos para activar la publicación de contenido al final de cada mes, independientemente de la cantidad de días en un mes específico.

  1. Cree un grupo de datos con una instrucción de SQL para que se active al final de cada mes:
  datagroup: month_end_datagroup {
  sql_trigger: SELECT (EXTRACT(MONTH FROM DATEADD( day, 1, GETDATE()))) ;;
  description: "Triggered on the last day of each month"
  }

Este ejemplo se encuentra en Redshift SQL y puede requerir ligeras adaptaciones para diferentes bases de datos.

Esta instrucción de SQL muestra el mes en el que se encuentra mañana (el último día del mes, mañana es el mes siguiente), por lo que se activará el grupo de datos. Como ocurre cada dos días, mañana es el mismo mes, por lo que no se activa el grupo de datos.

  1. Selecciona el grupo de datos en un programa nuevo o existente.

Las programaciones basadas en grupos de datos se envían solo después de que se completa el proceso de regeneración para todos los PDT que persisten con ese parámetro de grupo de datos, lo que garantiza que tu publicación incluya los datos más recientes.

Usar un grupo de datos con PDT en cascada

En el caso de las tablas derivadas en cascada persistentes, en las que se hace referencia a una tabla derivada persistente (PDT) en la definición de otra, puedes usar un grupo de datos a fin de especificar una estrategia de persistencia para la cadena de PDT en cascada.

Por ejemplo, aquí hay una parte de un archivo de modelo que define un grupo de datos llamado user_facts_etl y una exploración llamada user_stuff. La exploración de user_stuff persiste con el grupo de datos user_facts_etl:

datagroup: user_facts_etl {
  sql_trigger: SELECT max(ID) FROM etl_jobs ;;
}

explore: user_stuff {
  persist_with: user_facts_etl
  from: user_facts_pdt_1
  join: user_facts_pdt_2 {
    ...
  }
  ...
}

La exploración user_stuff une la vista user_facts_pdt_1 con la vista user_facts_pdt_2. Ambas vistas se basan en PDT que usan el grupo de datos user_facts_etl como activador de persistencia. La tabla derivada user_facts_pdt_2 hace referencia a la tabla derivada user_facts_pdt_1, por lo que son PDT en cascada. A continuación, se muestra un ejemplo de LookML de los archivos de vista de estos PDT:

view: user_facts_pdt_1 {
  derived_table: {
    datagroup_trigger: user_facts_etl
    explore_source: users {
      column: customer_ID {field:users.id}
      column: city {field:users.city}
      ...
    }
  }
}

view: user_facts_pdt_2 {
  derived_table: {
    sql:
      SELECT ...
      FROM ${users_facts_pdt_1.SQL_TABLE_NAME} ;;
  datagroup_trigger: user_facts_etl
  }
}

Si tiene PDT en cascada, debe asegurarse de que no tengan políticas de almacenamiento en caché de grupos de datos incompatibles.

El regenerador de Looker verifica el estado y, luego, inicia las recompilaciones de estos PDT de la siguiente manera:

  • De forma predeterminada, el regenerador de Looker verifica la consulta de sql_trigger del grupo de datos cada cinco minutos (tu administrador de Looker puede especificar este intervalo mediante la configuración de PDT y Programa de mantenimiento de grupos de datos en tu conexión a la base de datos).
  • Si el valor que muestra la consulta sql_trigger es diferente del resultado de la consulta en la verificación anterior, el grupo de datos pasa al estado activado. En este ejemplo, si la tabla etl_jobs tiene un valor ID nuevo, se activa el grupo de datos user_facts_etl.

  • Una vez que se activa el grupo de datos user_facts_etl, el regenerador de Looker vuelve a compilar todos los PDT que usan ese grupo de datos (es decir, todos los PDT que se definen con datagroup_trigger: user_facts_etl). En este ejemplo, el regenerador vuelve a compilar user_facts_pdt_1 y, luego, a user_facts_pdt_2.

    Cuando los PDT comparten el mismo datagroup_trigger, el regenerador vuelve a compilar los PDT en función de la dependencia, es decir, primero compila las tablas a las que hacen referencia otras tablas. Consulta la página de documentación Tablas derivadas en Looker para obtener más información sobre cómo Looker vuelve a compilar las tablas derivadas en cascada.

  • Cuando el regenerador vuelve a compilar todos los PDT en el grupo de datos, este quita el grupo de datos user_facts_etl del estado activado.

  • Una vez que el grupo de datos user_facts_etl ya no está en el estado activado, Looker restablece la caché para todos los modelos y exploraciones que usan el grupo de datos user_facts_etl (en otras palabras, todos los modelos y exploraciones que se definen con persist_with: user_facts_etl). En este ejemplo, eso significa que Looker restablece la caché para la exploración de user_stuff.

  • Se enviarán todas las entregas de contenido programadas basadas en el grupo de datos de user_facts_etl. En este ejemplo, si hay una entrega programada que incluye una consulta de la exploración de user_stuff, la consulta programada se recuperará de la base de datos para obtener resultados actualizados.

Comparte grupos de datos entre archivos de modelos

En este ejemplo, se muestra cómo compartir grupos de datos con varios archivos de modelo. Este enfoque es ventajoso porque, si necesita editar un grupo de datos, debe hacerlo en un solo lugar para que esos cambios se apliquen en todos sus modelos.

Para compartir grupos de datos con varios archivos de modelo, primero, crea un archivo separado que contenga solo los grupos de datos y, luego, usa el parámetro include para include el archivo de grupos de datos en los archivos del modelo.

Crea un archivo de grupos de datos

Crea un archivo .lkml separado para contener tus grupos de datos. Puedes crear un archivo de grupo de datos .lkml de la misma forma en que puedes crear un archivo .lkml Explore independiente.

En este ejemplo, el archivo de grupos de datos se llama datagroups.lkml:

datagroup: daily {
 max_cache_age: "24 hours"
 sql_trigger: SELECT CURRENT_DATE();;
}

Incluye el archivo de grupos de datos en tus archivos de modelo

Ahora que creaste el archivo de grupos de datos, puedes include en ambos modelos y usar persist_with, ya sea para aplicar el grupo de datos a exploraciones individuales en tus modelos o para aplicar el grupo de datos a todas las exploraciones de un modelo.

Por ejemplo, los siguientes dos archivos de modelo include el archivo datagroups.lkml.

Este archivo se llama ecommerce.model.lkml. El grupo de datos daily se usa a nivel de explore para que se aplique solo a la exploración de orders:

include: "datagroups.model.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

El siguiente archivo se llama inventory.model.lkml. El grupo de datos daily se usa a nivel de model para que se aplique a todas las exploraciones del archivo del modelo:

include: "datagroups.model.lkml"
connection: "database2"
persist_with: daily

explore: items {
}

explore: products {
}