Interroger des données

L’interrogation de données est l’étape fondamentale de l’exécution de presque toutes les tâches pilotées par les données dans Azure Databricks. Quel que soit le langage ou l’outil utilisé, les charges de travail commencent par définir une requête sur une table ou une autre source de données, puis effectuent des actions pour obtenir des insights à partir des données. Cet article décrit les principaux concepts et procédures d’exécution de requêtes sur différentes offres de produits Azure Databricks et inclut des exemples de code que vous pouvez adapter à votre cas d’usage.

Vous pouvez interroger des données de manière interactive à l’aide des éléments suivants :

• Notebooks
• éditeur SQL
• Éditeur de fichiers
• Tableaux de bord

Vous pouvez également exécuter des requêtes dans le cadre des pipelines Delta Live Tables ou des travaux.

Pour obtenir une vue d’ensemble des requêtes de diffusion en continu sur Azure Databricks, consultez Interroger des données de diffusion en continu.

Quelles données pouvez-vous interroger avec Azure Databricks ?

Azure Databricks prend en charge l’interrogation de données dans plusieurs formats et systèmes d’entreprise. Les données que vous interrogez à l’aide d’Azure Databricks se situent dans l’une des deux grandes catégories : les données dans un lakehouse Databricks et des données externes.

Quelles données se trouvent dans un lakehouse Databricks ?

Databricks Data Intelligence Platform stocke toutes vos données dans un lakehouse Databricks par défaut.

Cela signifie que lorsque vous exécutez une instruction CREATE TABLE de base pour créer une table, vous avez créé une table lakehouse. Les données lakehouse ont les propriétés suivantes :

• sont stockées au format Delta Lake ;
• sont stockées dans le stockage d’objets cloud ;
• sont gouvernées par Unity Catalog.

La plupart des données lakehouse sur Azure Databricks sont inscrites dans Unity Catalog en tant que tables managées. Les tables managées fournissent la syntaxe la plus simple et se comportent comme d’autres tables dans la plupart des systèmes de gestion de base de données relationnelle. Les tables managées sont recommandées pour la plupart des cas d’usage et conviennent à tous les utilisateurs qui ne souhaitent pas se soucier des détails de l’implémentation du stockage de données.

Une table non managée ou une table externe est une table inscrite auprès d’une LOCATION spécifiée. Le terme externe peut être trompeur, car les tables Delta externes sont toujours des données lakehouse. Les tables non managées peuvent être préférées par les utilisateurs qui accèdent directement aux tables à partir d’autres clients de lecteur Delta. Pour obtenir une vue d’ensemble des différences dans la sémantique des tables, consultez Qu’est-ce que les tables et les vues ?.

Certaines charges de travail héritées peuvent interagir exclusivement avec les données Delta Lake par le biais de chemins d’accès aux fichiers et ne pas inscrire de tables du tout. Ces données sont toujours des données lakehouse, mais peuvent être plus difficiles à découvrir, car elles ne sont pas inscrites dans Unity Catalog.

Quelles données sont considérées comme externes ?

Toutes les données qui ne se trouvent pas dans un lakehouse Databricks peuvent être considérées comme des données externes. Voici quelques exemples de données externes :

• tables sources contenant une clé étrangère inscrit auprès de Lakehouse ;
• tables dans le metastore Hive soutenu par Parquet ;
• tables externes dans Unity Catalog sauvegardées par JSON ;
• données CSV stockées dans le stockage d’objets cloud ;
• données de diffusion en continu lues à partir de Kafka.

Azure Databricks prend en charge la configuration des connexions à de nombreuses sources de données. Consultez Se connecter aux sources de données.

Bien que vous puissiez utiliser le catalogue Unity pour gouverner l’accès aux tables et les définir sur des données stockées dans plusieurs formats et systèmes externes, Delta Lake est une exigence pour que les données soient prises en compte dans le lakehouse.

Delta Lake fournit toutes les garanties transactionnelles dans Azure Databricks, qui sont essentielles pour maintenir l’intégrité et la cohérence des données. Si vous souhaitez en savoir plus sur les garanties transactionnelles sur les données Azure Databricks et pourquoi elles sont importantes, consultez Quelles sont les garanties ACID sur Azure Databricks ?.

La plupart des utilisateurs Azure Databricks interrogent une combinaison de données lakehouse et de données externes. La connexion avec des données externes est toujours la première étape pour l’ingestion des données et les pipelines ETL qui apportent des données dans le lakehouse. Pour obtenir des informations sur l’ingestion des données, consultez l’article Ingérer des données dans Databricks Lakehouse.

Interroger des tables par nom

Pour toutes les données inscrites en tant que table, Databricks recommande d’interroger à l’aide du nom de la table.

Si vous utilisez Unity Catalog, les tables utilisent un espace de noms à trois niveaux au format suivant : <catalog-name>.<schema-name>.<table-name>.

Sans Unity Catalog, les identificateurs de table utilisent le format <schema-name>.<table-name>.

L’interrogation par nom de table est prise en charge dans tous les contextes d’exécution d’Azure Databricks et les langues prises en charge.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

spark.read.table("catalog_name.schema_name.table_name")

Interroger des données par chemin d’accès

Vous pouvez interroger des données structurées, semi-structurées et non structurées à l’aide de chemins d’accès aux fichiers. La plupart des fichiers sur Azure Databricks sont soutenus par le stockage d’objets cloud. Consultez Utiliser des fichiers sur Azure Databricks.

Databricks recommande de configurer tous les accès au stockage d’objets cloud à l’aide de Unity Catalog et de définir des volumes pour les emplacements de stockage d’objets interrogés directement. Les volumes fournissent des alias lisibles par l’homme aux emplacements et aux fichiers dans le stockage d’objets cloud à l’aide de noms de catalogue et de schéma pour le chemin de fichier. Consultez Se connecter au stockage d’objets cloud et aux services à l’aide du catalogue Unity.

Les exemples suivants montrent comment utiliser des chemins de volume de Unity Catalog pour lire des données JSON :

SQL

SELECT * FROM json.`/Volumes/catalog_name/schema_name/volume_name/path/to/data`

Python

spark.read.format("json").load("/Volumes/catalog_name/schema_name/volume_name/path/to/data")

Pour les emplacements cloud qui ne sont pas configurés en tant que volumes Unity Catalog, vous pouvez interroger des données directement à l’aide d’URI. Vous devez configurer l’accès au stockage d’objets cloud pour interroger des données avec des URI. Consultez Configurer l’accès au stockage d’objets cloud pour Azure Databricks.

Les exemples suivants montrent comment utiliser des URI pour interroger des données JSON dans Azure Data Lake Storage Gen2, GCS et S3 :

SQL

SELECT * FROM json.`abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data`;

SELECT * FROM json.`gs://bucket_name/path/to/data`;

SELECT * FROM json.`s3://bucket_name/path/to/data`;

Python

spark.read.format("json").load("abfss://container-name@storage-account-name.dfs.core.windows.net/path/to/data")

spark.read.format("json").load("gs://bucket_name/path/to/data")

spark.read.format("json").load("s3://bucket_name/path/to/data")

Interroger des données à l’aide d’entrepôts SQL

Azure Databricks utilise des entrepôts SQL pour le calcul dans les interfaces suivantes :

• éditeur SQL
• Requêtes SQL Databricks
• Tableaux de bord
• Tableaux de bord hérités
• Alertes SQL

Vous pouvez éventuellement utiliser des entrepôts SQL avec les produits suivants :

• Notebooks Databricks
• Éditeur de fichiers Databricks
• Travaux Databricks

Lorsque vous interrogez des données avec des entrepôts SQL, vous pouvez utiliser uniquement la syntaxe SQL. D’autres langages de programmation et API ne sont pas pris en charge.

Pour les espaces de travail activés pour Unity Catalog, les entrepôts SQL utilisent toujours Unity Catalog pour gérer l’accès aux sources de données.

La plupart des requêtes exécutées sur des tables cibles d’entrepôts SQL. Les requêtes qui ciblent des fichiers de données doivent tirer parti des volumes Unity Catalog pour gérer l’accès aux emplacements de stockage.

L’utilisation d’URI directement dans les requêtes exécutées sur des entrepôts SQL peut entraîner des erreurs inattendues.

Interroger des données à l’aide des calculs à usage général ou des calculs de travail

La plupart des requêtes que vous exécutez à partir de notebooks Databricks, de flux de travail et de l’éditeur de fichiers s’exécutent sur des clusters de calcul configurés avec Databricks Runtime. Vous pouvez configurer ces clusters pour qu’ils s’exécutent de manière interactive ou les déployer en tant que calculs de travail qui alimentent les flux de travail. Databricks recommande d’utiliser toujours le calcul des travaux pour les charges de travail non interactives.

Charges de travail interactives et non interactives

De nombreux utilisateurs trouvent qu’il est utile d’afficher les résultats des requêtes pendant le traitement des transformations pendant le développement. Le déplacement d’une charge de travail interactive de calcul à usage unique vers le calcul des travail vous permet de gagner du temps et de traiter les coûts en supprimant les requêtes qui affichent les résultats.

Apache Spark utilise l’exécution différée du code, ce qui signifie que les résultats sont calculés uniquement si nécessaire, et plusieurs transformations ou requêtes sur une source de données peuvent être optimisées en tant que requête unique si vous ne forcez pas les résultats. Cela contraste avec le mode d’exécution hâtif utilisé dans pandas, ce qui nécessite le traitement des calculs dans l’ordre avant de passer les résultats à la méthode suivante.

Si votre objectif est d’enregistrer les données nettoyées, transformées et agrégées en tant que nouveau jeu de données, vous devez supprimer des requêtes qui affichent les résultats de votre code avant de planifier son exécution.

Pour les petites opérations et les petits jeux de données, les gains de temps et les économies sur les coûts peuvent être marginaux. Toutefois, avec des opérations volumineuses, le calcul et l’impression des résultats peuvent être perdus dans un bloc-notes qui peut ne pas être inspecté manuellement. Les mêmes résultats peuvent probablement être interrogés, quasiment gratuitement, à partir de la sortie enregistrée après leur stockage.