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.

Tables dérivées dans Looker

Dans Looker, une table dérivée est une requête dont les résultats sont utilisés comme s'il s'agissait d'une table réelle de la base de données.

Par exemple, vous pouvez avoir une table de base de données appelée orders qui comporte de nombreuses colonnes. Vous souhaitez calculer certaines métriques agrégées au niveau du client, comme le nombre de commandes passées par chaque client ou le moment auquel chaque client a passé sa première commande. À l'aide d'une table dérivée native ou d'une table dérivée basée sur SQL, vous pouvez créer une table de base de données nommée customer_order_summary qui inclut ces métriques.

Vous pouvez ensuite travailler avec la table dérivée customer_order_summary comme s'il s'agissait de n'importe quelle autre table de la base de données.

Pour connaître les cas d'utilisation courants des tables dérivées, consultez Livres de recettes Looker: tirer le meilleur parti des tables dérivées dans Looker.

Tables dérivées natives et tables dérivées SQL

Pour créer une table dérivée dans votre projet Looker, utilisez le paramètre derived_table sous un paramètre view. Dans le paramètre derived_table, vous pouvez définir la requête pour la table dérivée de l'une des deux manières suivantes:

Dans le cas d'une table dérivée native, vous devez la définir à l'aide d'une requête LookML.
Dans le cas d'une table dérivée basée sur SQL, vous devez la définir à l'aide d'une requête SQL.

Par exemple, les fichiers de vue suivants montrent comment utiliser LookML pour créer une vue à partir d'une table dérivée customer_order_summary. Les deux versions de LookML illustrent comment créer des tables dérivées équivalentes en utilisant LookML ou SQL pour définir la requête pour la table dérivée :

La table dérivée native définit la requête avec LookML dans le paramètre explore_source. Dans cet exemple, la requête est basée sur une vue orders existante, définie dans un fichier distinct qui n'est pas illustré dans cet exemple. La requête explore_source de la table dérivée native ajoute les champs customer_id, first_order et total_amount du fichier de vue orders.
La table dérivée basée sur SQL définit la requête à l'aide de SQL dans le paramètre sql. Dans cet exemple, la requête SQL est une requête directe de la table orders de la base de données.

Version de la table dérivée native

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      column: customer_id {
        field: orders.customer_id
      }
      column: first_order {
        field: orders.first_order
      }
      column: total_amount {
        field: orders.total_amount
      }
    }
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

Version de la table dérivée basée sur SQL

view: customer_order_summary {
  derived_table: {
    sql:
      SELECT
        customer_id,
        MIN(DATE(time)) AS first_order,
        SUM(amount) AS total_amount
      FROM
        orders
      GROUP BY
        customer_id ;;
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

Les deux versions créent une vue appelée customer_order_summary, basée sur la table orders et contenant les colonnes customer_id, first_order, et total_amount.

À l'exception du paramètre derived_table et de ses sous-paramètres, cette vue customer_order_summary fonctionne comme n'importe quel autre fichier de vue. Que vous définissiez la requête de la table dérivée avec LookML ou SQL, vous pouvez créer des mesures et dimensions LookML basées sur les colonnes de la table dérivée.

Une fois que vous avez défini votre table dérivée, vous pouvez l'utiliser comme n'importe quelle autre table dans votre base de données.

Tables dérivées natives

Les tables dérivées natives sont basées sur des requêtes que vous définissez en utilisant les termes LookML. Pour créer une table dérivée native, utilisez le paramètre explore_source dans le paramètre derived_table d'un paramètre view. Vous créez les colonnes de votre table dérivée native en vous référant aux dimensions et mesures LookML dans votre modèle. Consultez le fichier de vue Tableau dérivée native dans l'exemple précédent.

Comparées aux tables dérivées basées sur SQL, les tables dérivées natives sont beaucoup plus faciles à lire et à comprendre lors de la modélisation des données.

Consultez la page de documentation Créer des tables dérivées natives pour plus de détails sur la création de tables dérivées natives.

Tables dérivées basées sur SQL

Pour créer une table dérivée basée sur SQL, vous devez définir une requête SQL, en créant des colonnes dans la table à l'aide d'une requête SQL. Vous ne pouvez pas faire référence à des dimensions et mesures LookML dans une table dérivée basée sur SQL. Reportez-vous au fichier de vue Tableau dérivée basée sur SQL dans l'exemple précédent.

Le plus souvent, vous définissez la requête SQL à l'aide du paramètre sql dans le paramètre derived_table d'un paramètre view.

Un raccourci utile pour créer des requêtes basées sur SQL dans Looker consiste à utiliser SQL Runner pour créer la requête SQL et la transformer en définition de table dérivée.

Certains cas particuliers ne permettent pas l'utilisation du paramètre sql. Dans ce cas, Looker prend en charge les paramètres suivants afin de définir une requête SQL pour les tables dérivées persistantes (PDT):

create_process: lorsque vous utilisez le paramètre sql pour une table PDT, Looker encapsule en arrière-plan l'instruction CREATE TABLE LDD (langage de définition de données) CREATE TABLE du dialecte autour de votre requête pour créer la table PDT à partir de votre requête SQL. Certains dialectes ne sont pas compatibles avec une instruction SQL CREATE TABLE en une seule étape. Pour ces dialectes, vous ne pouvez pas créer de table PDT avec le paramètre sql. À la place, vous pouvez utiliser le paramètre create_process pour créer une table PDT en plusieurs étapes. Consultez la page de documentation du paramètre create_process pour en savoir plus et obtenir des exemples.
sql_create: si votre cas d'utilisation nécessite des commandes LDD personnalisées et que votre dialecte est compatible avec le LDD (par exemple, la prédiction Google BigQuery ML), vous pouvez utiliser le paramètre sql_create pour créer une table PDT au lieu du paramètre sql. Consultez la page de documentation de sql_create pour en savoir plus et obtenir des exemples.

Que vous utilisiez le paramètre sql, create_process ou sql_create, vous définissez dans tous ces cas la table dérivée à l'aide d'une requête SQL. Ces tables sont donc toutes considérées comme des tables dérivées basées sur SQL.

Lorsque vous définissez une table dérivée basée sur SQL, assurez-vous de donner à chaque colonne un alias propre à l'aide de AS. En effet, vous devrez référencer les noms de colonnes de votre ensemble de résultats dans vos dimensions (${TABLE}.first_order, par exemple). C'est pourquoi l'exemple précédent utilise MIN(DATE(time)) AS first_order au lieu de MIN(DATE(time)) simplement.

Tables dérivées temporaires et persistantes

Outre la distinction entre les tables dérivées natives et les tables dérivées basées sur SQL, il existe une autre distinction entre une table dérivée temporaire, qui n'est pas écrite dans la base de données, et une table dérivée persistante (PDT) qui est écrite dans un schéma de votre base de données.

Les tables dérivées natives et tables dérivées basées sur SQL peuvent être temporaires ou persistantes.

Tables dérivées temporaires

Les tables dérivées présentées précédemment sont des exemples de tables dérivées temporaires. Elles sont temporaires, car aucune stratégie de persistance n'est définie dans le paramètre derived_table.

Les tables dérivées temporaires ne sont pas écrites sur la base de données. Lorsqu'un utilisateur exécute une requête d'exploration impliquant une ou plusieurs tables dérivées, Looker construit une requête SQL en utilisant une combinaison spécifique au dialecte du SQL pour la ou les tables dérivées, ainsi que les champs, jointures et valeurs de filtre demandés. Si la combinaison a été exécutée auparavant et que les résultats se trouvent toujours dans le cache, Looker utilise les résultats mis en cache. Consultez la page de documentation Mettre en cache des requêtes pour en savoir plus sur la mise en cache des requêtes dans Looker.

Dans le cas contraire, si Looker ne peut pas utiliser les résultats mis en cache, il doit exécuter une nouvelle requête sur votre base de données chaque fois qu'un utilisateur demande des données à une table dérivée temporaire. C'est pourquoi vous devez vous assurer que vos tables dérivées temporaires sont performantes et ne surchargeront pas votre base de données. Si l'exécution de la requête prend un certain temps, une PDT constitue souvent une meilleure option.

Dialectes de base de données pris en charge pour les tables dérivées temporaires

Pour que Looker prenne en charge les tables dérivées dans votre projet, votre dialecte de base de données doit également les prendre en charge. Le tableau suivant indique les dialectes prenant en charge les tables dérivées dans la dernière version de Looker:

Dialecte	Compatible ?
Avalanche d'Actian	Oui
Amazon Athena	Oui
Amazon Aurora MySQL	Oui
Amazon Redshift	Oui
Apache Druid	Oui
Apache Druid 0.13 et versions ultérieures	Oui
Apache Druid 0.18 et versions ultérieures	Oui
Apache Hive 2.3 et versions ultérieures	Oui
Apache Hive 3.1.2 et versions ultérieures	Oui
Apache Spark 3 et versions ultérieures	Oui
ClickHouse	Oui
Cloudera Impala 3.1+	Oui
Cloudera Impala 3.1+ avec pilote natif	Oui
Cloudera Impala avec Native Driver	Oui
DataVirtuality	Oui
Databricks	Oui
Denodo 7	Oui
Denodo 8	Oui
Dremio	Oui
Dremio 11 et versions ultérieures	Oui
Exasol	Oui
Feu	Oui
Ancien SQL de Google BigQuery	Oui
SQL standard Google BigQuery	Oui
Google Cloud PostgreSQL	Oui
Google Cloud SQL	Oui
Google Spanner	Oui
Greenplum	Oui
HyperSQL	Oui
IBM Netezza	Oui
MariaDB	Oui
Microsoft Azure PostgreSQL	Oui
Base de données Microsoft Azure SQL	Oui
Microsoft Azure Synapse Analytics	Oui
Microsoft SQL Server 2008 et versions ultérieures	Oui
Microsoft SQL Server 2012 et versions ultérieures	Oui
Microsoft SQL Server 2016	Oui
Microsoft SQL Server 2017 et versions ultérieures	Oui
MongoBI	Oui
MySQL	Oui
MySQL 8.0.12 et versions ultérieures	Oui
Oracle	Oui
Oracle ADWC	Oui
PostgreSQL 9.5 et versions ultérieures	Oui
PostgreSQL version antérieure à 9.5	Oui
PrestoDB	Oui
PrestoSQL	Oui
SAP HANA 2 et versions ultérieures	Oui
SingleStore	Oui
SingleStore 7 et versions ultérieures	Oui
Snowflake	Oui
Teradata	Oui
Trino	Oui
Vecteur	Oui
Vertica	Oui

Tables dérivées persistantes

Une table dérivée persistante (PDT) est une table dérivée qui est écrite dans un schéma entièrement nouveau de votre base de données et régénérée selon la planification que vous spécifiez avec une stratégie de persistance.

Une table PDT peut être une table dérivée native ou une table dérivée basée sur SQL.

Exigences concernant les tables PDT

Pour utiliser des tables dérivées persistantes (PDT) dans votre projet Looker, vous avez besoin des éléments suivants:

Un dialecte de base de données qui prend en charge les PDT. Reportez-vous à la section Dialectes de base de données pris en charge pour les tables PDT plus loin sur cette page pour obtenir la liste des dialectes qui prennent en charge les tables dérivées persistantes basées sur SQL et les tables dérivées natives persistantes.
Un schéma entièrement nouveau sur votre base de données. Il peut s'agir de n'importe quel schéma sur votre base de données mais nous vous recommandons de créer un nouveau schéma qui sera utilisé uniquement à cette fin. Votre administrateur de base de données doit configurer le schéma avec une autorisation d'écriture pour l'utilisateur de la base de données Looker.
Une connexion Looker configurée avec l'option Activer les tables PDT activée Elle est généralement configurée lors de la configuration initiale de votre connexion Looker (consultez la page de documentation sur les dialectes Looker pour obtenir des instructions concernant votre dialecte de base de données), mais vous pouvez également activer les tables PDT pour votre connexion après la configuration initiale.

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

Pour que Looker prenne en charge les tables dérivées persistantes (PDT) dans votre projet Looker, votre dialecte de base de données doit également les prendre en charge.

Pour prendre en charge tout type de tables PDT (basées sur LookML ou SQL), le dialecte doit permettre les écritures dans la base de données, entre autres exigences. Certaines configurations de bases de données en lecture seule n'autorisent pas la persistance (il s'agit le plus souvent de bases de données de répliques à chaud Postgres). Dans ce cas, vous pouvez utiliser des tables dérivées temporaires à la place.

Le tableau suivant présente les dialectes compatibles avec les tables dérivées basées sur SQL persistantes dans la dernière version de Looker:

Dialecte	Compatible ?
Avalanche d'Actian	Oui
Amazon Athena	Oui
Amazon Aurora MySQL	Oui
Amazon Redshift	Oui
Apache Druid	Non
Apache Druid 0.13 et versions ultérieures	Non
Apache Druid 0.18 et versions ultérieures	Non
Apache Hive 2.3 et versions ultérieures	Oui
Apache Hive 3.1.2 et versions ultérieures	Oui
Apache Spark 3 et versions ultérieures	Oui
ClickHouse	Non
Cloudera Impala 3.1+	Oui
Cloudera Impala 3.1+ avec pilote natif	Oui
Cloudera Impala avec Native Driver	Oui
DataVirtuality	Non
Databricks	Oui
Denodo 7	Non
Denodo 8	Non
Dremio	Non
Dremio 11 et versions ultérieures	Non
Exasol	Oui
Feu	Non
Ancien SQL de Google BigQuery	Oui
SQL standard Google BigQuery	Oui
Google Cloud PostgreSQL	Oui
Google Cloud SQL	Oui
Google Spanner	Non
Greenplum	Oui
HyperSQL	Non
IBM Netezza	Oui
MariaDB	Oui
Microsoft Azure PostgreSQL	Oui
Base de données Microsoft Azure SQL	Oui
Microsoft Azure Synapse Analytics	Oui
Microsoft SQL Server 2008 et versions ultérieures	Oui
Microsoft SQL Server 2012 et versions ultérieures	Oui
Microsoft SQL Server 2016	Oui
Microsoft SQL Server 2017 et versions ultérieures	Oui
MongoBI	Non
MySQL	Oui
MySQL 8.0.12 et versions ultérieures	Oui
Oracle	Oui
Oracle ADWC	Oui
PostgreSQL 9.5 et versions ultérieures	Oui
PostgreSQL version antérieure à 9.5	Oui
PrestoDB	Oui
PrestoSQL	Oui
SAP HANA 2 et versions ultérieures	Oui
SingleStore	Oui
SingleStore 7 et versions ultérieures	Oui
Snowflake	Oui
Teradata	Oui
Trino	Oui
Vecteur	Oui
Vertica	Oui

Pour prendre en charge les tables dérivées natives persistantes (qui ont des requêtes basées sur LookML), le dialecte doit également prendre en charge une fonction LDD CREATE TABLE. Voici une liste des dialectes prenant en charge les tables dérivées natives (basées sur LookML) persistantes dans la dernière version de Looker:

Dialecte	Compatible ?
Avalanche d'Actian	Oui
Amazon Athena	Oui
Amazon Aurora MySQL	Oui
Amazon Redshift	Oui
Apache Druid	Non
Apache Druid 0.13 et versions ultérieures	Non
Apache Druid 0.18 et versions ultérieures	Non
Apache Hive 2.3 et versions ultérieures	Oui
Apache Hive 3.1.2 et versions ultérieures	Oui
Apache Spark 3 et versions ultérieures	Oui
ClickHouse	Non
Cloudera Impala 3.1+	Oui
Cloudera Impala 3.1+ avec pilote natif	Oui
Cloudera Impala avec Native Driver	Oui
DataVirtuality	Non
Databricks	Oui
Denodo 7	Non
Denodo 8	Non
Dremio	Non
Dremio 11 et versions ultérieures	Non
Exasol	Oui
Feu	Non
Ancien SQL de Google BigQuery	Oui
SQL standard Google BigQuery	Oui
Google Cloud PostgreSQL	Oui
Google Cloud SQL	Non
Google Spanner	Non
Greenplum	Oui
HyperSQL	Non
IBM Netezza	Oui
MariaDB	Oui
Microsoft Azure PostgreSQL	Oui
Base de données Microsoft Azure SQL	Oui
Microsoft Azure Synapse Analytics	Oui
Microsoft SQL Server 2008 et versions ultérieures	Oui
Microsoft SQL Server 2012 et versions ultérieures	Oui
Microsoft SQL Server 2016	Oui
Microsoft SQL Server 2017 et versions ultérieures	Oui
MongoBI	Non
MySQL	Oui
MySQL 8.0.12 et versions ultérieures	Oui
Oracle	Oui
Oracle ADWC	Oui
PostgreSQL 9.5 et versions ultérieures	Oui
PostgreSQL version antérieure à 9.5	Oui
PrestoDB	Oui
PrestoSQL	Oui
SAP HANA 2 et versions ultérieures	Oui
SingleStore	Oui
SingleStore 7 et versions ultérieures	Oui
Snowflake	Oui
Teradata	Oui
Trino	Oui
Vecteur	Oui
Vertica	Oui

Augmentation de la génération de tables PDT

Une PDT incrémentielle est une table dérivée persistante (PDT) créée par Looker en ajoutant de nouvelles données à la table, au lieu de régénérer la table dans son intégralité.

Si votre dialecte prend en charge l'augmentation de tables PDT et que votre table PDT utilise une stratégie de persistance basée sur des déclencheurs (datagroup_trigger, sql_trigger_value ou interval_trigger), vous pouvez définir la table PDT en tant qu'augmentation de tables PDT.

Pour en savoir plus, consultez la page de documentation sur l'augmentation de tables PDT.

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 également les prendre en charge. Le tableau suivant indique les dialectes prenant en charge les augmentations de tables PDT dans la dernière version de Looker:

Dialecte	Compatible ?
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 et versions ultérieures	Non
Apache Hive 2.3 et versions ultérieures	Non
Apache Hive 3.1.2 et versions ultérieures	Non
Apache Spark 3 et versions ultérieures	Non
ClickHouse	Non
Cloudera Impala 3.1+	Non
Cloudera Impala 3.1+ 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
Feu	Non
Ancien SQL de Google BigQuery	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
Base de données Microsoft Azure SQL	Non
Microsoft Azure Synapse Analytics	Oui
Microsoft SQL Server 2008 et versions ultérieures	Non
Microsoft SQL Server 2012 et versions ultérieures	Non
Microsoft SQL Server 2016	Non
Microsoft SQL Server 2017 et versions ultérieures	Non
MongoBI	Non
MySQL	Oui
MySQL 8.0.12 et versions ultérieures	Oui
Oracle	Non
Oracle ADWC	Non
PostgreSQL 9.5 et versions ultérieures	Oui
PostgreSQL version antérieure à 9.5	Oui
PrestoDB	Non
PrestoSQL	Non
SAP HANA 2 et versions ultérieures	Non
SingleStore	Non
SingleStore 7 et versions ultérieures	Non
Snowflake	Oui
Teradata	Non
Trino	Non
Vecteur	Non
Vertica	Oui

Création de tables PDT

Pour transformer une table dérivée en table dérivée persistante (PDT), vous devez définir une stratégie de persistance pour la table. Pour optimiser les performances, vous devez également ajouter une stratégie d'optimisation.

Stratégies de persistance

La persistance d'une table dérivée peut être gérée par Looker ou, pour les dialectes compatibles avec les vues matérialisées, par votre base de données à l'aide de vues matérialisées.

Pour rendre une table dérivée persistante, ajoutez l'un des paramètres suivants à la définition de derived_table:

Paramètres de persistance gérés par Looker :
Paramètres de persistance gérés par la base de données :
- materialized_view: yes

Avec les stratégies de persistance basées sur des déclencheurs (datagroup_trigger, sql_trigger_value et interval_trigger), Looker maintient la table PDT dans la base de données jusqu'à ce qu'elle soit déclenchée en vue d'une recompilation. Une fois la PDT déclenchée, Looker la régénère pour remplacer la version précédente. Ainsi, avec les PDT basées sur des éléments déclencheurs, vos utilisateurs n'auront pas à attendre que la PDT soit générée pour obtenir des réponses pour les requêtes d'exploration issues de la PDT.

`datagroup_trigger`

Les groupes de données constituent la méthode la plus flexible pour créer de la persistance. Si vous avez défini un groupe de données avec sql_trigger ou interval_trigger, vous pouvez utiliser le paramètre datagroup_trigger pour initier la recompilation de vos tables dérivées persistantes (PDT).

Looker maintient la table PDT dans la base de données jusqu'au déclenchement de son groupe de données. Une fois le groupe de données déclenché, Looker régénère la table PDT pour remplacer la version précédente. Ainsi, dans la plupart des cas, les utilisateurs n'auront pas à attendre que la table PDT soit générée. Si un utilisateur demande des données à la table PDT pendant sa création et que les résultats de la requête ne sont pas dans le cache, Looker renvoie les données de la table PDT existante jusqu'à ce que la nouvelle table soit générée. Pour en savoir plus sur les groupes de données, consultez la section Mettre en cache des requêtes.

Consultez la section sur le régénérateur Looker pour en savoir plus sur la façon dont il génère des tables PDT.

`sql_trigger_value`

Le paramètre sql_trigger_value déclenche la régénération d'une table dérivée persistante (PDT) en fonction d'une instruction SQL que vous fournissez. Si le résultat de l'instruction SQL est différent de la valeur précédente, la table PDT est régénérée. Sinon, la table PDT existante est maintenue dans la base de données. Ainsi, dans la plupart des cas, les utilisateurs n'auront pas à attendre que la table PDT soit générée. Si un utilisateur demande des données à la table PDT pendant sa création et que les résultats de la requête ne sont pas dans le cache, Looker renvoie les données de la table PDT existante jusqu'à ce que la nouvelle table soit générée.

Consultez la section sur le régénérateur Looker pour en savoir plus sur la façon dont il génère des tables PDT.

`interval_trigger`

Le paramètre interval_trigger déclenche la régénération d'une table dérivée persistante (PDT) en fonction d'un intervalle de temps que vous fournissez, tel que "24 hours" ou "60 minutes". Comme pour le paramètre sql_trigger, cela signifie que la table PDT est généralement prédéfinie lorsque vos utilisateurs l'interrogent. Si un utilisateur demande des données à la table PDT pendant sa création et que les résultats de la requête ne sont pas dans le cache, Looker renvoie les données de la table PDT existante jusqu'à ce que la nouvelle table soit générée.

`persist_for`

Une autre option consiste à utiliser le paramètre persist_for pour définir la durée pendant laquelle la table dérivée doit être stockée avant d'être marquée comme expirée, afin qu'elle ne soit plus utilisée pour les requêtes et qu'elle soit supprimée de la base de données.

Une table dérivée persistante persist_for est créée lorsqu&PDT;un utilisateur exécute une requête sur celle-ci pour la première fois. Looker maintient ensuite la table PDT dans la base de données pendant la durée spécifiée dans le paramètre persist_for de la table PDT. Si un utilisateur interroge la table PDT dans le délai de persist_for, Looker utilise si possible les résultats mis en cache, ou exécute la requête sur la table PDT.

Après le délai persist_for, Looker efface la table PDT de votre base de données. La table PDT sera recréée la prochaine fois qu'un utilisateur l'interrogera, ce qui signifie que cette requête devra attendre la recompilation.

Les tables PDT qui utilisent persist_for ne sont pas automatiquement recréées par le régénérateur de Looker, sauf dans le cas d'une cascade de dépendances de tables PDT. Lorsqu'une table persist_for fait partie d'une cascade de dépendances avec des tables PDT basées sur des déclencheurs (PDT utilisant la stratégie de persistance datagroup_trigger, interval_trigger ou sql_trigger_value), le régénérateur surveille et régénère la table persist_for afin de régénérer les autres tables de la cascade. Consultez la section Comment Looker crée des tables dérivées en cascade sur cette page.

`materialized_view: yes`

Les vues matérialisées vous permettent d'exploiter la fonctionnalité de votre base de données pour conserver les tables dérivées dans votre projet Looker. Si votre dialecte de base de données accepte les vues matérialisées et que votre connexion à Looker est configurée avec l'option Activer les tables PDT activée, vous pouvez créer une vue matérialisée en spécifiant materialized_view: yes pour une table dérivée. Les vues matérialisées sont compatibles avec les tables dérivées natives et les tables dérivées basées sur SQL.

À l'instar d'une table dérivée persistante (PDT), une vue matérialisée est un résultat de requête stocké sous forme de table dans le schéma entièrement nouveau de votre base de données. La principale différence entre une PDT et une vue matérialisée se situe au niveau de l'actualisation des tables :

Pour les PDT, la stratégie de persistance est définie dans Looker, et la persistance est gérée par Looker.
Pour les vues matérialisées, la base de données est responsable de l'entretien et de l'actualisation des données de la table.

Pour cette raison, la fonctionnalité vue matérialisée nécessite une connaissance avancée de votre dialecte et de ses caractéristiques. Dans la plupart des cas, votre base de données actualisera la vue matérialisée à chaque fois qu'elle détectera de nouvelles données dans les tables interrogées par la vue matérialisée. Les vues matérialisées sont optimales pour les scénarios requérant des données en temps réel.

Consultez la page de documentation sur le paramètre materialized_view pour en savoir plus sur la prise en charge des dialectes, les conditions requises et les considérations importantes.

Stratégies d'optimisation

Les tables dérivées persistantes (PDT) étant stockées dans votre base de données, vous devez les optimiser en utilisant les stratégies suivantes, selon votre dialecte:

Par exemple, pour rendre l'exemple de table dérivée persistante, vous pouvez le configurer de sorte qu'il se recompile lorsque le groupe de données orders_datagroup se déclenche, et ajouter des index à la fois sur customer_id et first_order, comme ceci:

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      ...
    }
    datagroup_trigger: orders_datagroup
    indexes: ["customer_id", "first_order"]
  }
}

Si vous n'ajoutez pas d'index (ni équivalent pour votre dialecte), Looker vous invite à le faire pour améliorer les performances des requêtes.

Cas d'utilisation des tables PDT

Les tables dérivées persistantes (PDT) sont utiles car elles peuvent améliorer les performances d'une requête en conservant les résultats de la requête dans une table.

En règle générale, les développeurs doivent essayer de modéliser des données sans utiliser de tables PDT tant que cela n'est pas absolument nécessaire.

Dans certains cas, les données peuvent être optimisées par d'autres moyens. Par exemple, l'ajout d'un index ou la modification du type de données d'une colonne peut résoudre un problème sans qu'il soit nécessaire de créer une table PDT. Veillez à analyser les plans d'exécution des requêtes lentes à l'aide de l'outil Expliquer de SQL Runner.

Outre la réduction de la durée des requêtes et de la charge de la base de données sur les requêtes fréquemment exécutées, il existe plusieurs autres cas d'utilisation des tables PDT, notamment:

Tester les optimisations
Préjoindre ou agréger des données

Vous pouvez également utiliser une table PDT pour définir une clé primaire lorsqu'il n'existe aucun moyen raisonnable d'identifier une ligne unique d'une table en tant que clé primaire.

Utilisation des tables PDT pour tester les optimisations

Vous pouvez utiliser les tables PDT pour tester différentes options d'indexation, de distribution et d'optimisation, sans avoir besoin d'une aide importante de la part de vos développeurs DBA ou ETL.

Imaginons que vous ayez une table, mais que vous souhaitiez tester différents index. Votre code LookML initial pour la vue peut se présenter comme suit:

view: customer {
  sql_table_name: warehouse.customer ;;
}

Pour tester les stratégies d'optimisation, vous pouvez utiliser le paramètre indexes afin d'ajouter des index au LookML, comme ceci:

view: customer {
  # sql_table_name: warehouse.customer
  derived_table: {
    sql: SELECT * FROM warehouse.customer ;;
    persist_for: "8 hours"
    indexes: [customer_id, customer_name, salesperson_id]
  }
}

Interrogez la vue une fois pour générer la table PDT. Exécutez ensuite vos requêtes de test et comparez les résultats. Si vos résultats sont favorables, vous pouvez demander à votre équipe DBA ou ETL d'ajouter les indices à la table d'origine.

N'oubliez pas de modifier à nouveau votre code d'affichage pour supprimer la PDT.

Utiliser des tables PDT pour pré-joindre ou agréger des données

Il peut être utile de pré-joindre ou de pré-agréger des données afin d'ajuster l'optimisation des requêtes pour des volumes importants ou plusieurs types de données.

Par exemple, supposons que vous souhaitiez créer un rapport sur les clients par cohorte en fonction de la date à laquelle ils ont passé leur première commande. Cette requête peut être coûteuse à exécuter plusieurs fois chaque fois que les données sont nécessaires en temps réel. Cependant, vous pouvez calculer la requête une seule fois, puis réutiliser les résultats avec une PDT:

view: customer_order_facts {
  derived_table: {
    sql: SELECT
    c.customer_id,
    MIN(o.order_date) OVER (PARTITION BY c.customer_id) AS first_order_date,
    MAX(o.order_date) OVER (PARTITION BY c.customer_id) AS most_recent_order_date,
    COUNT(o.order_id) OVER (PARTITION BY c.customer_id) AS lifetime_orders,
    SUM(o.order_value) OVER (PARTITION BY c.customer_id) AS lifetime_value,
    RANK() OVER (PARTITION BY c.customer_id ORDER BY o.order_date ASC) AS order_sequence,
    o.order_id
    FROM warehouse.customer c LEFT JOIN warehouse.order o ON c.customer_id = o.customer_id
    ;;
    sql_trigger_value: SELECT CURRENT_DATE ;;
    indexes: [customer_id, order_id, order_sequence, first_order_date]
  }
}

Tables dérivées en cascade

Il est possible de référencer une table dérivée dans la définition d'une autre, créant ainsi une chaîne de tables dérivées en cascade ou des tables dérivées persistantes en cascade (PDT), selon le cas. Une table dérivée en cascade pourrait être une table, TABLE_D, qui dépend d'une autre table, TABLE_C, tandis que TABLE_C dépend de TABLE_B et TABLE_B dépend de TABLE_A.

Syntaxe pour référencer une table dérivée

Pour référencer une table dérivée dans une autre table dérivée, utilisez cette syntaxe :

`${derived_table_or_view_name.SQL_TABLE_NAME}`

Dans ce format, SQL_TABLE_NAME est une chaîne littérale. Par exemple, vous pouvez référencer la table dérivée clean_events avec cette syntaxe:

`${clean_events.SQL_TABLE_NAME}`

Vous pouvez utiliser la même syntaxe pour désigner une vue LookML. Là encore, dans ce cas, SQL_TABLE_NAME est une chaîne littérale.

Dans l'exemple suivant, la table PDT clean_events est créée à partir de la table events de la base de données. La table PDT clean_events exclut les lignes indésirables de la table de base de données events. Ensuite, une deuxième PDT est affichée ; la PDT event_summary est un résumé de la PDT clean_events. La table event_summary est régénérée chaque fois que de nouvelles lignes sont ajoutées à clean_events.

La table PDT event_summary et la table PDT clean_events sont des tables PDT en cascade, où event_summary dépend de clean_events (car event_summary est défini à l'aide de la table PDT clean_events). Cet exemple particulier pourrait être réalisé plus efficacement dans une seule table PDT, mais il est utile pour démontrer les références à une table dérivée.

view: clean_events {
  derived_table: {
    sql:
      SELECT *
      FROM events
      WHERE type NOT IN ('test', 'staff') ;;
    datagroup_trigger: events_datagroup
  }
}

view: events_summary {
  derived_table: {
    sql:
      SELECT
        type,
        date,
        COUNT(*) AS num_events
      FROM
        ${clean_events.SQL_TABLE_NAME} AS clean_events
      GROUP BY
        type,
        date ;;
    datagroup_trigger: events_datagroup
  }
}

Bien que cela ne soit pas toujours obligatoire, lorsque vous faites référence à une table dérivée de cette manière, il est souvent utile de créer un alias pour la table en utilisant le format suivant:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

L'exemple précédent donne le résultat suivant :

${clean_events.SQL_TABLE_NAME} AS clean_events

Il est judicieux d'utiliser un alias, car en arrière-plan, les tables PDT sont nommées dans la base de données avec de longs codes. Dans certains cas (en particulier avec les clauses ON), il est facile d'oublier que vous devez utiliser la syntaxe ${derived_table_or_view_name.SQL_TABLE_NAME} pour récupérer ce nom long. Un alias permet d'éviter ce type d'erreur.

Comment Looker génère des tables dérivées en cascade

Dans le cas de tables dérivées temporaires en cascade, si les résultats d'une requête d'un utilisateur ne sont pas mis en cache, Looker crée toutes les tables dérivées nécessaires à la requête. Si vous avez un TABLE_D dont la définition contient une référence à TABLE_C, alors TABLE_D est dépendant de TABLE_C. Cela signifie que si vous interrogez TABLE_D et que la requête ne se trouve pas dans le cache de Looker, Looker recréera TABLE_D. Mais d'abord, il doit recompiler TABLE_C.

Prenons maintenant un scénario de tables dérivées temporaires en cascade où TABLE_D dépend de TABLE_C, lui-même dépendant de TABLE_B, qui dépend de TABLE_A. Si Looker n'a pas de résultats valides pour une requête portant sur TABLE_C dans le cache, Looker génère toutes les tables dont il a besoin pour la requête. Looker va donc compiler TABLE_A, TABLE_B, puis TABLE_C:

Dans ce scénario, TABLE_A doit terminer la génération avant que Looker puisse commencer à générer TABLE_B, et ainsi de suite, jusqu'à ce que TABLE_C soit terminé et que Looker puisse fournir les résultats de la requête. (Étant donné que TABLE_D n'est pas nécessaire pour répondre à cette requête, Looker ne recompile pas TABLE_D pour le moment.)

Consultez la page de documentation du paramètre datagroup pour obtenir un exemple de scénario de tables PDT en cascade utilisant le même groupe de données.

La même logique de base s'applique aux tables PDT: Looker crée les tables nécessaires pour répondre à une requête, tout au long de la chaîne de dépendances. Mais avec les tables PDT, il arrive souvent que les tables existent déjà et qu'elles n'aient pas besoin d'être régénérées. Avec les requêtes utilisateur standards sur les tables PDT en cascade, Looker régénère les tables PDT dans la cascade uniquement s'il n'existe pas de version valide des tables PDT dans la base de données. Si vous voulez forcer la régénération de toutes les tables PDT d'une cascade, vous pouvez recréer manuellement les tables pour une requête par le biais d'une exploration.

Il est important de comprendre qu'en cas de cascade de tables PDT, une table PDT dépendante interroge la table PDT dont elle dépend. Cela est particulièrement important pour les tables PDT qui utilisent la stratégie persist_for. En règle générale, les tables PDT persist_for sont créées lorsqu'un utilisateur les interroge, restent dans la base de données jusqu'à ce que leur intervalle persist_for soit écoulé, puis ne sont recréées qu'après être interrogées par un utilisateur. Toutefois, si une table PDT persist_for fait partie d'une cascade avec des tables PDT basées sur des déclencheurs (PDT qui utilisent la stratégie de persistance datagroup_trigger, interval_trigger ou sql_trigger_value), la table PDT persist_for est essentiellement interrogée chaque fois que ses tables PDT dépendantes sont régénérées. Dans ce cas, la table PDT persist_for sera donc régénérée selon le calendrier des tables PDT qui en dépendent. Cela signifie que les tables PDT persist_for peuvent être affectées par la stratégie de persistance de leurs dépendances.

Régénération manuelle de tables persistantes pour une requête

Les utilisateurs peuvent sélectionner l'option Recompiler les tables dérivées et exécuter dans le menu d'une exploration pour remplacer les paramètres de persistance et recréer toutes les tables dérivées persistantes (PDT) et les tables agrégées requises pour la requête en cours dans l'exploration:

Cliquez sur le bouton "Explorer les actions" pour ouvrir le menu "Explorer", à partir duquel vous pouvez sélectionner "Recompiler les tables dérivées et exécuter".

Cette option n'est visible que par les utilisateurs disposant de l'autorisation develop, et uniquement après le chargement de la requête d'exploration.

L'option Recompiler les tables dérivées et exécuter régénère toutes les tables persistantes (toutes les tables PDT et les tables agrégées) requises pour répondre à la requête, quelle que soit leur stratégie de persistance. Cela inclut les tables agrégées et les tables PDT de la requête en cours, ainsi que les tables agrégées et les tables PDT référencées par les tables agrégées et les tables PDT de la requête en cours.

Dans le cas des PDT incrémentielles, l'option Recompiler les tables dérivées et exécuter déclenche la compilation d'un nouvel incrément. Avec les augmentations de tables PDT, un incrément inclut la période spécifiée dans le paramètre increment_key, ainsi que le nombre de périodes précédentes spécifiées dans le paramètre increment_offset, le cas échéant. Reportez-vous à la page de documentation sur l'augmentation de tables PDT pour obtenir des exemples de scénarios montrant comment les augmentations de tables PDT se compilent, en fonction de leur configuration.

Dans le cas de Tables PDT en cascade, cela signifie reconstruire toutes les tables dérivées dans la cascade, en commençant par le haut. Ce comportement est le même que lorsque vous interrogez une table dans une cascade de tables dérivées temporaires:

Si table_c dépend de table_b et table_b dépend de table_a, la reconstruction de table_c recompile d'abord table_a, puis table_b et enfin table_c.

Notez les points suivants concernant la recréation manuelle des tables dérivées:

Pour l'utilisateur qui lance l'opération Rebuild Derived Tables & Run (Recompiler les tables dérivées et exécuter les tables), la requête attendra la recompilation des tables avant de charger les résultats. Les requêtes des autres utilisateurs continueront d'utiliser les tables existantes. Une fois les tables persistantes régénérées, tous les utilisateurs s'en servent. Bien que ce processus soit conçu pour éviter d'interrompre les requêtes des autres utilisateurs lors de la recréation des tables, ces utilisateurs peuvent tout de même être affectés par la charge supplémentaire pesant sur votre base de données. Si le lancement d'une régénération pendant les heures de bureau risque de soumettre votre base de données à une pression inacceptable, vous devrez peut-être demander aux utilisateurs de ne pas régénérer certaines tables PDT ni agréger de tables pendant ces heures.
Si un utilisateur est en mode Développement et que l'exploration est basée sur une table de développement, l'opération Recompiler les tables dérivées et exécuter recompile la table de développement, et non la table de production, pour l'exploration. Toutefois, si l'exploration en mode Développement utilise la version de production d'une table dérivée, la table de production sera recompilée. Pour plus d'informations sur les tables de développement et les tables de production, consultez la section Tables persistantes en mode Développement.
Pour les instances hébergées par Looker, si la recompilation de la table dérivée prend plus d'une heure, la table ne sera pas recompilée correctement et la session du navigateur expirera. Pour en savoir plus sur les délais avant expiration qui peuvent affecter les processus Looker, consultez la section Délais d'expiration des requêtes et mise en file d'attente sur la page de documentation Paramètres d'administration – Requêtes.

Tables persistantes en mode Développement

Looker adopte des comportements spéciaux pour gérer les tables persistantes en mode Développement.

Si vous interrogez une table persistante en mode Développement sans modifier sa définition, Looker interroge la version de production de cette table. Si vous apportez une modification à la définition de la table, ce qui affecte ses données ou la façon dont celle-ci est interrogée, une nouvelle version de développement de la table sera créée la prochaine fois que vous interrogerez la table en mode Développement. Une table de développement de la sorte vous permet de tester les modifications sans déranger l'utilisateur final.

Quelles commandes entraînent la création d'une table de développement par Looker ?

Dans la mesure du possible, Looker utilise la table de production existante pour répondre aux requêtes, que vous soyez ou non en mode Développement. Cependant, dans certains cas, Looker ne peut pas utiliser de table de production pour les requêtes en mode Développement :

Si votre table persistante contient un paramètre qui réduit son ensemble de données pour fonctionner plus rapidement en mode Développement
Si vous avez apporté des modifications à la définition de votre table persistante qui affectent les données de la table

Looker créera une table de développement si vous êtes en mode Développement et que vous interrogez une table dérivée basée sur SQL définie à l'aide d'une clause WHERE conditionnelle avec des instructions if prod et if dev.

Pour les tables persistantes qui ne comportent pas de paramètre permettant de restreindre l'ensemble de données en mode Développement, Looker utilise la version de production de la table pour répondre aux requêtes en mode Développement, sauf si vous modifiez la définition de la table, puis que vous interrogez la table en mode Développement. Cela s'applique à toutes les modifications affectant les données dans la table ou la façon dont elle est interrogée.

Voici quelques exemples de modifications entraînant la création d'une version de développement d'une table persistante par Looker (Looker créera la table uniquement si vous interrogez la table après avoir apporté ces modifications) :

Modifier la requête sur laquelle repose la table persistante, telle que la modification du paramètre explore_source, sql, query, sql_create ou create_process dans la table persistante elle-même, ou dans toute table requise (dans le cas de tables dérivées en cascade)
Modification de la stratégie de persistance de la table, telle que la modification du paramètre datagroup_trigger, sql_trigger_value, interval_trigger ou persist_for de la table
Modifier le nom du paramètre view d'une table dérivée
Modifier la valeur increment_key ou increment_offset d'une PDT incrémentielle
Modifier le connection utilisé par le modèle associé

Pour les modifications qui ne modifient pas les données de la table ni n'affectent la façon dont Looker interroge la table, Looker ne crée pas de table de développement. Le paramètre publish_as_db_view est un bon exemple: en mode Développement, si vous modifiez uniquement le paramètre publish_as_db_view d'une table dérivée, Looker n'a pas besoin de recréer la table dérivée et ne créera donc pas de table de développement.

Durée de persistance des tables de développement

Quelle que soit la stratégie de persistance réelle des tables, Looker traite les tables persistantes de développement comme si elles disposaient d'une stratégie de persistance définie sur persist_for: "24 hours". Looker procède ainsi pour s'assurer que les tables de développement ne sont pas conservées plus d'une journée, car un développeur Looker peut interroger de nombreuses itérations d'une table pendant le développement et chaque fois qu'une nouvelle table de développement est créée. Pour éviter que les tables de développement n'encombrent la base de données, Looker applique la stratégie persist_for: "24 hours" pour s'assurer que les tables sont nettoyées fréquemment de la base de données.

Sinon, Looker crée des tables dérivées persistantes (PDT) et des tables agrégées en mode Développement de la même manière qu'il crée des tables persistantes en mode Production.

Si une table de développement est conservée dans votre base de données lorsque vous déployez des modifications sur une table PDT ou une table agrégée, Looker peut souvent utiliser la table de développement comme table de production. Ainsi, vos utilisateurs n'ont pas à attendre la création de la table lorsqu'ils interrogent la table.

Notez que, lorsque vous déployez vos modifications, vous devez peut-être régénérer la table pour qu'elle soit interrogée en production, en fonction de la situation :

Si vous avez interrogé la table en mode Développement depuis plus de 24 heures, la version de développement de la table est marquée comme expirée et ne sera pas utilisée pour les requêtes. Vous pouvez rechercher les tables PDT non compilées à l'aide de l'IDE Looker ou dans l'onglet Développement de la page Tables dérivées persistantes. Si vous disposez de tables PDT déconstruites, vous pouvez les interroger en mode Développement avant d'apporter vos modifications afin que la table de développement puisse être utilisée en production.
Si une table persistante comporte le paramètre dev_filters (pour les tables dérivées natives) ou la clause WHERE conditionnelle qui utilise les instructions if prod et if dev (pour les tables dérivées basées sur SQL), la table de développement ne peut pas être utilisée comme version de production, car la version de développement comporte un ensemble de données abrégé. Dans ce cas, après avoir terminé le développement de la table et avant de déployer vos modifications, vous pouvez mettre en commentaire le paramètre dev_filters ou la clause WHERE conditionnelle, puis interroger la table en mode Développement. Looker générera alors une version complète de la table qui pourra être utilisée pour la production lorsque vous déploierez vos modifications.

Si vous déployez vos modifications lorsqu'il n'existe aucune table de développement valide pouvant être utilisée comme table de production, Looker la recréera la prochaine fois que la table sera interrogée en mode Production (pour les tables persistantes utilisant la stratégie persist_for) ou lors de la prochaine exécution du régénérateur (pour les tables persistantes qui utilisent datagroup_trigger, interval_trigger ou sql_trigger_value).

Recherche de tables PDT déconstruites en mode Développement

Si une table de développement est conservée dans votre base de données lorsque vous déployez des modifications sur une table dérivée persistante (PDT) ou une table agrégée, Looker peut souvent utiliser la table de développement comme table de production afin que vos utilisateurs n'aient pas à attendre la création de la table lorsqu'ils interrogent la table. Pour en savoir plus, consultez les sections Durée de persistance des tables de développement et Ce qui pousse Looker à créer une table de développement sur cette page.

Par conséquent, il est optimal que toutes vos tables PDT soient créées lors du déploiement en production, afin que les tables puissent être utilisées immédiatement en tant que versions de production.

Vous pouvez rechercher des tables PDT non compilées dans votre projet dans le panneau État du projet. Cliquez sur l'icône Project Health (État du projet) dans l'IDE Looker pour ouvrir le panneau Project Health (État du projet). Cliquez ensuite sur le bouton Validate PDT Status (Valider l'état de la PDT).

S'il existe des tables PDT déconstruites, le panneau État du projet les répertorie:

Le panneau "État du projet" affiche la liste des tables PDT non compilées pour le projet, ainsi qu'un bouton "Accéder à la gestion des tables PDT".

Si vous disposez de l'autorisation see_pdts, vous pouvez cliquer sur le bouton Go to PDT Management (Accéder à la gestion des tables PDT). Looker ouvre l'onglet Développement de la page Tables dérivées persistantes et filtre les résultats en fonction de votre projet LookML. Vous pouvez consulter les tables PDT construites et déconstruites, et accéder à d'autres informations de résolution. Pour en savoir plus, consultez la page de documentation Paramètres d'administration – Tables dérivées persistantes.

Une fois que vous avez identifié une table PDT non compilée dans votre projet, vous pouvez créer une version de développement en ouvrant une exploration qui interroge la table, puis en utilisant l'option Recompiler les tables dérivées et exécuter dans le menu Exploration. Consultez la section Régénérer manuellement des tables persistantes pour une requête sur cette page.

Remarque :Si une table persistante est une table dérivée basée sur SQL définie à l'aide d'une clause WHERE conditionnelle avec des instructions if prod et if dev, vous ne pourrez pas utiliser la version de développement de la table pour la production, car la version de développement de la table comporte un ensemble de données abrégé. Pour en savoir plus, consultez la section Durée de persistance des tables de développement sur cette page. Pour les tables dérivées natives avec le paramètre dev_filters, Looker utilise la table de production pour répondre aux requêtes en mode Développement, sauf si vous modifiez la définition de la table, puis que vous interrogez la table en mode Développement (consultez la section Qu'est-ce qui pousse Looker à créer une table de développement sur cette page de documentation).

Partage et nettoyage de tables

Au sein d'une instance Looker donnée, Looker partage entre les utilisateurs les tables persistantes ayant la même définition et faisant appel à la même méthode de persistance. De plus, si la définition d'une table cesse d'exister, Looker la marque comme expirée.

Ces mesures offrent plusieurs avantages :

Si vous n'avez apporté aucune modification à une table en mode Développement, vos requêtes utiliseront les tables de production existantes. C'est le cas, sauf si votre table est une table dérivée basée sur SQL définie à l'aide d'une clause WHERE conditionnelle avec des instructions if prod et if dev. Si la table est définie avec une clause WHERE conditionnelle, Looker créera une table de développement si vous interrogez la table en mode Développement. (Pour les tables dérivées natives avec le paramètre dev_filters, Looker a la logique d'utiliser la table de production pour répondre aux requêtes en mode Développement, sauf si vous modifiez la définition de la table, puis que vous interrogez la table en mode Développement.)
Si deux développeurs apportent la même modification à une table en mode Développement, ils partageront la même table de développement.
Après la mise en production des changements apportés en mode Développement, l'ancienne définition de production n'existe plus, de sorte que l'ancienne table de production est marquée comme étant expirée et est supprimée.
Si vous décidez d'annuler les modifications effectuées en mode Développement, cette définition de la table n'existe plus, et les tables de développement devenues inutiles sont marquées comme expirées et supprimées.

Gains d'efficacité en mode Développement

Dans certains cas, la génération de la table dérivée persistante (PDT) que vous créez prend beaucoup de temps, ce qui peut s'avérer fastidieux si vous testez de nombreuses modifications en mode Développement. Dans ce cas, vous pouvez demander à Looker de créer des versions plus petites d'une table dérivée lorsque vous êtes en mode Développement.

Pour les tables dérivées natives, vous pouvez utiliser le sous-paramètre dev_filters de explore_source pour spécifier des filtres qui ne s'appliquent qu'aux versions de développement de la table dérivée:

view: e_faa_pdt {
  derived_table: {
  ...
    datagroup_trigger: e_faa_shared_datagroup
    explore_source: flights {
      dev_filters: [flights.event_date: "90 days"]
      filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
      column: id {}
      column: airport_name {}
      column: event_date {}
    }
  }
...
}

Cet exemple inclut un paramètre dev_filters qui filtre les données sur les 90 derniers jours et un paramètre filters qui filtre les données pour les deux dernières années et pour l'aéroport de Yucca Valley.

Le paramètre dev_filters agit conjointement avec le paramètre filters afin que tous les filtres soient appliqués à la version de développement de la table. Si dev_filters et filters spécifient tous deux des filtres pour la même colonne, dev_filters est prioritaire pour la version de développement de la table. Dans cet exemple, la version de développement de la table filtrera les données des 90 derniers jours pour l'aéroport de Yucca Valley.

Pour les tables dérivées basées sur SQL, Looker accepte une clause WHERE conditionnelle avec différentes options pour les versions de production (if prod) et de développement (if dev) de la table:

view: my_view {
  derived_table: {
    sql:
      SELECT
        columns
      FROM
        my_table
      WHERE
        -- if prod -- date > '2000-01-01'
        -- if dev -- date > '2020-01-01'
      ;;
  }
}

Dans cet exemple, la requête inclut toutes les données datées à partir de l'an 2000 en mode Production, mais seulement à partir de 2020 en mode Développement. Utilisée à bon escient pour limiter le jeu de résultats obtenu et accélérer les requêtes, cette fonctionnalité peut simplifier considérablement la validation des modifications apportées en mode Développement.

Remarque :Si une table persistante contient le paramètre dev_filters ou la clause conditionnelle WHERE, la table de développement ne peut pas être utilisée comme version de production, car elle comporte un ensemble de données abrégé. Dans ce cas, après avoir terminé le développement de la table et avant de déployer vos modifications, vous pouvez mettre en commentaire le paramètre dev_filters ou la clause WHERE conditionnelle, puis interroger la table en mode Développement. Looker générera alors une version complète de la table qui pourra être utilisée pour la production lorsque vous déploierez vos modifications. Consultez la section Durée de persistance des tables de développement sur cette page pour en savoir plus sur l'utilisation des tables de développement en production.

Comment Looker génère des tables PDT

Une fois qu'une table dérivée persistante (PDT) a été définie et qu'elle est exécutée pour la première fois ou déclenchée par le régénérateur pour être recompilée selon sa stratégie de persistance, Looker procède comme suit:

Utiliser la table dérivée SQL pour façonner une instruction CREATE TABLE AS SELECT (ou CTAS) et l'exécuter. Par exemple, pour recréer une table PDT appelée customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
Émettre les instructions pour créer les index lors de la création de la table
Renommez la table de LC$.. ("Looker Create") en LR$. ("Looker Read"), pour indiquer que la table est prête à l'emploi.
Supprimer toute ancienne version de la table qui ne devrait plus être utilisée

Cela a quelques conséquences importantes:

Le code SQL qui forme la table dérivée doit être valide dans une instruction CTAS.
Les alias de colonne de l'ensemble de résultats de l'instruction SELECT doivent être des noms de colonne valides.
Les noms utilisés lors de la spécification de distribution, de clés de tri et d'index doivent être les noms de colonne répertoriés dans la définition SQL de la table dérivée, et non les noms de champs définis dans le LookML.

Le régénérateur Looker

Le régénérateur Looker vérifie le statut et lance les régénérations des tables persistantes à déclenchement. Une table persistante à déclenchement est une table dérivée persistante (PDT) ou une table agrégée qui utilise un déclencheur comme stratégie de persistance:

Pour les tables qui utilisent sql_trigger_value, le déclencheur est une requête spécifiée dans le paramètre sql_trigger_value de la table. Le régénérateur Looker déclenche une régénération de la table lorsque le résultat du dernier contrôle de requête de déclenchement diffère du précédent. Par exemple, si votre table dérivée est persistante avec la requête SQL SELECT CURDATE(), le régénérateur Looker recréera la table la prochaine fois qu'il vérifiera le déclencheur après le changement de date.
Pour les tables qui utilisent interval_trigger, le déclencheur est une durée spécifiée dans le paramètre interval_trigger de la table. Le régénérateur Looker déclenche une régénération de la table lorsque la durée spécifiée est passée.
Pour les tables qui utilisent datagroup_trigger, le déclencheur peut être une requête spécifiée dans le paramètre sql_trigger du groupe de données associé, ou une durée spécifiée dans le paramètre interval_trigger du groupe de données.

Le régénérateur Looker lance également des recompilations pour les tables persistantes qui utilisent le paramètre persist_for, mais uniquement lorsque la table persist_for est une cascade de dépendance d'une table persistante avec déclencheur. Dans ce cas, le régénérateur Looker lancera les régénérations d'une table persist_for, car celle-ci est nécessaire pour recréer les autres tables de la cascade. Sinon, le régénérateur ne surveille pas les tables persistantes qui utilisent la stratégie persist_for.

Le cycle du régénérateur Looker commence à un intervalle régulier configuré par votre administrateur Looker dans le paramètre Planification de maintenance des groupes de données et des tables PDT dans votre connexion à la base de données (par défaut, un intervalle de cinq minutes). Toutefois, le régénérateur Looker ne démarre pas de nouveau cycle tant qu'il n'a pas terminé toutes les vérifications et recompilations de tables PDT à partir du dernier cycle. Cela signifie que si vous avez des compilations de tables PDT de longue durée, le cycle du régénérateur Looker risque de ne pas s'exécuter aussi souvent que défini dans le paramètre Planification de la maintenance des groupes de données et des tables PDT. D'autres facteurs peuvent affecter le temps nécessaire pour recréer vos tables, comme décrit dans la section Éléments importants à prendre en compte pour implémenter des tables persistantes de cette page.

En cas d'échec de la génération d'une table PDT, le régénérateur peut tenter de recréer la table dans le cycle suivant:

Si le paramètre Relancer les générations de tables PDT ayant échoué est activé sur votre connexion à la base de données, le régénérateur Looker tentera de régénérer la table lors du prochain cycle, même si la condition de déclenchement de la table n'est pas remplie.
Si le paramètre Relancer les générations de tables PDT ayant échoué est désactivé, le régénérateur Looker n'essaiera pas de régénérer la table tant que les conditions de déclenchement de la table PDT ne seront pas remplies.

Si un utilisateur demande des données à la table persistante pendant sa création et que les résultats de la requête ne sont pas dans le cache, Looker vérifie si la table existante est toujours valide. (La table précédente peut ne pas être valide si elle n'est pas compatible avec la nouvelle version de la table, ce qui peut se produire à cause d'une définition différente ou d'une connexion de base de données différente de la nouvelle table ou parce que la nouvelle table a été créée avec une version différente de Looker.) Si la table existante est toujours valide, Looker renvoie les données issues de la table existante jusqu'à la génération de la nouvelle table. Autrement, si la table existante n'est pas valide, Looker renvoie les résultats de requête une fois que la nouvelle table est régénérée.

Éléments importants à prendre en compte lors de la mise en œuvre de tables persistantes

Compte tenu de l'utilité des tables persistantes (PDT et tables agrégées), il est facile d'en accumuler un grand nombre sur votre instance Looker. Il est possible de créer un scénario dans lequel le régénérateur Looker doit créer plusieurs tables en même temps. En particulier avec les tables en cascade, ou tables de longue durée, vous pouvez créer un scénario dans lequel les tables ont un long délai avant la recréation d'une table, ou dans lequel les utilisateurs constatent un délai d'obtention des résultats de requête d'une table alors que la base de données travaille dur pour générer la table.

Le régénérateur de Looker vérifie les déclencheurs de tables PDT pour déterminer s'il doit régénérer les tables persistantes associées à ces déclencheurs. Le cycle de régénération est défini à un intervalle régulier configuré par votre administrateur Looker dans le paramètre Planification de maintenance des groupes de données et des tables PDT de votre connexion à la base de données (par défaut, un intervalle de cinq minutes).

Plusieurs facteurs peuvent affecter le temps nécessaire pour reconstruire vos tables:

Votre administrateur Looker a peut-être modifié l'intervalle des vérifications du déclencheur du régénérateur en utilisant le paramètre Planification de la maintenance des groupes de données et des tables PDT sur votre connexion à la base de données.
Le régénérateur Looker ne démarre pas de nouveau cycle tant qu'il n'a pas terminé toutes les vérifications et recompilations de tables PDT à partir du dernier cycle. Ainsi, si vous avez des compilations de tables PDT de longue durée, le cycle du régénérateur Looker peut être moins fréquent que le paramètre Planification de la maintenance des groupes de données et des tables PDT.
Par défaut, le régénérateur peut lancer la régénération d'une table PDT ou agrégée à un temps donnée sur une connexion. Un administrateur Looker peut ajuster le nombre autorisé de recompilations simultanées pour le régénérateur à l'aide du champ Nombre maximal de connexions au compilateur de tables PDT dans les paramètres d'une connexion.
Toutes les tables PDT et les tables agrégées déclenchées par le même datagroup seront recréées au cours du même processus. La charge peut être importante si de nombreuses tables utilisent le groupe de données, soit directement, soit à la suite de dépendances en cascade.

Outre les considérations précédentes, il existe également des situations dans lesquelles vous devez éviter d'ajouter de la persistance à une table dérivée:

Quand les tables dérivées sont extended : chaque extension d'une table PDT crée une copie de la table dans votre base de données.
Lorsque les tables dérivées utilisent des filtres modélisés ou des paramètres Liquid : la persistance n'est pas compatible avec les tables dérivées qui utilisent des filtres basés sur un modèle ou des paramètres Liquid.
Lorsque des tables dérivées natives sont créées à partir d'explorations qui utilisent des attributs utilisateur avec access_filters ou sql_always_where : des copies de la table sont créées dans votre base de données pour chaque valeur d'attribut utilisateur éventuellement spécifiée.
Lorsque les données sous-jacentes changent fréquemment et que votre dialecte de base de données ne prend pas en charge les PDT incrémentielles.
Lorsque le coût et le temps liés à la création de tables PDT sont trop élevés.

Selon le nombre et la complexité des tables persistantes sur votre connexion Looker, la file d'attente peut contenir de nombreuses tables persistantes en attente de contrôle et de régénération à chaque cycle. Il est donc important de garder ces facteurs à l'esprit lors de la mise en œuvre de tables dérivées sur votre instance Looker.

Gestion des tables PDT à grande échelle via l'API

Plus vous créez de tables PDT sur votre instance, plus la surveillance et la gestion des tables dérivées persistantes (PDT) qui s'actualisent selon des planifications variables deviennent de plus en plus complexes. Envisagez d'utiliser l'intégration Apache Airflow de Looker pour gérer vos planifications de tables PDT en même temps que vos autres processus ETL et ELT.

Surveillance et correction de tables PDT

Si vous utilisez des tables dérivées persistantes (PDT), et en particulier des tables PDT en cascade, il est utile de pouvoir consulter leur état. Vous pouvez consulter l'état de vos tables PDT à l'aide de la page d'administration Tables dérivées persistantes de Looker. Pour en savoir plus, consultez la page de documentation Paramètres d'administration – Tables dérivées persistantes.

Pour résoudre les problèmes liés aux tables PDT:

Lorsque vous examinez le journal des événements PDT, portez une attention particulière à la distinction entre les tables de développement et les tables de production.
Assurez-vous qu'aucune modification n'a été apportée au schéma créé de toutes pièces dans lequel Looker stocke les tables dérivées persistantes. Si des modifications ont été apportées, vous devrez peut-être mettre à jour les paramètres de connexion dans la section Admin de Looker, puis redémarrer Looker pour rétablir le fonctionnement normal des tables PDT.
Déterminez si toutes les tables PDT posent problème, ou une seule d'entre elles. Dans ce dernier cas, le problème est probablement dû à une erreur LookML ou SQL.
Déterminez si les problèmes liés à la table PDT coïncident avec les régénérations planifiées.
Assurez-vous que toutes les requêtes sql_trigger_value sont correctement évaluées et qu'elles ne renvoient qu'une seule ligne et qu'une seule colonne. Pour ce faire, vous pouvez exécuter les tables PDT basées sur SQL dans SQL Runner. (L'application d'un LIMIT protège contre les requêtes intempestives.) Pour en savoir plus sur l'utilisation de SQL Runner pour déboguer les tables dérivées, consultez le post de la communauté Utiliser sql runner pour tester les tables dérivées .
Pour les tables PDT basées sur SQL, utilisez SQL Runner pour vérifier si le code SQL d'une table s'exécute sans erreur. (Veillez à appliquer un LIMIT dans SQL Runner pour que les durées des requêtes restent raisonnables.)
Pour les tables dérivées basées sur SQL, évitez d'utiliser des expressions de table courantes. L'utilisation de CTE avec les DT crée des instructions WITH imbriquées qui peuvent entraîner l'échec des tables PDT sans avertissement. Utilisez plutôt le code SQL de votre CTE afin de créer une DT secondaire et de la référencer à partir de votre première DT en utilisant la syntaxe ${derived_table_or_view_name.SQL_TABLE_NAME}.
Vérifiez qu'il existe bien des tables dont dépend la table PDT problématique, qu'il s'agisse de tables normales ou de tables PDT elles-mêmes, et qu'elles puissent être interrogées.
Assurez-vous que les tables dont la PDT posant problème dépend ne possèdent pas de verrous partagés ou exclusifs. Pour créer une table PDT, Looker doit acquérir un verrou exclusif sur la table à mettre à jour. Cela crée un conflit avec les autres verrous partagés ou exclusifs associés à la table. Looker ne peut pas mettre à jour la table PDT tant que les autres verrous ne sont pas supprimés. Il en va de même pour les verrous exclusifs sur la table à partir de laquelle Looker crée une table PDT. Si une table possède un verrou exclusif, Looker ne pourra pas acquérir de verrou partagé pour exécuter des requêtes tant que le verrou exclusif n'aura pas été supprimé.
Utilisez le bouton Show Processes (Afficher les processus) dans SQL Runner. Si de nombreux processus sont actifs, l'exécution des requêtes pourrait être ralentie.
Surveillez les commentaires figurant dans la requête. Consultez la section Commentaires sur la requête pour les tables PDT sur cette page.

Commentaires de requête pour les tables PDT

Les administrateurs de bases de données peuvent facilement différencier les requêtes normales de celles qui génèrent des tables dérivées persistantes (PDT). Looker ajoute des commentaires à l'instruction CREATE TABLE ... AS SELECT ..., qui incluent le modèle et la vue LookML de la table PDT, ainsi qu'un identifiant unique (slug) pour l'instance Looker. Si la table PDT est générée au nom d'un utilisateur en mode Développement, les commentaires indiquent l'ID de l'utilisateur. Les commentaires de génération d'une table PDT suivent le schéma ci-dessous :

-- Building `<view_name>` in dev mode for user `<user_id>` on instance `<instance_slug>`
CREATE TABLE `<table_name>` SELECT ...
-- finished `<view_name>` => `<table_name>`

Le commentaire sur la génération d'une table PDT apparaîtra dans l'onglet SQL d'une exploration si Looker a dû générer une table PDT pour la requête de l'exploration. Dans ce cas, le commentaire apparaît en haut de l'instruction SQL.

Enfin, le commentaire sur la génération de tables PDT s'affiche dans le champ Message de l'onglet Informations de la fenêtre pop-up Détails de la requête pour chaque requête sur la page d'administration Requêtes.

Régénération d'une table PDT après échec

En cas de défaillance d'une table dérivée persistante (PDT), voici ce qui se passe lorsqu'elle est interrogée:

Looker utilise les résultats dans le cache si la même requête a été exécutée précédemment. Pour en savoir plus, consultez la page de documentation sur la mise en cache des requêtes.
Si les résultats ne sont pas dans le cache, Looker extrait les résultats de la table PDT dans la base de données, à condition qu'une version valide de la table PDT existe.
S'il n'existe aucune table PDT valide dans la base de données, Looker tente de régénérer la table PDT.
Si la table PDT ne peut pas être régénérée, Looker renvoie une erreur pour une requête. Le régénérateur Looker tentera de régénérer la table PDT la prochaine fois qu'elle sera interrogée ou que la stratégie de persistance de la table PDT déclenchera une recompilation.

Avec les tables PDT en cascade, la même logique s'applique, sauf qu'avec les tables PDT en cascade:

Un échec de création de table empêche la création de PDT tout le long de la chaîne de dépendance.
Une table PDT dépendante interroge essentiellement la table PDT sur laquelle elle repose. Par conséquent, la stratégie de persistance d'une table peut déclencher des régénérations des tables PDT en haut de la chaîne.

Reprenons l'exemple précédent de tables en cascade, dans lequel TABLE_D dépend de TABLE_C, qui dépend de TABLE_B, qui dépend de TABLE_A:

En cas d'échec de TABLE_B, tous les comportements standards (hors cascade) s'appliquent pour TABLE_B: si TABLE_B est interrogé, Looker essaie d'abord d'utiliser le cache pour renvoyer les résultats, puis, si possible, d'utiliser une version précédente de la table, puis de la recréer. Enfin, elle renvoie une erreur si TABLE_B ne peut pas recompiler. Looker réessaiera de recréer TABLE_B lors de la prochaine requête de la table ou lorsque la stratégie de persistance de la table déclenchera une nouvelle recompilation.

Il en va de même pour les éléments dépendants de TABLE_B. Ainsi, si TABLE_B ne peut pas être compilé et qu'il y a une requête sur TABLE_C:

Looker tentera d'utiliser le cache pour la requête sur TABLE_C.
Si les résultats ne se trouvent pas dans le cache, Looker essaie d'extraire les résultats de TABLE_C dans la base de données.
S'il n'existe aucune version valide de TABLE_C, Looker tentera de recompiler TABLE_C, ce qui crée une requête sur TABLE_B.
Looker tentera ensuite de recompiler TABLE_B (ce qui échouera si TABLE_B n'a pas été corrigé).
Si TABLE_B ne peut pas être recompilé, TABLE_C ne peut pas recompiler. Looker renvoie donc une erreur pour la requête sur TABLE_C.
Looker tentera ensuite de recompiler TABLE_C selon sa stratégie de persistance habituelle ou la prochaine fois que la table PDT sera interrogée (y compris lors de la prochaine tentative de compilation de TABLE_D, car TABLE_D dépend de TABLE_C).

Une fois que vous aurez résolu le problème avec TABLE_B, TABLE_B et chacune des tables dépendantes tenteront de se recompiler en fonction de leurs stratégies de persistance, ou la prochaine fois qu'elles seront interrogées (ce qui inclut la prochaine tentative de recompilation d'une table PDT dépendante). Ou, si une version de développement des tables PDT dans la cascade a été générée en mode Développement, les versions de développement peuvent être utilisées comme les nouvelles tables PDT de production. Pour en savoir plus, consultez la section Tables persistantes en mode Développement de cette page. Vous pouvez également utiliser une exploration pour exécuter une requête sur TABLE_D, puis reconstruire manuellement les tables PDT associées à la requête, ce qui forcera une recompilation de toutes les tables PDT remontant dans la cascade des dépendances.

Amélioration des performances des tables PDT

Lorsque vous créez des tables dérivées persistantes (PDT), les performances peuvent poser problème. L'interrogation de la table peut prendre du temps, en particulier lorsque celle-ci est très volumineuse, tout comme cela peut être le cas pour n'importe quelle table volumineuse de votre base de données.

Pour améliorer les performances, vous pouvez filtrer les données ou contrôler la manière dont les données de la table PDT sont triées et indexées.

Ajouter des filtres pour limiter l'ensemble de données

Avec les ensembles de données particulièrement volumineux, le fait d'avoir de nombreuses lignes ralentira les requêtes sur une table dérivée persistante (PDT). Si vous n'interrogez généralement que des données récentes, envisagez d'ajouter un filtre à la clause WHERE de votre table PDT qui limite les données de la table à 90 jours ou moins. Ainsi, seules les données pertinentes seront ajoutées à la table à chaque recompilation, ce qui accélère l'exécution des requêtes. Ensuite, vous pouvez créer une table PDT distincte et plus grande pour l'analyse historique afin de permettre à la fois d'interroger rapidement les données récentes et de pouvoir interroger d'anciennes données.

Avec `indexes`, ou `sortkeys` et `distribution`

Lorsque vous créez une grande table dérivée persistante (PDT), l'indexation de la table (pour les dialectes tels que MySQL ou Postgres) ou l'ajout de clés de tri et de distribution (pour Redshift) peut améliorer les performances.

Il est généralement préférable d'ajouter le paramètre indexes aux champs d'ID ou de date.

Pour Redshift, il est généralement préférable d'ajouter le paramètre sortkeys dans les champs d'ID ou de date, et le paramètre distribution dans le champ utilisé pour la jointure.

Paramètres recommandés pour améliorer les performances

Les paramètres suivants contrôlent la manière dont les données de la table dérivée persistante (PDT) sont triées et indexées. Ces paramètres sont facultatifs, mais vivement recommandés:

Pour Redshift et Aster, utilisez le paramètre distribution pour spécifier le nom de la colonne dont la valeur est utilisée pour répartir les données autour d'un cluster. Lorsque deux tables sont jointes par la colonne spécifiée dans le paramètre distribution, la base de données peut trouver les données de jointure sur le même nœud, ce qui réduit les E/S entre les nœuds.
Pour Redshift, définissez le paramètre distribution_style sur all pour indiquer à la base de données de conserver une copie complète des données sur chaque nœud. Cela permet souvent de réduire les E/S entre nœuds lorsque des tables relativement petites sont jointes. Définissez cette valeur sur even pour indiquer à la base de données de répartir les données uniformément dans le cluster sans utiliser de colonne de distribution. Cette valeur ne peut être spécifiée que si distribution n'est pas spécifié.
Pour Redshift, utilisez le paramètre sortkeys. Les valeurs spécifient quelles colonnes de la table PDT sont utilisées pour trier les données sur le disque afin de faciliter la recherche. Avec Redshift, vous pouvez utiliser sortkeys ou indexes, mais pas les deux.
Sur la plupart des bases de données, utilisez le paramètre indexes. Les valeurs spécifient les colonnes de la table PDT à indexer. (Sur Redshift, les index sont utilisés pour générer des clés de tri entrelacées.)