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 basée sur le temps

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 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 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 de 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 granularité de la clé d'incrémentation) qui sont régénérées pour tenir compte des données tardives.

Le increment_key d'une PDT est indépendant du déclencheur de persistance de la PDT. Consultez la page de documentation sur les PDT incrémentales 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 tables PDT et les tables agrégées (qui sont un type de table PDT).

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

En outre, increment_key doit être :

  • Une heure absolue tronquée, comme le jour, le mois, l'année, le trimestre fiscal, etc. 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ément 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 de l'utilisateur ne fonctionnerait pas comme clé d'incrément, car il 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émentielle, 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 est basé le explore_source du PDT.

Par exemple, voici un fichier de vue pour une table PDT basée sur LookML, à l'aide du paramètre LookML explore_source. La 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 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 correspond en fait à la période de la dimension departure.date (Pour en savoir plus sur le fonctionnement des groupes de dimensions, consultez la page de documentation sur le paramètre dimension_group.) 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 d'affichage flights :

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

Créer une PDT incrémentielle basée sur SQL

Looker vous recommande d'utiliser des tables dérivées basées sur LookML (natives) 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 de manière inhérente 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 table PDT basée sur SQL incrémentielle, 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 s'appliquent pour transformer une table PDT basée sur SQL en table PDT incrémentielle :

  • Vous devez baser la clé d'incrément sur une dimension LookML basée sur le temps que vous définissez dans le fichier de vue de la PDT.
  • Vous devez fournir un filtre Liquid {% incrementcondition %} dans le 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 pour une PDT basée sur SQL qui est reconstruite 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 reconstruction (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. L'alias departure est attribué à la colonne.
  • Le fichier de vue de la 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 du tableau dérivé.
    • Le paramètre timeframes du groupe de dimensions inclut date comme période.
  • Le 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. (Pour en savoir plus sur le fonctionnement des groupes de dimensions, consultez la page de documentation sur le paramètre dimension_group.)
  • Le filtre Liquid {% incrementcondition %} est utilisé pour 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).
    • L'{% 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, 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, {% incrementcondition %} est flights.leaving_time. Étant donné que la clause FROM spécifie la table flights, {% 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ément. Dans cet exemple, la clé d'incrément est dep_date, une dimension définie par la colonne departure dans le PDT, qui est un alias de la colonne flights.leaving_time dans la base de données. Le filtre pointe donc 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 à de nombreuses années, vous pouvez créer un filtre pour que la création initiale de la PDT n'utilise que les données postérieures à 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 dans SQL et les convertir en code temporel, puis leur attribuer un alias. Par exemple, la PDT incrémentielle 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 du groupe de dimensions sql, 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é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 agrégé incrémentiel, 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 basée sur le temps. 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 basée sur la vue accidents dans ce cas. La table agrégée est reconstruite par incréments d'une semaine (increment_key: event_week), sur 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ément 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 le paramètre dimension_group.) 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 l'augmentation de table PDT est optimisée pour les requêtes temporelles. Plus précisément, la colonne basée sur le temps utilisée pour la clé d'incrément doit avoir une stratégie d'optimisation, telle que partitionnement, sortkeys, indexes 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 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 PDT incrémentielles dans votre projet Looker, votre dialecte de base de données doit prendre en charge 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+
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 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
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