Beslutsguide för Microsoft Fabric: välj ett datalager

Använd den här referensguiden och exempelscenarier som hjälper dig att välja ett datalager för dina Microsoft Fabric-arbetsbelastningar, alla tillgängliga i en enhetlig lagring i OneLake.

Personas och kompetensuppsättningar

Scenarier

Läs de här scenarierna om du vill ha hjälp med att välja ett datalager i Fabric.

Scenario 1:

Susan, en professionell utvecklare, är ny i Microsoft Fabric. De är redo att komma igång med att rensa, modellera och analysera data, men de måste bestämma sig för att skapa ett informationslager eller ett sjöhus. Efter granskning av informationen i föregående tabell är de primära beslutspunkterna den tillgängliga kunskapsuppsättningen och behovet av transaktioner med flera tabeller.

Susan har ägnat många år åt att skapa informationslager på relationsdatabasmotorer och är bekant med SQL-syntax och funktioner. När man tänker på det större teamet är de primära konsumenterna av dessa data också skickliga med SQL- och SQL-analysverktyg. Susan bestämmer sig för att använda ett Fabric-lager, vilket gör att teamet främst kan interagera med T-SQL, samtidigt som alla Spark-användare i organisationen kan komma åt data.

Susan skapar ett nytt informationslager och interagerar med det med hjälp av T-SQL precis som sina andra SQL Server-databaser. Det mesta av den befintliga T-SQL-kod som hon har skrivit för att bygga sitt lager på SQL Server fungerar på infrastrukturdatalagret, vilket gör övergången enkel. Om hon väljer att göra det kan hon till och med använda samma verktyg som fungerar med hennes andra databaser, till exempel SQL Server Management Studio. Med sql-redigeraren i Infrastrukturportalen skriver Susan och andra teammedlemmar analysfrågor som refererar till andra informationslager och Delta-tabeller i lakehouses genom att bara använda tredelade namn för att utföra frågor mellan databaser.

Scenario 2

Rob, en datatekniker, måste lagra och modellera flera terabyte data i Fabric. Teamet har en blandning av PySpark- och T-SQL-kunskaper. De flesta i teamet som kör T-SQL-frågor är konsumenter och behöver därför inte skriva INSERT-, UPDATE- eller DELETE-instruktioner. De återstående utvecklarna är bekväma med att arbeta i notebook-filer, och eftersom data lagras i Delta kan de interagera med en liknande SQL-syntax.

Rob bestämmer sig för att använda en lakehouse-, som gör det möjligt för datateknikteamet att använda sina olika kunskaper mot data, samtidigt som teammedlemmarna som är mycket skickliga i T-SQL kan använda data.

Scenario 3

Daisy är affärsanalytiker med erfarenhet av att använda Power BI för att analysera flaskhalsar i leveranskedjan för en stor global detaljhandelskedja. De måste skapa en skalbar datalösning som kan hantera miljarder rader med data och som kan användas för att skapa instrumentpaneler och rapporter som kan användas för att fatta affärsbeslut. Data kommer från anläggningar, leverantörer, speditörer och andra källor i olika strukturerade, halvstrukturerade och ostrukturerade format.

Daisy bestämmer sig för att använda en Eventhouse- på grund av dess skalbarhet, snabba svarstider, avancerade analysfunktioner, inklusive tidsserieanalys, geospatiala funktioner och snabbt direktfrågeläge i Power BI. Frågeställningar kan köras med hjälp av Power BI och KQL för att jämföra aktuella och tidigare perioder, snabbt identifiera nya problem eller utföra geospatial analys av land- och sjövägar.

Scenario 4

Kirby är en programarkitekt med erfarenhet av att utveckla .NET-program för driftdata. De behöver en databas med hög samtidighet med fullständig ACID-transaktionsefterlevnad och starkt framtvingade sekundärnycklar för relationsintegritet. Kirby vill ha fördelen med automatisk prestandajustering för att förenkla den dagliga databashanteringen.

Kirby bestämmer sig för en SQL-databas i Fabricmed samma SQL Database-motor som Azure SQL Database. SQL-databaser i Fabric skalas automatiskt för att möta efterfrågan under hela arbetsdagen. De har fullständig kapacitet för transaktionstabeller och flexibiliteten i transaktionsisoleringsnivåer från serialiserbar till läsbar ögonblicksbild. SQL-databasen i Fabric skapar och släpper automatiskt icke-klustrade index baserat på starka signaler från exekveringsplaner som har observerats över tid.

I Kirbys scenario måste data från det operativa programmet kopplas till andra data i Infrastruktur: i Spark, i ett lager och från realtidshändelser i ett Eventhouse. Varje Fabric-databas innehåller en SQL-analysslutpunkt, så att data kan nås i realtid från Spark eller med Power BI-frågor med DirectLake-läge. De här rapporteringslösningarna besparar den primära driftdatabasen från kostnaderna för analytiska arbetsbelastningar och undviker avnormalisering. Kirby har också befintliga driftdata i andra SQL-databaser och måste importera dessa data utan transformering. Om du vill importera befintliga driftdata utan någon datatypkonvertering utformar Kirby pipelines med Fabric Data Factory för att importera data till Fabric SQL-databasen.

Nästa steg