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 utiliser la table dérivée de customer_order_summary comme s'il s'agissait d'une autre table de la base de données.

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:

Par exemple, les fichiers de vue suivants montrent comment utiliser LookML pour créer une vue à partir d'une table dérivée de 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, qui est définie dans un fichier distinct non présenté dans cet exemple. La requête explore_source de la table dérivée native affiche les champs customer_id, first_order et total_amount à partir du fichier de vue orders.
  • La table dérivée 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 dans la base de données.
Version native de la table dérivée 
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 table dérivée 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, avec 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 tout 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 des dimensions LookML basées sur les colonnes de cette table.

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, vous devez utiliser 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 natif de la vue dérivée de la table 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.

Pour en savoir plus sur la création de tables dérivées natives, consultez la page Créer des 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. Consultez le fichier de vue Tableau dérivée basée sur SQL dans l'exemple précédent.

La plupart du temps, 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 SQL dans Looker consiste à utiliser l'exécuteur SQL 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 accepte les paramètres suivants pour 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 PDT, Looker encapsule l'instruction CREATE TABLE langage de définition de données (LDD) du dialecte autour de votre requête pour créer la 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 PDT avec le paramètre sql. En revanche, vous pouvez utiliser le paramètre create_process pour créer une PDT en plusieurs étapes. Pour en savoir plus et obtenir des exemples, consultez la page de documentation sur le paramètre create_process.
  • sql_create: si votre cas d'utilisation nécessite des commandes DDL personnalisées et que votre dialecte est compatible avec le LDD (par exemple, le prédiction BigQuery ML de Google), vous pouvez utiliser le paramètre sql_create pour créer une PDT plutôt que le paramètre sql. Consultez la page de documentation sql_create pour obtenir des informations et des exemples.

Que vous utilisiez les paramètres sql, create_process ou sql_create, vous définissez la table dérivée à l'aide d'une requête SQL, qui sont donc toutes considérées comme basées sur SQL.

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

Tables dérivées temporaires et persistantes (PDT)

En plus de la distinction entre les tables dérivées natives et les tables dérivées SQL, il existe une 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 affiché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 Explorer impliquant une ou plusieurs tables dérivées, Looker crée une requête SQL en utilisant une combinaison SQL du dialecte pour les tables dérivées, plus les champs demandés, les jointures et les valeurs de filtre. 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. Pour en savoir plus sur la mise en cache des requêtes dans Looker, consultez la page de documentation Requêtes de mise en cache.

Sinon, 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 surchargent pas votre base de données de manière excessive. Dans les cas où l'exécution de la requête prend du temps, il est souvent préférable d'utiliser une PDT.

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 présente les dialectes compatibles avec les tables dérivées de la dernière version de Looker:

Tables dérivées persistantes (PDT)

Une table dérivée persistante (PDT) est une table dérivée écrite dans un schéma de base de données et générée de nouveau sur la planification que vous spécifiez à l'aide d'une stratégie de persistance.

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

Conditions requises pour les tables dérivées persistantes

Pour utiliser des PDT dans votre projet Looker, vous avez besoin des éléments suivants :

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

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

Pour accepter n'importe quel type de PDT (basé sur LookML ou SQL), le dialecte doit prendre en charge les écritures dans la base de données, entre autres conditions. Certaines configurations de bases de données en lecture seule ne permettent pas la persistance du fonctionnement (généralement des bases de données d'instances dupliquées Postgres à échange à chaud). 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 SQL persistantes dans la dernière version de Looker:

Pour accepter les tables dérivées natives persistantes (qui contiennent des requêtes basées sur LookML), le dialecte doit également être compatible avec une fonction LDD CREATE TABLE. Voici une liste des dialectes compatibles avec les tables dérivées natives (basées sur LookML) présentes dans la dernière version de Looker:

Augmentation de la génération de tables PDT

Une PDT incrémentielle est une table dérivée persistante (PDT) que Looker crée en ajoutant des données récentes à la table au lieu de la recréer dans son intégralité.

Si votre dialecte persistante persistante (PDT) est compatible avec les PDT incrémentiels et qu'elle utilise une stratégie de persistance basée sur des déclencheurs (datagroup_trigger, sql_trigger_value ou interval_trigger), vous pouvez la définir en tant que PDT incrémentiel.

Pour en savoir plus, consultez la page PDT incrémentiel.

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 compatibles avec les tables dérivées persistantes incrémentielles dans la dernière version de Looker:

Créer des tables dérivées persistantes (PDT)

Pour transformer une table dérivée en table dérivée persistante (PDT), définissez une stratégie de persistance pour cette 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 derived_table:

Avec les stratégies de persistance basées sur des déclencheurs (datagroup_trigger, sql_trigger_value et interval_trigger), Looker conserve les PDT dans la base de données jusqu'à ce quPDT;elles soient déclenchées pour la 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 sont la méthode la plus flexible pour créer une 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 lancer la recompilation de vos tables dérivées persistantes.

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 PDT pendant sa compilation et que les résultats de la requête ne sont pas dans le cache, Looker renvoie les données de la PDT existante jusqu'à ce que la nouvelle PDT soit créée. Pour en savoir plus sur les groupes de données, consultez la section Mettre en cache des requêtes.

Pour en savoir plus sur la manière dont le générateur génère des tables dérivées persistantes, consultez la section Le générateur sur Looker.

sql_trigger_value

Le paramètre sql_trigger_value déclenche la génération d'une PDT à partir 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 PDT pendant sa compilation et que les résultats de la requête ne se trouvent pas dans le cache, Looker renvoie les données de la PDT existante jusqu'à ce que la nouvelle PDT soit créée.

Pour en savoir plus sur la manière dont le générateur génère des tables dérivées persistantes, consultez la section Le générateur sur Looker.

interval_trigger

Le paramètre interval_trigger déclenche la génération d'une 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, la PDT est généralement prédéfinie lorsque les utilisateurs l'interrogent. Si un utilisateur demande des données à la PDT pendant sa compilation et que les résultats de la requête ne se trouvent pas dans le cache, Looker renvoie les données de la PDT existante jusqu'à ce que la nouvelle PDT soit créé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. Elle ne sera ainsi plus utilisée pour les requêtes et sera supprimée de la base de données.

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

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

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

materialized_view: yes

Les vues matérialisées vous permettent d'exploiter les fonctionnalités de votre base de données pour conserver les tables dérivées de votre projet Looker. Si le dialecte de votre base de données accepte les vues matérialisées et que votre connexion à Looker est configurée avec l'option Activer les 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 SQL.

Comme 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 de travail 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 du dialecte, les exigences et les considérations importantes.

Stratégies d'optimisation

Étant donné que des PDT sont stockées dans votre base de données, vous devriez optimiser vos PDT en suivant les stratégies suivantes, selon ce que prend en charge votre dialecte :

Par exemple, pour ajouter une persistance à l'exemple de table dérivée, vous pouvez la recompiler lorsque le groupe de données orders_datagroup se déclenche, et ajouter des index à la fois pour customer_id et pour first_order, comme suit:

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 avertira que vous devez le faire pour améliorer les performances des requêtes.

Cas d'utilisation des PDT

Les tables dérivées persistantes 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 les données sans PDT jusqu'à ce que cela soit absolument nécessaire.

Dans certains cas, il est possible d'optimiser les données par d'autres moyens. Par exemple, ajouter un index ou modifier le type de données d'une colonne peut résoudre un problème sans qu'il soit nécessaire de créer une PDT. Veillez à analyser les plans d'exécution des requêtes lentes à l'aide de l'outil Explain from SQL Runner.

En plus de réduire le temps et la charge de la base de données pour les requêtes fréquentes, il existe d'autres cas d'utilisation des tables dérivées persistantes:

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

Tester l'optimisation à l'aide des tables dérivées persistantes

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

Imaginons que vous disposez d'une table, mais que vous souhaitez tester différents index. Le LookML initial de 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 suit:

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 seule fois pour générer la PDT. Exécutez ensuite vos requêtes de test et comparez vos résultats. Si les résultats sont favorables, vous pouvez demander à votre équipe DBA ou ETL d'ajouter les index à la table d'origine.

N'oubliez pas de modifier le code de la vue afin de supprimer la PDT.

Utiliser des tables dérivées persistantes pour préjoindre ou agréger les données

Il peut être utile de joindre ou de pré-agréger des données afin d'ajuster l'optimisation des requêtes pour des volumes de données 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 de leur première commande. L'exécution de cette requête peut s'avérer coûteuse chaque fois que les données sont nécessaires en temps réel. Cependant, vous ne pouvez calculer la requête qu'une seule fois et 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, ce qui crée une chaîne de tables dérivées en cascade ou des PDT en cascade, comme cela peut être le cas. Voici un exemple de tables dérivées en cascade : 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 de clean_events avec la syntaxe suivante:

`${clean_events.SQL_TABLE_NAME}`

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

Dans l'exemple suivant, la PDT clean_events est créée à partir de la table events de la base de données. La PDT clean_events ignore les lignes indésirables de la table de base de données events. Une deuxième PDT s'affiche. La PDT event_summary est un récapitulatif 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 PDT event_summary et la PDT clean_events sont en cascade, où event_summary dépend de clean_events (car event_summary est défini à l'aide de la PDT clean_events). Cet exemple particulier peut être réalisé plus efficacement en une seule PDT, mais il est utile pour démontrer les références de tables dérivées.

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 nécessaire, 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 à l'aide du 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 des tables dérivées temporaires en cascade, si les résultats de requête d'un utilisateur ne se trouvent pas dans le cache, Looker crée toutes les tables dérivées nécessaires à la requête. Si vous disposez d'un TABLE_D dont la définition contient une référence à TABLE_C, 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 va recompiler TABLE_D. Mais avant, il doit recompiler TABLE_C.

Prenons le scénario de la cascade en cascade de tables dérivées temporaires, où TABLE_D dépend de TABLE_C, qui dépend de TABLE_B, qui dépend de TABLE_A. Si Looker n'a pas de résultats valides pour une requête sur TABLE_C dans le cache, Looker crée toutes les tables nécessaires à la requête. Looker va donc créer TABLE_A, TABLE_B, puis TABLE_C:

Dans ce scénario, TABLE_A doit terminer la génération avant que Looker ne 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 sur le paramètre datagroup pour obtenir un exemple de scénario où les tables dérivées persistantes en cascade utilisent le même groupe de données.

La même logique de base s'applique aux tables dérivées persistantes: Looker crée toute table requise pour répondre à une requête, et ce, tout au long de la chaîne de dépendances. Cependant, avec les tables dérivées persistantes, il arrive souvent que les tables existent déjà et n'aient pas besoin d'être recompilées. Avec les requêtes utilisateur standards sur les PDT en cascade, Looker ne les recompile dans la cascade que s'il n'existe aucune version valide de ces PDT dans la base de données. Si vous souhaitez forcer la recompilation de toutes les tables dérivées persistantes d'une cascade, vous pouvez recompiler manuellement les tables pour une requête via une exploration.

Un point logique à comprendre est que, dans le cas d'une cascade de PDT, un PDT dépendant consiste essentiellement à interroger le PDT dont il dépend. Cela est particulièrement important pour les PDT qui utilisent la stratégie persist_for. En général, les tables dérivées persistantes persist_for sont compilé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 pas recompilés tant qu'elles ne sont pas interrogées par l'utilisateur. Toutefois, si une PDT persist_for fait partie d'une cascade de PDT basée sur des déclencheurs (PDT utilisant la stratégie de persistance datagroup_trigger, interval_trigger ou sql_trigger_value), elle est essentiellement interrogée chaque fois que ses PDT dépendantes sont recompilées.persist_for Dans ce cas, la PDT persist_for sera recréée selon le calendrier des PDT dépendants. Cela signifie que la PDT de persist_for peut être affectée par la stratégie de persistance de ses dépendances.

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

Les utilisateurs peuvent sélectionner l'option Recompiler derived Tables & Run (Recompiler les tables dérivées et les exécutions) dans le menu Explorer pour remplacer les paramètres de persistance et recompiler toutes les tables dérivées persistantes et les tables agrégées requises pour la requête actuelle dans Explorer:

Cliquez sur le bouton Explorer les actions pour ouvrir le menu "Explorer", dans lequel 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 seulement après le chargement de la requête Explorer.

L'option Recompiler Tables & Run (Recompiler les tables dérivées et l'exécution) recompile toutes les tables persistantes (toutes les tables dérivées persistantes et les tables agrégées) nécessaires pour répondre à la requête, quelle que soit leur stratégie de persistance. Cela inclut toutes les tables et tables dérivées persistantes agrégées dans la requête actuelle, ainsi que toutes les tables et tables dérivées persistantes référencées par ces tables dans la requête actuelle.

Dans le cas de PDT incrémentiels, l'option Recompiler les tables dérivées et l'exécution déclenche la compilation d'un nouvel incrément. Avec les tables dérivées persistantes incrémentielles, un incrément inclut la période spécifiée dans le paramètre increment_key et le nombre de périodes précédentes spécifiées dans le paramètre increment_offset. Consultez la page de documentation sur les PDT incrémentiels pour obtenir des exemples de scénarios illustrant la génération des PDT incrémentiels en fonction de leur configuration.

Dans le cas des PDT en cascade, il faut recréer toutes les tables dérivées de la cascade, en commençant par le haut. Le 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 que table_b dépend de table_a, reconstruire table_c recompile d'abord table_a, puis table_b et enfin table_c.

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

  • Si l'utilisateur lance l'opération Recompiler les tables dérivées et exécuter, la requête attend que les tables se recompilent 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 pendant la recréation des tables, ces utilisateurs pourraient toujours être affectés par la charge supplémentaire 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 l'exécution recompile la table de développement, et non la table de production, pour l'exploration. Toutefois, si l'option Explorer en mode de développement utilise la version de production d'une table dérivée, celle-ci est recréée. Pour en savoir plus 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, elle ne peut pas être recompilée et la session du navigateur expire. Pour en savoir plus sur les délais avant expiration susceptibles d'affecter les processus Looker, consultez la section Délais d'expiration des requêtes et file d'attente de la page Paramètres d'administration – Requêtes.

Tables persistantes en mode Développement

Looker présente 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 interrogera la version de production de cette table. Si vous modifiez la définition de la table qui affecte les données de la table ou la manière 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 comporte un paramètre qui limite 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ée 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 n'ont 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 puis interrogez-la 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) :

Pour les modifications qui ne modifient pas les données de la table ou qui n'affectent pas 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 en est un bon exemple. En mode de développement, si vous ne modifiez que le paramètre publish_as_db_view pour une table dérivée, Looker n'a pas besoin de recompiler la table dérivée. Par conséquent, aucune table de développement n'est créée.

Durée de persistance des tables de développement

Quelle que soit la stratégie de persistance réelle de la table, Looker traite ces tables comme si elles avaient une stratégie de persistance de persist_for: "24 hours". Looker procède ainsi pour s'assurer que les tables de développement ne sont pas conservées plus d'un jour, 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 d'encombrer la table de développement, Looker applique la stratégie persist_for: "24 hours" afin de s'assurer qu'elles sont fréquemment nettoyées.

Sinon, Looker génère des tables PDT et des tables agrégées en mode Développement de la même façon qu'il génère des tables persistantes en mode Production.

Si une table de développement est conservée sur votre base de données lorsque vous déployez des modifications dans une PDT ou une table agrégée, Looker peut souvent utiliser la table de développement comme table de production. Ainsi, vos utilisateurs n'auront pas à attendre la compilation 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 plus de 24 heures se sont écoulées depuis que vous avez interrogé la table en mode développement, 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 des tables dérivées persistantes non compilées à l'aide de l'IDE Looker ou à l'aide de 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 SQL), la table de développement ne peut pas être utilisée comme version de production, car elle inclut un ensemble de données abrégé. Dans ce cas, après avoir développé la table et avant de déployer vos modifications, vous pouvez mettre en commentaire le paramètre dev_filters ou la clause conditionnelle WHERE, 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 en l'absence d'une table de développement valide pouvant être utilisée comme table de production, Looker recompilera la table la prochaine fois qu'elle sera interrogée en mode production (pour les tables persistantes qui utilisent la stratégie persist_for) ou la prochaine fois que le regénérateur s'exécutera (pour les tables persistantes utilisant 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 sur votre base de données lorsque vous déployez des modifications dans une PDT ou une table agrégée, Looker peut souvent utiliser la table de développement comme table de production. Ainsi, vos utilisateurs n'auront pas à attendre la compilation lorsqu'ils interrogent la table. Pour en savoir plus, consultez les sections Pendant combien de temps les tables de développement sont conservées dans Looker et Qu'est-ce qui permet à Looker de créer une table de développement sur cette page ?

Par conséquent, il est optimal que toutes vos tables dérivées persistantes soient compilées lorsque vous les déployez en production afin que les tables puissent être utilisées immédiatement en tant que versions de production.

Vous pouvez rechercher les 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 Valider l'état de la PDT.


Si des tables dérivées persistantes n'ont pas été créées, le panneau État du projet les répertorie:

Le panneau "Project Health" (État du projet) affiche une liste de tables dérivées persistantes non intégrées pour le projet, ainsi qu'un bouton "Accéder à la gestion des tables dérivées persistantes".

Si vous disposez de l'autorisation see_pdts, vous pouvez cliquer sur le bouton Accéder à la gestion des tables dérivées persistantes. 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 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 l'exécution dans le menu "Explorer". Cette section présente la section Recréer manuellement des tables persistantes pour une requête.

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 conditionnelle WHERE avec des instructions if prod et if dev. Si la table est définie avec une clause WHERE conditionnelle, Looker crée 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 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 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 PDT prend beaucoup de temps, ce qui peut prendre beaucoup de temps si vous testez de nombreuses modifications en mode développement. Dans ce cas, vous pouvez inviter Looker à créer de plus petites versions 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 sont appliqués 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 des 90 derniers jours et un paramètre filters qui filtre les données des deux dernières années et de l'aéroport de Yucca Valley.

Le paramètre dev_filters fonctionne conjointement avec le paramètre filters. Ainsi, tous les filtres sont appliqués à la version de développement de la table. Si dev_filters et filters spécifient des filtres pour la même colonne, dev_filters prévaut 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 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.

Comment Looker crée des PDT

Une fois qu'une PDT a été définie et qu'elle est exécutée pour la première fois ou déclenchée par le regénérateur pour recompiler conformément à sa stratégie de persistance, Looker suit les étapes suivantes:

  1. Utiliser le langage SQL dérivé de la table pour personnaliser une instruction CREATE TABLE AS SELECT (ou CTAS) et l'exécuter. Par exemple, pour recompiler une PDT appelée customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
  2. Émettre les instructions pour créer les index lors de la création de la table
  3. Renommez la table de LC$.. ("Looker Create") en LR$.. ("Looker Read") pour indiquer que la table est prête à l'emploi.
  4. Supprimez toutes les anciennes versions de la table qui ne doivent plus être utilisées.

Il y a plusieurs conséquences importantes:

  • Le code SQL qui constitue 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 colonnes valides.
  • Les noms utilisés lors de la spécification de la distribution, des clés de tri et des index doivent correspondre à ceux figurant dans la définition SQL de la table dérivée, et non à ceux définis dans 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 PDT ou une table agrégée qui utilise un déclencheur comme stratégie de persistance:

  • Pour les tables utilisant 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 la table dérivée est conservée avec la requête SQL SELECT CURDATE(), le regénérateur Looker recompile la table la prochaine fois qu'il vérifie le déclencheur après la date.
  • Pour les tables qui utilisent interval_trigger, le déclencheur correspond à 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 générateur de 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épendances d'une table persistante à déclenchement. Dans le cas présent, le générateur de Looker lance des recompilations pour une table persist_for, car celle-ci est nécessaire pour recompiler 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 de régénérateur Looker commence à un intervalle régulier configuré par votre administrateur Looker dans le paramètre Calendrier de maintenance du groupe de données et de la PDT sur votre connexion à la base de données (par défaut, il s'agit d'un intervalle de cinq minutes). Toutefois, le générateur de Looker ne lance pas de nouveau cycle tant qu'il n'a pas terminé toutes les vérifications et recompilations du PDT du dernier cycle. Cela signifie que si vous disposez de compilations de PDT de longue durée, le cycle de regénérateur de Looker peut ne pas s'exécuter aussi souvent que celui défini dans le paramètre Group PDT Maintenance Schedule (Calendrier de maintenance des PDT et des groupes de données). D'autres facteurs peuvent affecter le temps nécessaire à la recompilation de vos tables, comme décrit dans la section Remarques importantes pour l'implémentation des tables persistantes de cette page.

En cas d'échec de la compilation d'une PDT, le régénérateur peut essayer de recompiler la table lors du prochain cycle de régénération:

  • Si le paramètre Relancer les PDT ayant échoué est activé sur votre connexion à la base de données, le générateur de Looker tente de recompiler la table lors du prochain cycle de génération, même si la condition de déclenchement de la table n'est pas remplie.
  • Si le paramètre Relancer les PDT ayant échoué est désactivé, le générateur de Looker n'essaiera pas de recompiler la table tant que la condition de déclenchement de la PDT n'est pas remplie.

Si un utilisateur demande des données à la table persistante pendant sa compilation et que les résultats de la requête ne se trouvent 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 des 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 générateur de Looker doit créer plusieurs tables en même temps. En particulier, pour les tables en cascade ou les tables de longue durée, vous pouvez créer un scénario dans lequel les tables ont un long délai avant la recompilation, ou les utilisateurs peuvent avoir du retard à obtenir les résultats des requêtes lorsqu'une table est générée par la base de données.

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

Plusieurs facteurs peuvent affecter le temps nécessaire à la recompilation des tables:

  • Votre administrateur Looker a peut-être modifié l'intervalle entre les vérifications du déclencheur du générateur, à l'aide du paramètre Datagroup and PDT Maintenance Schedule (Planification de maintenance des groupes de données et des tables dérivées persistantes) de votre connexion à la base de données.
  • Le générateur de Looker ne lance pas de nouveau cycle tant qu'il n'a pas terminé toutes les vérifications et recompilations de PDT du dernier cycle. Par conséquent, si vous disposez de compilations de PDT de longue durée, le cycle de régénération de Looker peut ne pas être aussi fréquent que le paramètre Calendrier de maintenance des PDT et des groupes de données.
  • 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 de recompilations simultanées autorisé du régénérateur à l'aide du champ Nombre maximal de connexions du générateur PDT dans les paramètres d'une connexion.
  • Toutes les tables dérivées persistantes et les tables agrégées déclenchées par la même datagroup seront recréées lors du même processus de régénération. Cela peut être une charge de travail importante si vous utilisez de nombreuses tables dans le groupe de données, directement ou en raison de dépendances en cascade.

En plus des considérations précédentes, dans certains cas, vous devez éviter d'ajouter une persistance à une table dérivée:

  • Lorsque les tables dérivées sont étendues : chaque extension d'une PDT crée une copie de la table dans votre base de données.
  • Lorsque des tables dérivées sont utilisées, utilisez des filtres modélisés ou des paramètres Liquid. La persistance n'est pas disponible pour les tables dérivées qui utilisent des filtres modélisés 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, une copie de la table est créée dans votre base de données pour chaque valeur d'attribut utilisateur spécifiée.
  • Lorsque les données sous-jacentes changent fréquemment et que le dialecte de votre base de données n'est pas compatible avec les PDT incrémentiels
  • Lorsque le coût et le temps nécessaires à la création de tables dérivées persistantes 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 de PDT à grande échelle avec l'API

Plus vous créez des PDT sur votre instance, plus la surveillance et la gestion des PDT qui s'actualisent selon un calendrier variable se compliquent. Pensez à utiliser l'intégration d'Apache Airflow de Looker pour gérer vos planifications de PDT parallèlement à vos autres processus ETL et ELT.

Surveillance et correction de tables PDT

Si vous utilisez des PDT, et en particulier les PDT en cascade, il peut être utile de consulter leur état. Vous pouvez consulter la page d'administration des tables dérivées persistantes de Looker pour consulter l'état de vos tables dérivées persistantes. Pour en savoir plus, consultez la page de documentation Paramètres d'administration – Tables dérivées persistantes.

Lorsque vous tentez de résoudre le problème des tables dérivées persistantes:

  • Faites particulièrement attention à la distinction entre les tables de développement et les tables de production lorsque vous examinez le journal des événements PDT.
  • 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 vous avez apporté des modifications, vous devrez peut-être mettre à jour les paramètres de Connexion dans la section Administration de Looker, puis éventuellement redémarrer Looker pour rétablir la fonctionnalité de PDT normale.
  • 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 une seule colonne. Pour ce faire, vous pouvez les exécuter dans l'exécuteur SQL. (L'application d'un LIMIT protège contre les requêtes incontrôlées.) Pour en savoir plus sur l'utilisation de l'exécuteur SQL pour déboguer les tables dérivées, consultez l'article Utiliser l'exécuteur SQL 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. (Assurez-vous d'appliquer un LIMIT dans l'exécuteur SQL pour que les requêtes restent raisonnables.)
  • Pour les tables dérivées de SQL, évitez d'utiliser des expressions de table courantes (CTE). L'utilisation de CTE avec des DT crée des instructions WITH imbriquées qui peuvent entraîner l'échec des PDT sans avertissement. Utilisez plutôt le langage SQL pour votre CTE afin de créer un transfert de données secondaire et de le référencer à partir de votre premier transfert de données à l'aide de la syntaxe ${derived_table_or_view_name.SQL_TABLE_NAME}.
  • Vérifiez que toutes les tables dont dépend la PDT (qu'il s'agisse de tables normales ou de PDT elles-mêmes) 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 tous les verrous exclusifs de la table à partir desquels Looker crée une PDT. En cas de verrouillage exclusif d'une table, Looker ne pourra pas acquérir un 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 Interroger les commentaires pour les tables dérivées persistantes sur cette page.

Commentaires de requête pour les tables PDT

Les administrateurs de bases de données distinguent aisément les requêtes normales de celles qui génèrent des tables PDT. Looker ajoute des commentaires à l'instruction CREATE TABLE ... AS SELECT ..., qui inclut le modèle et la vue LookML de la PDT, ainsi qu'un identifiant unique (slug) pour l'instance Looker. Si la PDT est générée pour le compte 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 de PDT apparaît dans l'onglet SQL d'Explore si Looker a dû générer un PDT pour la requête d'exploration. Dans ce cas, le commentaire apparaît en haut de l'instruction SQL.

Enfin, le commentaire de la génération de PDT apparaît dans le champ Message de l'onglet Infos de la fenêtre pop-up Détails de la requête pour chaque requête de la page d'administration Requêtes.

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

En cas d'échec d'une table PDT, voici ce qui se produit lors de l'interrogation de cette table :

  • 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 Documentation sur la mise en cache des requêtes.
  • Si les résultats ne se trouvent pas dans le cache, Looker extrait les résultats de la PDT dans la base de données, s'il existe une version valide de cette PDT.
  • 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 PDT ne peut pas être recréée, Looker renvoie une erreur pour une requête. Le générateur de Looker tentera de recompiler la PDT la prochaine fois que cette requête est interrogée ou la prochaine fois que sa stratégie de persistance déclenche une recompilation.

Avec les PDT en cascade, la même logique s'applique, sauf que pour les 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 PDT dépendante interroge essentiellement la PDT sur laquelle elle s'appuie, de sorte que la stratégie de persistance d'une table peut déclencher la recompilation des PDT en haut de la chaîne.

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

En cas de défaillance de TABLE_B, tout le comportement standard (sans cassage) s'applique à TABLE_B: si TABLE_B est interrogé, Looker commence par utiliser le cache pour renvoyer les résultats, puis tente d'utiliser une version précédente de la table si possible, puis tente de recompiler la table. Enfin, renvoie une erreur si TABLE_B ne peut pas recompiler. Looker réessaie de recompiler TABLE_B lorsque la table est interrogée ou lorsque la stratégie de persistance de la table déclenche ensuite une recompilation.

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

  • Looker essaiera d'utiliser le cache pour la requête sur TABLE_C.
  • Si les résultats ne sont pas dans le cache, Looker essaie d'extraire les résultats de TABLE_C dans la base de données.
  • S'il n'existe pas de version valide de TABLE_C, Looker va tenter de recompiler TABLE_C, ce qui crée une requête sur TABLE_B.
  • Looker tentera ensuite de recompiler TABLE_B (qui échouera si TABLE_B n'a pas été corrigé).
  • Si TABLE_B ne peut pas être recréé, cela signifie que TABLE_C ne peut pas être recompilé. Looker renverra donc une erreur pour la requête sur TABLE_C.
  • Looker tentera ensuite de recompiler TABLE_C conformément à sa stratégie de persistance habituelle, ou la prochaine fois que la PDT est interrogée (ce qui inclut la prochaine tentative de compilation de TABLE_D, car TABLE_D dépend de TABLE_C).

Une fois que vous avez résolu le problème avec TABLE_B, TABLE_B et chaque table dépendante tentent d'être recompilées en fonction de leurs stratégies de persistance ou la prochaine fois qu'elles sont interrogées (y compris la prochaine fois qu'une PDT tente de recompiler). 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 Tableaux persistants en mode développement de cette page. Vous pouvez également utiliser une exploration pour exécuter une requête sur TABLE_D, puis recompiler manuellement les PDT pour la requête, ce qui forcera la recompilation de tous les PDT en montée dans la cascade de dépendances.

Améliorer les performances des PDT

Lorsque vous créez des tables dérivées persistantes, les performances peuvent poser problème. L'interrogation de la table peut être lente, en particulier lorsqu'elle est très volumineuse, tout comme 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 le tri et l'indexation des données dans la PDT.

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

Avec des ensembles de données particulièrement volumineux, comporter plusieurs lignes ralentit les requêtes sur une PDT. Si vous n'interrogez que des données récentes uniquement, envisagez d'ajouter un filtre à la clause WHERE de votre PDT qui limite la table à 90 jours ou moins. De cette façon, seules les données pertinentes seront ajoutées à la table chaque fois qu'elle sera recréée, ce qui permettra d'exécuter des requêtes beaucoup plus rapidement. Vous pouvez ensuite créer un PDT distinct, plus important, pour l'analyse historique afin de permettre des requêtes rapides pour des données récentes et la possibilité d'interroger d'anciennes données.

Utilisation de indexes, sortkeys ou distribution

Lorsque vous créez une PDT volumineuse, 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 aux champs d'ID ou de date, et le paramètre distribution au niveau du champ utilisé pour la jointure.

Les paramètres suivants contrôlent la façon dont les données de la PDT sont triées et indexées. Ces paramètres sont facultatifs, mais fortement 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. Ainsi, les E/S entre nœuds sont réduites.
  • Pour Redshift, définissez le paramètre distribution_style sur all pour demander à la base de données de conserver une copie complète des données sur chaque nœud. Cela permet souvent de minimiser les E/S entre les nœuds lorsque des tables de petite taille sont jointes de manière passive. 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 lorsque distribution n'est pas spécifié.
  • Pour Redshift, utilisez le paramètre sortkeys. Les valeurs spécifient les colonnes de la PDT qui sont utilisées pour trier les données sur le disque afin de faciliter la recherche. Sur Redshift, vous pouvez utiliser sortkeys ou indexes, mais pas les deux. Exemple :
* On most databases, use the [`indexes`](/reference/view-params/indexes) parameter. The values specify which columns of the PDT are indexed. (On Redshift, indexes are used to generate interleaved sort keys.)