Partager via


Qu’est-ce qu’une vue ?

Une vue est un objet en lecture seule qui est le résultat d’une requête sur une ou plusieurs tables et vues dans un metastore de l'Unity Catalog. Vous pouvez créer une vue à partir de tables et d’autres vues dans plusieurs schémas ou catalogues.

Cet article décrit les vues que vous pouvez créer dans Azur  Databricks et fournit une explication des autorisations et du calcul nécessaires pour les interroger.

Pour plus d’informations sur la création de vues, consultez :

Vues dans Unity Catalog

Dans le catalogue Unity, les vues se trouvent au troisième niveau de l’espace de noms de trois niveaux (catalog.schema.view) :

Diagramme du modèle objet Unity Catalog, axé sur la vue

Une vue stocke le texte d’une requête généralement sur une ou plusieurs sources de données ou tables dans le metastore. Dans Azure Databricks, une vue équivaut à un DataFrame Spark conservé en tant qu’objet dans un schéma. Contrairement aux DataFrames, vous pouvez interroger des vues n’importe où dans Azure Databricks, en supposant que vous disposez de l’autorisation de le faire. La création d’une vue ne traite ni n’écrit aucune donnée. Seul le texte de requête est inscrit dans le metastore dans le schéma associé.

Remarque

Les vues peuvent avoir une sémantique d’exécution différente si elles sont sauvegardées par des sources de données autres que des tables Delta. Databricks recommande de toujours définir des vues en référençant des sources de données à l’aide d’un nom de table ou de vue. La définition de vues sur des jeux de données en spécifiant un chemin d’accès ou un URI peut entraîner des exigences de gouvernance des données déroutantes.

Vues des indicateurs

Les vues de métriques dans le catalogue Unity définissent des métriques métier réutilisables qui sont gérées de manière centralisée et accessibles à tous les utilisateurs de votre espace de travail. Une vue des métriques extrait la logique derrière les indicateurs de performance clés couramment utilisés, tels que le chiffre d’affaires, le nombre de clients ou le taux de conversion, afin qu’elles puissent être interrogées de manière cohérente entre les tableaux de bord, les notebooks et les rapports. Chaque vue de métrique spécifie un ensemble de mesures et de dimensions en fonction d’une table source, d’une vue ou d’une requête SQL. Les vues de métriques sont définies dans YAML et interrogées à l’aide de SQL.

L’utilisation de vues de métriques permet de réduire les incohérences dans les définitions de métriques susceptibles d’être dupliquées entre plusieurs outils et flux de travail. Pour en savoir plus, consultez les vues métriques .

Vues matérialisées

Les vues matérialisées calculent et mettent à jour de manière incrémentielle les résultats retournés par la requête de définition. Les vues matérialisées sur Azure Databricks sont un type spécial de table Delta. Alors que toutes les autres vues sur Azure Databricks calculent les résultats en évaluant la logique qui a défini la vue lorsqu’elle est interrogée, les vues matérialisées traitent les résultats et les stockent dans une table sous-jacente lorsque les mises à jour sont traitées à l’aide d’une planification d’actualisation ou d’exécution d’une mise à jour de pipeline.

Vous pouvez inscrire des vues matérialisées dans le catalogue Unity à l’aide de Databricks SQL ou les définir dans le cadre de pipelines déclaratifs Lakeflow. Consultez Utiliser des vues matérialisées dans Databricks SQL et Lakeflow Declarative Pipelines.

Vues temporaires

Une vue temporaire a une étendue et une persistance limitées et n’est pas inscrite dans un schéma ou un catalogue. La durée de vie d’une vue temporaire diffère en fonction de l’environnement que vous utilisez :

  • Dans les notebooks et les travaux, les vues temporaires sont délimitées au niveau du notebook ou du script. Ils ne peuvent pas être référencés en dehors du bloc-notes dans lequel ils sont déclarés et n’existent plus lorsque le bloc-notes se détache du cluster.
  • Dans Databricks SQL, les vues temporaires sont étendues au niveau de la requête. Plusieurs instructions au sein de la même requête peuvent utiliser la vue temporaire, mais elles ne peuvent pas être référencées dans d’autres requêtes, y compris dans le même tableau de bord.

Vues dynamiques

Les vues dynamiques peuvent être utilisées pour fournir un contrôle d’accès au niveau des lignes et des colonnes, en plus du masquage des données. Consultez Créer une vue dynamique.

Vues dans le metastore Hive (hérité)

Vous pouvez définir des vues Hive héritées sur n’importe quelle source de données et les inscrire dans le metastore Hive hérité. Databricks recommande de migrer toutes les vues Hive héritées vers le catalogue Unity. Consultez Vues dans le metastore Hive.

Vue temporaire globale Hive (hérité)

Les vues temporaires globales sont une fonctionnalité Azure Databricks héritée qui vous permet d’inscrire une vue temporaire disponible pour toutes les charges de travail exécutées sur une ressource de calcul. Les vues temporaires globales sont des vestiges hérités de Hive et HDFS. Databricks recommande de ne pas utiliser des vues temporaires globales.

Conditions requises pour interroger des vues

Pour lire les vues inscrites dans le catalogue Unity, les autorisations requises dépendent du type de calcul, de la version de Databricks Runtime et du mode d’accès.

Remarque

Pour toutes les vues, les vérifications d’autorisation sont effectuées à la fois sur la vue elle-même et sur les tables et vues sous-jacentes sur lesquelles repose la vue. Pour les tables et vues sous-jacentes, l'utilisateur dont les autorisations sont vérifiées dépend des ressources de calcul. Pour ce qui suit, Unity Catalog vérifie les autorisations du propriétaire de l’affichage sur les données sous-jacentes :

  • Entrepôts de données SQL.
  • Calcul standard (anciennement calcul partagé).
  • Calcul dédié (anciennement calcul mono-utilisateur) sur Databricks Runtime 15.4 LTS et versions ultérieures avec un contrôle d’accès affiné activé.

Pour le calcul dédié sur Databricks Runtime 15.3 et ci-dessous, Unity Catalog vérifie les autorisations du propriétaire de la vue et les autorisations de l’utilisateur de vue sur les données sous-jacentes.

Ce comportement est reflété dans les exigences répertoriées ci-dessous. Dans les deux cas, le propriétaire de la vue doit conserver les autorisations sur les données sous-jacentes pour permettre aux utilisateurs d’accéder à la vue.

  • Pour toutes les ressources de calcul, vous devez avoir SELECT sur la vue elle-même, USE CATALOG sur son catalogue parent et USE SCHEMA sur son schéma parent. Cela s’applique à tous les types de calcul qui prennent en charge le catalogue Unity, notamment les entrepôts SQL, les clusters en mode d’accès standard et les clusters en mode d’accès dédié sur Databricks Runtime 15.4 et versions ultérieures.
  • Pour les clusters sur Databricks Runtime 15.3 et versions antérieures qui utilisent le mode d’accès dédié, vous devez également avoir SELECT sur toutes les tables et vues référencées par la vue, ainsi que USE CATALOG sur leurs catalogues parents et USE SCHEMA sur leurs schémas parents.

Remarque

Si vous utilisez un cluster dédié sur Databricks Runtime 15.4 LTS et versions ultérieures et que vous souhaitez éviter la nécessité d’avoir SELECT sur les tables et vues sous-jacentes, vérifiez que votre espace de travail est activé pour le calcul serverless.

Le calcul serverless gère le filtrage des données, permettant d’accéder à une vue sans avoir besoin d’autorisations sur ses tables et vues sous-jacentes. N’oubliez pas que vous risquez d’être facturé pour le calcul serverless lorsque vous utilisez le calcul dédié pour interroger des vues. Pour plus d’informations, consultez Contrôle d’accès affiné sur le calcul dédié.