Lakehouse Real-Time

Lakehouse Real-Time (Lakehouse//RT) är en serverlös beräkning som skapats för användningsfall med låg latens och hög samtidighet, till exempel att hantera analysdata till anpassade program, köra driftanalys eller driva BI-instrumentpaneler som kräver svar under sekunden för hundratals till tusentals samtidiga användare.

Lakehouse//RT erbjuder svarstid under sekunden för SQL-läsfrågor mot dina Unity Catalog-tabeller som använder Delta Lake- eller Apache Iceberg-format i molnlagring. Du skapar och hanterar Lakehouse//RT ungefär som du gör med andra SQL-lager. En arbetsyteadministratör eller privilegierad användare skapar en eller flera per arbetsyta och tilldelar behörigheter till användare.

Kravspecifikation

Om du vill använda Lakehouse//RT måste du:

• Vara i en region som stöds.
• Låt Lakehouse//RT Beta vara aktiverat på din arbetsyta.

Aktivera Lakehouse//RT på din arbetsyta

Arbetsyteadministratörer kan aktivera Lakehouse//RT Beta på din arbetsyta:

1. I arbetsytans meny (övre högra hörnet) går du till Förhandsgranskningar.
2. Sök efter Lakehouse RT.
3. Aktivera förhandsversionen.

När du har aktiverat förhandsversionen blir lagertypen Realtid tillgänglig i skapandeflödet för SQL-lager för din arbetsyta.

Skapa ett Lakehouse//RT-lager

Så här skapar du ett Lakehouse//RT-lager:

1. Gå till Compute>SQL Warehouses>Skapa SQL Warehouse.
2. Välj Realtid.
3. Välj en frågestorlek: Liten, Medel,Stor eller X-Stor beroende på vilken prestanda dina frågor kräver.
4. Konfigurera Autoscaling för att ange det maximala antalet DBU:er som du kan debiteras för per timme.
5. Ange Auto stop för att styra när ett inaktivt lager ska stoppas.
6. Ange ett namn på lagret.
7. Klicka på Skapa.

Tilldela behörigheter genom att bevilja Kan använda, Kan övervaka eller Kan hantera till användare och grupper, samma som ett SQL-lager.

Storlek och skala ett Lakehouse//RT-lager

Lakehouse//RT har inställningar som styr prestanda och kostnad:

• Frågestorleken styr den beräkning som är tillgänglig för en enskild fråga.
• Autoskalning styr hur mycket lagret skalar ut för att hantera samtidiga frågor.
• Autostopp styr hur länge ett tomt lager fortsätter att vara igång innan det stannar.

Frågestorlek och autoskalning fungerar annorlunda än storleks- och skalningsinställningarna på ett serverlöst SQL-lager.

Frågestorlek

Frågestorleken anger den maximala beräkning en enskild fråga kan använda, vilket avgör hur snabbt en enskild fråga kan köras. Den anger också den lägsta beräkningskapacitet som datalagret körs med, och den miniminivå du debiteras för, så länge datalagret är igång.

Du ställer in frågestorleken när du skapar lagret. Välj liten, medelstor, stor eller X-stor. En större storlek ger varje fråga mer beräkningskraft för snabbare resultat, till en högre minimikostnad.

Denna inställning liknar i koncept storleken på ett serverlöst SQL-lager, som också sätter beräkningen tillgänglig för en enda fråga.

Autoscaling

Autoskalning gör att ett datalager kan lägga till beräkningsresurser för att hantera fler samtidiga frågor och sedan frigöra dem när efterfrågan minskar. Du anger den maximala beräkningskapacitet som warehouset kan skala upp till, mätt i DBU:er.

Autoskalning på Lakehouse//RT skiljer sig från klusterskalning på ett serverless SQL-lager på några sätt:

• Den mäts i DBU:er, inte kluster.
• Maximalt är oberoende av frågestorleken. Du kan para ihop en liten frågestorlek med ett högt maximum för att få hög samtidighet utan att ge varje fråga mer beräkning.
• Lakehouse//RT:s autoskalning lägger endast till och tar bort den beräkningskapacitet som behövs, i stället för i klustersteg.

För att se hur mycket ett lager skalar, använd dess övervakningssida.

Automatisk stopp

Autostopp avslutar lagret efter att det varit inaktivt i ett visst antal minuter, så ett inaktivt lager fortsätter inte att samla på sig avgifter. Du ställer in vilotidsgränsen när du skapar lagret.

Automatisk stopp på Lakehouse//RT fungerar på samma sätt som på ett serverlöst SQL-datalager. För standard- och minimivärden, se Konfigurera SQL-lagerinställningar.

Övervaka Lakehouse//RT-aktivitet

Du kan övervaka Lakehouse//RT-frågor på samma sätt som alla frågor som körs på ett SQL-lager:

• Frågehistorik: Lakehouse//RT-frågor visas i användargränssnittet för frågehistorik och systemtabellen för frågehistorik.
• Frågeprofiler: Öppna en Lakehouse//RT-fråga i användargränssnittet för frågehistorik för att visa dess frågeprofil.
• Övervakningssida: Övervaka frågedataflöde, köade frågor och frågehistorik på övervakningssidan för varje Lakehouse//RT-lager.
• Fakturering: Lakehouse//RT-användning visas i faktureringssystemets tabeller med sku_nameLakehouse_Serverless.

Metodtips

Förbered dina arbetsbelastningar innan du flyttar över dem för att få bästa resultat från Lakehouse//RT:

• Verifiera på serverlös SQL först. Kör dina frågor på ett serverlöst SQL-lager och bekräfta att de körs om några sekunder.
• Använd hanterade Unity Catalog-tabeller. Hanterade tabeller med förutsägande optimering och flytande klustring säkerställer att dina data är väl klustrade för dina arbetsbelastningsmönster.
• Kontrollera att frågorna är selektiva. För svarstid under sekund kontrollerar du att dina frågor söker igenom mindre mängder data. Filtrera tidigt med WHERE -satser, välj bara de kolumner du behöver och luta dig mot aggregeringar. Anslutning mellan tabeller stöds, men om du tycker att frågan blir komplex eller långsam kan du överväga att använda materialiserade vyer som föraggregerar dina data för snabbare svarstider.
• Kontrollera SQL-täckningen. Lakehouse//RT stöder endast ANSI-kompatibla skrivfrågor. Bekräfta att dina arbetsbelastningar är ANSI-kompatibla och undvik de instruktioner, funktioner och datatyper som inte stöds som anges under Begränsningar.

Funktioner som stöds

Verktyg och gränssnitt

Du kan välja Lakehouse//RT från beräkningsväljaren i någon av följande Azure Databricks funktioner:

• SQL-redigerare
• SQL-notebook-filer
• AI/BI-översikter
• Katalogutforskaren
• Alerts

För att bygga AI/BI-dashboards på ett Lakehouse//RT-lager, inklusive skyddsmekanismer och dashboardspecifika begränsningar, se Use Lakehouse Real-Time with AI/BI-dashboards.

Tabelltyper

Lakehouse//RT frågar endast Unity Catalog-data. För bästa prestanda använder du hanterade Unity Catalog-tabeller, som ger motorn den datalayout som behövs för låg svarstid.

Lakehouse//RT stöder följande tabelltyper:

• Hanterade tabeller (Delta Lake- och Apache Iceberg-tabeller)
• Materialiserade vyer och strömmande tabeller
• Måttvyer

Connectivity

Lakehouse//RT accepterar endast anslutningar som använder API:et för instruktionskörning. Det stöder inte det äldre Thrift-protokollet, så en drivrutin som ansluter utan att uttryckligen använda Statement Execution API får felet 501.

Du kan ansluta till ett Lakehouse//RT-lager på följande sätt:

• API för instruktionskörning: Anropa API:et direkt från externa program. Se Statement Execution API: Kör SQL på datamagasiner.
• Databricks-drivrutiner: Följande drivrutiner kan ansluta via Statement Execution API. Ange drivrutinens HTTP-sökväg till ditt Lakehouse//RT-lager och följ sedan konfigurationen som anges för drivrutinen:
  • Databricks SQL Connector för Python: Ange use_kernel=True.
  • Databricks SQL-drivrutin för Node.js: Ange useKernel: true.
  • Databricks SQL-drivrutin för Go: Bygg med taggen databricks_kernel och sätt WithUseKernel(true).
  • JDBC: Ange UseThriftClient=0 i anslutnings-URL:en.
  • ADBC-drivrutin för Power BI: Ställ in Implementation=2.0 och Protocol=REST(SEA) under Avancerade alternativ.
  • Databricks OSS ODBC-drivrutin (Beta): Ingen ytterligare konfiguration krävs. Drivrutinen stödjer SQL-lagerplatser, inklusive Lakehouse//RT, men inte allmän beräkning.

Pricing

Information om priser finns på sidan Lakehouse Real-Time Prissättning.

Limitations

När en fråga använder en funktion som inte stöds returnerar Lakehouse//RT ett fel när funktionen namnges. För att kunna köra frågan använder du i stället ett serverlöst SQL-datalager.

Verktyg och funktioner

Lakehouse//RT har ännu inte stöd för följande funktioner:

• Genie
• Genie-agenter
• Jobbuppgifter

Tabelltyper

Följande tabelltyper stöds inte ännu:

• Systemtabeller
• Delta Sharing-tabeller
• Tabeller i Standardlagring i Unity Catalog
• Externa tabeller i Unity Catalog

Lakehouse//RT stöder inte följande tabelltyper:

• Hive-metaarkivtabeller (hanterade eller externa)
• Utländska tabeller och frågefederation (Lakehouse Federation)
• Temporära tabeller
• Tabeller som använder andra dataformat (CSV, JSON, Avro, Parquet, ORC och text)

Drivrutiner och anslutningar

Lakehouse//RT stöder inte Simba Spark ODBC-drivrutinen eller Databricks ODBC-drivrutinen. Använd Databricks OSS ODBC-drivrutinen istället.

SQL-språk

Lakehouse//RT kör endast SQL-läsfrågor i ANSI-läge . Den utvärderar alla implicita typtvång och gjutningar enligt strikta ANSI SQL-regler, och det här beteendet kan inte inaktiveras. Under ANSI-semantik kan frågor som förlitade sig på icke-ANSI-beteende:

• Utlös ett körningsfel i stället för att tyst producera NULL. Till exempel att konvertera en icke-numerisk sträng till ett tal.
• Generera ett fel vid analystid när det inte finns någon säker gemensam typ. Till exempel , COALESCE, CASEIN, eller ange åtgärder mellan inkompatibla typer.
• Returnera en annan resultattyp än äldre läge eftersom ANSI-stränghöjning och numerisk breddning väljer säkra, förlustfria typer.

För att få förutsägbara resultat använder du explicita CAST uttryck när implicita konverteringar i ANSI-läge inte ger det beteende du förväntar dig.

Lakehouse//RT stöder inte följande:

• Datatyper: Datatyperna GEOGRAPHY och GEOMETRY .
• Funktioner: AI-funktioner, Python UDF:er, rumsliga SQL-funktioner och XPath- och XML-funktioner.
• Styrelseformer: Attributbaserad åtkomstkontroll (ABAC), inklusive säkerhet på radnivå och kolumnmaskering.

Lakehouse//RT är endast för läsfrågor (SELECT). Skriv- och ETL-kommandon stöds inte, inklusive:

• Skrivåtgärder:INSERT, UPDATE, DELETE, MERGEoch CREATE TABLE AS SELECT (CTAS).
• DDL:CREATE, ALTER, DROPoch andra instruktioner som skapar eller ändrar objekt.
• Säkerhetsinstruktioner:GRANT och REVOKE.
• Skript, lagrade procedurer, temporära tabeller och transaktioner med flera instruktioner.
• Delta Lake-underhåll:OPTIMIZE, ANALYZE, VACUUMoch REFRESH.

Nätverkssäkerhet

Lakehouse//RT har ännu inte stöd för följande nätverkskonfigurationer:

• Utgående Private Link (serverlös)

• Serverlös kontroll av utgående trafik

Compliance

Säkerhetsprofiler för efterlevnad stöds inte för närvarande.