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 utilisant uniquement des lettres, des chiffres et des traits de soulignement. Aucun autre caractère n'est autorisé.

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 la section label et description sur cette page.
  • description : spécifie une description facultative du groupe de données qui peut être utilisée pour expliquer l'objectif et le mécanisme du groupe de données. Pour en savoir plus, consultez la section label et description sur 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'âge 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 sur 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 sur 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 sur 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 effacé par sql_trigger ou interval_trigger, les entrées de cache expireront à une certaine heure. De cette façon, 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 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'âge du cache d'une requête dépasse 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 ne définit que le moment où le cache est invalidé. Il ne déclenche pas la régénération des tables 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 régénérer une 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 régénération de la PDT.

Lorsque vous configurez max_cache_age pour des groupes de données utilisés avec des structures PDT profondément imbriquées (chaînes de PDT en cascade avec plusieurs niveaux de dépendances), assurez-vous que la période de conservation du cache est suffisamment longue pour éviter les conditions de concurrence lors de l'actualisation. Pour en savoir plus, consultez Bonnes pratiques pour les PDT profondément imbriqués.

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 à intervalles réguliers, comme indiqué dans le champ Planification de la maintenance des groupes de données et des 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 pour lesquelles ce groupe de données est spécifié dans leur paramètre datagroup_trigger. Une fois la régénération des tables 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 à ce code temporel 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'informations d'identification 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és 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 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 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é personnalisé et une description du groupe de données. Vous pouvez également localiser ces sous-paramètres à l'aide des 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 qu'il existe des données 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 stratégie 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 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 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 mois prochain, le dernier jour du mois). Le groupe de données sera donc déclenché. Les autres jours, le lendemain 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 persistantes en cascade, 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 de la maintenance 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 générateur régénère toutes les PDT du groupe de données, il fait passer 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 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 pour l'exploration user_stuff.

  • Toutes les livraisons de contenu planifiées basées sur le groupe de données user_facts_etl seront envoyées. Dans cet exemple, s'il existe une livraison planifiée qui inclut une requête à partir de l'exploration user_stuff, la requête planifiée sera récupérée à partir de la base de données pour obtenir des résultats récents.

Bonnes pratiques pour les PDT profondément imbriquées

Lorsque vous travaillez avec des structures PDT profondément imbriquées (chaînes de PDT en cascade avec plusieurs niveaux de dépendances), la configuration de périodes de conservation du cache courtes (par exemple, 15 minutes) peut entraîner une condition de concurrence qui génère une erreur 409 Conflict lors de l'actualisation.

Cette condition de concurrence se produit, car le cache des tables PDT imbriquées de niveau inférieur peut expirer alors que les tables PDT de niveau supérieur sont toujours en cours de création. Dans ce cas, Looker déclenche une nouvelle demande de génération en double pour les PDT de niveau inférieur, tandis que le job initial est toujours en cours de traitement dans l'entrepôt de données, ce qui entraîne le conflit.

Pour résoudre ou éviter cette erreur, suivez les bonnes pratiques suivantes :

  • Augmentez la période de conservation du cache : définissez la période de conservation du cache (max_cache_age ou persist_for) pour les PDT sur au moins deux à trois fois la durée maximale nécessaire pour compiler entièrement toutes les PDT imbriquées.
  • Augmentez l'intervalle d'actualisation du groupe de données : laissez suffisamment de temps pour que les PDT profondément imbriquées soient créées, ce qui réduit le risque de chevauchement des processus de création.

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 est avantageuse, car si vous devez modifier un groupe de données, il vous suffit de le faire à un seul endroit pour que les 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 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 .lkml de groupe de données de la même manière que vous pouvez créer un fichier d'exploration .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 pour appliquer le groupe de données à des explorations individuelles dans vos modèles ou à 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 {
}