groupe de données

Utilisation

datagroup: datagroup_name {
max_cache_age: "24 heures"
sql_trigger: SELECT max(id) FROM my_tablename ;;
interval_trigger: "12 heures"
label: :description:":" :
Hiérarchie
datagroup
Valeur par défaut
Aucun

Acceptation
Identifiant de votre groupe de données, avec sous-paramètres définissant ses propriétés.

Définition

Utilisez datagroup pour attribuer une règle de mise en cache à Explorer et/ou aux tables dérivées persistantes. Si vous souhaitez utiliser des règles de mise en cache différentes pour chaque exploration et/ou traitement du traitement des données, utilisez un paramètre datagroup distinct pour spécifier chaque règle.

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

  • label : spécifie un libellé facultatif pour le groupe de données. Pour en savoir plus, consultez les sections label et description de cette page.
  • description : spécifie une description facultative du groupe de données, qui permet d'expliquer son objectif et son mécanisme. Pour en savoir plus, consultez les sections label et description de cette page.

Spécifiez les détails de la règle de mise en cache à 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'envoie à la base de données pour obtenir de nouveaux résultats. 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, 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 un calendrier de déclenchement du groupe de données, tel que "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 une valeur max_cache_age qui invalidera les anciennes données en cas d'échec de l'ETL. 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 expirent un certain temps. De cette manière, le mode de défaillance 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 contenir à la fois les paramètres sql_trigger et interval_trigger. Si vous définissez un groupe de données avec les deux paramètres, le groupe de données 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 utilisant des attributs utilisateur pour spécifier les paramètres de connexion, vous devez créer une connexion distincte à l'aide des champs de remplacement du champ PDT si vous souhaitez définir une règle de mise en cache du groupe de données à l'aide d'un déclencheur de requête SQL.

Sans les exceptions 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 entier suivi de "secondes", "minutes" ou "heures". Cette période correspond à la période maximale d'utilisation des résultats mis en cache par les requêtes Explorer utilisant le groupe de données.

Lorsque l'ancienneté du cache d'une requête dépasse la valeur max_cache_age, Looker invalide le cache. La prochaine fois que la requête sera émise, Looker l'envoie à la base de données pour obtenir de nouveaux résultats. Lorsque l'ancienneté du cache d'une requête dépasse la valeur max_cache_age, Looker invalide le cache. La prochaine fois que la requête sera émise, Looker l'envoie à la base de données pour obtenir de nouveaux résultats. Consultez la page de documentation Mettre en cache des requêtes et recréer des PDT à l'aide de groupes de données pour en savoir plus sur la durée de stockage des données dans le cache.

Si la fonctionnalité Labs de Looker des tableaux de bord instantanés est activée, les requêtes exécutées à partir d'un tableau de bord seront toujours exécutées sur la base de données. Les données des exécutions précédentes seront affichées sur le tableau de bord jusqu'à ce que les résultats de requête soient renvoyés, quelle que soit la valeur max_cache_age.

Le paramètre max_cache_age ne définit que lorsque le cache n'est pas valide ; il ne déclenche pas la recompilation des PDT. Si vous définissez un groupe de données contenant uniquement max_cache_age, vous recevrez un avertissement de validation LookML 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 seulement un paramètre max_cache_age, la table dérivée est créée lors de la première requête, mais la table dérivée reste indéfiniment dans le schéma de travail et n'est jamais recompilée, même si elle est de nouveau interrogée. Si vous avez l'intention d'effectuer une recompilation sur un PDT à 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 recompilation.

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 à des intervalles spécifiés dans le champ PDT et planification des opérations de maintenance des groupes de données de la connexion à la base de données. Si la requête renvoie une valeur différente de celle 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 recompile tous les PDT avec ce groupe de données spécifié dans leur paramètre datagroup_trigger. Une fois la recompilation terminée, le groupe de données est prêt et Looker invalide les résultats mis en cache de toute exploration utilisant ce groupe de données.

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

Looker n'effectue pas de conversion de fuseau horaire pour sql_trigger. Si vous souhaitez déclencher votre groupe de données à un moment précis 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 dans le paramètre sql_trigger pour obtenir des idées sur la configuration de 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 la durée de la recompilation. Dans le paramètre interval_trigger, vous transmettez une chaîne contenant un entier suivi de "secondes", "minutes" ou "heures".

label et description

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

Ces sous-paramètres sont affichés sur la page Groupes de données de la section Base de données du panneau Admin. Pour en savoir plus sur l'affichage de ces paramètres, consultez la page Paramètres d'administration – Groupes de données.

Examples

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 les 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 permettant de récupérer les 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 indiquant que de nouvelles données sont disponibles: select max(id) from my_tablename. Chaque fois que les données sont mises à jour, cette requête renvoie un nouveau numéro.
  • Utilisez le paramètre max_cache_age pour invalider les données si elles sont mises en cache depuis 24 heures.
  • Utilisez les paramètres facultatifs label et description pour ajouter une étiquette personnalisée 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 l'élément 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, puis 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 la règle de mise en cache du groupe de données orders_datagroup pour recréer un PDT, vous pouvez ajouter datagroup_trigger sous le paramètre derived_table et spécifier orders_datagroup:

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

Créer un groupe de données pour planifier les livraisons le dernier jour de chaque mois

Vous pouvez créer un planning pour envoyer vos contenus à la fin de chaque mois. Cependant, tous les mois ne comportent pas le même nombre de jours. Vous pouvez créer un groupe de données pour déclencher la diffusion de contenus à la fin de chaque mois, quel que soit le nombre de jours dans un mois donné.

  1. Créez un groupe de données à l'aide d'une instruction SQL qui se déclenchera à 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 basé sur 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 en cours, le mois suivant). Le groupe de données sera donc déclenché. Tous les deux jours, le même mois a lieu demain. Le groupe de données n'est donc pas déclenché.

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

Les planifications basées sur des groupes de données ne sont envoyées qu'une fois le processus de régénération terminé pour tous les PDT qui sont conservés avec ce paramètre de groupe de données. Vous vous assurez ainsi que votre livraison inclut les données les plus récentes.

Utiliser un groupe de données en cascade PDT

Dans le cas des 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 de la chaîne de ce type de tables.

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. La fonction user_stuff Explorer continue 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 {
    ...
  }
  ...
}

La fonction Explorer de user_stuff rejoint la vue user_facts_pdt_1 avec 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 de user_facts_pdt_2 fait référence à la table dérivée de user_facts_pdt_1, qui est donc en cascade (PDT). Voici quelques exemples de LookML issus des fichiers de vue de 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'ils ne comportent pas de règles de mise en cache de groupe de données incompatibles.

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

  • Par défaut, le régénérateur de 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 PDT et planification des groupes de données de 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 vérification précédente, le groupe de données passe à l'état déclenché. Dans cet exemple, si la table etl_jobs a 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 recompile tous les disques persistants qui utilisent le groupe de données (en d'autres termes, tous les disques persistants définis avec datagroup_trigger: user_facts_etl). Dans cet exemple, le régénérateur recompile user_facts_pdt_1, puis reconstruit user_facts_pdt_2.

    Lorsque les PDT partagent le même datagroup_trigger, le générateur génère à nouveau les PDT par ordre de dépendance, en créant d'abord des tables référencées par d'autres tables. Consultez la page Tables dérivées dans Looker pour en savoir plus sur la recompilation de tables dérivées en cascade par Looker.

  • Lorsque le régénérateur recompile tous les PDT du groupe de données, il retire le groupe de données user_facts_etl de l'état 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 explorations qui utilisent le groupe de données user_facts_etl (en d'autres termes, tous les modèles et explorations définis avec persist_with: user_facts_etl). Dans cet exemple, Looker réinitialise le cache pour 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 livraison planifiée inclut une requête de la fonction Explorer user_stuff, la requête programmée sera extraite de la base de données pour obtenir de nouveaux résultats.

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

Cet exemple montre comment partager des groupes de données avec plusieurs fichiers de modèle. Cette approche présente un avantage : si vous devez modifier un groupe de données, vous devez le modifier à un seul endroit pour que ces modifications soient appliquées à 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 des 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 qu'un fichier Explorer .lkml distinct.

Dans cet exemple, le fichier de groupes de données s'appelle 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 les deux modèles et utiliser persist_with pour appliquer le groupe de données à des explorations individuelles dans vos modèles ou 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 s'appelle ecommerce.model.lkml. Le groupe de données daily est utilisé au niveau explore afin qu'il ne s'applique qu'à orders:

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

explore: items {
}

explore: products {
}