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 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 Tables dérivées persistantes 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.

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 brouillon 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 sera prioritaire.

Exemple

Cette table dérivée e_flights_pdt contient 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 les 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éera une version de développement de la vue matérialisée, qui pourra é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 que le code LookML de la table dérivée associée est 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, ce qui permet de l'interroger en dehors de Looker. Il s'agit de la même fonctionnalité de vue stable que celle utilisée avec le paramètre publish_as_db_view.

Looker crée la vue stable lors du prochain cycle du régénérateur Looker, une fois que le LookML de la vue matérialisée est 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 modalité Détails de la PDT sur la page "Tables dérivées persistantes" de la section Admin de Looker.

Pour interroger directement une vue matérialisée, il vous suffit d'ajouter le nom du schéma temporaire 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 le nom du schéma temporaire 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 configurée avec l'option Tables dérivées persistantes activée. Cette configuration est généralement effectuée lors de la configuration initiale de votre connexion Looker (consultez la page de documentation sur les dialectes Looker pour obtenir des instructions concernant le dialecte de votre base de données). Toutefois, vous pouvez également activer les 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 des autorisations suivantes :
    • Si les PDT sont activées sur la connexion et que la connexion 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'est pas 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. 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, comme les 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 au dialecte 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 sous la forme d'un événement dans le journal des événements de tables PDT, soit sous la forme d'une erreur d'exécution si vous essayez d'interroger la vue matérialisée. Consultez la documentation de votre dialecte pour en savoir plus sur 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 savoir si c'est le cas.
  • Certains dialectes tenteront d'actualiser la vue matérialisée de manière incrémentielle au lieu de la reconstruire entièrement. 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, il est possible que vous ne puissiez pas interroger la vue matérialisée et que les nouvelles versions ne puissent 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 sera prioritaire.
  • Les vues matérialisées sont compatibles avec les mêmes paramètres spécifiques au dialecte que ceux acceptés par les tables dérivées en général, tels que partitionnement, sortkeys et index.
  • Dans le cas des 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. Leur présence dans la base de données n'est donc pas garantie.
    • Les PDT sont reconstruites avec un nom unique. Par conséquent, si une vue matérialisée utilise une PDT dans sa définition, elle sera mise à jour pour pointer vers la nouvelle version de la PDT chaque fois que celle-ci sera reconstruite. Cela signifie que la vue matérialisée sera essentiellement reconstruite à partir de zéro si une dépendance est entièrement reconstruite, ce qui peut avoir un impact sur les performances. Dans ce cas, il est préférable de faire référence à une table de base qui n'est modifiable que par ajout, ou à une table PDT incrémentielle 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