Microsoft Fabric-beslutningsvejledning: Vælg et datalager

Brug denne referenceguide og eksempelscenarierne til at hjælpe dig med at vælge et datalager til dine Microsoft Fabric-arbejdsbelastninger. Alle datalagre er tilgængelige i samlet lagring i OneLake.

• Til streaming af eventdata og højgranularitet interaktiv analyse, brug et eventhouse.
• For NoSQL-databaser skal du bruge Cosmos DB i Fabric.
• For operationelle, transaktionelle, OLTP-arbejdsbelastninger eller normaliserede relationelle databaser, brug SQL-database i Fabric.
• For at udvikle AI med vektordatatyper, brug SQL-databasen i Fabric eller Cosmos DB i Fabric.
• Til enterprise data warehousing, SQL-baseret BI, OLAP og fuld SQL-transaktionsunderstøttelse, brug Fabric data warehouse.
• For big data og maskinlæring med ustrukturerede, semistrukturerede eller strukturerede data samt data engineering, brug et lakehouse.
• Alle Fabric-datalagre er tilgængelige i OneLake i åbent tabelformat som standard, med undtagelse af en KQL-database i et eventhouse, hvor OneLake-tilgængelighed er tilgængelig som en opt-in-funktion.

Personas og færdigheder

Scenarier

Gennemse disse scenarier for at få hjælp til at vælge et datalager i Fabric.

Scenarie 1

Susan, der er professionel udvikler, er ny i Microsoft Fabric. De er klar til at begynde at rense, modellere og analysere data, men skal beslutte, om de vil bygge et datalager eller et lakehouse. Efter at have gennemgået detaljerne i den foregående tabel er de primære beslutningspunkter det tilgængelige færdighedssæt og behovet for transaktioner med flere tabel.

Susan brugte mange år på at opbygge datalagre på relationelle databasemotorer og er bekendt med SQL-syntaks og funktionalitet. Når man tænker på det større team, er de primære forbrugere af disse data også dygtige til SQL- og SQL-analyseværktøjer. Susan beslutter at bruge et Fabric Warehouse-, som gør det muligt for teamet primært at interagere med T-SQL, samtidig med at spark-brugere i organisationen får adgang til dataene.

Susan opretter et nyt data warehouse og interagerer med det ved hjælp af T-SQL på samme måde som sine andre SQL-serverdatabaser. Det meste af den eksisterende T-SQL-kode, hun skrev for at bygge sit lager på SQL Server, fungerer i Fabric data warehouse, hvilket gør overgangen nem. Hvis hun vælger det, kan hun endda bruge de samme værktøjer, der fungerer sammen med sine andre databaser, f.eks. SQL Server Management Studio. Ved at bruge SQL-editoren i Fabric-portalen skriver Susan og andre teammedlemmer analytiske forespørgsler, der refererer til andre datalagre og Delta-tabeller i lakehouses blot ved at bruge tre-delte navne til at udføre krydsdatabaseforespørgsler.

Scenarie 2

Rob, der er datatekniker, skal gemme og modellere flere terabyte data i Fabric. Teamet har en blanding af PySpark og T-SQL færdigheder. De fleste af teamet, der kører T-SQL-forespørgsler, er forbrugere og behøver derfor ikke at skrive INSERT, UPDATE, eller DELETE sætninger. De resterende udviklere er komfortable med at arbejde i notesbøger, og da dataene er gemt i Delta, kan de interagere med en lignende SQL-syntaks.

Rob beslutter at bruge et lakehouse-, som gør det muligt for datateknikerteamet at bruge deres forskellige færdigheder i forhold til dataene, samtidig med at de gør det muligt for de teammedlemmer, der er højt kvalificerede i T-SQL, at forbruge dataene.

Scenarie 3

Daisy er forretningsanalytiker og har erfaring med at bruge Power BI til at analysere flaskehalse i forsyningskæden for en stor global detailkæde. De skal bygge en skalerbar dataløsning, der kan håndtere milliarder af rækker med data og kan bruges til at oprette dashboards og rapporter, der kan bruges til at træffe forretningsbeslutninger. Dataene kommer fra anlæg, leverandører, afsendere og andre kilder i forskellige strukturerede, semi-strukturerede og ustrukturerede formater.

Daisy beslutter sig for at bruge en Eventhouse- på grund af dens skalerbarhed, hurtige svartider, avancerede analysefunktioner, herunder tidsserieanalyse, geospatiale funktioner og hurtig direct query-tilstand i Power BI. Hun kan udføre forespørgsler ved at bruge Power BI og KQL til at sammenligne nuværende og tidligere perioder, hurtigt identificere nye problemer eller levere geo-spatiale analyser af land- og søruter.

Scenarie 4

Kirby er en programarkitekt, der har erfaring med udvikling af .NET-programmer til driftsdata. De har brug for en database med høj samtidighed med fuld ACID-transaktionsoverholdelse og stærkt gennemtvungne fremmede nøgler for relationsintegritet. Kirby ønsker fordelen ved automatisk justering af ydeevnen for at forenkle den daglige databaseadministration.

Kirby beslutter sig for en SQL-database i Fabricmed det samme SQL databaseprogram som Azure SQL Database. SQL-databaser i Fabric skaleres automatisk for at imødekomme efterspørgslen i løbet af arbejdsdagen. De har den fulde funktionalitet i transaktionstabeller og fleksibiliteten i transaktionsisolationsniveauerne fra serialiserbare til læsebelagte snapshots. SQL-databasen i Fabric opretter og dropper automatisk ikke-registrerede indeks baseret på stærke signaler fra udførelsesplaner, der er observeret over tid.

I Kirbys scenarie skal data fra driftsprogrammet være forbundet med andre data i Fabric: i Spark, i et lager og fra hændelser i realtid i et Eventhouse. Alle Fabric-databaser indeholder et SQL-analyseslutpunkt, så der kan opnås adgang til data i realtid fra Spark eller med Power BI-forespørgsler ved hjælp af DirectLake-tilstand. Disse rapporteringsløsninger skåner den primære driftsmæssige database fra omkostningerne ved analytiske arbejdsbelastninger og undgår denormalisering. Kirby har også eksisterende driftsdata i andre SQL-databaser og skal importere disse data uden transformation. For at importere eksisterende driftsdata uden nogen datatypekonvertering designer Kirby pipelines med Fabric Data Factory for at importere data til Fabric SQL-databasen.

Næste trin