Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
För att förbättra prestanda och tillförlitlighet använder Dataflow Gen2 mellanlagringsobjekt för att lagra mellanliggande data under datatransformeringen. Den här artikeln beskriver vad mellanlagringsobjekt är, elt-mönstren som de låser upp genom fasen en gång, refererar till många modeller och hur de hanterar de data de har.
Vad är mellanlagringsobjekt?
Mellanlagringsobjekt är mellanliggande datalagringsplatser som används av Dataflow Gen2 för att lagra data under datatransformeringen. Dessa objekt går under namnen "DataflowsStagingLakehouse" och "DataflowsStagingWarehouse". Mellanlagringsobjekten används för att lagra mellanliggande data under datatransformeringen för att förbättra prestandan. Dessa objekt skapas automatiskt när du skapar ditt första dataflöde och hanteras av Dataflow Gen2. Dessa objekt är dolda för användaren på arbetsytan, men kan vara synliga i andra upplevelser som Hämta data eller Lakehouse Explorer. Vi rekommenderar starkt att du inte kommer åt eller ändrar data i mellanlagringsobjekten direkt eftersom det kan leda till oväntat beteende. Att lagra data på egen hand i mellanlagringsobjekten stöds inte och kan leda till dataförlust.
ELT-mönster: steg en gång, referera många gånger
Förutom att tillhandahålla mellanlagringsutrymme möjliggör staging en uppsättning ELT-mönster byggda på en enda grund: ladda en gång, använd många gånger. En källfråga markeras som mellanlagrad så att dess utdata materialiseras till intern mellanlagring. Underordnade frågor refererar sedan till den mellanlagrade frågan i stället för att läsa om källan. Fast Copy är en valfri accelerator som gör att den mellanlagrade frågan fylls i snabbare, men det är inte det som definierar mönstret.
Mönstret är viktigt eftersom, när data mellanlagras, kan nedströmsfrågor:
- Kör mot en indexerad, sökbar kopia utan att komma åt källan igen.
- Sammanfoga filter, föreningar och aggregat tillbaka till mellanlagrets SQL-slutpunkt i stället för att köras i mashup-motorn.
- Förgrena till flera parallella omvandlingar eller mål från ett enda materialiserat resultat.
Vanliga användningsfall
Följande mönster läggs vanligtvis ovanpå en etapperad källfråga.
| Användningsfall | Beskrivning |
|---|---|
| Forma mellanlagrade data till analysmodeller | Refererade frågor formar stegade data till fakta- och dimensionstabeller, sammanställningar, summeringar eller KPI:er genom deduplicering, gruppering och nyckelgenerering. |
| Nedfällbar beräkningsoptimering | Refererade frågor som skrivs mot mellanlagrade data integrerar sina kopplingar, filter och gruppvillkor med mellanlagringens SQL-slutpunkt och pushar beräkningen till lagermotorn istället för kombinationsmotorn. Det här är ofta den enskilt största prestandavinsten som möjliggörs. |
| Datakvalitet och granskningsgren | Refererade frågor validerar eller inspekterar mellanlagrade data (null-kontroller, begränsningsverifiering, radantal) utan att läsa källan igen. |
| Förgrening till flera mottagare | Flera refererade frågor läser in olika mål från samma mellanlagrade källa (till exempel ett Lakehouse och ett lager). |
| Steg-sedan-sammanslagning | Varje källa mellanlagras i sin egen fråga, sedan sammanfogas eller kopplas en underordnad refererad fråga till mellanlagrade resultat, vilket viker kopplingen tillbaka till sql-slutpunkten för mellanlagring. |
När en staging-miljö inte är passande
Mellanlagring ökar lagringskostnaden och kräver en extra skrivning innan efterföljande frågor körs. Överväg att hoppa över det när:
- Omvandlingen integreras redan sömlöst med källsystemet, utan beräkning i mashup-motorn.
- Dataflödet har en enda utgång och ingen nedströmsförgrening, validering eller förgrening.
- Källfördröjning är flaskhalsen och källan kan inte parallelliseras via förberedelsestadier.
Mer information om när du ska aktivera eller inaktivera mellanlagring finns i Metodtips för att få bästa prestanda med Dataflöde Gen2.
Data i mellanlagringsobjekt
Mellanlagringsobjekt är inte utformade för direkt åtkomst av användare. Dataflöde Gen2 hanterar data i mellanlagringsobjekten och säkerställer att data är i ett konsekvent skick. Åtkomst till data i mellanlagringsobjekt stöds inte direkt eftersom det inte går att garantera att data är i ett konsekvent tillstånd. Om du behöver komma åt data i mellanlagringsobjekt kan du använda dataflödesanslutningen i Power BI, Excel eller andra dataflöden.
Viktigt!
Det interna API:et som hanterar mellanlagrade data till nedströmskonsumenter (till exempel semantiska modeller eller andra dataflöden med dataflödesanslutningen) kan uppleva tillfälliga timeouter. Dessa timeouter kan orsaka uppdateringsfel i förbrukande objekt, vilket ofta visas som felet "Nyckeln matchade inte några rader i tabellen.". Det här felet tyder inte på något dataproblem. Det innebär att serverdelen inte kunde hämta mellanlagrade resultat i tid.
Rekommenderad lösning: Konfigurera ett datamål (Lakehouse eller Warehouse) för ditt dataflöde och uppdatera underordnade objekt för att läsa från målet direkt med hjälp av Lakehouse- eller Warehouse-anslutningsappen. Detta kringgår det interna mellanlagrings-API:et och förbättrar uppdateringstillförlitligheten.
Mer information finns i Begränsningar för Data Factory.
Att ta bort data från mellanlagringsobjekten kan tvingas av någon av följande åtgärder:
- Inaktivera staging i dataflödet och uppdatera det; efter 30 dagar genomför vi en automatisk rensning av data.
- Ta bort dataflödet (tar bort data direkt).
- Ta bort arbetsytan (tar direkt bort StagingLakehouse och StagingWarehouse).
Kostnadskonsekvenser av mellanlagring
Staging-Lakehouse och staging-Warehouse lagrar mellanliggande data som en del av databehandlingsflödet. Lagringen som förbrukas av dessa mellanlagringsobjekt faktureras som en del av din OneLake-lagring. Det innebär att data som lagras i mellanlagringsobjekten räknas mot din totala OneLake-lagringsförbrukning och tillhörande kostnader.
Så här hanterar du lagringskostnaderna effektivt:
- Övervaka användning av mellanlagring: Tänk på att mellanlagringsdata ackumuleras med varje dataflödesuppdatering tills det är skräp som samlas in eller uttryckligen tas bort.
- Inaktivera mellanlagring när det inte behövs: Om omvandlingarna viks till källsystemet kanske du inte behöver mellanlagring aktiverat. Om du inaktiverar mellanlagring minskar lagringsutrymmesanvändningen.
- Rensa oanvända dataflöden: Om du tar bort dataflöden som inte längre behövs tas de associerade mellanlagringsdata bort omedelbart.
- Överväg uppdateringsfrekvens: Frekventa uppdateringar med staging aktiverat kan leda till högre lagringsförbrukning. Balansera prestandafördelar mot lagringskostnader.
Mer information om priser för OneLake-lagring finns i Microsoft Fabric-priser.