Notez que vous consultez la documentation 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 d'essai de votre base de données. Looker régénère et rend une table PDT persistante 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 augmentation de table PDT est une PDT créée par Looker en annexant des données à jour à la table, au lieu de régénérer la totalité de la table :

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

Si votre dialecte prend en charge les augmentations de tables PDT, vous pouvez transformer les types de tables PDT suivants en augmentations de tables PDT :

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 concernant les tables PDT incrémentielles :

Les augmentations de tables PDT ne sont compatibles qu'avec les tables PDT qui utilisent une stratégie de persistance basée sur un déclencheur (datagroup_trigger, sql_trigger_value ou interval_trigger). Les augmentations de tables PDT ne sont pas compatibles avec les tables PDT qui utilisent la stratégie de persistance persist_for.
Pour les tables PDT basées sur SQL, la requête de table doit être définie à l'aide du paramètre sql pour être utilisée en tant que table PDT incrémentielle. Les tables PDT basées sur SQL définies avec les paramètres 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 tables PDT. La table dérivée ne peut pas être définie au moyen d'instructions personnalisées DDL (Data Definition Language) car Looker ne pourrait déterminer quelles instructions DDL sont nécessaires pour créer un incrément précis.
La table source de l'augmentation de table 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. L'optimisation de la table source est vivement recommandée, 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 pour 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 (nécessaire pour transformer une table PDT en augmentation de tables PDT): définit la période pendant laquelle les nouveaux enregistrements doivent être interrogés.
{% incrementcondition %} Filtre Liquid (nécessaire pour créer une PDT basée sur SQL en une augmentation de tables PDT ; non applicable aux PDT basées sur LookML): connecte la clé d'incrémentation à la colonne d'heure de la base de données sur laquelle la clé d'incrément 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 passées (selon la granularité de la clé d'incrémentation) qui sont régénérées pour chaque génération d'augmentation. Le paramètre increment_offset est utile dans le cas de données tardives, où les périodes précédentes peuvent comporter de nouvelles données qui n'ont pas été incluses lorsque l'incrément correspondant a été initialement créé et ajouté à la table PDT.

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

La clé d'incrément est basée sur la dimension departure_date, qui est en fait le période date du groupe de dimensions departure. Pour savoir comment fonctionnent les groupes de dimensions, consultez la page de documentation sur le paramètre dimension_group. Le groupe de dimensions et la période sont définis dans la vue flights, qui correspond à la explore_source de cette table 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 d'une augmentation de tables PDT détermine uniquement à quel moment la PDT augmente. Le générateur de PDT ne modifie pas l'augmentation de tables PDT à moins que la stratégie de persistance de la table ne soit déclenchée, ou à moins que la table PDT soit déclenchée manuellement à l'aide de l'option Rebuild Derived Tables & Exécuter dans une exploration.
Lorsque la PDT augmente, le générateur de PDT détermine la date du dernier ajout de données à la table en termes d'incrément de temps le plus courant (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 table PDT dispose d'un paramètre increment_offset, le générateur de table 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 (la période définie par le paramètre increment_key).

Les exemples de scénarios ci-dessous illustrent de quelle façon les augmentations de tables PDT sont mises à jour 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 de l'incrément : 3
Stratégie de persistance : déclenchée une fois par mois au 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 table 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ément : mois
Décalage d'incrémentation: 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émentation: 3
Stratégie de persistance : déclenchée une fois par jour

Ce scénario illustre une mauvaise configuration pour une augmentation de tables PDT, car il s'agit d'une table PDT déclenchant chaque jour 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 table PDT a un décalage d'incrémentation 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 régénérées à partir de février, mars et avril, et jusqu'au 1er juin, jusqu'à la date du jour.

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 pour créer une exploration de la vue de l'augmentation de tables PDT.
```
 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 un nom d'exploration.

Dans l'exploration, sélectionnez des dimensions ou des mesures, puis cliquez sur Run (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 de la table PDT. Si vous ne voyez pas d'événements créés par la PDT dans le journal des événements de tables PDT, vérifiez les informations de statut en haut du volet exploration du journal des événements de tables PDT. S'il indique "depuis le cache", vous pouvez sélectionner Vider le cache et actualiser pour obtenir des informations plus récentes.
- Sinon, vous pouvez consulter les commentaires dans l'onglet SQL de la barre Données de l'exploration. L'onglet SQL affiche la requête et les actions qui seront entreprises lorsque vous exécuterez la requête dans l'exploration. Par exemple, si les commentaires de l'onglet SQL indiquent -- generate derived table e_incremental_pdt,c'est l'action qui est effectuée lorsque vous cliquez sur Run (Exécuter).
Une fois que vous avez créé la compilation initiale de la table PDT, lancez une compilation incrémentielle de la table PDT en utilisant le module Rebuild Derived Tables & 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 de la table PDT pour afficher les événements create increment complete de la table PDT incrémentielle. Si vous ne voyez pas cet événement dans le journal des événements des tables dérivées persistantes et que l'état de la requête indique "depuis le cache", sélectionnez Vider le cache et Actualisez la page pour obtenir des informations plus récentes.
- Examinez les commentaires de l'onglet SQL de la barre Data (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
Une fois que vous avez vérifié que le PDT est créé et incrémenté correctement, si vous ne souhaitez pas conserver l'exploration dédiée pour le PDT, vous pouvez supprimer ou commenter les paramètres explore et include du PDT dans votre fichier de modèle.

Une fois la table PDT créée en mode Développement, la même table est utilisée pour la production lorsque vous déployez vos modifications, sauf si vous apportez 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 augmentations de tables PDT dans votre projet, votre dialecte de base de données doit prendre en charge 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 augmentations de tables PDT dans la dernière version de Looker (pour Databricks, les augmentations de tables PDT ne sont compatibles qu'avec Databricks version 12.1 ou ultérieure) :

Dialecte	Compatibilité
Avalanche d'Actian	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 ou version ultérieure	Non
Apache Hive 2.3 et versions ultérieures	Non
Apache Hive 3.1.2 ou version ultérieure	Non
Apache Spark 3 et versions ultérieures	Non
ClickHouse	Non
Cloudera Impala 3.1+	Non
Cloudera Impala 3.1 et versions ultérieures avec pilote natif	Non
Cloudera Impala avec Native Driver	Non
DataVirtuality	Non
Databricks	Oui
Denodo 7	Non
Denodo 8	Non
Dremio	Non
Dremio 11 et versions ultérieures	Non
Exasol	Non
Flèche de feu	Non
Google BigQuery Legacy SQL	Non
SQL standard Google BigQuery	Oui
Google Cloud PostgreSQL	Oui
Google Cloud SQL	Non
Google Spanner	Non
Greenplum	Oui
HyperSQL	Non
IBM Netezza	Non
MariaDB	Non
Microsoft Azure PostgreSQL	Oui
Microsoft Azure SQL Database	Non
Microsoft Azure Synapse Analytics	Oui
Microsoft SQL Server 2008 et versions ultérieures	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 version antérieure à 9.5	Oui
PrestoDB	Non
PrestoSQL	Non
SAP HANA 2 ou version ultérieure	Non
SingleStore	Non
SingleStore 7 et versions ultérieures	Non
Snowflake	Oui
Teradata	Non
Trino	Non
Vecteur	Non
Vertica	Oui