Aller au contenu principal
Dernière mise à jour le

Qu'est-ce qu'une vue ?

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

Cet article décrit les vues que vous pouvez créer dans Databricks et fournit une explication des permissions et du compute requis pour les query.

Pour obtenir des informations sur la création de vues, consultez :

Vues dans Unity Catalog​

Dans Unity Catalog, les vues se situent au troisième niveau de l'espace de noms à trois niveaux (catalog.schema.view) :

Schéma du modèle d'objet Unity Catalog, axé sur la vue

Une vue stocke le texte d'une query généralement par rapport à une ou plusieurs sources de données ou tables dans le metastore. Dans Databricks, une vue est équivalente à un DataFrame Spark persisté en tant qu'objet dans un schéma. Contrairement aux DataFrames, vous pouvez query les vues depuis n'importe où dans Databricks, à condition d'y être autorisé. La création d'une vue ne traite ni n'écrit aucune donnée. Seul le texte de la query est enregistré dans le metastore du schéma associé.

remarque

Les vues peuvent avoir des sémantiques d'exécution différentes si elles sont basées sur des sources de données autres que les tables Delta. Databricks vous recommande de toujours définir les vues en référençant les sources de données à l'aide d'un nom de table ou de vue. La définition de vues sur des datasets en spécifiant un chemin d'accès ou un URI peut entraîner des exigences de gouvernance des données confuses.

Vues de métriques​

Les vues métriques dans Unity Catalog définissent des indicateurs métier réutilisables qui sont gérés de manière centralisée et accessibles à tous les utilisateurs dans votre Workspace. Une vue métrique abstrait la logique derrière les KPI couramment utilisés — tels que les revenus, le nombre de clients ou le taux de conversion — afin qu'ils puissent être interrogés de manière cohérente sur les tableaux de bord, les Notebooks et les rapports. Chaque vue métrique spécifie un ensemble de mesures et de dimensions basées sur une table source, une vue ou une requête SQL. Les vues de métriques sont définies en YAML et interrogées à l'aide de SQL.

L'utilisation des vues métriques permet de réduire les incohérences dans les définitions de métriques qui pourraient autrement être dupliquées sur plusieurs outils et workflows. Pour en savoir plus, consultez Vues métriques.

Vues matérialisées​

Les vues matérialisées calculent et mettent à jour de manière incrémentielle les résultats renvoyés par la query de définition. Les vues matérialisées sur Databricks sont un type spécial de table Delta. Alors que toutes les autres vues sur 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 en utilisant soit un calendrier de refresh, soit l'exécution d'une mise à jour de pipeline.

Vous pouvez enregistrer des vues matérialisées dans Unity Catalog à l'aide de Databricks SQL ou les définir dans le cadre des LakeFlow Pipelines. Voir Utiliser les vues matérialisées autonomes et Spark Declarative Pipelines.

Vues temporaires​

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

  • Dans les notebooks et les jobs, les vues temporaires sont limitées au niveau du notebook ou du script. Ils ne peuvent pas être référencés en dehors du notebook dans lequel ils sont déclarés, et n'existent plus lorsque le notebook se détache du cluster.
  • Dans Databricks SQL, les vues temporaires sont limitées au niveau de la query. Plusieurs déclarations au sein de la même query peuvent utiliser la vue temporaire, mais elle ne peut pas être référencée dans d'autres queries, même au sein du 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 de données. Voir Créer une vue dynamique.

Vues dans le Hive metastore (hérité)​

Vous pouvez définir des vues Hive héritées par rapport à n'importe quelle source de données et les enregistrer dans le Hive metastore hérité. Databricks recommande de migrer toutes les vues Hive héritées vers Unity Catalog. Voir les vues dans Hive metastore.

Vue temporaire globale Hive (hérité)​

Les vues temporaires globales sont une fonctionnalité Databricks héritée qui vous permet d'enregistrer une vue temporaire disponible pour toutes les charges de travail s'exécutant sur une ressource de compute. Les vues temporaires globales sont un vestige hérité de Hive et HDFS. Databricks déconseille d'utiliser les vues temporaires globales.

Conditions requises pour interroger les vues​

Pour lire les vues enregistrées dans Unity Catalog, les autorisations requises dépendent du type de compute, de la version de Databricks Runtime et du mode d’accès.

remarque

Pour toutes les vues, les contrôles d'autorisation sont effectués à la fois sur la vue elle-même et sur les tables et vues sous-jacentes sur lesquelles la vue est basée. L'utilisateur dont les autorisations sont vérifiées pour les tables et vues sous-jacentes dépend du compute. Pour les éléments suivants, Unity Catalog vérifie les autorisations du propriétaire de la vue sur les données sous-jacentes :

  • SQL Warehouse.
  • Compute Standard (anciennement compute partagé).
  • Compute dédié (anciennement compute à utilisateur unique) sur Databricks Runtime 15.4 LTS et versions supérieures avec contrôle d'accès détaillé activé.

Pour le compute dédié sur Databricks Runtime 15.3 et versions antérieures, Unity Catalog vérifie à la fois les autorisations du propriétaire de la vue et celles de l'utilisateur de la vue sur les données sous-jacentes.

Ce comportement est reflété dans les exigences listées ci-dessous. Dans les deux cas, le propriétaire de la vue doit maintenir les autorisations sur les données sous-jacentes afin que les utilisateurs de la vue puissent y accéder.

  • Pour toutes les ressources compute, vous devez disposer de SELECT sur la vue elle-même, de USE CATALOG sur son catalogue parent et de USE SCHEMA sur son schéma parent. Ceci s'applique à tous les types de compute qui prennent en charge Unity Catalog, y compris les SQL Warehouses, 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 exécutant Databricks Runtime 15,3 et versions antérieures qui utilisent le mode d'accès dédié, vous devez également disposer de SELECT sur toutes les tables et vues référencées par la vue, en plus de USE CATALOG sur leurs catalogues parents et de 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 voulez éviter l'obligation d'avoir SELECT sur les tables et vues sous-jacentes, vérifiez que votre Workspace est activé pour le compute Serverless .

Le compute serverless gère le filtrage des données, ce qui permet d'accéder à une vue sans nécessiter d'autorisations sur ses tables et vues sous-jacentes. Sachez que vous pourriez encourir des frais de compute serverless lorsque vous utilisez un compute dédié pour query des vues. Pour plus d'informations, consultez le contrôle d'accès précis sur le compute dédié.

Sur cette page