grupo de datos

Uso

datagroup: datagroup_name {
  max_cache_age: "24 hours"
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  interval_trigger: "12 hours"
  label: "desired label"
  description: "description string"
}
Jerarquía
datagroup
Valor predeterminado
Ninguno

Acepta
Es un identificador de tu grupo de datos, además de subparámetros que definen las propiedades de tu grupo de datos.

Definición

Usa datagroup para asignar una política de almacenamiento en caché a las Exploraciones o para especificar una estrategia de persistencia para las tablas derivadas persistentes (PDT). Si deseas tener varias políticas para diferentes Explorar y PDT, usa un parámetro datagroup independiente para especificar cada política.

Proporciona un nombre único para el grupo de datos que contenga solo letras, números y guiones bajos. No se permiten otros caracteres.

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

  • label: Especifica una etiqueta opcional para el grupo de datos. Consulta la sección label y description en esta página para obtener más detalles.
  • description: Especifica una descripción opcional para el grupo de datos que se puede usar para explicar el propósito y el mecanismo del grupo de datos. Consulta la sección label y description en esta página para obtener más detalles.

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

  • max_cache_age: Especifica una cadena 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 de esta página para obtener más detalles.
  • sql_trigger: Especifica una consulta en SQL que devuelve una fila con una columna. Si el valor que devuelve 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 de esta página para obtener más detalles.
  • interval_trigger: Especifica un programa horario para activar el grupo de datos, como "24 hours". Consulta la sección interval_trigger de esta página para obtener más detalles.

A menudo, la mejor solución es usar max_cache_age en combinación con sql_trigger o interval_trigger. Especifica un valor de sql_trigger o interval_trigger que coincida con la carga de datos (ETL) en tu base de datos y, luego, especifica un valor de max_cache_age que invalide los datos antiguos si falla tu ETL. 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 obsoletos de la caché de Looker.

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

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

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

max_cache_age

El parámetro max_cache_age especifica una cadena que contiene un número entero seguido de “seconds”, “minutes” o “hours”. Este período es el máximo durante el cual las consultas de Explorar que usan el grupo de datos pueden utilizar los resultados almacenados en caché.

Cuando la antigüedad de la caché de una consulta supera el valor de 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 Almacenamiento en caché de consultas para obtener información sobre cuánto tiempo se almacenan los datos en la caché.

El parámetro max_cache_age solo define cuándo se invalida la caché, pero no activa la recompilación de los PDT. Si defines un grupo de datos solo con max_cache_age, recibirás una advertencia de validación de LookML si alguna tabla derivada se asigna 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 permanecerá en el esquema de borrador de forma indefinida y nunca se volverá a compilar, incluso si se vuelve a consultar. Si tu intención es 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 un programa de recompilación de la PDT.

sql_trigger

Usa el parámetro sql_trigger para especificar una consulta en SQL que devuelva exactamente una fila con una columna. Looker ejecuta la consulta en SQL en los intervalos especificados en el campo Datagroup and PDT Maintenance Schedule de la conexión de la base de datos. Si la consulta devuelve un valor diferente 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 cualquier PDT que tenga 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 un estado 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 en SQL que indica cuándo se produjo una nueva carga de datos (ETL), por ejemplo, consultando max(ID) en una tabla. También puedes usar sql_trigger para especificar una hora del día determinada. Para ello, consulta la fecha actual y agrega las horas adicionales que sean necesarias a esa marca de tiempo para llegar a la hora que deseas, por ejemplo, las 4 a.m.

Ten en cuenta los siguientes puntos importantes sobre sql_trigger:

  • No puedes usar sql_trigger si tu conexión de base de datos usa OAuth o atributos del usuario, y deshabilitaste las PDT para la conexión. Esto se debe a que Looker necesita credenciales estáticas para acceder a tu base de datos y ejecutar la consulta especificada en el parámetro sql_trigger. Cuando las PDT están habilitadas, puedes usar los campos de PDT Overrides para proporcionar a Looker credenciales de acceso estáticas y separadas para los procesos de PDT, incluso si tu conexión usa credenciales dinámicas, como OAuth o atributos del usuario. Sin embargo, si las PDT están inhabilitadas y tu conexión usa OAuth o atributos de usuario, no puedes proporcionar a Looker las credenciales de usuario estáticas que se requieren para las consultas de sql_trigger.
  • Looker no realiza la conversión de zona horaria para sql_trigger. Si deseas activar tu grupo de datos en un momento específico del día, configura el activador en la zona horaria para la que está configurada tu base de datos.

Consulta estos ejemplos de la documentación del parámetro sql_trigger para obtener ideas sobre cómo configurar consultas en SQL que activen un grupo de datos.

interval_trigger

Puedes usar el subparámetro opcional interval_trigger para especificar una duración para la recompilación. En el parámetro interval_trigger, pasas una cadena que contiene un número entero seguido de "seconds", "minutes" o "hours".

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 puedes localizar estos subparámetros con archivos de cadenas de configuración regional.

Estos subparámetros se muestran en la página Datagroups, en la sección Database del panel Admin. Consulta la página de documentación Configuración del administrador: grupos de datos para obtener más información sobre cómo se muestran.

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 cada vez que haya datos nuevos disponibles o, al menos, cada 24 horas

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

  • Usa el grupo de datos orders_datagroup (en el archivo del 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 nuevos: select max(id) from my_tablename. Cada vez que se actualizan los datos, esta consulta devuelve un número nuevo.
  • Usa el parámetro de 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"
}

Para usar la política de almacenamiento en caché orders_datagroup como predeterminada para las exploraciones en un modelo, usa el parámetro persist_with a nivel del modelo y especifica orders_datagroup:

persist_with: orders_datagroup

Para usar la política de almacenamiento en caché orders_datagroup para una exploración específica, agrega el parámetro persist_with debajo del 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 el parámetro de configuración predeterminado.

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

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

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

Cómo crear un grupo de datos para programar entregas el último día de cada mes

Es posible que desees crear un programa que envíe una entrega de contenido al final de cada mes. Sin embargo, no todos los meses tienen la misma cantidad de días. Puedes crear un grupo de datos para activar las entregas de contenido al final de cada mes, independientemente de la cantidad de días que tenga un mes específico.

  1. Crea 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 está en SQL de Redshift y puede requerir pequeñas adaptaciones para diferentes bases de datos.

    Esta instrucción de SQL devuelve el mes en el que se encuentra el día de mañana (el último día del mes, mañana es el mes siguiente), por lo que se activará el grupo de datos. Para todos los demás días, el día siguiente está en el mismo mes, por lo que no se activa el grupo de datos.

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

Los programas basados en grupos de datos se envían solo después de que se completa el proceso de regeneración para todos los PDT que se conservan con ese parámetro de grupo de datos, lo que garantiza que tu entrega incluya los datos más recientes.

Cómo 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 para especificar una estrategia de persistencia para la cadena de PDT en cascada.

Por ejemplo, aquí se muestra parte de un archivo de modelo que define un grupo de datos llamado user_facts_etl y una exploración llamada user_stuff. La user_stuff Exploración 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 estas son PDT en cascada. A continuación, se muestra parte del código LookML de los archivos de vistas para 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 tienes PDT en cascada, debes asegurarte de que las PDT no tengan políticas de almacenamiento en caché de datagroups incompatibles.

El regenerador de Looker verifica el estado y, luego, inicia la recompilación de estas PDT de la siguiente manera:

  • De forma predeterminada, el regenerador de Looker verifica la consulta sql_trigger del grupo de datos cada cinco minutos (el administrador de Looker puede especificar este intervalo con el parámetro de configuración Programa de mantenimiento de grupos de datos y PDT en la conexión de base de datos).
  • Si el valor que devuelve la consulta sql_trigger es diferente del resultado de la consulta en la verificación previa, 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 todas las PDT que usan el grupo de datos (en otras palabras, todas las PDT que se definen con datagroup_trigger: user_facts_etl). En este ejemplo, el regenerador vuelve a compilar user_facts_pdt_1 y, luego, user_facts_pdt_2.

    Cuando las PDT comparten el mismo datagroup_trigger, el regenerador vuelve a compilar las PDT en orden de dependencia, 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 del grupo de datos, 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 restablecerá la caché de todos los modelos y las exploraciones que usen el grupo de datos user_facts_etl (en otras palabras, todos los modelos y las exploraciones que se definan con persist_with: user_facts_etl). En este ejemplo, eso significa que Looker restablecerá la caché de la exploración user_stuff.

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

Cómo compartir grupos de datos entre archivos de modelos

En este ejemplo, se muestra cómo compartir grupos de datos con varios archivos de modelos. Este enfoque es ventajoso, ya que, si necesitas editar un grupo de datos, solo debes hacerlo en un lugar para que los cambios se apliquen en todos tus modelos.

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

Cómo crear un archivo de grupos de datos

Crea un archivo .lkml separado para que contenga tus grupos de datos. Puedes crear un archivo de grupo de datos .lkml de la misma manera que puedes crear un archivo de exploración .lkml 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();;
}

Cómo incluir el archivo de grupos de datos en los archivos del 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 en un modelo.

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

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

include: "datagroups.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.lkml"
connection: "database2"
persist_with: daily

explore: items {
}

explore: products {
}