Objets de données dans le Databricks Lakehouse

  • Article

Le Databricks Lakehouse organise les données stockées avec Delta Lake dans le stockage d’objets cloud en utilisant des relations familières, telles que la base de données, les tables et les vues. Ce modèle réunit la plupart des avantages d’un entrepôt de données d’entreprise, tout en offrant la scalabilité et la flexibilité d’un lac de données. Apprenez-en davantage sur le fonctionnement de ce modèle ainsi que sur la relation entre les données d’objet et les métadonnées afin de pouvoir appliquer les meilleures pratiques lors de la conception et de l’implémentation de Databricks Lakehouse pour votre organisation.

Qu’est-ce qu’un objet de données dans le lakehouse Databricks ?

L’architecture Databricks Lakehouse combine les données stockées à l’aide du protocole Delta Lake dans le stockage d’objets cloud avec les métadonnées inscrites dans un metastore. Le Databricks Lakehouse compte cinq principaux objets :

  • Catalogue : regroupement de bases de données.
  • Base de données ou schéma : regroupement d’objets dans un catalogue. Les bases de données contiennent des tables, des vues et des fonctions.
  • Table : collection de lignes et de colonnes stockées sous forme de fichiers de données dans le stockage d’objets.
  • Vue : requête généralement enregistrée sur une ou plusieurs tables ou sources de données.
  • Fonction : logique enregistrée qui retourne une valeur scalaire ou un ensemble de lignes.

Unity Catalog object model diagram

Pour plus d’informations sur la sécurisation des objets avec le catalogue Unity, consultez la section Modèle d’objets sécurisables.

Qu’est-ce qu’un metastore ?

Le metastore contient toutes les métadonnées qui définissent des objets de données dans le lakehouse. Azure Databricks fournit les options de metastore suivantes :

  • Metastore Unity Catalog : Unity Catalog fournit des fonctionnalités centralisées de contrôle d’accès, d’audit, de traçabilité et de découverte des données. Vous créez des metastores Unity Catalog au niveau du compte Azure Databricks, et un seul metastore peut être utilisé dans plusieurs espaces de travail.

    Chaque metastore Unity Catalog est configuré avec un emplacement de stockage racine dans un conteneur Azure Data Lake Storage Gen2 dans votre compte Azure. Cet emplacement de stockage est utilisé par défaut pour stocker les données des tables managées.

    Dans Unity Catalog, les données sont sécurisées par défaut. Initialement, les utilisateurs n’ont pas accès aux données d’un metastore. L’accès peut être accordé par un administrateur de metastore ou le propriétaire d’un objet. Les objets sécurisables dans Unity Catalog sont hiérarchiques et les privilèges sont hérités vers le bas. Unity Catalog offre un emplacement unique pour administrer les stratégies d’accès aux données. Les utilisateurs peuvent accéder aux données dans Unity Catalog à partir de n’importe quel espace de travail auquel le metastore est attaché. Pour plus d’informations, consultez Gérer les privilèges dans Unity Catalog.

  • Metastore Hive intégré (hérité) : chaque espace de travail Azure Databricks inclut un metastore Hive intégré en tant que service managé. Une instance du metastore est déployée sur chaque cluster et accède en toute sécurité aux métadonnées à partir d’un référentiel central pour chaque espace de travail client.

    Le metastore Hive fournit un modèle de gouvernance des données moins centralisé que Unity Catalog. Par défaut, un cluster permet à tous les utilisateurs d’accéder à toutes les données gérées par le metastore Hive intégré de l’espace de travail, sauf si le contrôle d’accès aux tables est activé pour ce cluster. Pour plus d’informations, consultez Contrôle d’accès aux tables du metastore Hive (hérité).

    Les contrôles d’accès aux tables ne sont pas stockés au niveau du compte et doivent donc être configurés séparément pour chaque espace de travail. Pour tirer parti du modèle centralisé et simplifié de gouvernance des données fourni par Unity Catalog, Databricks vous recommande de mettre à niveau les tables gérées par le metastore Hive de votre espace de travail vers le metastore Unity Catalog.

  • Metastore Hive externe (hérité) : vous pouvez également fournir votre propre metastore à Azure Databricks. Les clusters Azure Databricks peuvent se connecter à des metastores Apache Hive externes existants. Vous pouvez utiliser le contrôle d’accès aux tables pour gérer les autorisations dans un metastore externe. Les contrôles d’accès aux tables ne sont pas stockés dans le metastore externe et doivent donc être configurés séparément pour chaque espace de travail. Databricks vous recommande d’utiliser plutôt Unity Catalog pour sa simplicité et son modèle de gouvernance centré sur les comptes.

Quel que soit le metastore que vous utilisez, Azure Databricks stocke toutes les données de tables dans le stockage d’objets de votre compte cloud.

Qu’est-ce qu’un catalogue ?

Un catalogue est l’abstraction la plus élevée (ou le grain le plus grossier) du modèle relationnel Databricks Lakehouse. Chaque base de données est associée à un catalogue. Les catalogues existent en tant qu’objets dans un metastore.

Avant l’introduction du catalogue Unity, Azure Databricks utilisait un espace de noms à deux niveaux. Les catalogues représentent le troisième niveau du modèle d’espace de noms du catalogue Unity :

catalog_name.database_name.table_name

Le metastore Hive intégré ne prend en charge qu’un seul catalogue, hive_metastore.

Qu’est-ce qu’une base de données ?

Une base de données est une collection d’objets de données, par exemple des tables ou des vues (également appelées « relations ») et des fonctions. Dans Azure Databricks, les termes « schéma » et « base de données » sont utilisés indifféremment (contrairement à de nombreux autres systèmes relationnels, pour lesquels une base de données est une collection de schémas).

Les bases de données sont toujours associées à un emplacement sur le stockage d’objets cloud. Vous pouvez éventuellement spécifier un paramètre LOCATION lors de l’inscription d’une base de données, en gardant à l’esprit que :

  • Le paramètre LOCATION associé à une base de données est toujours considéré comme un emplacement managé.
  • La création d’une base de données ne crée aucun fichier à l’emplacement cible.
  • Le paramètre LOCATION d’une base de données détermine l’emplacement par défaut des données de toutes les tables inscrites dans cette base de données.
  • L’annulation d’une base de données a pour effet d’annuler de manière récursive toutes les données et tous fichiers stockés dans un emplacement managé.

Cette interaction entre les emplacements gérés par la base de données et les fichiers de données est très importante. Pour éviter de supprimer accidentellement des données :

  • Ne partagez pas d’emplacements de base de données entre plusieurs définitions de base de données.
  • N’inscrivez pas de base de données à un emplacement qui contient déjà des données.
  • Pour gérer le cycle de vie des données indépendamment de la base de données, enregistrez les données dans un emplacement qui n’est imbriqué sous aucun emplacement de base de données.

Qu’est-ce qu’une table ?

Une table Azure Databricks est une collection de données structurées. Une table Delta stocke les données sous la forme d’un répertoire de fichiers sur le stockage d’objets cloud et enregistre les métadonnées de table dans le metastore au sein d’un catalogue et d’un schéma. Comme Delta Lake est le fournisseur de stockage par défaut pour les tables créées dans Azure Databricks, toutes les tables créées dans Databricks sont, par défaut, des tables Delta. Étant donné que les tables Delta stockent des données dans le stockage d’objets cloud et fournissent des références aux données via un metastore, les utilisateurs d’une organisation peuvent accéder aux données à l’aide de leurs API préférées ; sur Databricks, cela englobe SQL, Python, PySpark, Scala et R.

Notez qu’il est possible de créer des tables sur Databricks qui ne sont pas des tables Delta. Ces tables ne sont pas sauvegardées par Delta Lake et ne fournissent pas les transactions ACID et les performances optimisées des tables Delta. Les tables comprises dans cette catégorie incluent les tables inscrites sur les données dans des systèmes externes et les tables inscrites sous d’autres formats de fichiers dans le lac de données. Consultez Se connecter aux sources de données.

Il existe deux types de tables dans des tables Databricks : managé et non managé (ou externe).

Notes

La distinction entre les tables dynamiques et les tables dynamiques de diffusion en continu n’est pas appliquée du point de vue de la table dans Delta Live Tables.

Qu’est-ce qu’une table managée ?

Azure Databricks gère à la fois les métadonnées et les données d’une table managée ; lorsque vous supprimez une table, vous supprimez également les données sous-jacentes. Les analystes de données et d’autres utilisateurs qui travaillent principalement dans SQL peuvent préférer ce comportement. Les tables managées sont utilisées par défaut lors de la création d’une table. Les données d’une table managée résident dans le paramètre LOCATION de la base de données sur laquelle il est inscrit. Cette relation managée entre l’emplacement des données et la base de données signifie que pour déplacer une table managée vers une nouvelle base de données, vous devez réécrire toutes les données vers le nouvel emplacement.

Il existe plusieurs façons de créer des tables managées, à savoir :

CREATE TABLE table_name AS SELECT * FROM another_table

CREATE TABLE table_name (field_name1 INT, field_name2 STRING)

df.write.saveAsTable("table_name")

Qu’est-ce qu’une table non managée ?

Azure Databricks gère uniquement les métadonnées des tables non managées (externes). Lorsque vous supprimez une table, les données sous-jacentes ne sont pas affectées. Les tables non managées spécifient toujours un paramètre LOCATION lors de la création de la table ; vous pouvez inscrire un répertoire existant de fichiers de données en tant que table ou fournir un chemin d’accès lorsque vous définissez une table pour la première fois. Étant donné que les données et les métadonnées sont gérées indépendamment, vous pouvez renommer une table ou l’inscrire dans une nouvelle base de données sans avoir à déplacer de données. Les ingénieurs de données préfèrent souvent les tables non managées et la flexibilité qu’elles offrent pour les données de production.

Il existe plusieurs façons de créer des tables non managées, à savoir :

CREATE TABLE table_name
USING DELTA
LOCATION '/path/to/existing/data'

CREATE TABLE table_name
(field_name1 INT, field_name2 STRING)
LOCATION '/path/to/empty/directory'

df.write.option("path", "/path/to/empty/directory").saveAsTable("table_name")

Qu’est-ce qu’une 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 Databricks, une vue équivaut à un DataFrame Spark conservé en tant qu’objet dans une base de données. Contrairement aux DataFrames, vous pouvez interroger des vues à partir de n’importe quelle partie du produit Databricks, en supposant que vous disposez de l’autorisation requise. La création d’une vue ne traite ni n’écrit aucune donnée ; seul le texte de la requête est inscrit dans le metastore de la base de données associée.

Qu’est-ce qu’une vue temporaire ?

Une vue temporaire possède 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 selon l’environnement que vous utilisez :

  • Dans les notebooks et les travaux, les vues temporaires sont limitées au niveau du notebook ou du script. Elles ne peuvent pas être référencées en dehors du notebook dans lequel elles sont déclarées et n’existent plus lorsque le notebook est détaché 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.
  • Les vues temporaires globales sont étendues au niveau du cluster et peuvent être partagées entre des notebooks ou des travaux qui partagent des ressources de calcul. Databricks recommande d’utiliser des vues avec des listes de contrôle d’accès de table appropriées plutôt que des vues temporaires globales.

Qu’est-ce qu’une fonction ?

Les fonctions vous permettent d’associer une logique définie par l’utilisateur à une base de données. Les fonctions peuvent retourner des valeurs scalaires ou des ensembles de lignes. Les fonctions sont utilisées pour agréger des données. Azure Databricks vous permet d’enregistrer des fonctions dans différents langages en fonction de votre contexte d’exécution, SQL étant largement pris en charge. Vous pouvez utiliser des fonctions pour fournir un accès managé à une logique personnalisée dans toutes sortes de contextes sur le produit Databricks.

Comment fonctionnent les objets relationnels dans Delta Live Tables ?

Delta Live Tables utilise une syntaxe déclarative pour définir et gérer le déploiement de DDL, DML et de l’infrastructure. Delta Live Tables utilise le concept de « schéma virtuel » pendant la planification et l’exécution de la logique. Delta Live Tables peut interagir avec d’autres bases de données dans votre environnement Databricks et peut publier et conserver des tables pour lancer des requêtes ailleurs en spécifiant une base de données cible dans les paramètres de configuration du pipeline.

Toutes les tables créées dans Delta Live Tables sont des tables Delta. Lorsque vous utilisez Unity Catalog avec Delta Live Tables, toutes les tables sont des tables managées par Unity Catalog. Si la solution Unity Catalog n’est pas active, les tables peuvent être déclarées en tant que tables managées ou non managées.

Bien qu’il soit possible de déclarer les vues dans Delta Live Tables, elles doivent être considérées comme des vues temporaires étendues au pipeline. Les tables temporaires dans Delta Live Tables forment un concept unique : ces tables conservent les données dans le stockage, mais ne publient pas de données dans la base de données cible.

Certaines opérations, telles que APPLY CHANGES INTO, inscrivent à la fois une table et une vue dans la base de données ; le nom de la table commence par un trait de soulignement (_) et la vue prend le nom de table déclaré comme cible de l’opération APPLY CHANGES INTO. La vue interroge la table masquée correspondante pour matérialiser les résultats.