Delen via

Querygegevens

  • Artikel

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 basisinstructie CREATE TABLE 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 tabel of externe tabel is een tabel die is geregistreerd bij een LOCATION opgegeven. De term extern 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. Zie Wat is een tabel voor een overzicht van verschillen in tabelsemantiek.

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:

  • Refererende tabellen die zijn geregistreerd bij Lakehouse Federation.
  • Tabellen in de Hive-metastore die wordt 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.

Azure Databricks biedt ondersteuning voor het configureren van verbindingen met veel gegevensbronnen. Zie Verbinding maken met gegevensbronnen.

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 Databricks Lakehouse voor informatie over het opnemen van gegevens.

Query's uitvoeren 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.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

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

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 met behulp van Unity Catalog.

In de volgende voorbeelden ziet u hoe u volumepaden van Unity Catalog gebruikt om JSON-gegevens te lezen:

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")

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

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")

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.