Eseguire query sui dati

L'esecuzione di query sui dati è il passaggio fondamentale per eseguire quasi tutte le attività guidate dai dati in Azure Databricks. Indipendentemente dal linguaggio o dallo strumento usato, i carichi di lavoro iniziano definendo una query su una tabella o un'altra origine dati e quindi eseguendo azioni per ottenere informazioni dettagliate dai dati. Questo articolo descrive i concetti e le procedure di base per l'esecuzione di query in varie offerte di prodotti Azure Databricks e include esempi di codice che è possibile adattare per il caso d'uso.

È possibile eseguire query sui dati in modo interattivo usando:

• Notebook
• Editor SQL
• Editor di file
• Dashboard

È anche possibile eseguire query nell'ambito di pipeline o processi di Delta Live Tables.

Per una panoramica delle query di streaming in Azure Databricks, vedere Eseguire query sui dati di streaming.

Quali dati è possibile eseguire query con Azure Databricks?

Azure Databricks supporta l'esecuzione di query sui dati in più formati e sistemi aziendali. I dati su cui si esegue una query usando Azure Databricks rientrano in una delle due categorie generali: dati in un databricks lakehouse e dati esterni.

Quali dati si trovano in una databricks lakehouse?

Databricks Data Intelligence Platform archivia tutti i dati in una databricks lakehouse per impostazione predefinita.

Ciò significa che quando si esegue un'istruzione di base CREATE TABLE per creare una nuova tabella, è stata creata una tabella lakehouse. I dati di Lakehouse hanno le proprietà seguenti:

• Archiviato nel formato Delta Lake.
• Archiviato nell'archiviazione di oggetti cloud.
• Gestito dal Catalogo Unity.

La maggior parte dei dati lakehouse in Azure Databricks è registrata in Unity Catalog come tabelle gestite. Le tabelle gestite forniscono la sintassi più semplice e si comportano come altre tabelle nella maggior parte dei sistemi di gestione di database relazionali. Le tabelle gestite sono consigliate per la maggior parte dei casi d'uso e sono adatte a tutti gli utenti che non vogliono preoccuparsi dei dettagli di implementazione dell'archiviazione dei dati.

Una tabella non gestitao tabella esterna, è una tabella registrata con un LOCATION specificato. Il termine esterno può essere fuorviante, poiché le tabelle Delta esterne sono comunque dati lakehouse. Le tabelle non gestite potrebbero essere preferite dagli utenti che accedono direttamente alle tabelle da altri client di lettura Delta. Per una panoramica delle differenze nella semantica delle tabelle, vedere Che cosa sono le tabelle e le viste?.

Alcuni carichi di lavoro legacy potrebbero interagire esclusivamente con i dati Delta Lake tramite percorsi di file e non registrare affatto le tabelle. Questi dati sono ancora dati lakehouse, ma possono essere più difficili da individuare perché non sono registrati in Unity Catalog.

Nota

L'amministratore dell'area di lavoro potrebbe non aver aggiornato la governance dei dati per l'uso di Unity Catalog. È comunque possibile ottenere molti dei vantaggi di databricks lakehouse senza Unity Catalog, ma non tutte le funzionalità elencate in questo articolo o in tutta la documentazione di Azure Databricks è supportata.

Quali dati sono considerati esterni?

Tutti i dati che non si trovano in un lakehouse di Databricks possono essere considerati dati esterni. Di seguito sono riportati alcuni esempi di dati esterni:

• Tabelle esterne registrate nella Lakehouse Federation.
• Tabelle nel metastore Hive supportate da Parquet.
• Tabelle esterne nel catalogo Unity supportato da JSON.
• Dati CSV archiviati nell'archiviazione di oggetti cloud.
• Streaming dei dati letti da Kafka.

Azure Databricks supporta la configurazione delle connessioni a molte origini dati. Vedere Connettersi alle origini dati.

Sebbene sia possibile usare Unity Catalog per gestire l'accesso e definire tabelle sui dati archiviati in più formati e sistemi esterni, Delta Lake è un requisito per considerare i dati nel contesto di un lakehouse.

Delta Lake offre tutte le garanzie transazionali in Azure Databricks, fondamentali per mantenere l'integrità e la coerenza dei dati. Per altre informazioni sulle garanzie transazionali sui dati di Azure Databricks e sui motivi per cui sono importanti, vedere Che cosa sono le garanzie ACID in Azure Databricks?.

La maggior parte degli utenti di Azure Databricks esegue una query su una combinazione di dati lakehouse e dati esterni. La connessione con dati esterni è sempre il primo passaggio per l'inserimento dei dati e le pipeline ETL che inseriscono i dati nel lakehouse. Per informazioni sull'inserimento di dati, vedere Inserire dati in un'istanza di Azure Databricks lakehouse.

tabelle di query in base al nome

Per tutti i dati registrati come tabella, Databricks consiglia di eseguire query usando il nome della tabella.

Se si usa Il catalogo Unity, le tabelle usano uno spazio dei nomi a tre livelli con il formato seguente: <catalog-name>.<schema-name>.<table-name>.

Senza il catalogo unity, gli identificatori di tabella usano il formato <schema-name>.<table-name>.

Nota

Azure Databricks eredita gran parte della sintassi SQL da Apache Spark, che non distingue tra SCHEMA e DATABASE.

L'esecuzione di query in base al nome della tabella è supportata in tutti i contesti di esecuzione di Azure Databricks e in tutti i linguaggi supportati.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

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

risoluzione dell'identificatore del catalogo Unity

Databricks consiglia di usare identificatori completi quando le query o i carichi di lavoro interagiscono con oggetti di database archiviati in più schemi o cataloghi.

Nella tabella seguente vengono descritti i comportamenti per gli identificatori parzialmente qualificati e non qualificati:

Modello di identificatore	Comportamento
catalog_name.schema_name.object_name	Fa riferimento all'oggetto di database specificato dall'identificatore.
schema_name.object_name	Si riferisce all'oggetto di database associato al schema_name e al object_name specificati nel catalogo corrente.
object_name	Fa riferimento all'oggetto di database associato al object_name specificato nel catalogo e nello schema correnti.

Qual è il catalogo e lo schema correnti?

Negli ambienti di calcolo interattivi usare current_catalog() e current_schema() per verificare il catalogo e lo schema correnti.

Tutte le aree di lavoro configurate con Unity Catalog hanno un catalogo predefinito impostato a livello di area di lavoro. Vedere Gestire il catalogo predefinito.

La tabella seguente descrive le configurazioni per i prodotti Databricks che potrebbero eseguire l'override del catalogo predefinito dell'area di lavoro:

Prodotto	Configurazione
Calcolo di tutti gli scopi o processi	Impostare la configurazione di Spark spark.databricks.sql.initial.catalog.namespace durante la configurazione del calcolo.
Tabelle Delta Live	Il catalogo e lo schema specificati durante la configurazione della pipeline sostituiscono le impostazioni predefinite dell'area di lavoro per tutta la logica della pipeline.

Nota

Il catalogo o lo schema predefinito possono essere impostati anche dalle configurazioni JDBC durante la connessione a sistemi esterni o metastore. Contattare l'amministratore responsabile della configurazione dei sistemi di calcolo e integrati di Databricks se si verifica un comportamento predefinito imprevisto.

Usare la sintassi USE CATALOG o USE SCHEMA per specificare il catalogo o lo schema corrente per la sessione corrente. Il catalogo o lo schema corrente viene usato quando una query o un'istruzione usa un identificatore parzialmente qualificato o non qualificato.

Affermazione	Risultato
USE CATALOG catalog_name	Imposta il catalogo corrente utilizzando il catalog_namefornito. Imposta lo schema corrente su default.
USE SCHEMA schema_name	Imposta lo schema corrente utilizzando il schema_name fornito nel catalogo corrente.
USE SCHEMA catalog_name.schema_name	Impostare il catalogo corrente usando il catalog_name fornito e lo schema corrente usando il schema_namefornito.

Nota

Le query e i comandi che usano identificatori completi per interagire con oggetti come tabelle, viste, funzioni o modelli non modificano il catalogo o lo schema corrente e fanno sempre riferimento all'oggetto specificato.

Eseguire query sui dati in base al percorso

È possibile eseguire query su dati strutturati, semistrutturati e non strutturati usando percorsi di file. La maggior parte dei file in Azure Databricks è supportata dall'archiviazione di oggetti cloud. Vedere Usare file in Azure Databricks.

Databricks consiglia di configurare tutti gli accessi all'archiviazione di oggetti cloud usando Unity Catalog e di definire i volumi per le posizioni di archiviazione degli oggetti su cui vengono eseguite direttamente query. I volumi forniscono alias leggibili ai percorsi e ai file nell'archiviazione di oggetti cloud usando nomi di catalogo e schema per il percorso file. Consultare Collegarsi all'archiviazione oggetti cloud e ai servizi utilizzando Unity Catalog.

Gli esempi seguenti illustrano come usare i percorsi del volume di Unity Catalog per leggere i dati 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")

Per le posizioni cloud non configurate come volumi del catalogo Unity, è possibile eseguire query sui dati direttamente usando gli URI. È necessario configurare l'accesso all'archiviazione di oggetti cloud per eseguire query sui dati con URI. Vedere Configurare l'accesso all'archiviazione di oggetti cloud per Azure Databricks.

Gli esempi seguenti illustrano come usare gli URI per eseguire query sui dati JSON in Azure Data Lake Storage Gen2, GCS e 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")

Eseguire query sui dati usando SQL Warehouse

Azure Databricks usa SQL Warehouse per il calcolo nelle interfacce seguenti:

• Editor SQL
• Query SQL di Databricks
• Dashboard
• Dashboard legacy
• Avvisi SQL

Facoltativamente, è possibile usare SQL Warehouse con i prodotti seguenti:

• Notebook di Databricks
• Editor di file di Databricks
• Processi Databricks

Quando si eseguono query sui dati con SQL Warehouse, è possibile usare solo la sintassi SQL. Altri linguaggi di programmazione e API non sono supportati.

Per le aree di lavoro abilitate per il catalogo Unity, i warehouse SQL usano sempre Unity Catalog per gestire l'accesso alle origini dati.

La maggior parte delle query eseguite sui magazzini SQL prende di mira le tabelle. Le query destinate ai file di dati devono sfruttare i volumi del catalogo Unity per gestire l'accesso ai percorsi di archiviazione.

L'uso di URI direttamente nelle query eseguite in SQL Warehouse può causare errori imprevisti.

Eseguire query sui dati usando tutte le risorse di calcolo o processi per scopi di calcolo

La maggior parte delle query eseguite da notebook di Databricks, flussi di lavoro e l'editor di file vengono eseguite su cluster di calcolo configurati con Databricks Runtime. È possibile configurare questi cluster per l'esecuzione in modo interattivo o distribuirli come processi che calcolano i flussi di lavoro con potenza. Databricks consiglia di usare sempre il calcolo dei processi per carichi di lavoro non interattivi.

Carichi di lavoro interattivi e non interattivi

Molti utenti trovano utile visualizzare i risultati delle query durante l'elaborazione delle trasformazioni durante lo sviluppo. Lo spostamento di un carico di lavoro interattivo dal calcolo all'ambiente di calcolo per i processi consente di risparmiare tempo ed elaborazione rimuovendo le query che visualizzano i risultati.

Apache Spark usa l'esecuzione di codice differita, ovvero i risultati vengono calcolati solo in base alle esigenze e più trasformazioni o query su un'origine dati possono essere ottimizzate come singola query se non si forzano i risultati. Questo contrasto con la modalità di esecuzione eager usata in pandas, che richiede l'elaborazione dei calcoli in ordine prima di passare i risultati al metodo successivo.

Se l'obiettivo è salvare i dati puliti, trasformati e aggregati come nuovo set di dati, è necessario rimuovere le query che visualizzano i risultati dal codice prima di pianificare l'esecuzione.

Per operazioni di piccole dimensioni e set di dati di piccole dimensioni, il tempo e i risparmi sui costi potrebbero essere marginali. Tuttavia, con operazioni di grandi dimensioni, il calcolo e la stampa dei risultati in un notebook che potrebbe non essere controllato manualmente possono essere sprecate. Gli stessi risultati potrebbero probabilmente essere sottoposti a query dall'output salvato a quasi nessun costo dopo l'archiviazione.