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 des dialectes spécifiques

Définition

Vous pouvez créer des augmentations de tables PDT incrémentielles dans votre projet si votre dialecte les prend en charge. Une augmentation de table PDT est une table dérivée persistante (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. Pour en savoir plus, consultez la page de documentation sur les augmentations de tables PDT.

increment_key est le paramètre qui transforme une table PDT en augmentation de table PDT en spécifiant l'incrément de temps pour lequel les données à jour doivent être interrogées et ajoutées à la table 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 granularité de la clé d'incrémentation) qui sont régénérées pour représenter des données tardives.

La increment_key d'une table PDT est indépendante du déclencheur de persistance de la table PDT. Pour obtenir des exemples de scénarios présentant l'interaction de increment_key, increment_offset et la stratégie de persistance, consultez la page de documentation sur les augmentations de tables PDT.

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

La increment_key doit spécifier une dimension LookML temporelle :

De plus, la increment_key doit être :

  • une heure absolue tronquée, telle que le jour, le mois, l'année, le trimestre fiscal, etc. Les périodes telles que le jour de la semaine ne sont pas prises en charge.
  • un 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 comportent également l'horodatage le plus récent. Un horodatage tel que l'anniversaire de l'utilisateur ne fonctionnerait pas comme clé d'incrémentation, car un horodatage d'anniversaire n'augmente pas de manière fiable avec les nouveaux utilisateurs ajoutés à la table.

Créer une augmentation de table PDT basée sur LookML

Pour transformer une table PDT basée sur LookML (native) en augmentation de table PDT, 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 la table PDTexplore_source est basée.

Voici, par exemple, un fichier d'affichage pour une table PDT basée sur LookML, à l'aide du paramètre LookML explore_source. La table PDT est créée à partir de l'exploration flights, qui dans ce cas est basée 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. Après cela, la table 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 temporelle du groupe de dimensions departure. Pour une présentation du fonctionnement des groupes de dimensions, consultez la page relative au paramètre dimension_group de la documentation. Le groupe de dimensions et la période sont tous deux définis par la vue flights, qui est la explore_source de cette table PDT. Voici comment le groupe de dimensions departure est défini dans le fichier d'affichage flights :

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

Créer une augmentation de table PDT basée sur SQL

Looker vous suggère d'utiliser des tables dérivées basées sur LookML (natives) comme base pour les augmentations de tables PDT, plutôt que des tables dérivées basées sur SQL. Les tables dérivées natives gèrent de manière inhérente la logique complexe requise pour les augmentations de tables PDT. Les tables 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 augmentation de table PDT basée sur SQL, utilisez increment_key et (facultativement) increment_offset comme vous le feriez avec une table PDT basée sur LookML. Toutefois, comme les tables PDT basées sur SQL ne sont pas basées sur des fichiers de vue LookML, des exigences supplémentaires sont nécessaires pour transformer une table PDT basée sur SQL en augmentation de table PDT :

  • Vous devez baser la clé d'incrémentation sur une dimension LookML temporelle que vous définissez dans le fichier d'affichage de la table PDT.
  • Vous devez fournir un {% incrementcondition %} filtre Liquid dans la table PDT pour connecter la clé d'incrémentation à la colonne temporelle de la base de données sur laquelle la clé d'incrémentation 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 %}

Voici, par exemple, le fichier de vue d'une table PDT basée sur SQL qui est régénérée en augmentations d'une journée (increment_key: "dep_date"), où les données des trois derniers jours seront ajoutées à la table lors de sa régénération (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 à 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 d'affichage de la table PDT définit un groupe de dimensions appelé dep.
    • Le paramètre sql du groupe de dimensions indique que le groupe de dimensions est basé sur la colonne departure de la table dérivée.
    • Le paramètre timeframes du groupe de dimensions inclut date comme période.
  • La table dérivée increment_key utilise la dimension dep_date, qui est une dimension basée sur la période date du groupe de dimensions dep. Pour une présentation du fonctionnement des groupes de dimensions, consultez la page relative au paramètre dimension_group de la documentation.
  • Le filtre Liquid {% incrementcondition %} est utilisé pour connecter la clé d'incrémentation à la colonne flights.leaving_time de la base de données.
    • Le {% incrementcondition %} doit spécifier le nom d'une colonne TIMESTAMP dans votre base de données (ou il doit être évalué comme une colonne TIMESTAMP dans votre base de données).
    • Le {% incrementcondition %} doit être évalué par rapport à ce qui est disponible dans la clause FROM qui définit votre table PDT, comme les colonnes de la table spécifiée dans la clause FROM. Le {% incrementcondition %} ne peut pas faire référence au résultat de l'instruction SELECT, comme un alias qui a été attribué à une colonne dans l'instruction SQL, ou le nom d'une dimension basée sur la colonne. Dans cet exemple, le {% incrementcondition %} est flights.leaving_time. Étant donné que la clause FROM spécifie la table flights, le {% incrementcondition %} peut faire référence aux colonnes de la table flights.
    • Le {% 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émentation est dep_date, une dimension définie par la colonne departure de la table PDT, qui est un alias de la colonne flights.leaving_time de la base de données. Par conséquent, le filtre pointe vers flights.leaving_time :
WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

Vous pouvez ajouter à la clause WHERE pour créer d'autres filtres. Par exemple, si la table de base de données remonte à de nombreuses années, vous pouvez créer un filtre afin que la création initiale de la table PDT n'utilise que les données postérieures à une certaine date. Ce WHERE crée une table 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'augmentation de table PDT 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 SQL dans la définition sql du groupe de dimensions, mais vous devez utiliser l'expression SQL dans la clause WHERE. Ensuite, comme minute15 a été configuré comme période dans le groupe de dimensions event, vous pouvez utiliser event_minute15 comme clé d'incrémentation pour obtenir un incrément de 15 minutes pour la table PDT.

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

Pour créer un tableau cumulé incrémental, ajoutez increment_key et (facultativement) 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 l'exploration de la table agrégée est basée.

Par exemple, ce tableau cumulé est basé sur l'exploration accidents, qui dans ce cas est basée sur la vue accidents. La table agrégée est régénérée en augmentations 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émentation utilise la dimension event_week, qui est basée sur la période week timeframe du groupe de dimensions event. Pour une présentation du fonctionnement des groupes de dimensions, consultez la page relative au paramètre dimension_group de la documentation. Le groupe de dimensions et la période sont tous deux définis par 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 l'augmentation de table PDT est optimisée pour les requêtes temporelles. En particulier, la colonne temporelle utilisée pour la clé d'incrémentation doit avoir une stratégie d'optimisation, comprenant par exemple un partitionnement, des clés de tri, des index, ou toute stratégie d'optimisation prise en charge par 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 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 être compatible avec les commandes LDD (langage de définition de données) qui permettent de supprimer et d'insérer des lignes.

Le tableau suivant répertorie les dialectes prenant en charge les augmentations de tables PDT 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
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+
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