increment_key

Utilisation

view: my_view {
  derived_table: {
    increment_key: "created_date"
    ...
  }
}
Hiérarchie
view
derived_table
increment_key

- ou -

explore
aggregate_table
materialization
increment_key
Valeur par défaut
Aucun

Acceptation
Nom d'une dimension LookML temporelle.

Règles spéciales
increment_key n'est compatible qu'avec les tables persistantes et uniquement pour certains dialectes.

Définition

Vous pouvez créer des PDT incrémentales dans votre projet si votre dialecte les prend en charge. Une PDT incrémentale est une table dérivée persistante (PDT) créée par Looker en ajoutant des données à jour à la table, au lieu de régénérer la totalité de la table. Pour en savoir plus, consultez la page de documentation sur les PDT incrémentales.

increment_key est le paramètre qui transforme une PDT en PDT incrémentale en spécifiant l'incrément de temps pour lequel les nouvelles données doivent être interrogées et ajoutées à la PDT. En plus de increment_key, vous pouvez éventuellement fournir un increment_offset pour spécifier le nombre de périodes précédentes (selon la précision de la clé d'incrémentation) qui sont régénérées pour tenir compte des données arrivant tardivement.

Le increment_key d'une PDT est indépendant du déclencheur de persistance de la PDT. Consultez la page de documentation PDT incrémentielles pour obtenir des exemples de scénarios illustrant l'interaction de increment_key, increment_offset et de 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 paramètre increment_key doit spécifier une dimension LookML temporelle :

De plus, increment_key doit être :

  • Une heure absolue tronquée, telle que le jour, le mois, l'année ou le trimestre fiscal. Les périodes telles que le jour de la semaine ne sont pas acceptées.
  • Un code temporel qui augmente de manière prévisible avec les nouvelles données, comme la date de création de la commande. En d'autres termes, un code temporel ne doit être utilisé comme clé d'incrémentation que si les données les plus récentes ajoutées à la table ont également le code temporel le plus récent. Un code temporel tel que la date de naissance d'un utilisateur ne fonctionnerait pas comme clé d'incrémentation, car un code temporel de date de naissance n'augmente pas de manière fiable lorsque de nouveaux utilisateurs sont ajoutés à la table.

Créer une PDT incrémentale basée sur LookML

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

Par exemple, voici un fichier de vue pour une PDT basée sur LookML, qui utilise le paramètre LookML explore_source. La table de données dérivée persistante est créée à partir de l'exploration flights, qui est basée sur la vue flights dans ce cas :

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. Après cela, la PDT sera régénérée en augmentations d'une journée (increment_key: departure_date), en remontant trois jours en arrière (increment_offset: 3).

La dimension departure_date est en fait la période date du groupe de dimensions departure. (Consultez la page de documentation sur le paramètre dimension_group pour découvrir le fonctionnement des groupes de dimensions.) Le groupe de dimensions et la période sont tous deux définis par la vue flights, qui est la explore_source de 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 ;;
  }
...

Créer une PDT persistante incrémentale basée sur SQL

Looker vous suggère d'utiliser des tables dérivées (natives) basées sur LookML comme base pour les PDT incrémentielles, plutôt que des 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émentielles. Les PDT basées sur SQL reposent 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 une PDT incrémentale basée sur SQL, utilisez increment_key et (facultatif) increment_offset comme vous le feriez avec une PDT basée sur LookML. Toutefois, comme les PDT basées sur SQL ne sont pas basées sur des fichiers de vue LookML, des exigences supplémentaires s'appliquent pour transformer une PDT basée sur SQL en PDT incrémentielle :

  • Vous devez baser la clé d'incrément sur une dimension LookML temporelle que vous définissez dans le fichier de vue de la PDT.
  • Vous devez fournir un filtre Liquid {% incrementcondition %} dans la PDT pour connecter la clé d'incrément à la colonne horaire de la base de données sur laquelle la clé d'incrément 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'une PDT basée sur SQL qui est recréée par incréments d'un jour (increment_key: "dep_date"), où les données des trois derniers jours seront ajoutées à la table lors de sa recréation (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: [date, week, month, year]
    datatype: date
    sql:  ${TABLE}.departure
    ;;
  }
  dimension: id {
      type: number
    }
    dimension: origin {
      type: string
  }
}

Notez les points suivants concernant 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 de la table PDT 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 de la table dérivée.
    • Le paramètre timeframes du groupe de dimensions inclut date en tant que période.
  • Le paramètre increment_key de la table dérivée utilise la dimension dep_date, qui est une dimension basée sur la période date du groupe de dimensions dep. (Consultez la page de documentation sur le paramètre dimension_group pour découvrir le fonctionnement des groupes de dimensions.)
  • Le filtre Liquid {% incrementcondition %} permet de connecter la clé d'incrément à la colonne flights.leaving_time de la base de données.
    • {% incrementcondition %} doit spécifier le nom d'une colonne TIMESTAMP de votre base de données (ou doit correspondre à une colonne TIMESTAMP de votre base de données).
    • Le {% incrementcondition %} doit être évalué par rapport à 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. {% incrementcondition %} ne peut pas faire référence au résultat de l'instruction SELECT, par exemple un alias attribué à une colonne dans l'instruction SQL ou le nom d'une dimension basée sur la colonne. Dans cet exemple, {% incrementcondition %} est flights.leaving_time. Étant donné que la clause FROM spécifie la table flights, l'{% incrementcondition %} peut faire référence aux colonnes de la table flights.
    • {% incrementcondition %} doit pointer vers la même colonne de base de données que celle utilisée pour la clé d'incrémentation. Dans cet exemple, la clé d'incrément est dep_date, une dimension définie par la colonne departure dans la PDT, 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 base de données remonte à plusieurs années, vous pouvez créer un filtre pour que la compilation initiale de la PDT n'utilise que les données postérieures à une certaine date. Ce WHERE crée une 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 des données en SQL dans un code temporel, puis lui attribuer un alias. Par exemple, la PDT incrémentale suivante utilise un incrément de 15 minutes basé sur text_column, qui correspond à des données de chaîne analysées en 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 code 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é en tant que période dans le groupe de dimensions event, vous pouvez utiliser event_minute15 comme clé d'incrément pour obtenir un incrément de 15 minutes pour la PDT.

Créer une table agrégée incrémentale

Pour créer un tableau cumulé incrémentiel, ajoutez increment_key et (facultatif) 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 temporelle. La dimension doit être définie dans la vue sur laquelle repose l'exploration de la table agrégée.

Par exemple, cette table agrégée est basée sur l'exploration accidents, qui est elle-même basée sur la vue accidents. La table agrégée est recréée par incréments d'une semaine (increment_key: event_week), en remontant deux semaines en arrière (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ément utilise la dimension event_week, qui est basée sur la période week du groupe de dimensions event. (Consultez la page de documentation sur le paramètre 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 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 de la PDT incrémentielle est 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. L'optimisation de la table source est fortement recommandée, 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 des dernières valeurs par Looker peut être lente et coûteuse.

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

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

Le tableau suivant répertorie les dialectes prenant en charge les tables PDT incrémentielles dans la dernière version de Looker :

Dialecte Compatibilité
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
Apache Druid 0.18+
Apache Hive 2.3+
Apache Hive 3.1.2+
Apache Spark 3+
ClickHouse
ClickHouse 26+
Cloudera Impala 3.1+
Cloudera Impala 3.1+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Dremio 26+ with Arrow Flight SQL
Exasol
Google BigQuery Legacy SQL
Google BigQuery Standard SQL
Google Cloud AlloyDB for PostgreSQL
Google Cloud PostgreSQL
Google Cloud SQL
Google Spanner
Greenplum
HyperSQL
IBM Netezza
MariaDB
Microsoft Azure PostgreSQL
Microsoft Azure SQL Database
Microsoft Azure Synapse Analytics
Microsoft SQL Server 2008+
Microsoft SQL Server 2012+
Microsoft SQL Server 2016
Microsoft SQL Server 2017+
MongoBI
MongoSQL
MySQL
MySQL 8.0.12+
Oracle
Oracle ADWC
PostgreSQL 9.5+
PostgreSQL pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica