Query des données
L'interrogation des données est l'étape fondamentale pour l'exécution de presque toutes les tâches data-driven dans Databricks. Quel que soit le langage ou l'outil utilisé, les charges de travail commencent par la définition d'une query sur une table ou une autre source de données, puis effectuent des actions pour obtenir des informations à partir des données. Cet article présente les concepts et procédures de base pour exécuter des queries dans les différentes offres de produit Databricks, et inclut des exemples de code que vous pouvez adapter à votre cas d’usage.
Vous pouvez query des données de manière interactive en utilisant :
- Notebooks
- Éditeur SQL
- Éditeur de fichiers
- Tableaux de bord
Vous pouvez également exécuter des queries dans le cadre de LakeFlow Pipelines ou de jobs.
Pour un aperçu des queries de streaming sur Databricks, consultez Interroger les données de streaming.
Quelles données pouvez-vous interroger avec Databricks ?
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 de Databricks se répartissent en deux grandes catégories : les données d’un lakehouse Databricks et les données externes.
Quelles sont les données dans un lakehouse Databricks ?
La Databricks Data Intelligence Platform stocke toutes vos données dans un lakehouse Databricks par default.
Cela signifie que lorsque vous exécutez une instruction CREATE TABLE de base pour créer une nouvelle table, vous avez créé une table lakehouse. Les données du Lakehouse possèdent les propriétés suivantes :
- Stocké au format Delta Lake.
- Stocké dans le stockage d'objets cloud.
- Gouverné par Unity Catalog.
La plupart des données lakehouse sur Databricks sont enregistrées dans Unity Catalog en tant que tables gérées. Les tables gérées offrent la syntaxe la plus simple et se comportent comme les autres tables dans la plupart des systèmes de gestion de base de données relationnelles. Les tables gérées sont recommandées pour la plupart des cas d'utilisation et conviennent à tous les utilisateurs qui ne veulent pas se soucier des détails de mise en œuvre du stockage des données.
Une table non gérée , ou table externe , est une table enregistrée avec un LOCATION spécifié. Le terme externe peut être trompeur, car les tables Delta externes sont toujours des données lakehouse. Les tables non gérées peuvent être préférées par les utilisateurs qui accèdent directement aux tables à partir d'autres clients Delta reader. Pour une présentation des différences de sémantique de table, voir tables Databricks.
Certaines charges de travail existantes pourraient interagir exclusivement avec les données Delta Lake via des chemins de fichiers et ne pas du tout enregistrer de tables. Ces données restent des données lakehouse, mais peuvent être plus difficiles à découvrir car elles ne sont pas enregistrées dans Unity Catalog.
Votre administrateur de Workspace n’a peut-être pas mis à niveau votre gouvernance des données pour utiliser Unity Catalog. Vous pouvez toujours obtenir de nombreux avantages d’un lakehouse Databricks sans Unity Catalog, mais toutes les fonctionnalités répertoriées dans cet article ou dans la documentation Databricks ne sont pas prises en charge.
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 externes enregistrées avec Lakehouse Federation.
- Tables dans le Hive metastore reposant sur Parquet.
- Tables externes dans Unity Catalog basées sur JSON.
- Données CSV stockées dans un stockage d'objets cloud.
- Données de streaming lues depuis Kafka.
Databricks prend en charge la configuration des connexions à de nombreuses sources de données. Consultez Connecter aux sources de données et aux services externes.
Bien que vous puissiez utiliser Unity Catalog pour régir l'accès aux données stockées dans plusieurs formats et systèmes externes et définir des tables par rapport à celles-ci, Delta Lake est une exigence pour que les données soient prises en compte dans le lakehouse.
Delta Lake offre toutes les garanties transactionnelles dans Databricks, qui sont cruciales 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 Databricks et leur importance, consultez Que sont les garanties ACID sur Databricks ?.
La plupart des utilisateurs de Databricks interrogent une combinaison de données lakehouse et de données externes. La connexion aux données externes est toujours la première étape des pipelines d'ingestion de données et d'ETL qui acheminent les données vers le lakehouse. Pour des informations sur l'ingestion des données, consultez Connecteurs standard dans Lakeflow Connect.
Interroger les tables par nom
Pour toutes les données enregistrées en tant que table, Databricks recommande d'interroger en utilisant le nom de la table.
Si vous utilisez Unity Catalog, les tables utilisent un espace de noms à trois niveaux avec le format suivant : <catalog-name>.<schema-name>.<table-name>.
Sans Unity Catalog, les identificateurs de table utilisent le format <schema-name>.<table-name>.
Databricks hérite une grande partie de sa syntaxe SQL d'Apache Spark, qui ne fait pas de distinction entre SCHEMA et DATABASE.
L'interrogation par nom de table est prise en charge dans tous les contextes d'exécution Databricks et les langages pris en charge.
- SQL
- Python
SELECT * FROM catalog_name.schema_name.table_name
spark.read.table("catalog_name.schema_name.table_name")
Résolution d'identifiants Unity Catalog
Databricks recommande d'utiliser des identifiants entièrement qualifiés lorsque les queries ou les charges de travail interagissent avec des objets de base de données stockés sur plusieurs schémas ou catalogues.
Le tableau suivant décrit les comportements des identificateurs partiellement qualifiés et non qualifiés :
Identifier un modèle | Comportement |
|---|---|
| Fait référence à l'objet de base de données spécifié par l'identifiant. |
| Désigne l'objet de base de données associé aux |
| Fait référence à l'objet de base de données associé au |
Quel est le catalogue et le schéma actuels ?
Dans les environnements de compute interactifs, utilisez current_catalog() et current_schema() pour confirmer votre catalogue et votre schéma actuels.
Tous les workspaces configurés avec Unity Catalog ont un catalogue par default défini au niveau du workspace. Voir Gérer le catalogue default.
Le tableau suivant décrit les configurations des produits Databricks qui pourraient remplacer le catalogue par défaut du Workspace :
Produit | Configuration |
|---|---|
Calcul multifonction ou Job | Définissez la configuration Spark |
LakeFlow Pipelines | Le catalogue et le schéma spécifiés lors de la configuration du pipeline remplacent les valeurs par default du Workspace pour toute la logique de pipeline. |
Le catalogue ou le schéma par default peut également être défini par des configurations JDBC lors de la connexion à des systèmes externes ou à des métastores. Contactez l'administrateur responsable de la configuration de votre compute Databricks et des systèmes intégrés si vous rencontrez un comportement default inattendu.
Utilisez la syntaxe USE CATALOG ou USE SCHEMA pour spécifier le catalogue ou le schéma actuel pour votre session en cours. Le catalogue ou le schéma actuel est utilisé lorsqu'une requête ou une instruction utilise un identifiant partiellement ou non qualifié.
Déclaration | Résultat |
|---|---|
| Définit le catalogue actuel à l'aide de |
| Définit le schéma actuel à l'aide de |
| Définissez le catalogue actuel à l'aide du |
Les requêtes et les commandes qui utilisent des identifiants entièrement qualifiés pour interagir avec des objets comme des tables, des vues, des fonctions ou des modèles ne changent pas le catalogue ou le schéma actuel et font toujours référence à l'objet spécifié.
Query les données par chemin
Vous pouvez query des données structurées, semi-structurées et non structurées à l'aide de chemins de fichier. La plupart des fichiers sur Databricks sont sauvegardés par le stockage d'objets cloud. Voir Travailler avec les fichiers sur Databricks.
Databricks vous 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 qui sont directement interrogés. Les volumes fournissent des alias lisibles par l'homme pour les emplacements et les fichiers dans le stockage d'objets cloud, en utilisant les noms de catalogue et de schéma pour le chemin de fichier. Consultez Connectez-vous au stockage d'objets cloud à l'aide de Unity Catalog.
Les exemples suivants montrent comment utiliser les chemins de volume Unity Catalog pour lire les données JSON :
- SQL
- Python
SELECT * FROM json.`/Volumes/catalog_name/schema_name/volume_name/path/to/data`
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 query les données directement à l'aide d'URI. Vous devez configurer l'accès au stockage d'objets cloud pour interroger les données avec des URI. Consultez Configurer l'accès au stockage d'objets cloud pour Databricks à l'aide de modèles hérités.
Les exemples suivants montrent comment utiliser les URI pour query les données JSON dans Azure Data Lake Storage, GCS et S3 :
- SQL
- Python
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`;
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")
Query data using SQL Warehouses
Databricks utilise des SQL Warehouse pour le compute dans les interfaces suivantes :
- Éditeur SQL
- Requêtes Databricks SQL
- Tableaux de bord
- Alertes SQL
Vous pouvez éventuellement utiliser les SQL Warehouse avec les produits suivants :
- Databricks notebooks
- Éditeur de fichiers Databricks
- Tâches Lakeflow
Lorsque vous interrogez des données avec des SQL Warehouse, vous pouvez utiliser uniquement la syntaxe SQL. Les autres langages de programmation et APIs ne sont pas pris en charge.
Pour les workspaces compatibles avec Unity Catalog, les SQL warehouses utilisent toujours Unity Catalog pour gérer l'accès aux sources de données.
La plupart des queries exécutées sur les SQL Warehouse ciblent des tables. Les queries qui ciblent les fichiers de données doivent tirer parti des volumes Unity Catalog pour gérer l’accès aux emplacements de stockage.
L'utilisation directe des URI dans les queries exécutées sur les SQL Warehouse peut entraîner des erreurs inattendues.
query data using all purpose compute or Jobs compute
La plupart des queries que vous exécutez à partir des Notebooks Databricks, des workflows et de l'éditeur de fichiers s'exécutent sur des clusters de compute 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 *compute de Jobs* qui alimentent les workflows. Databricks vous recommande de toujours utiliser le compute de Jobs pour les charges de travail non interactives.
Charges de travail interactives ou non interactives
De nombreux utilisateurs trouvent utile de visualiser les résultats des query pendant que les Transformations sont traitées durant le développement. En déplaçant une charge de travail interactive du compute polyvalent vers le compute de jobs, vous pouvez gagner du temps et réduire les coûts de traitement en supprimant les requêtes qui affichent les résultats.
Apache Spark utilise l'exécution de code paresseuse, ce qui signifie que les résultats ne sont calculés qu'en cas de besoin, et que plusieurs transformations ou queries sur une source de données peuvent être optimisées en une seule query si vous ne forcez pas les résultats. Cela contraste avec le mode d'exécution eager utilisé dans pandas, qui exige que les calculs soient traités dans l'ordre avant de transférer les résultats à la méthode suivante.
Si votre objectif est d’enregistrer des données nettoyées, transformées et agrégées en tant que nouveau dataset, vous devez supprimer les query qui affichent les résultats de votre code avant de planifier son exécution.
Pour les petites opérations et les petits datasets, les économies de temps et de coûts pourraient être marginales. Cependant, avec des Opérations de grande envergure, un temps considérable peut être gaspillé à calculer et à imprimer des résultats dans un Notebook qui pourrait ne pas être inspecté manuellement. Les mêmes résultats pourraient probablement être interrogés (query) à partir de la sortie enregistrée à un coût presque nul après leur stockage.