materialized_view

Utilisation

view: my_view {
  derived_table: {
    materialized_view: yes
    ...
  }
}
Hiérarchie
view
derived_table
materialized_view
Valeur par défaut
no

Acceptation
Booléen (yes ou no)

Règles spéciales
materialized_view n'est compatible qu'avec certains dialectes

Définition

La fonctionnalité vue matérialisée est une fonction avancée. La quantité de ressources nécessaires à une vue matérialisée dépend de votre dialecte ; vous devez donc comprendre la mise en œuvre des vues matérialisées par votre dialecte. Consultez la documentation relative à votre dialecte pour obtenir des informations sur son comportement et sur la fréquence à laquelle il actualise les données pour les vues matérialisées.

Les vues matérialisées vous permettent d'exploiter la fonctionnalité de votre base de données à rendre persistantes vos tables dérivées dans votre projet Looker. Si votre dialecte de base de données prend en charge les vues matérialisées et que l'option Tables dérivées persistantes est activée dans votre connexion Looker, 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 prises en charge à la fois pour les tables dérivées natives et les tables dérivées basées sur SQL.

Similaire à une table dérivée persistante (PDT), une vue matérialisée est le résultat d'une requête enregistrée sous la forme d'une 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.

Si une table dérivée avec une instruction materialized_view: yes comporte également un paramètre datagroup, sql_trigger_value ou persist_for, l'instruction materialized_view: yes est prioritaire.

Exemple

Cette table dérivée e_flights_pdt comporte l'instruction materialized_view: yes. Une vue matérialisée est donc créée dans le schéma brouillon de la base de données :


view: e_flights_pdt {
  derived_table: {
    materialized_view: yes
    explore_source: ontime {
      column: flight_num {}
      column: carrier {}
      column: arr_date {}
    }
  }
  dimension: flight_num {}
  dimension: carrier {}
  dimension: arr_date {
    type: date
  }
}

Lorsque Looker crée la vue matérialisée

Looker génère des vues matérialisées de la même manière que les autres PDT. Si vous créez la vue matérialisée et que vous l'interrogez en mode Développement, Looker crée une version de développement de la vue matérialisée, qui peut également être utilisée pour la production. Pour en savoir plus, consultez la section Tables persistantes en mode Développement de la page de documentation Tables dérivées dans Looker.

Sinon, la vue matérialisée est créée lors du prochain cycle du régénérateur Looker, une fois le code LookML de la table dérivée associée déployé en production avec materialized_view: yes.

Vues de base de données stables pour les vues matérialisées

Looker crée automatiquement une vue de base de données stable pour chaque vue matérialisée. La vue de base de données stable est créée dans la base de données elle-même, afin de pouvoir être interrogée en dehors de Looker. Il s'agit de la même fonctionnalité de vue stable que celle utilisée avec le publish_as_db_view paramètre.

Looker crée la vue stable lors du prochain cycle du régénérateur Looker, une fois le code LookML de la vue matérialisée déployé en production. Une fois la vue de base de données stable publiée, vous pouvez l'interroger directement.

Les administrateurs ou les utilisateurs disposant de l'autorisation see_pdts peuvent obtenir le nom de la vue de base de données stable à partir de la fenêtre modale Détails de la PDTde la page Tables dérivées persistantes de la section Admin de Looker.

Pour interroger directement une vue matérialisée, ajoutez simplement le nom du schéma brouillon avant le nom de la table. Par exemple, si le nom de la vue de base de données stable est NN_e_redflight_e_redflight_publish_as_db et que le nom du schéma brouillon est tmp, vous pouvez interroger la vue de base de données stable avec une commande comme celle-ci :


SELECT * from tmp.NN_e_redflight_e_redflight_publish_as_db

Exigences concernant les vues matérialisées

Pour utiliser des vues matérialisées dans votre projet Looker, vous avez besoin des éléments suivants :

  • Un dialecte de base de données qui prend en charge les vues matérialisées. Pour obtenir la liste des dialectes compatibles avec les vues matérialisées, consultez la section Compatibilité des dialectes avec les vues matérialisées sur cette page.
  • 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 pour laquelle l'option Tables dérivées persistantes est activée. Cela est généralement défini lors de la configuration initiale de votre connexion Looker (pour des instructions spécifiques à votre dialecte de base de données, lisez la page Dialectes Looker de la documentation). Cependant, vous pouvez également activer des tables PDT pour votre connexion après la configuration initiale.
  • Une connexion Looker avec l'autorisation CREATE TABLE pour le schéma temporaire de votre base de données. Il s'agit de la même autorisation que celle requise pour créer des PDT. De plus, pour créer la vue de base de données stable pour la vue matérialisée, la connexion doit disposer des autorisations CREATE VIEW pour le schéma temporaire de votre base de données. Vous pouvez tester la connexion pour vérifier qu'elle dispose de ces autorisations :
    • Si les PDT sont activées sur la connexion et que celle-ci dispose de l'autorisation CREATE TABLE, le test de connexion renvoie un résultat tel que Can use persistent derived tables in temp schema "docsexamples_scratch" in database "demo_db".
    • Si la connexion autorise les vues stables et qu'elle dispose de l'autorisation CREATE VIEW, le test de connexion renvoie un résultat tel que Can use stable views in temp schema "docsexamples_scratch" in database "flightstats".

Remarques importantes concernant les vues matérialisées

Avec les vues matérialisées, Looker n'entretient ni n'actualise les 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. Voici quelques éléments à prendre en compte lorsque vous créez une vue matérialisée :

  • Certains dialectes présentent des limites pour les vues matérialisées, telles que des intervalles d'actualisation maximaux par défaut et la prise en charge des jointures. Looker ne génère pas d'erreurs LookML concernant les fonctionnalités spécifiques aux dialectes des vues matérialisées. Au lieu de cela, Looker génère une erreur si la vue matérialisée ne parvient pas à être créée, soit en tant qu'événement dans le journal des événements de tables PDT, soit en tant qu'erreur d'exécution si vous essayez d'interroger la vue matérialisée. Consultez la documentation de votre dialecte concernant les limites des vues matérialisées.
  • Certains dialectes vérifient la fraîcheur des requêtes lorsque des vues matérialisées sont interrogées, ce qui peut ajouter un léger délai à l'obtention des résultats des requêtes. Consultez la documentation de votre dialecte pour voir si c'est le cas pour votre dialecte.
  • Certains dialectes tentent d'actualiser la vue matérialisée de manière incrémentale au lieu de la reconstruire complètement. Pour en savoir plus, consultez la documentation de votre dialecte.
  • Si votre vue matérialisée utilise une table de base qui est supprimée de la base de données, vous ne pourrez peut-être pas interroger la vue matérialisée, et les nouvelles versions ne pourront pas être créées.
  • Si une table dérivée avec une instruction materialized_view: yes comporte également un paramètre datagroup, sql_trigger_value ou persist_for, l'instruction materialized_view: yes est prioritaire.
  • Les vues matérialisées sont compatibles avec les mêmes paramètres spécifiques aux dialectes que ceux pris en charge par les tables dérivées en général, tels que le partitionnement, les clés de tri et les index.
  • Dans le cas de tables dérivées en cascade, les vues matérialisées peuvent dépendre des PDT Looker, avec les mises en garde suivantes :
    • Vous ne pouvez pas utiliser de table dérivée avec la stratégie de persistance persist_for dans la définition d'une table dérivée avec materialized_view: yes. Pour les vues matérialisées, la table source d'une vue matérialisée doit toujours être présente dans la base de données. Les tables dérivées persist_for sont supprimées de votre base de données après la durée spécifiée dans le paramètre persist_for. Elles ne sont donc pas garanties d'être présentes dans la base de données.
    • Les PDT sont reconstruites avec un nom unique. Par conséquent, si une vue matérialisée utilise une PDT dans sa définition, la vue matérialisée est mise à jour pour pointer vers la nouvelle version de la PDT chaque fois que la PDT est reconstruite. Cela signifie que la vue matérialisée est essentiellement reconstruite à partir de zéro si une dépendance est complètement reconstruite, ce qui peut avoir un impact sur les performances. Dans ce cas, il est préférable de référencer une table de base en mode ajout uniquement ou de référencer une PDT incrémentale définie à l'aide de Looker.

Compatibilité des dialectes avec les vues matérialisées

La possibilité de transformer une table dérivée en vue matérialisée dépend du dialecte de base de données utilisé par votre connexion Looker. Dans la version actuelle de Looker, les dialectes suivants sont compatibles avec les vues matérialisées :

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