Beslutningsveiledning for Microsoft Fabric: Velg et datalager

Bruk denne referanseguiden og eksempelscenarioene for å hjelpe deg med å velge et datalager for dine Microsoft Fabric-arbeidsbelastninger. Alle datalagre er tilgjengelige i enhetlig lagring i OneLake.

• For strømming av hendelsesdata og høygranularitets interaktiv analyse, bruk et eventhus.
• For NoSQL-databaser, bruk Cosmos DB in Fabric.
• For operative, transaksjonelle, OLTP-arbeidsbelastninger eller normaliserte relasjonsdatabaser, bruk SQL-database i Fabric.
• For å utvikle AI med vektordatatyper, bruk SQL-databasen i Fabric eller Cosmos DB i Fabric.
• For bedriftsdatavarehus, SQL-basert BI, OLAP og full støtte for SQL-transaksjoner, bruk Fabric datalager.
• For big data og maskinlæring med ustrukturerte, semistrukturerte eller strukturerte data, og data engineering, bruk et lakehouse.
• Alle Fabric-datalagre er tilgjengelige i OneLake i åpen tabell-format som standard, med unntak av en KQL-database i et eventhouse, hvor OneLake-tilgjengelighet er tilgjengelig som en opt-in-funksjon.

Personas og ferdigheter

Scenarier

Se gjennom disse scenariene for å få hjelp til å velge et datalager i Fabric.

Scenario 1

Susan, en profesjonell utvikler, er ny hos Microsoft Fabric. De er klare til å begynne å rense, modellere og analysere data, men må bestemme seg for om de skal bygge et datalager eller et innsjøhus. Etter å ha gjennomgått detaljene i forrige tabell, er de viktigste beslutningspunktene tilgjengelig ferdighetssett og behovet for transaksjoner med flere tabeller.

Susan brukte mange år på å bygge datavarehus på relasjonsdatabasemotorer, og er kjent med SQL-syntaks og funksjonalitet. Når du tenker på det større teamet, er de primære forbrukerne av disse dataene også dyktige med SQL- og SQL-analytiske verktøy. Susan bestemmer seg for å bruke et Fabric-lager, som gjør det mulig for teamet å samhandle primært med T-SQL, samtidig som alle Spark-brukere i organisasjonen får tilgang til dataene.

Susan oppretter et nytt datalager og samhandler med det ved hjelp av T-SQL, akkurat som de andre SQL Server-databasene. Det meste av den eksisterende T-SQL-koden hun skrev for å bygge lageret sitt på SQL Server fungerer i Fabric datalager, noe som gjør overgangen enkel. Hvis hun velger det, kan hun til og med bruke de samme verktøyene som fungerer med de andre databasene, for eksempel SQL Server Management Studio. Ved å bruke SQL-editoren i Fabric-portalen skriver Susan og andre teammedlemmer analytiske spørringer som refererer til andre datavarehus og Delta-tabeller i lakehouses, enkelt ved å bruke tredelte navn for å utføre kryssdatabase-spørringer.

Scenario 2

Rob, en dataingeniør, må lagre og modellere flere terabyte med data i Fabric. Teamet har en blanding av PySpark- og T-SQL-ferdigheter. De fleste i teamet som kjører T-SQL-spørringer er forbrukere, og trenger derfor ikke å skrive INSERT, UPDATE, eller DELETE setninger. De gjenværende utviklerne er komfortable med å arbeide i notatblokker, og fordi dataene er lagret i Delta, kan de samhandle med en lignende SQL-syntaks.

Rob bestemmer seg for å bruke en lakehouse, som gjør det mulig for dataingeniørteamet å bruke sine ulike ferdigheter mot dataene, samtidig som teammedlemmene som er svært dyktige i T-SQL, kan bruke dataene.

Scenario 3

Daisy er forretningsanalytiker med erfaring med å bruke Power BI til å analysere flaskehalser i forsyningskjeden for en stor global butikkjede. De må bygge en skalerbar dataløsning som kan håndtere milliarder av rader med data og kan brukes til å bygge instrumentbord og rapporter som kan brukes til å ta forretningsbeslutninger. Dataene kommer fra anlegg, leverandører, avsendere og andre kilder i ulike strukturerte, halvstrukturerte og ustrukturerte formater.

Daisy bestemmer seg for å bruke en Eventhouse- på grunn av skalerbarheten, raske responstider, avanserte analysefunksjoner, inkludert tidsserieanalyse, geospatiale funksjoner og rask direkte spørringsmodus i Power BI. Hun kan utføre spørringer ved å bruke Power BI og KQL for å sammenligne nåværende og tidligere perioder, raskt identifisere nye problemer, eller gi geo-spatiale analyser av land- og sjøruter.

Scenario 4

Kirby er en programarkitekt med erfaring i utvikling av .NET-programmer for driftsdata. De trenger en database med høy samtidighet med fullstendig ACID-transaksjonssamsvar og sterkt håndhevet sekundærnøkler for relasjonsintegritet. Kirby ønsker fordelen av automatisk ytelsesjustering for å forenkle den daglige databasebehandlingen.

Kirby bestemmer seg for en SQL-database i Fabric, med samme SQL databasemotor som Azure SQL Database. SQL-databaser i Fabric skaleres automatisk for å møte etterspørselen i løpet av arbeidsdagen. De har den fullstendige funksjonaliteten til transaksjonstabeller og fleksibiliteten til transaksjonsisolasjonsnivåer fra serialiserbart til å lese forpliktet øyeblikksbilde. SQL-database i Fabric oppretter og slipper automatisk indekser som ikke er inkludert basert på sterke signaler fra utførelsesplaner som er observert over tid.

I Kirbys scenario må data fra den operative applikasjonen kobles sammen med andre data i Fabric: i Spark, på et lager og fra sanntidshendelser i et Eventhouse. Hver Fabric-database inneholder et SQL Analytics-endepunkt, slik at data som skal åpnes i sanntid fra Spark eller med Power BI-spørringer ved hjelp av DirectLake-modus. Disse rapporteringsløsningene sparer den primære driftsdatabasen fra overhead av analytiske arbeidsbelastninger, og unngår denormalisering. Kirby har også eksisterende driftsdata i andre SQL-databaser, og må importere disse dataene uten transformasjon. For å importere eksisterende driftsdata uten datatypekonvertering, designer Kirby pipeliner med Fabric Data Factory for å importere data til Fabric SQL-databasen.

Neste trinn: