groupe de données

Utilisation

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"
}
Hiérarchie
datagroup
Valeur par défaut
Aucun

Acceptation
Identifiant de votre groupe de données, ainsi que des sous-paramètres définissant les propriétés de votre groupe de données.

Définition

Utilisez datagroup pour attribuer une règle de mise en cache aux explorations et/ou pour spécifier une stratégie de persistance pour les tables dérivées persistantes (PDT). Si vous souhaitez appliquer plusieurs règles à différents Explorers et PDT, utilisez un paramètre datagroup distinct pour spécifier chaque règle.

Donnez un nom unique au groupe de données en n'utilisant que des lettres, des chiffres et des traits de soulignement. Aucun autre caractère n'est autorisé.

Vous pouvez ajouter un libellé et une description pour le groupe de données :

  • label : spécifie un libellé facultatif pour le groupe de données. Pour en savoir plus, consultez la section label et description de cette page.
  • description : spécifie une description facultative du groupe de données, qui peut être utilisée pour expliquer son objectif et son mécanisme. Pour en savoir plus, consultez la section label et description de cette page.

Spécifiez les détails des règles de mise en cache et de persistance à l'aide des sous-paramètres datagroup :

  • max_cache_age : spécifie une chaîne qui définit une période. Lorsque l'ancienneté du cache d'une requête dépasse la période, Looker invalide le cache. La prochaine fois que la requête sera émise, Looker l'enverra à la base de données pour obtenir des résultats actualisés. Pour en savoir plus, consultez la section max_cache_age de cette page.
  • sql_trigger : spécifie une requête SQL qui renvoie une ligne avec une colonne. Si la valeur renvoyée par la requête est différente des résultats précédents de la requête, le groupe de données passe à l'état déclenché. Pour en savoir plus, consultez la section sql_trigger de cette page.
  • interval_trigger : spécifie une programmation pour déclencher le groupe de données, par exemple "24 hours". Pour en savoir plus, consultez la section interval_trigger de cette page.

La meilleure solution consiste souvent à utiliser max_cache_age en combinaison avec sql_trigger ou interval_trigger. Spécifiez une valeur sql_trigger ou interval_trigger qui correspond au chargement de données (ETL) dans votre base de données, puis spécifiez une valeur max_cache_age qui invalidera les anciennes données si votre ETL échoue. Le paramètre max_cache_age garantit que si le cache d'un groupe de données n'est pas vidé par sql_trigger ou interval_trigger, les entrées de cache expireront au bout d'un certain temps. Ainsi, le mode d'échec d'un groupe de données consiste à interroger la base de données plutôt qu'à diffuser des données obsolètes à partir du cache Looker.

Un groupe de données ne peut pas comporter à la fois les paramètres sql_trigger et interval_trigger. Si vous définissez un groupe de données avec les deux paramètres, il utilisera la valeur interval_trigger et ignorera la valeur sql_trigger, car le paramètre sql_trigger nécessite l'utilisation de ressources de base de données lors de l'interrogation de la base de données.

Pour les connexions qui utilisent des attributs utilisateur pour spécifier les paramètres de connexion, vous devez créer une connexion distincte à l'aide des champs de remplacement des PDT si vous souhaitez définir une règle de mise en cache de groupe de données à l'aide d'un déclencheur de requête SQL.

Sans les remplacements de PDT, vous pouvez toujours utiliser un groupe de données pour le modèle et ses explorations, à condition de définir la règle de mise en cache du groupe de données en utilisant uniquement max_cache_age, et non sql_trigger.

max_cache_age

Le paramètre max_cache_age spécifie une chaîne contenant un nombre entier suivi de "seconds", "minutes" ou "hours". Cette période correspond à la durée maximale pendant laquelle les résultats mis en cache peuvent être utilisés par les requêtes Explorer qui utilisent le groupe de données.

Lorsque l'ancienneté du cache d'une requête dépasse la max_cache_age, Looker invalide le cache. La prochaine fois que la requête sera émise, Looker l'enverra à la base de données pour obtenir des résultats actualisés. Pour savoir combien de temps les données sont stockées dans le cache, consultez la page de documentation Mise en cache des requêtes.

Le paramètre max_cache_age définit uniquement le moment où le cache est invalidé. Il ne déclenche pas la régénération des PDT. Si vous définissez un groupe de données avec uniquement max_cache_age, un avertissement de validation LookML s'affichera si des tables dérivées sont attribuées au groupe de données. Si vous laissez une table dérivée attribuée à un groupe de données avec un seul paramètre max_cache_age, la table dérivée sera créée lors de la première requête, mais elle restera indéfiniment dans le schéma temporaire et ne sera jamais reconstruite, même si elle est à nouveau interrogée. Si vous souhaitez qu'une PDT soit régénérée à un intervalle de temps spécifique, vous devez ajouter un paramètre interval_trigger à votre groupe de données pour définir un calendrier de régénération de la PDT.

sql_trigger

Utilisez le paramètre sql_trigger pour spécifier une requête SQL qui renvoie exactement une ligne avec une colonne. Looker exécute la requête SQL aux intervalles spécifiés dans le champ Planification du suivi des groupes de données et des tables PDT de la connexion à la base de données. Si la requête renvoie une valeur différente du résultat précédent, le groupe de données passe à l'état "Déclenché". Une fois le groupe de données déclenché, Looker régénère toutes les tables PDT dont ce groupe de données est spécifié dans leur paramètre datagroup_trigger. Une fois la régénération des PDT terminée, le groupe de données passe à l'état "Prêt", et Looker invalide les résultats mis en cache de toutes les explorations utilisant ce groupe de données.

En règle générale, sql_trigger spécifie une requête SQL qui indique quand un nouveau chargement de données (ETL) a eu lieu, par exemple en interrogeant max(ID) dans une table. Vous pouvez également utiliser sql_trigger pour spécifier une heure de la journée en interrogeant la date actuelle et en ajoutant des heures à cet horodatage si nécessaire pour atteindre l'heure souhaitée, par exemple 4h du matin.

Notez les points importants suivants concernant sql_trigger :

  • Vous ne pouvez pas utiliser sql_trigger si votre connexion à la base de données utilise OAuth ou des attributs utilisateur et que vous avez désactivé les PDT pour la connexion. En effet, Looker a besoin d'identifiants statiques pour accéder à votre base de données et exécuter la requête spécifiée dans le paramètre sql_trigger. Lorsque les PDT sont activées, vous pouvez utiliser les champs Remplacements de PDT pour fournir à Looker des identifiants de connexion statiques distincts pour les processus PDT, même si votre connexion utilise des identifiants dynamiques tels qu'OAuth ou des attributs utilisateur. Toutefois, si les PDT sont désactivées et que votre connexion utilise OAuth ou des attributs utilisateur, vous ne pouvez pas fournir à Looker les identifiants utilisateur statiques requis pour les requêtes sql_trigger.
  • Looker ne convertit pas le fuseau horaire pour sql_trigger. Si vous souhaitez déclencher votre groupe de données à une heure spécifique de la journée, définissez le déclencheur dans le fuseau horaire pour lequel votre base de données est configurée.

Consultez ces exemples tirés de la documentation sur le paramètre sql_trigger pour obtenir des idées sur la configuration des requêtes SQL permettant de déclencher un groupe de données.

interval_trigger

Vous pouvez utiliser le sous-paramètre facultatif interval_trigger pour spécifier une durée de reconstruction. Dans le paramètre interval_trigger, vous transmettez une chaîne contenant un nombre entier suivi de "seconds", "minutes" ou "hours".

label et description

Vous pouvez utiliser les sous-paramètres facultatifs label et description pour ajouter un libellé et une description personnalisés au groupe de données. Vous pouvez également localiser ces sous-paramètres à l'aide de fichiers de chaînes de paramètres régionaux.

Ces sous-paramètres s'affichent sur la page Groupes de données, dans la section Base de données du panneau Admin. Pour en savoir plus sur leur affichage, consultez la page de documentation Paramètres d'administration : groupes de données.

Exemples

Les exemples suivants mettent en évidence les cas d'utilisation de datagroup, y compris :

Créer une règle de mise en cache pour récupérer de nouveaux résultats chaque fois que de nouvelles données sont disponibles ou au moins toutes les 24 heures

Pour créer une règle de mise en cache qui récupère de nouveaux résultats chaque fois que de nouvelles données sont disponibles ou au moins toutes les 24 heures :

  • Utilisez le groupe de données orders_datagroup (dans le fichier de modèle) pour nommer la règle de mise en cache.
  • Utilisez le paramètre sql_trigger pour spécifier la requête qui indique que les données sont récentes : select max(id) from my_tablename. Chaque fois que les données sont mises à jour, cette requête renvoie un nouveau nombre.
  • Utilisez le paramètre max_cache_age pour invalider les données si elles ont été mises en cache pendant 24 heures.
  • Utilisez les paramètres facultatifs label et description pour ajouter un libellé personnalisé et une description du groupe de données.
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"
}

Pour utiliser la règle de mise en cache orders_datagroup par défaut pour les explorations d'un modèle, utilisez le paramètre persist_with au niveau du modèle et spécifiez orders_datagroup :

persist_with: orders_datagroup

Pour utiliser la règle de mise en cache orders_datagroup pour une exploration spécifique, ajoutez le paramètre persist_with sous le paramètre explore et spécifiez orders_datagroup. Si un groupe de données par défaut est spécifié au niveau du modèle, vous pouvez utiliser le paramètre persist_with sous un explore pour remplacer le paramètre par défaut.

explore: customer_facts {
  persist_with: orders_datagroup
  ...
}

Pour utiliser les règles de mise en cache du groupe de données orders_datagroup afin de régénérer une PDT, vous pouvez ajouter datagroup_trigger sous le paramètre derived_table et spécifier le orders_datagroup :

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

Créer un groupe de données pour programmer des livraisons le dernier jour de chaque mois

Vous pouvez créer un planning qui envoie un contenu à la fin de chaque mois. Cependant, tous les mois n'ont pas le même nombre de jours. Vous pouvez créer un groupe de données pour déclencher la diffusion de contenu à la fin de chaque mois, quel que soit le nombre de jours d'un mois donné.

  1. Créez un groupe de données à l'aide d'une instruction SQL pour le déclencher à la fin de chaque mois :

    datagroup: month_end_datagroup {
sql_trigger: SELECT (EXTRACT(MONTH FROM DATEADD( day, 1, GETDATE()))) ;;
description: "Triggered on the last day of each month"
}

    Cet exemple est en Redshift SQL et peut nécessiter de légères adaptations pour différentes bases de données.

    Cette instruction SQL renvoie le mois de demain (le dernier jour du mois, demain est le mois prochain), ce qui déclenchera le groupe de données. Les autres jours, "demain" est dans le même mois, donc le groupe de données n'est pas déclenché.

  2. Sélectionnez le groupe de données dans une planification nouvelle ou existante.

Les planifications fondées sur des groupes de données sont envoyées uniquement au terme du processus de régénération de toutes les tables PDT liées à ce paramètre du groupe de données, et vous assurent que l'envoi contient les données les plus récentes.

Utiliser un groupe de données avec des PDT en cascade

Dans le cas de tables dérivées en cascade persistantes, où une table dérivée persistante (PDT) est référencée dans la définition d'une autre, vous pouvez utiliser un groupe de données pour spécifier une stratégie de persistance pour la chaîne de PDT en cascade.

Par exemple, voici une partie d'un fichier de modèle qui définit un groupe de données appelé user_facts_etl et une exploration appelée user_stuff. L'exploration user_stuff persiste avec le groupe de données 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 {
    ...
  }
  ...
}

L'exploration user_stuff joint la vue user_facts_pdt_1 à la vue user_facts_pdt_2. Ces deux vues sont basées sur des PDT qui utilisent le groupe de données user_facts_etl comme déclencheur de persistance. La table dérivée user_facts_pdt_2 fait référence à la table dérivée user_facts_pdt_1. Il s'agit donc de PDT en cascade. Voici une partie du code LookML des fichiers de vue pour ces 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 vous avez des PDT en cascade, vous devez vous assurer qu'elles n'ont pas de règles de mise en cache de groupes de données incompatibles.

Le régénérateur Looker vérifie l'état et lance les régénérations de ces PDT comme suit :

  • Par défaut, le régénérateur Looker vérifie la requête sql_trigger du groupe de données toutes les cinq minutes (votre administrateur Looker peut spécifier cet intervalle à l'aide du paramètre Planification du suivi des groupes de données et des PDT sur votre connexion à la base de données).
  • Si la valeur renvoyée par la requête sql_trigger est différente du résultat de la requête lors du contrôle précédent, le groupe de données passe à l'état déclenché. Dans cet exemple, si la table etl_jobs comporte une nouvelle valeur ID, le groupe de données user_facts_etl est déclenché.

  • Une fois le groupe de données user_facts_etl déclenché, le régénérateur Looker régénère toutes les tables PDT qui utilisent le groupe de données (en d'autres termes, toutes les tables PDT définies avec datagroup_trigger: user_facts_etl). Dans cet exemple, le régénérateur régénère user_facts_pdt_1, puis user_facts_pdt_2.

    Lorsque des PDT partagent le même datagroup_trigger, le régénérateur les recrée en fonction de leur dépendance, en commençant par les tables référencées par d'autres tables. Pour en savoir plus sur la façon dont Looker reconstruit les tables dérivées en cascade, consultez la page de documentation Tables dérivées dans Looker.

  • Lorsque le régénérateur recrée toutes les tables PDT du groupe de données, il fait passer le groupe de données user_facts_etl de l'état déclenché à l'état non déclenché.

  • Une fois que le groupe de données user_facts_etl n'est plus à l'état déclenché, Looker réinitialise le cache pour tous les modèles et toutes les explorations qui utilisent le groupe de données user_facts_etl (en d'autres termes, tous les modèles et toutes les explorations définis avec persist_with: user_facts_etl). Dans cet exemple, cela signifie que Looker réinitialise le cache de l'exploration user_stuff.

  • Toutes les diffusions de contenu planifiées basées sur le groupe de données user_facts_etl seront envoyées. Dans cet exemple, si une requête de l'exploration user_stuff est incluse dans une livraison planifiée, elle sera extraite de la base de données pour obtenir des résultats actualisés.

Partager des groupes de données entre plusieurs fichiers de modèle

Cet exemple montre comment partager des groupes de données avec plusieurs fichiers de modèle. Cette approche est avantageuse, car si vous devez modifier un groupe de données, vous n'avez besoin de le faire qu'à un seul endroit pour que ces modifications prennent effet dans tous vos modèles.

Pour partager des groupes de données avec plusieurs fichiers de modèle, commencez par créer un fichier distinct contenant uniquement les groupes de données, puis utilisez le paramètre include pour include le fichier de groupes de données dans vos fichiers de modèle.

Créer un fichier de groupes de données

Créez un fichier .lkml distinct pour contenir vos groupes de données. Vous pouvez créer un fichier de groupe de données .lkml de la même manière que vous créez un fichier Explore .lkml distinct.

Dans cet exemple, le fichier de groupes de données est nommé datagroups.lkml :

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

Inclure le fichier de groupes de données dans vos fichiers de modèle

Maintenant que vous avez créé le fichier de groupes de données, vous pouvez l'include dans vos deux modèles et utiliser persist_with, soit pour appliquer le groupe de données à des explorations individuelles dans vos modèles, soit pour appliquer le groupe de données à toutes les explorations d'un modèle.

Par exemple, les deux fichiers de modèle suivants include le fichier datagroups.lkml.

Ce fichier est nommé ecommerce.model.lkml. Le groupe de données daily est utilisé au niveau explore afin qu'il s'applique uniquement à l'exploration orders :

include: "datagroups.lkml"

connection: "database1"

explore: orders {
  persist_with: daily
}

Le fichier suivant est nommé inventory.model.lkml. Le groupe de données daily est utilisé au niveau model afin qu'il s'applique à toutes les explorations du fichier de modèle :

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

explore: items {
}

explore: products {
}