Notez que vous consultez la documentation Looker. Pour accéder à la documentation sur Looker Studio, consultez la page https://support.google.com/looker-studio.

Augmentation de tables PDT

Dans Looker, les tables dérivées persistantes (PDT) sont écrites dans le schéma de travail de votre base de données. Looker conserve et recompile une PDT en fonction de sa stratégie de persistance. Lorsqu'une table PDT est déclenchée pour se régénérer, par défaut, Looker régénère la totalité de la table.

Une PDT incrémentielle est une PDT que Looker compile en ajoutant des données récentes à la table au lieu de la recréer dans son intégralité:

Tableau volumineux avec les trois lignes inférieures en surbrillance pour afficher un petit nombre de nouvelles lignes.

Si votre dialecte utilise des PDT incrémentiels, vous pouvez convertir les PDT suivants en PDT incrémentiels:

Lors de la première exécution d'une requête sur une augmentation de table PDT, Looker génère intégralement la PDT pour extraire les données initiales. Selon la taille de la table, la génération initiale peut prendre beaucoup de temps, comme pour toute génération d'une table imposante. Une fois la table initiale générée, les générations suivantes se feront par augmentation et prendront moins de temps si l'augmentation de table PDT est configurée de façon stratégique.

Remarques concernant les tables dérivées persistantes incrémentielles:

Les PDT incrémentiels ne sont compatibles qu'avec les PDT qui utilisent une stratégie de persistance basée sur un déclencheur (datagroup_trigger, sql_trigger_value ou interval_trigger). Les PDT incrémentiels ne sont pas compatibles avec les PDT utilisant la stratégie de persistance persist_for.
Pour les PDT basées sur SQL, la requête de table doit être définie à l'aide du paramètre sql afin d'être utilisée comme PDT incrémentiel. Les tables dérivées persistantes basées sur SQL et définies avec le paramètre sql_create ou le paramètre create_process ne peuvent pas être compilées de manière incrémentielle. Comme vous pouvez le voir dans l'exemple 1 sur cette page, Looker utilise les commandes INSERT ou Merge pour créer les incréments d'une PDT incrémentiel. La table dérivée ne peut pas être définie à l'aide d'instructions LDD (langage de définition de données) personnalisées, car Looker n'est pas en mesure de déterminer quelles instructions LDD sont nécessaires pour créer un incrément précis.
La table source incrémentielle de la PDT doit être optimisée pour les requêtes temporelles. Plus précisément, la colonne temporelle utilisée pour la clé d'incrémentation doit avoir une stratégie d'optimisation, telle que le partitionnement, les clés de tri, les index ou toute autre stratégie d'optimisation compatible avec votre dialecte. Il est vivement recommandé d'optimiser la table source, car chaque fois que la table incrémentielle est mise à jour, Looker interroge la table source pour déterminer les dernières valeurs de la colonne temporelle utilisée pour la clé d'incrémentation. Si la table source n'est pas optimisée pour ces requêtes, la requête de Looker sur les dernières valeurs peut être lente et coûteuse.

Définition d'une augmentation de tables PDT

Vous pouvez utiliser les paramètres suivants pour transformer une table PDT dans une augmentation de PDT :

increment_key (obligatoire pour transformer le PDT en PDT incrémentiel): définit la période pendant laquelle les nouveaux enregistrements doivent être interrogés.
{% incrementcondition %} Filtre Liquid (obligatoire pour convertir une PDT basée sur SQL en PDT incrémentiel, non applicable aux PDT basées sur LookML): connecte la clé d'incrémentation à la colonne de temps de la base de données sur laquelle la clé d'incrémentation est basée. Pour en savoir plus, consultez la page de la documentation increment_key.
increment_offset (facultatif): entier définissant le nombre de périodes précédentes (avec la précision de la clé d'incrémentation) qui sont recompilées pour chaque compilation incrémentielle. Le paramètre increment_offset est utile pour les données tardives, lorsque les périodes précédentes peuvent comporter de nouvelles données qui n'étaient pas incluses lors de la création initiale de l'incrément correspondant et de leur ajout à la PDT.

Consultez la page de documentation sur le paramètre increment_key pour obtenir des exemples de création de tables dérivées persistantes incrémentielles à partir de tables dérivées natives persistantes, de tables dérivées persistantes basées sur SQL et de tables agrégées.

Voici un exemple simple de fichier de vue définissant une augmentation de tables PDT basées sur LookML :

view: flights_lookml_incremental_pdt {
  derived_table: {
    indexes: ["id"]
    increment_key: "departure_date"
    increment_offset: 3
    datagroup_trigger: flights_default_datagroup
    distribution_style: all
    explore_source: flights {
      column: id {}
      column: carrier {}
      column: departure_date {}
    }
  }

  dimension: id {
    type: number
  }
  dimension: carrier {
    type: string
  }
   dimension: departure_date {
    type: date
  }
}

Cette table sera générée intégralement lorsque la première requête sera exécutée sur elle. Passé ce délai, la PDT sera recréée par incréments d'une journée (increment_key: departure_date), en remontant trois jours plus tard (increment_offset: 3).

La clé d'incrémentation est basée sur la dimension departure_date, qui correspond en fait à la période date du groupe de dimensions departure. Pour en savoir plus sur le fonctionnement des groupes de dimensions, consultez la page de documentation sur les paramètres dimension_group. Le groupe de dimensions et la période sont tous deux définis dans la vue flights, qui est explore_source pour cette PDT. Voici comment le groupe de dimensions departure est défini dans le fichier de vue flights:

...
  dimension_group: departure {
    type: time
    timeframes: [
      raw,
      date,
      week,
      month,
      year
    ]
    sql: ${TABLE}.dep_time ;;
  }
...

Interaction des paramètres d'augmentation et stratégie de persistance

Les paramètres increment_key et increment_offset d'une PDT sont indépendants de la stratégie de persistance de la PDT:

La stratégie de persistance des tables dérivées persistantes détermine uniquement lorsque celles-ci sont incrémentielles. Le générateur PDT ne modifie la PDT que si la stratégie de persistance de la table est déclenchée, ou si la PDT est déclenchée manuellement avec l'option Recompiler les tables dérivées et l'exécution dans une exploration.
Lorsque la PDT s'incrémente, le PDT détermine le moment auquel les dernières données ont été ajoutées à la table, en fonction de l'incrément de temps le plus récent (période définie par le paramètre increment_key). De ce fait, le générateur de PDT tronque les données au début de l'incrément de temps le plus courant de la table, puis génère l'incrément le plus récent à partir de là.
Si la PDT comporte un paramètre increment_offset, le compilateur recompile également le nombre de périodes précédentes spécifié dans le paramètre increment_offset. Les périodes précédentes remontent au début du premier incrément de temps (la période définie par le paramètre increment_key).

Les exemples de scénarios suivants montrent comment les tables dérivées persistantes incrémentielles sont mises à jour, en montrant l'interaction entre increment_key, increment_offset et la stratégie de persistance.

Exemple 1

Cet exemple utilise une PDT avec les propriétés suivantes :

Clé d'incrémentation: date
Décalage d'incrément: 3
Stratégie de persistance: déclenchée une fois par mois le premier jour du mois

Voici comment cette table sera mise à jour :

Une stratégie de persistance mensuelle signifie que la table sera générée automatiquement une fois par mois. Cela signifie que le 1er juin, par exemple, la dernière ligne de la table aura été ajoutée le 1er mai.
Comme la PDT a une clé d'incrémentation basée sur la date, le générateur de PDT tronque le 1er mai jusqu'au début de la journée et régénère les données du 1er mai jusqu'à la date actuelle du 1er juin.
De plus, cette PDT a un décalage d'incrémentation de 3. Le générateur de PDT régénère donc également les données des trois périodes précédentes (jours) avant le 1er mai. Les données sont donc régénérées pour les 28, 29 et 30 avril, et jusqu'au jour actuel, le 1er juin.

En termes SQL, voici la commande qu'exécutera le générateur de PDT le 1er juin pour déterminer les lignes de la PDT existante à régénérer :

## Example SQL for BigQuery:
SELECT FORMAT_TIMESTAMP('%F %T',TIMESTAMP_ADD(MAX(pdt_name),INTERVAL -3 DAY))

## Example SQL for other dialects:
SELECT CAST(DATE_ADD(MAX(pdt_name),INTERVAL -3 DAY) AS CHAR)

Et voici la commande SQL qu'exécutera le générateur de PDT le 1er juin pour générer l'incrément le plus récent :

## Example SQL for BigQuery:

MERGE INTO [pdt_name] USING (SELECT [columns]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM'))
   AS tmp_name ON FALSE
WHEN NOT MATCHED BY SOURCE AND created_date >= TIMESTAMP('4/28/21 12:00:00 AM')
   THEN DELETE
WHEN NOT MATCHED THEN INSERT [columns]

## Example SQL for other dialects:

START TRANSACTION;
DELETE FROM [pdt_name]
   WHERE created_date >= TIMESTAMP('4/28/21 12:00:00 AM');
INSERT INTO [pdt_name]
   SELECT [columns]
   FROM [source_table]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM');
COMMIT;

Exemple 2

Cet exemple utilise une PDT avec les propriétés suivantes :

Stratégie de persistance: déclenchée une fois par jour.
Clé d'incrémentation: mois
Décalage d'incrément: 0

Voici comment cette table sera mise à jour le 1er juin :

La stratégie de persistance quotidienne signifie que la table sera générée automatiquement une fois par jour. Le 1er juin, la dernière ligne de la table aura été ajoutée le 31 mai.
Comme la clé d'incrémentation est basée sur le mois, le générateur de PDT tronque à partir du 31 mai jusqu'au début du mois et régénère les données de tout le mois de mai jusqu'à la date actuelle, y compris le 1er juin.
Comme cette PDT n'a pas de décalage d'incrémentation, aucune période précédente n'est régénérée.

Voici comment cette table sera mise à jour le 2 juin :

Le 2 juin, la dernière ligne de la table aura été ajoutée le 1er juin.
Comme le générateur de PDT tronque jusqu'au début du mois de juin et régénère les données comprises entre le 1er juin et la date actuelle, les données ne sont régénérées que pour le 1er et le 2 juin.
Comme cette PDT n'a pas de décalage d'incrémentation, aucune période précédente n'est régénérée.

Exemple 3

Cet exemple utilise une PDT avec les propriétés suivantes :

Clé d'incrémentation: mois
Décalage d'incrément: 3
Stratégie de persistance: déclenchée une fois par jour.

Ce scénario illustre une mauvaise configuration de la PDT incrémentiel, car il s'agit d'une PDT quotidienne qui se déclenche avec un décalage de trois mois. Cela signifie qu'au moins trois mois de données seront régénérées chaque jour, ce qui constitue une utilisation particulièrement inefficace d'une augmentation de tables PDT. Cependant, c'est un scénario intéressant pour comprendre comment les augmentations de tables PDT fonctionnent.

Voici comment cette table sera mise à jour le 1er juin :

La stratégie de persistance quotidienne signifie que la table sera générée automatiquement une fois par jour. Le 1er juin, par exemple, la dernière ligne de la table aura été ajoutée le 31 mai.
Comme la clé d'incrémentation est basée sur le mois, le générateur de PDT tronque à partir du 31 mai jusqu'au début du mois et régénère les données de tout le mois de mai jusqu'à la date actuelle, y compris le 1er juin.
De plus, cette PDT a un décalage d'incrémentation de 3. Cela signifie que l'outil de PDT recompile les données des trois périodes précédentes (mois) avant mai. Les données sont donc reconstituées à partir de février, mars, avril et aujourd'hui (le 1er juin).

Voici comment cette table sera mise à jour le 2 juin :

Le 2 juin, la dernière ligne de la table aura été ajoutée le 1er juin.
Le générateur de PDT tronque le mois jusqu'au 1er juin et régénère les données pour le mois de juin, en incluant le 2 juin.
En outre, en raison du décalage d'incrémentation, le générateur de PDT régénère les données des trois mois précédant le mois de juin. Les données sont donc régénérées à partir des mois de mars, avril et mai, et jusqu'au jour actuel, le 2 juin.

Test d'une augmentation de tables PDT en mode Développement

Avant de déployer une nouvelle augmentation de tables PDT dans votre environnement de production, vous pouvez tester la PDT pour vérifier qu'elle génère et incrémente correctement. Pour tester une augmentation de tables PDT en mode Développement :

Créer une exploration pour la PDT :
- Dans un fichier de modèle associé, utilisez le paramètre include pour inclure le fichier de vue de la PDT dans le fichier de modèle.
- Dans le même fichier de modèle, utilisez le paramètre explore pour créer une exploration de la vue de la PDT incrémentiel.
```
 include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}
```
Ouvrez l'exploration pour la PDT. Pour ce faire, sélectionnez le bouton Afficher les actions sur les fichiers, puis choisissez le nom "Explorer".

Dans l'onglet "Explorer", sélectionnez des dimensions ou des mesures, puis cliquez sur Exécuter. Looker régénère ensuite intégralement la PDT. S'il s'agit de la première exécution d'une requête sur l'augmentation de tables PDT, le générateur de PDT génère intégralement la PDT pour extraire les données initiales. Selon la taille de la table, la génération initiale peut prendre beaucoup de temps, comme pour toute génération d'une table imposante.
Vous pouvez vérifier que la PDT initiale a été générée comme suit :
- Si vous disposez de l'autorisation see_logs, vous pouvez vérifier que la table a été créée en consultant le journal des événements PDT. Si vous ne voyez pas d'événements de création de PDT dans le journal des événements de la PDT, consultez les informations d'état en haut de la page. Si la mention "depuis le cache" est affichée, vous pouvez sélectionner Vider le cache et actualiser pour obtenir des informations plus récentes.
- Sinon, vous pouvez consulter les commentaires de l'onglet SQL de la barre Données d'Explore. L'onglet SQL affiche la requête et les actions qui seront effectuées lorsque vous l'exécuterez dans Explorer. Par exemple, si les commentaires de l'onglet SQL indiquent -- generate derived table e_incremental_pdt,, cette action sera effectuée lorsque vous cliquerez sur Exécuter.
Après avoir créé la compilation initiale de la PDT, invoquez une compilation incrémentielle à l'aide de l'option Recompiler les tables dérivées et exécution de l'exploration.
Vous pouvez utiliser les mêmes méthodes qu'auparavant pour vérifier que la PDT se génère par augmentation :
- Si vous disposez de l'autorisation see_logs, vous pouvez utiliser le PDT d'événement PDT pour afficher les événements create increment complete de la PDT incrémentiel. Si cet événement n'apparaît pas dans le journal des événements de la PDT et que l'état de la requête indique "De la mémoire cache ", sélectionnez Vider le cache et actualiser pour obtenir des informations plus récentes.
- Consultez les commentaires de l'onglet SQL de la barre Données d'Explore. Dans ce cas, les commentaires indiquent que la PDT a été augmentée. Exemple: -- increment persistent derived table e_incremental_pdt to generation 2
Une fois que vous avez vérifié que la PDT est compilée et incrémentée correctement, si vous ne souhaitez pas conserver l'exploration dédiée de la PDT, vous pouvez supprimer ou mettre en commentaire les paramètres explore et include de la PDT dans votre fichier de modèle.

Une fois la PDT créée en mode développement, la même table sera utilisée pour la production une fois que vous aurez déployé vos modifications, sauf si vous en apportez d'autres à la définition de la table. Pour en savoir plus, consultez la section Tableaux persistants en mode développement de la page de tables dérivées de Looker.

Dialectes de base de données pris en charge pour les augmentations de tables PDT

Pour que Looker accepte les tables dérivées persistantes incrémentielles dans votre projet Looker, votre dialecte de base de données doit accepter les commandes LDD (langage de définition de données), qui permettent de supprimer et d'insérer des lignes.

Le tableau suivant indique les dialectes compatibles avec les tables dérivées persistantes incrémentielles dans la dernière version de Looker: