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 come parte di pipeline o flussi di lavoro di tabelle live Delta.

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 gestita o una tabella esterna è una tabella registrata con un LOCATION oggetto specificato. Il termine esterno può essere fuorviante, poiché le tabelle Delta esterne sono ancora 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 cos'è una tabella?.

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 con 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 i dati da considerare nella 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 lakehouse di Databricks.

Eseguire query sulle tabelle 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")

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. Vedere Connettersi all'archiviazione di oggetti cloud usando il catalogo unity.

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
• Flussi di lavoro di 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 nelle tabelle di destinazione di SQL Warehouse. 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.