Vous pouvez créer des PDT incrémentiels dans votre projet si votre dialecte les accepte. Un PDT incrémentiel est une table dérivée persistante (PDT) que Looker crée en ajoutant des données récentes à la table, au lieu de la reconstruire entièrement. Pour en savoir plus, consultez la page sur la PDT incrémentiel.

increment_key est le paramètre qui transforme un PDT en PDT incrémentiel en spécifiant l'incrément de temps pour lequel les nouvelles données doivent être interrogées et ajoutées au PDT. En plus du increment_key, vous pouvez éventuellement fournir un increment_offset pour spécifier le nombre de périodes précédentes (avec la précision de la clé d'incrémentation) qui sont recompilées pour tenir compte des données tardives.

Le increment_key d'un PDT est indépendant du déclencheur de persistance du PDT. Consultez la page de documentation sur les PDT incrémentiels pour obtenir des exemples de scénarios montrant l'interaction de increment_key, increment_offset et la stratégie de persistance.

Le paramètre increment_key ne fonctionne qu'avec les dialectes compatibles, et uniquement avec les tables qui ont une stratégie de persistance, comme les PDT et les tables agrégées (qui sont un type de PDT).

Le increment_key doit spécifier une dimension LookML basée sur le temps:

Pour les PDT basés sur LookML, le increment_key doit être basé sur une dimension LookML définie dans la vue sur laquelle le explore_source du PDT est basé. Consultez la section Créer un PDT basé sur LookML incrémentiel sur cette page pour obtenir un exemple.
Pour les tables agrégées, l'increment_key doit être basée sur une dimension LookML définie dans la vue sur laquelle se base l'exploration de la table agrégée. Pour obtenir un exemple, consultez la section Créer un tableau cumulé incrémentiel sur cette page.
Pour les PDT SQL, le increment_key doit être basé sur une dimension LookML définie dans le fichier d'affichage du PDT. Consultez la section Créer un PDT SQL incrémentiel sur cette page pour obtenir un exemple.

En outre, increment_key doit être:

Heure absolue tronquée, telle que "jour", "mois", "année", "trimestre fiscal", etc. Les périodes telles que le jour de la semaine ne sont pas acceptées.
Horodatage qui augmente de manière prévisible avec de nouvelles données, comme la date de création de la commande. En d'autres termes, un horodatage ne doit être utilisé comme clé d'incrémentation que si les données les plus récentes ajoutées à la table possèdent également le dernier horodatage. Un horodatage tel que la date de naissance de l'utilisateur ne fonctionne pas comme une clé d'incrémentation, car l'horodatage d'anniversaire n'augmente pas de manière fiable avec l'ajout de nouveaux utilisateurs à la table.

Créer un PDT incrémentiel basé sur LookML

Pour transformer un PDT basé sur LookML (native) en PDT incrémentiel, utilisez le paramètre increment_key pour spécifier le nom d'une dimension LookML basée sur le temps. La dimension doit être définie dans la vue sur laquelle le explore_source du PDT est basé.

Voici par exemple un fichier de vue pour un disque persistant basé sur LookML, qui utilise le paramètre LookML explore_source. Le PDT est créé à partir de flights Explore, qui est basé sur la vue flights:

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, le PDT sera reconstruit par incréments d'une journée (increment_key: departure_date), en remontant jusqu'à trois jours (increment_offset: 3).

La dimension departure_date est 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 correspond au explore_source de ce 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 ;;
  }
...

Créer un PDT incrémentiel basé sur SQL

Looker vous recommande d'utiliser les tables dérivées (natives) basées sur LookML plutôt que les tables dérivées basées sur SQL. Les tables dérivées natives gèrent intrinsèquement la logique complexe requise pour les PDT incrémentiels. Les disques persistants persistants basés sur SQL s'appuient sur une logique créée manuellement, qui est sujette aux erreurs lorsqu'elle est utilisée avec des fonctionnalités très complexes.

Pour définir un PDT basé sur SQL incrémentiel, utilisez increment_key et (éventuellement) increment_offset comme vous le feriez avec un PDT basé sur LookML. Toutefois, étant donné que les PDT basés sur SQL ne sont pas basés sur des fichiers de vue LookML, des exigences supplémentaires s'appliquent pour transformer un PDT SQL en PDT incrémentiel:

Vous devez baser la clé d'incrémentation sur une dimension LookML basée sur le temps que vous définissez dans le fichier d'affichage du disque persistant.
Vous devez fournir un filtre Liquid {% incrementcondition %} dans le disque persistant pour associer la clé d'incrémentation à la colonne de base de données sur laquelle elle est basée. Le filtre {% incrementcondition %} doit spécifier le nom de la colonne dans votre base de données, et non un alias SQL, ni le nom d'une dimension basée sur la colonne (voir l'exemple suivant).

Le format de base du filtre Liquid est le suivant:

   WHERE {% incrementcondition %} database_table_name.database_time_column {% endincrementcondition %}

Par exemple, voici le fichier de vue d'un disque persistant basé sur SQL qui est recompilé par incréments d'une journée (increment_key: "dep_date"), dans lequel les données des trois derniers jours sont ajoutées à la table lors de la recompilation (increment_offset: 3):

view: sql_based_incremental_date_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "dep_date"
    increment_offset: 3
    distribution_style: all
    sql: SELECT
        flights.id2  AS "id",
        flights.origin  AS "origin",
        DATE(flights.leaving_time )  AS "departure"
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
          ;;
  }

  dimension_group: dep {
    type: time
    timeframes: [raw, date, week, month, year]
    datatype: timestamp
    sql:  ${TABLE}.departure
    ;;
  }
  dimension: id {
      type: number
    }
    dimension: origin {
      type: string
  }
}

Notez les points suivants à propos de cet exemple:

La table dérivée est basée sur une instruction SQL. L'instruction SQL crée une colonne dans la table dérivée basée sur la colonne flights.leaving_time de la base de données. La colonne reçoit l'alias departure.
Le fichier de vue du disque persistant définit un groupe de dimensions appelé dep.
- Le paramètre sql du groupe de dimensions indique que celui-ci est basé sur la colonne departure du tableau dérivé.
- Le paramètre timeframes du groupe de dimensions inclut date comme période.
La increment_key du tableau dérivé utilise la dimension dep_date, qui est basée sur la période date du groupe de dimensions dep. Pour en savoir plus sur le fonctionnement des groupes de dimensions, consultez la page de documentation sur les paramètres dimension_group.
Le filtre Liquid {% incrementcondition %} permet d'associer la clé d'incrémentation à la colonne flights.leaving_time de la base de données.
- La colonne {% incrementcondition %} doit spécifier le nom d'une colonne TIMESTAMP dans votre base de données (ou doit correspondre à une colonne TIMESTAMP dans votre base de données).
- Le {% incrementcondition %} doit évaluer ce qui est disponible dans la clause FROM qui définit votre PDT, comme les colonnes de la table spécifiée dans la clause FROM. La {% incrementcondition %} ne peut pas faire référence au résultat de l'instruction SELECT, tel qu'un alias attribué à une colonne de l'instruction SQL ou au nom d'une dimension basée sur la colonne. Dans l'exemple ci-dessus, {% incrementcondition %} est flights.leaving_time. Étant donné que la clause FROM spécifie la table flights, {% incrementcondition %} peut faire référence à des colonnes de la table flights.
- Le {% incrementcondition %} doit pointer vers la colonne de base de données utilisée pour la clé d'incrémentation. Dans cet exemple, la clé d'incrémentation est dep_date, une dimension définie par la colonne departure du disque persistant, qui est un alias de la colonne flights.leaving_time dans la base de données. Par conséquent, le filtre pointe vers flights.leaving_time :

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

Vous pouvez ajouter des éléments à la clause WHERE pour créer d'autres filtres. Par exemple, si la table de la base de données remonte à plusieurs années, vous pouvez créer un filtre afin que la compilation initiale du disque persistant n'utilise que les données après une certaine date. Ce WHERE crée un PDT avec des données postérieures au 1er janvier 2020:

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
  AND flights.leaving_time > '2020-01-01'

Vous pouvez également utiliser la clause WHERE pour analyser les données en SQL dans un horodatage, puis lui attribuer un alias. Par exemple, l'incrément PDT suivant utilise un incrément de 15 minutes basé sur le text_column, qui correspond aux données de chaîne analysées dans les données d'horodatage:

view: sql_based_incremental_15min_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "event_minute15"
    increment_offset: 1
    sql: SELECT PARSE_TIMESTAMP("%c", flights.text_column) as parsed_timestamp_column,
        flights.id2  AS "id",
        flights.origin  AS "origin",
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} PARSE_TIMESTAMP("%c", flights.text_column)
          {% endincrementcondition %} ;;
  }

  dimension_group: event {
    type: time
    timeframes: [raw, minute15, hour, date, week, month, year]
    datatype: timestamp
    sql:  ${TABLE}.parsed_timestamp_column ;;
  }
  dimension: id {
    type: number
  }
  dimension: origin {
    type: string
  }
}

Vous pouvez utiliser l'alias pour le langage SQL dans la définition du groupe de dimensions sql, mais vous devez utiliser l'expression SQL dans la clause WHERE. Ensuite, comme minute15 a été configuré comme délai dans le groupe de dimensions event, vous pouvez utiliser event_minute15 comme clé d'incrémentation de 15 minutes pour le PDT.

Créer un tableau cumulé incrémentiel

Pour créer un tableau cumulé incrémentiel, ajoutez increment_key et (éventuellement) increment_offset sous le paramètre materialization du paramètre aggregate_table. Utilisez le paramètre increment_key pour spécifier le nom d'une dimension LookML basée sur le temps. La dimension doit être définie dans la vue sur laquelle la fonction Explorer du tableau cumulé est basée.

Par exemple, ce tableau cumulé est basé sur la fonction accidents Explorer, qui dans ce cas est basée sur la vue accidents. Le tableau cumulé est reconstruit par incréments d'une semaine (increment_key: event_week), en remontant de deux semaines (increment_offset: 2):

explore: accidents {
  . . .
  aggregate_table: accidents_daily {
    query: {
      dimensions: [event_date, id, weather_condition]
      measures: [count]
    }
    materialization: {
      datagroup_trigger: flights_default_datagroup
      increment_key: "event_week"
      increment_offset: 2
    }
  }
}

La clé d'incrémentation utilise la dimension event_week, qui est basée sur la période week du groupe de dimensions event. 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 définis dans la vue accidents:

. . .
view: accidents {
  . . .
  dimension_group: event {
      type: time
      timeframes: [
        raw,
        date,
        week,
        year
      ]
      sql: ${TABLE}.event_date ;;
  }
  . . .
}

Éléments à prendre en compte

Optimiser la table source pour les requêtes temporelles

Assurez-vous que la table source du PDT incrémentiel est 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 fortement recommandée car, à chaque mise à jour de l'augmentation de table, Looker demande à la table source de 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.

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

Pour que Looker accepte les PDT incrémentiels dans votre projet Looker, le dialecte de votre base de données doit accepter les commandes DDL (Data Definition Language) qui permettent de supprimer et d'insérer des lignes.

Le tableau suivant présente les dialectes compatibles avec les PDT incrémentiels dans la dernière version de Looker: