Fråga efter data

Att fråga efter data är det grundläggande steget för att utföra nästan alla datadrivna uppgifter i Azure Databricks. Oavsett vilket språk eller verktyg som används börjar arbetsbelastningarna med att definiera en fråga mot en tabell eller annan datakälla och sedan utföra åtgärder för att få insikter från data. Den här artikeln beskriver de grundläggande begreppen och procedurerna för att köra frågor i olika Azure Databricks-produkterbjudanden och innehåller kodexempel som du kan anpassa för ditt användningsfall.

Du kan fråga data interaktivt med hjälp av:

• Notebook-filer
• SQL-redigerare
• Filredigeraren
• Instrumentpaneler

Du kan också köra frågor som en del av Delta Live Tables-pipelines eller arbetsflöden.

En översikt över strömmande frågor på Azure Databricks finns i Fråga efter strömmande data.

Vilka data kan du köra frågor mot med Azure Databricks?

Azure Databricks stöder frågor mot data i flera format och företagssystem. De data som du frågar med Azure Databricks ingår i en av två breda kategorier: data i ett Databricks lakehouse och externa data.

Vilka data finns i ett Databricks lakehouse?

Databricks Data Intelligence Platform lagrar alla dina data i ett Databricks lakehouse som standard.

Det innebär att när du kör en grundläggande CREATE TABLE instruktion för att skapa en ny tabell har du skapat en lakehouse-tabell. Lakehouse-data har följande egenskaper:

• Lagras i Delta Lake-format.
• Lagras i molnobjektlagring.
• Styrs av Unity Catalog.

De flesta lakehouse-data på Azure Databricks är registrerade i Unity Catalog som hanterade tabeller. Hanterade tabeller ger den enklaste syntaxen och fungerar som andra tabeller i de flesta hanteringssystem för relationsdatabaser. Hanterade tabeller rekommenderas för de flesta användningsfall och är lämpliga för alla användare som inte vill oroa sig för implementeringsinformationen för datalagring.

En ohanterad tabell, eller en extern tabell, är en tabell som har registrerats med en LOCATION angiven tabell. Termen extern kan vara missvisande eftersom externa Delta-tabeller fortfarande är lakehouse-data. Ohanterade tabeller kan föredras av användare som har direkt åtkomst till tabeller från andra Delta-läsarklienter. En översikt över skillnader i tabellsemantik finns i Vad är en tabell?.

Vissa äldre arbetsbelastningar kan uteslutande interagera med Delta Lake-data via filsökvägar och inte registrera tabeller alls. Dessa data är fortfarande lakehouse-data, men kan vara svårare att identifiera eftersom de inte är registrerade i Unity Catalog.

Kommentar

Arbetsyteadministratören kanske inte har uppgraderat datastyrningen till att använda Unity Catalog. Du kan fortfarande få många av fördelarna med ett Databricks lakehouse utan Unity Catalog, men inte alla funktioner som anges i den här artikeln eller i Azure Databricks-dokumentationen stöds.

Vilka data anses vara externa?

Alla data som inte finns i ett Databricks lakehouse kan betraktas som externa data. Några exempel på externa data är följande:

• Utländska tabeller som registrerats med Lakehouse Federation.
• Tabeller i Hive-metaarkivet som backas upp av Parquet.
• Externa tabeller i Unity Catalog som backas upp av JSON.
• CSV-data som lagras i molnobjektlagring.
• Strömmande data som lästs från Kafka.

Azure Databricks stöder konfiguration av anslutningar till många datakällor. Se Ansluta till datakällor.

Du kan använda Unity Catalog för att styra åtkomsten till och definiera tabeller mot data som lagras i flera format och externa system, men Delta Lake är ett krav för att data ska beaktas i lakehouse.

Delta Lake tillhandahåller alla transaktionsgarantier i Azure Databricks, som är avgörande för att upprätthålla dataintegritet och konsekvens. Om du vill veta mer om transaktionsgarantier för Azure Databricks-data och varför de är viktiga kan du läsa Vad är ACID-garantier i Azure Databricks?.

De flesta Azure Databricks-användare kör frågor mot en kombination av lakehouse-data och externa data. Att ansluta med externa data är alltid det första steget för datainmatning och ETL-pipelines som tar data till lakehouse. Information om hur du matar in data finns i Mata in data i en Databricks lakehouse.

Frågetabeller efter namn

För alla data som registrerats som en tabell rekommenderar Databricks att du frågar med tabellnamnet.

Om du använder Unity Catalog använder tabeller ett namnområde på tre nivåer med följande format: <catalog-name>.<schema-name>.<table-name>.

Utan Unity Catalog använder tabellidentifierare formatet <schema-name>.<table-name>.

Kommentar

Azure Databricks ärver mycket av sin SQL-syntax från Apache Spark, som inte skiljer mellan SCHEMA och DATABASE.

Frågor efter tabellnamn stöds i alla Azure Databricks-körningskontexter och språk som stöds.

SQL

SELECT * FROM catalog_name.schema_name.table_name

Python

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

Fråga efter sökväg

Du kan köra frågor mot strukturerade, halvstrukturerade och ostrukturerade data med hjälp av filsökvägar. De flesta filer på Azure Databricks backas upp av molnobjektlagring. Se Arbeta med filer på Azure Databricks.

Databricks rekommenderar att du konfigurerar all åtkomst till molnobjektlagring med hjälp av Unity Catalog och definierar volymer för objektlagringsplatser som efterfrågas direkt. Volymer tillhandahåller läsbara alias för platser och filer i lagring av molnobjekt med hjälp av katalog- och schemanamn för filsökvägen. Se Ansluta till molnobjektlagring med Unity Catalog.

Följande exempel visar hur du använder volymsökvägar i Unity Catalog för att läsa JSON-data:

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

För molnplatser som inte har konfigurerats som Unity Catalog-volymer kan du köra frågor mot data direkt med hjälp av URI:er. Du måste konfigurera åtkomst till molnobjektlagring för att köra frågor mot data med URI:er. Se Konfigurera åtkomst till molnobjektlagring för Azure Databricks.

Följande exempel visar hur du använder URI:er för att fråga JSON-data i Azure Data Lake Storage Gen2, GCS och 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")

Fråga efter data med hjälp av SQL-lager

Azure Databricks använder SQL-lager för beräkning i följande gränssnitt:

• SQL-redigerare
• Databricks SQL-frågor
• Instrumentpaneler
• Äldre instrumentpaneler
• SQL-aviseringar

Du kan också använda SQL-lager med följande produkter:

• Databricks-notebook-filer
• Databricks-filredigeraren
• Databricks-arbetsflöden

När du frågar efter data med SQL-lager kan du bara använda SQL-syntax. Andra programmeringsspråk och API:er stöds inte.

För arbetsytor som är aktiverade för Unity Catalog använder SQL-lager alltid Unity Catalog för att hantera åtkomst till datakällor.

De flesta frågor som körs på SQL-lagermåltabeller. Frågor som riktar sig till datafiler bör använda Unity Catalog-volymer för att hantera åtkomst till lagringsplatser.

Användning av URI:er direkt i frågor som körs på SQL-lager kan leda till oväntade fel.

Fråga efter data med beräkning eller jobbberäkning för alla ändamål

De flesta frågor som du kör från Databricks-notebook-filer, arbetsflöden och filredigeraren körs mot beräkningskluster som konfigurerats med Databricks Runtime. Du kan konfigurera dessa kluster så att de körs interaktivt eller distribuera dem som jobbberäkning som driver arbetsflöden. Databricks rekommenderar att du alltid använder jobbberäkning för icke-interaktiva arbetsbelastningar.

Interaktiva kontra icke-interaktiva arbetsbelastningar

Många användare tycker att det är bra att visa frågeresultat medan transformeringar bearbetas under utvecklingen. Om du flyttar en interaktiv arbetsbelastning från all-purpose compute till jobbberäkning kan du spara tid och bearbeta kostnader genom att ta bort frågor som visar resultat.

Apache Spark använder lat kodkörning, vilket innebär att resultaten endast beräknas vid behov, och flera omvandlingar eller frågor mot en datakälla kan optimeras som en enda fråga om du inte tvingar fram resultat. Detta står i kontrast till det ivriga körningsläget som används i Pandas, vilket kräver att beräkningar bearbetas i ordning innan resultatet skickas till nästa metod.

Om målet är att spara rensade, transformerade, aggregerade data som en ny datauppsättning bör du ta bort frågor som visar resultat från koden innan du schemalägger den för körning.

För små åtgärder och små datauppsättningar kan tids- och kostnadsbesparingarna vara marginella. Med stora åtgärder kan det dock ta lång tid att beräkna och skriva ut resultat till en notebook-fil som kanske inte inspekteras manuellt. Samma resultat kan sannolikt efterfrågas från de sparade utdatan nästan utan kostnad när de har lagrats.