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

Cette page a été traduite par l'API Cloud Translation.

Augmentation de tables PDT

Dans Looker, les tables dérivées persistantes (PDT) sont écrites dans le schéma entièrement nouveau de votre base de données. Looker conserve et régénère 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 génère en ajoutant de nouvelles données à la table au lieu de la reconstruire dans son intégralité:

Un grand tableau avec les trois lignes du bas mises en évidence pour montrer un petit nombre de nouvelles lignes ajoutées au tableau.

Si votre dialecte accepte les PDT incrémentielles, vous pouvez convertir les types de PDT suivants en PDT incrémentielles:

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.

Notez les points suivants pour les augmentations de tables PDT:

Les PDT incrémentielles ne sont compatibles qu'avec les PDT qui utilisent une stratégie de persistance basée sur des déclencheurs (datagroup_trigger, sql_trigger_value ou interval_trigger). Elles ne sont pas compatibles avec les PDT qui utilisent 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 pour être utilisée comme une PDT incrémentielle. Les tables PDT basées sur SQL définies avec le paramètre sql_create ou create_process ne peuvent pas être créées de manière incrémentielle. Comme vous pouvez le voir dans l'exemple 1 de cette page, Looker utilise une commande INSERT ou MERGE pour créer les incréments d'une augmentation de table PDT. 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 ne serait pas en mesure de déterminer quelles instructions LDD seraient nécessaires pour créer un incrément précis.
La table source de la PDT incrémentielle doit être optimisée pour les requêtes temporelles. Plus précisément, la colonne temporelle utilisée pour la clé d'incrément 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. Nous vous recommandons vivement d'optimiser la table source, car à chaque mise à jour de la table incrémentielle, 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 pour obtenir les dernières valeurs peut s'avérer 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 la PDT une PDT incrémentielle): définit la période pendant laquelle les nouveaux enregistrements doivent être interrogés.
{% incrementcondition %} Filtre Liquid (requis pour transformer une PDT basée sur SQL en une PDT incrémentielle ; non applicable aux PDT basées sur LookML): connecte la clé d'incrément à la colonne de temps de base de données sur laquelle elle est basée. Pour en savoir plus, consultez la page de documentation de increment_key.
increment_offset (facultatif): nombre entier qui définit le nombre de périodes précédentes (selon la précision de la clé d'incrémentation) recompilées pour chaque compilation incrémentielle. Le paramètre increment_offset est utile dans le cas de données tardives, où des périodes précédentes peuvent comporter de nouvelles données qui n'étaient pas incluses lorsque l'incrément correspondant a été initialement créé et ajouté à la PDT.

Consultez la page de documentation des paramètres increment_key pour obtenir des exemples montrant comment créer des PDT 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. Ensuite, la PDT sera régénérée par incréments d'un jour (increment_key: departure_date), à raison de trois jours en arrière (increment_offset: 3).

La clé d'incrément est basée sur la dimension departure_date, qui correspond en réalité à la période date du groupe de dimensions departure. Consultez la page de documentation des paramètres dimension_group pour découvrir le fonctionnement des groupes de dimensions. Le groupe de dimensions et la période sont tous deux définis dans la vue flights, qui correspond à la 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 table PDT sont indépendants de sa stratégie de persistance:

La stratégie de persistance de la PDT incrémentielle détermine uniquement à quel moment la PDT augmente. Le générateur de PDT ne modifie pas la PDT incrémentielle, sauf 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 Recréer les tables dérivées et exécuter dans une exploration.
Lorsque la PDT augmente, le générateur de PDT détermine quand les dernières données ont été précédemment ajoutées à la table, en termes d'incrément de temps le plus récent (la 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 générateur de PDT régénère é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 de l'incrément de temps le plus récent (période définie par le paramètre increment_key).

Les exemples de scénarios suivants illustrent la mise à jour des PDT incrémentielles en montrant l'interaction de 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ément: date
Décalage d'incrément: 3
Stratégie de persistance: la campagne est 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.
En outre, cette PDT présente un décalage d'incrément 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ément : "month"
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ément : "month"
Décalage d'incrément: 3
Stratégie de persistance: déclenchée une fois par jour

Ce scénario illustre une mauvaise configuration d'augmentation de PDT, puisqu'il s'agit d'une PDT à déclenchement quotidien 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.
En outre, cette PDT présente un décalage d'incrément de 3. Cela signifie que le générateur de PDT régénère également les données des trois périodes précédentes (mois) avant mai. Résultat, les données sont recréées à partir de février, mars, avril et jusqu'au jour en cours, 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 table PDT dans le fichier de modèle.
- Dans le même fichier de modèle, utilisez le paramètre explore afin de créer une exploration pour la vue de la PDT incrémentielle.
```
 include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}
```
Ouvrez l'exploration pour la PDT. Pour ce faire, sélectionnez le bouton See file actions (Voir les actions sur les fichiers), puis sélectionnez un nom d'exploration.

Dans l'exploration, 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 créés par la PDT dans le journal des événements PDT, vérifiez les informations d'état en haut de l'exploration du journal des événements PDT. Si la mention "depuis le cache" s'affiche, 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 de l'exploration. L'onglet SQL affiche la requête et les actions qui seront effectuées lorsque vous l'exécuterez dans l'exploration. Par exemple, si les commentaires de l'onglet SQL indiquent -- generate derived table e_incremental_pdt,c'est l'action qui sera effectuée lorsque vous cliquerez sur Exécuter.
Une fois que vous avez créé le build initial de la PDT, lancez une compilation incrémentielle de la PDT à l'aide de l'option Rebuild Derived Tables & Run (Recréer les tables dérivées et exécuter) 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 journal des événements PDT pour afficher les événements create increment complete pour la PDT incrémentielle. Si vous ne voyez pas cet événement dans le journal des événements des PDT et que l'état de la requête indique "depuis le 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 de l'exploration. Dans ce cas, les commentaires indiquent que la PDT a été augmentée. Par exemple: -- increment persistent derived table e_incremental_pdt to generation 2
Après avoir vérifié que la PDT est créée et incrémentée correctement, si vous ne souhaitez pas conserver l'exploration dédiée à la PDT, vous pouvez supprimer ou commenter les paramètres explore et include de la PDT de votre fichier de modèle.

Une fois la PDT créée en mode Développement, la même table sera utilisée en production une fois vos modifications déployées, à moins que vous n'apportiez d'autres modifications à la définition de la table. Pour en savoir plus, consultez la section Tables persistantes en mode Développement de la page de documentation Tables dérivées dans Looker.

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

Pour que Looker prenne en charge les PDT 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) permettant de supprimer et d'insérer des lignes.

Le tableau suivant indique les dialectes compatibles avec les PDT incrémentielles dans la dernière version de Looker (pour Databricks, les PDT incrémentielles ne sont compatibles qu'avec Databricks 12.1 ou version ultérieure):

Dialecte	Compatible ?
Actian Avalanche	Non
Amazon Athena	Non
Amazon Aurora MySQL	Non
Amazon Redshift	Oui
Apache Druid	Non
Apache Druid 0.13 et versions ultérieures	Non
Apache Druid 0.18 et versions ultérieures	Non
Apache Hive 2.3 et versions ultérieures	Non
Apache Hive 3.1.2+	Non
Apache Spark 3 ou version ultérieure	Non
ClickHouse	Non
Cloudera Impala 3.1 ou version ultérieure	Non
Cloudera Impala 3.1 ou version ultérieure avec pilote natif	Non
Cloudera Impala avec pilote natif	Non
DataVirtuality	Non
Databricks	Oui
Denodo 7	Non
Denodo 8	Non
Dremio	Non
Dremio 11 et versions ultérieures	Non
Exasol	Non
Boulon	Non
Ancien SQL de Google BigQuery	Non
SQL standard Google BigQuery	Oui
Google Cloud PostgreSQL	Oui
Google Cloud SQL	Non
Google Spanner	Non
Prune	Oui
HyperSQL	Non
IBM Netezza	Non
MariaDB	Non
Microsoft Azure PostgreSQL	Oui
Base de données Microsoft Azure SQL	Non
Microsoft Azure Synapse Analytics	Oui
Microsoft SQL Server 2008 ou version ultérieure	Non
Microsoft SQL Server 2012 ou version ultérieure	Non
Microsoft SQL Server 2016	Non
Microsoft SQL Server 2017 ou version ultérieure	Non
MongoBI	Non
MySQL	Oui
MySQL 8.0.12 et versions ultérieures	Oui
Oracle	Non
Oracle ADWC	Non
PostgreSQL 9.5 ou version ultérieure	Oui
PostgreSQL antérieur à la version 9.5	Oui
PrestoDB	Non
PrestoSQL	Non
SAP HANA 2+	Non
SingleStore	Non
SingleStore 7+	Non
Snowflake	Oui
Teradata	Non
Trino	Non
Vecteur	Non
Vertica	Oui