Använd Lakehouse Real-Time med AI/BI-dashboards

Du kan använda ett Lakehouse//RT-datavaruhus för att driva AI/BI-dashboards som kräver svar på under en sekund för hundratals till tusentals samtidiga användare. Använd Lakehouse//RT för att bygga nya dashboards som passar in i de nuvarande begränsningarna. Att migrera en befintlig instrumentpanel rekommenderas inte, eftersom befintliga dashboards ofta är beroende av funktionalitet som Lakehouse//RT ännu inte stödjer, såsom Genie, externa tabeller eller materialisering av metrisk vy.

Avsedd användning

Lakehouse//RT ger subsekundslatens för selektiva frågor som läser en liten mängd data. Det påskyndar inte dyra frågor/queryer, som de som skannar stora mängder data eller sammanfogar många stora tabeller.

Lakehouse//RT:s skyddsräcken (se Skyddsräcken) upprätthåller hårda gränser i stället för att hantera fel kontrollerat, så förbered dina arbetsbelastningar innan du flyttar dem till ett Lakehouse//RT-lager:

• Optimera dyra frågor genom att filtrera tidigt så att de skannar mindre data.
• Föraggregera resultat med materialiserade vyer när en instrumentpanel läser mycket mindre data än den skannar.

Sätt upp en dashboard på ett datavaruhus i Lakehouse//RT

För att publicera en AI/BI-dashboard som körs på Lakehouse//RT, skapa datalagret och välj det som dashboardens datalager:

1. Skapa ett Lakehouse//RT-warehouse, precis som vilket annat SQL warehouse som helst. Se Lakehouse Real-Time.
2. Ge användare behörigheten Kan använda eller högre för lagret. Lagret visas sedan i compute picker för dashboardredigering för dessa användare.
3. I din dashboard, välj Lakehouse//RT-warehouse som instrumentpanelens warehouse.
4. Publicera dashboarden som vanligt.

Skyddsmekanismer

För att skydda den delade tjänsten med låg latens upprätthåller Lakehouse//RT resursgränser per fråga. En dashbordsfråga som överskrider en skyddsgräns ger ett fel istället för att köras långsamt, så utforma dina frågor så att de bekvämt håller sig inom dessa gränser.

Dessa värden sattes under betatestning och kan ändras innan allmän tillgänglighet:

• Frågetid: 2 minuter. Lakehouse//RT avbryter en widget-fråga som körs för länge. En fråga som närmar sig denna gräns kommer inte att nå subsekundmålet även om den slutförs, och det är mer sannolikt att den når shuffle eller spill-gränserna nedanför. Behandla det som en signal att filtrera mer eller föraggregera.
• Tidsgräns för sats: 1 minut som standard. Du kan konfigurera timeout per uttryck upp till frågekörningsgränsen på 2 minuter.
• Shuffle-byte skrivna per steg: 300 GB. Breda sammanfogningar eller aggregeringar över stora tabeller kan överstiga denna gräns. Om en databasfråga överskrider den, föraggregera med materialiserade vyer i stället för att sammanfoga stora tabeller vid frågetillfället.
• Spillstorlek: 30 GB, när spill är aktiverat.
• Fillista efter beskärning: 10 000 filer, justerbar upp till 50 000. Om en fråga överskrider denna gräns, filtrera på partitions- eller liquid clustering-kolumner så att instrumentpanelen bara läser de filer den behöver.

Limitations

Dashboards på ett Lakehouse//RT-lager ärver alla Lakehouse//RT-begränsningar, inklusive stöd för endast Unity Catalog-hanterade tabeller och endast ANSI-kompatibla SELECT frågor. Konvertera andra tabelltyper, såsom externa tabeller, till hanterade tabeller innan du kör frågor mot dem.

Följande begränsningar är specifika för instrumentpaneler publicerade med ett Lakehouse//RT-lager:

• Genie stöds inte.
• Materialisering av lokala metriska vyer stöds inte.

Få hjälp

Om du fortsätter att uppleva problem med en instrumentpanel på Lakehouse//RT, samla in följande information och kontakta Azure Databricks support:

• Felmeddelandena du ser.
• En export av din sökfrågeprofil, inklusive råtexten från din sökfråga.
• En länk till din dashboard.
• Bekräftelse på att samma fel inte uppstår i ett serverlöst SQL-datalager.