Het uitvoeren van query's op gegevens is de basisstap voor het uitvoeren van bijna alle gegevensgestuurde taken in Azure Databricks. Ongeacht de taal of het hulpprogramma dat wordt gebruikt, beginnen workloads door een query te definiëren op basis van een tabel of andere gegevensbron en vervolgens acties uit te voeren om inzicht te krijgen in de gegevens. Dit artikel bevat een overzicht van de belangrijkste concepten en procedures voor het uitvoeren van query's in verschillende Azure Databricks-productaanbiedingen en bevat codevoorbeelden die u kunt aanpassen voor uw use-case.
U kunt interactief query's uitvoeren op gegevens met behulp van:
Notebooks
SQL-editor
Bestandseditor
Dashboards
U kunt ook query's uitvoeren als onderdeel van Delta Live Tables-pijplijnen of -taken.
Zie Streaminggegevens opvragen voor een overzicht van streamingquery's in Azure Databricks.
Welke gegevens kunt u opvragen met Azure Databricks?
Azure Databricks biedt ondersteuning voor het opvragen van gegevens in meerdere indelingen en bedrijfssystemen. De gegevens die u opvraagt met behulp van Azure Databricks, vallen in een van de twee algemene categorieën: gegevens in een Databricks Lakehouse en externe gegevens.
Welke gegevens zijn opgenomen in een Databricks Lakehouse?
Het Databricks Data Intelligence Platform slaat standaard al uw gegevens op in een Databricks Lakehouse.
Dit betekent dat wanneer u een eenvoudige CREATE TABLE instructie uitvoert om een nieuwe tabel te maken, u een lakehouse-tabel hebt gemaakt. Lakehouse-gegevens hebben de volgende eigenschappen:
Opgeslagen in de Delta Lake-indeling.
Opgeslagen in cloudobjectopslag.
Beheerd door Unity Catalog.
De meeste lakehouse-gegevens in Azure Databricks worden geregistreerd in Unity Catalog als beheerde tabellen. Beheerde tabellen bieden de eenvoudigste syntaxis en gedragen zich als andere tabellen in de meeste relationele databasebeheersystemen. Beheerde tabellen worden aanbevolen voor de meeste gebruiksvoorbeelden en zijn geschikt voor alle gebruikers die zich geen zorgen willen maken over de implementatiedetails van gegevensopslag.
Een niet-beheerde tabelof externe tabel, is een tabel die is geregistreerd bij een gespecificeerd LOCATION. De term externe kan misleidend zijn, omdat externe Delta-tabellen nog steeds lakehouse-gegevens zijn. Onbeheerde tabellen kunnen de voorkeur krijgen van gebruikers die rechtstreeks toegang hebben tot tabellen van andere Delta-lezerclients. Voor een overzicht van verschillen in tafelsemantiek, zie Wat zijn tabellen en weergaven?.
Sommige verouderde workloads werken mogelijk uitsluitend met Delta Lake-gegevens via bestandspaden en registreren helemaal geen tabellen. Deze gegevens zijn nog steeds lakehouse-gegevens, maar kunnen lastiger te detecteren zijn omdat deze niet zijn geregistreerd bij Unity Catalog.
Notitie
Uw werkruimtebeheerder heeft mogelijk uw gegevensbeheer niet bijgewerkt om Unity Catalog te gebruiken. U kunt nog steeds veel voordelen krijgen van een Databricks Lakehouse zonder Unity Catalog, maar niet alle functionaliteit die in dit artikel of in de Documentatie van Azure Databricks wordt vermeld, wordt ondersteund.
Welke gegevens worden als extern beschouwd?
Gegevens die zich niet in een Databricks Lakehouse bevonden, kunnen worden beschouwd als externe gegevens. Enkele voorbeelden van externe gegevens zijn:
Externe tabellen die zijn geregistreerd bij Lakehouse Federation.
Tabellen in de Hive-metastore die worden ondersteund door Parquet.
Externe tabellen in Unity Catalog ondersteund door JSON.
CSV-gegevens die zijn opgeslagen in de opslag van cloudobjecten.
Streaminggegevens die vanuit Kafka worden gelezen.
Hoewel u Unity Catalog kunt gebruiken om de toegang tot tabellen te beheren en te definiëren op basis van gegevens die zijn opgeslagen in meerdere indelingen en externe systemen, is Delta Lake een vereiste voor gegevens die in lakehouse moeten worden overwogen.
Delta Lake biedt alle transactionele garanties in Azure Databricks, die essentieel zijn voor het behouden van gegevensintegriteit en consistentie. Als u meer wilt weten over transactionele garanties op Azure Databricks-gegevens en waarom ze belangrijk zijn, raadpleegt u Wat zijn ACID-garanties in Azure Databricks?.
De meeste Azure Databricks-gebruikers voeren een query uit op een combinatie van lakehouse-gegevens en externe gegevens. Verbinding maken met externe gegevens is altijd de eerste stap voor gegevensopname en ETL-pijplijnen die gegevens in lakehouse brengen. Zie Gegevens opnemen in een Azure Databricks Lakehouse-voor meer informatie over het opnemen van gegevens.
Querytabellen op naam
Voor alle gegevens die zijn geregistreerd als een tabel, raadt Databricks aan query's uit te voeren met behulp van de tabelnaam.
Als u Unity Catalog gebruikt, gebruiken tabellen een naamruimte met drie lagen met de volgende indeling: <catalog-name>.<schema-name>.<table-name>.
Zonder Unity Catalog gebruiken tabel-id's de indeling <schema-name>.<table-name>.
Notitie
Azure Databricks neemt veel van de SQL-syntaxis over van Apache Spark, die geen onderscheid maakt tussen SCHEMA en DATABASE.
Query's uitvoeren op tabelnaam wordt ondersteund in alle Azure Databricks-uitvoeringscontexten en ondersteunde talen.
Databricks raadt aan om volledig gekwalificeerde id's te gebruiken wanneer query's of workloads communiceren met databaseobjecten die zijn opgeslagen in meerdere schema's of catalogi.
De volgende tabel bevat een overzicht van het gedrag voor gedeeltelijk gekwalificeerde en niet-gekwalificeerde id's:
Id-patroon
Gedrag
catalog_name.schema_name.object_name
Verwijst naar het databaseobject dat is opgegeven door de id.
schema_name.object_name
Verwijst naar het databaseobject dat is gekoppeld aan de opgegeven schema_name en object_name in de huidige catalogus.
object_name
Verwijst naar het databaseobject dat is gekoppeld aan de opgegeven object_name in de huidige catalogus en schema.
Wat is de huidige catalogus en het huidige schema?
Gebruik in interactieve rekenomgevingen current_catalog() en current_schema() om uw huidige catalogus en schema te bevestigen.
Alle werkruimten die zijn geconfigureerd met Unity Catalog, hebben een standaardcatalogus ingesteld op werkruimteniveau. Zie De standaardcatalogus beheren.
In de volgende tabel worden configuraties beschreven voor Databricks-producten die de standaardcatalogus van de werkruimte kunnen overschrijven:
Product
Configuratie
Berekening van alle doeleinden of taken
Stel de Spark-configuratie spark.databricks.sql.initial.catalog.namespace in bij het configureren van rekenkracht.
Delta Live-tabellen
De catalogus en het schema die tijdens de pijplijnconfiguratie zijn opgegeven, overschrijven de standaardwaarden voor de werkruimte voor alle pijplijnlogica.
Notitie
Standaardcatalogus of -schema kan ook worden ingesteld door JDBC-configuraties bij het maken van verbinding met externe systemen of metastores. Neem contact op met de beheerder die verantwoordelijk is voor het configureren van uw Databricks-reken- en geïntegreerde systemen als u onverwacht standaardgedrag ondervindt.
Gebruik de syntaxis van de USE CATALOG of USE SCHEMA om de huidige catalogus of het huidige schema voor uw huidige sessie op te geven. De huidige catalogus of het huidige schema wordt gebruikt wanneer een query of opdracht een gedeeltelijk gekwalificeerde of ongedefinieerde identificator gebruikt.
Verklaring
Resultaat
USE CATALOG catalog_name
Hiermee stelt u de huidige catalogus in met behulp van de opgegeven catalog_name. Hiermee stelt u het huidige schema in op default.
USE SCHEMA schema_name
Hiermee stelt u het huidige schema in met behulp van de opgegeven schema_name in de huidige catalogus.
USE SCHEMA catalog_name.schema_name
Stel de huidige catalogus in met behulp van de opgegeven catalog_name en het huidige schema met behulp van de opgegeven schema_name.
Notitie
Query's en opdrachten die gebruikmaken van volledig gekwalificeerde id's om te communiceren met objecten zoals tabellen, weergaven, functies of modellen wijzigen de huidige catalogus of het huidige schema niet en verwijzen altijd naar het opgegeven object.
Gegevens op pad opvragen
U kunt query's uitvoeren op gestructureerde, semi-gestructureerde en ongestructureerde gegevens met behulp van bestandspaden. De meeste bestanden in Azure Databricks worden ondersteund door opslag van cloudobjecten. Zie Werken met bestanden in Azure Databricks.
Databricks raadt aan om alle toegang tot cloudobjectopslag te configureren met behulp van Unity Catalog en volumes te definiëren voor objectopslaglocaties die rechtstreeks worden opgevraagd. Volumes bieden leesbare aliassen voor locaties en bestanden in opslag van cloudobjecten met behulp van catalogus- en schemanamen voor het bestandspad. Zie Verbinding maken met cloudobjectopslag en -services met behulp van Unity Catalog.
In de volgende voorbeelden ziet u hoe u volumepaden van Unity Catalog gebruikt om JSON-gegevens te lezen:
SQL
SQL
SELECT * FROM json.`/Volumes/catalog_name/schema_name/volume_name/path/to/data`
Voor cloudlocaties die niet zijn geconfigureerd als Unity Catalog-volumes, kunt u rechtstreeks query's uitvoeren op gegevens met behulp van URI's. U moet de toegang tot cloudobjectopslag configureren om query's uit te voeren op gegevens met URI's. Zie Toegang tot cloudobjectopslag configureren voor Azure Databricks.
In de volgende voorbeelden ziet u hoe u URI's gebruikt om query's uit te voeren op JSON-gegevens in Azure Data Lake Storage Gen2, GCS en S3:
SQL
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`;
Query's uitvoeren op gegevens met BEHULP van SQL Warehouses
Azure Databricks maakt gebruik van SQL-warehouses voor berekening in de volgende interfaces:
SQL-editor
Databricks SQL-query's
Dashboards
Verouderde dashboards
SQL-waarschuwingen
U kunt desgewenst SQL Warehouses gebruiken met de volgende producten:
Databricks-notebooks
Databricks-bestandseditor
Databricks-taken
Wanneer u query's uitvoert op gegevens met SQL Warehouses, kunt u alleen SQL-syntaxis gebruiken. Andere programmeertalen en API's worden niet ondersteund.
Voor werkruimten die zijn ingeschakeld voor Unity Catalog, gebruiken SQL Warehouses altijd Unity Catalog om de toegang tot gegevensbronnen te beheren.
De meeste query's die worden uitgevoerd op doeltabellen van SQL Warehouses. Query's die zijn gericht op gegevensbestanden, moeten gebruikmaken van Unity Catalog-volumes om de toegang tot opslaglocaties te beheren.
Het rechtstreeks gebruiken van URI's in query's die worden uitgevoerd in SQL Warehouses, kan leiden tot onverwachte fouten.
Query's uitvoeren op gegevens met alle doeleinden berekenen of taken berekenen
De meeste query's die u uitvoert vanuit Databricks-notebooks, werkstromen en de bestandseditor worden uitgevoerd op rekenclusters die zijn geconfigureerd met Databricks Runtime. U kunt deze clusters zo configureren dat ze interactief worden uitgevoerd of als taken die werkstromen berekenen . Databricks raadt u aan om altijd taken te berekenen voor niet-interactieve workloads.
Interactieve versus niet-interactieve workloads
Veel gebruikers vinden het handig om queryresultaten weer te geven terwijl transformaties tijdens de ontwikkeling worden verwerkt. Als u een interactieve workload verplaatst van berekeningen voor alle doeleinden naar taken, kunt u tijd en verwerkingskosten besparen door query's te verwijderen die resultaten weergeven.
Apache Spark maakt gebruik van luie code-uitvoering, wat betekent dat resultaten alleen als nodig worden berekend en dat meerdere transformaties of query's op een gegevensbron kunnen worden geoptimaliseerd als één query als u geen resultaten forceert. Dit contrasteert met de gretige uitvoeringsmodus die wordt gebruikt in pandas. Hiervoor moeten berekeningen op volgorde worden verwerkt voordat resultaten worden doorgegeven aan de volgende methode.
Als u opgeschoonde, getransformeerde, geaggregeerde gegevens wilt opslaan als een nieuwe gegevensset, moet u query's verwijderen die resultaten van uw code weergeven voordat u deze gaat uitvoeren.
Voor kleine bewerkingen en kleine gegevenssets kunnen de tijd- en kostenbesparing marginaal zijn. Toch kan bij grote bewerkingen aanzienlijke tijd worden verspild aan het berekenen en afdrukken van resultaten naar een notitieblok dat mogelijk niet handmatig wordt geïnspecteerd. Dezelfde resultaten kunnen waarschijnlijk zonder kosten worden opgevraagd uit de opgeslagen uitvoer nadat ze zijn opgeslagen.
Demonstreer inzicht in algemene data engineering-taken voor het implementeren en beheren van data engineering-workloads in Microsoft Azure met behulp van een aantal Azure-services.