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 un table 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 delle query all'interno di pipeline o processi 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 CREATE TABLE di base per creare una nuova table, è stata creata una lakehouse table. I dati di Lakehouse hanno le proprietà seguenti:

• Archiviato nel formato Delta Lake.
• Archiviato nell'archiviazione di oggetti cloud.
• Governato da Unity Catalog.

La maggior parte dei dati lakehouse in Azure Databricks viene registrata in Unity Catalog come gestita tables. I tables gestiti forniscono la sintassi più semplice e si comportano come altri tables nella maggior parte dei sistemi di gestione di database relazionali. Si consiglia l'uso dei tables gestiti per la maggior parte dei casi d'uso, in quanto sono adatti a tutti gli utenti che preferiscono non preoccuparsi dei dettagli di implementazione dell'archiviazione dei dati.

Un tablenon gestito o un tableesterno è un table registrato con un LOCATION specificato. Il termine esterni può essere fuorviante, poiché i tables Delta esterni sono ancora dati lakehouse. I tables non gestiti potrebbero essere preferiti dagli utenti che accedono direttamente a tables da altri client lettori Delta. Per una panoramica delle differenze nella semantica di table, vedere Che cosa sono tables e views?.

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

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:

• Straniero tables registrato presso la Lakehouse Federation.
• Tables nel metastore Hive supportato da Parquet.
• tables esterni in Unity Catalog supportati da JSON.
• Dati CSV archiviati nell'archiviazione di oggetti cloud.
• Streaming dei dati letti da Kafka.

Azure Databricks supporta la configurazione di connections in molte origini dati. Vedere Connettersi alle origini dati.

Anche se è possibile usare Unity Catalog per gestire l'accesso e definire tables sui dati archiviati in più formati e sistemi esterni, Delta Lake è necessario affinché i dati siano considerati nella piattaforma 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.

Query tables per nome

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

Se si usa Unity Catalog, tables usa uno spazio dei nomi a tre livelli con il formato seguente: <catalog-name>.<schema-name>.<table-name>.

Senza Unity Catalog, gli identificatori di table usano il formato <schema-name>.<table-name>.

L'esecuzione di query in base table nome è 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 volumes per le posizioni di archiviazione degli oggetti su cui vengono eseguite direttamente query. Volumes può fornire alias leggibili alle posizioni e ai file nell'archiviazione oggetti cloud usando i nomi catalog e schema per il percorso del file. Consulta Connettiti all'archiviazione cloud di oggetti e ai servizi usando Unity Catalog.

Gli esempi seguenti illustrano come usare i percorsi di volume Catalog Unity 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 Unity Catalogvolumes, è 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 Unity Catalog, i warehouse SQL usano sempre Unity Catalog per gestire l'accesso alle origini dati.

La maggior parte delle query eseguite nei data warehouse SQL ha come obiettivo tables. Le query destinate ai file di dati devono sfruttare Unity Catalogvolumes 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 remove query che visualizzano i risultati del codice prima di pianificarlo per 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.