Beslutningsveiledning for Microsoft Fabric: Velg et datalager

  • Artikkel

Bruk denne referanseveiledningen og eksempelscenarioene for å hjelpe deg med å velge et datalager for Microsoft Fabric-arbeidsbelastningene dine.

Egenskaper for datalager

Datalager Lakehouse Power BI Datamart KQL-database (Eventhouse)
Datavolum Ubegrenset Ubegrenset Opptil 100 GB Ubegrenset
Type data Strukturert Ustrukturert, halvstrukturert, strukturert Strukturert Ustrukturert, halvstrukturert, strukturert
Primær utviklerperson Datalagerutvikler, SQL-tekniker Dataingeniør, dataforsker Borgerutvikler Citizen Data scientist, Data engineer, Data scientist, SQL engineer
Ferdighetssett for primærutvikler SQL Spark(Scala, PySpark, Spark SQL, R) Ingen kode, SQL Ingen kode, KQL, SQL
Data organisert etter Databaser, skjemaer og tabeller Mapper og filer, databaser og tabeller Database, tabeller, spørringer Databaser, skjemaer og tabeller
Les operasjoner T-SQL, Spark (støtter lesing fra tabeller ved hjelp av snarveier, støtter ennå ikke tilgang til visninger, lagrede prosedyrer, fuksjoner osv.) Spark, T-SQL Spark, T-SQL, Power BI KQL, T-SQL, Spark, Power BI
Skriveoperasjoner T-SQL Spark(Scala, PySpark, Spark SQL, R) Dataflyter, T-SQL KQL, Spark, koblingsøkosystem
Transaksjoner med flere tabeller Ja No No Ja, for flertabellinntak. Se oppdateringspolicy.
Primært utviklingsgrensesnitt SQL-skript Spark-notatblokker, Spark-jobbdefinisjoner Power BI KQL Queryset, KQL Database
Sikkerhet Objektnivå (tabell, visning, funksjon, lagret prosedyre osv.), kolonnenivå, radnivå, DDL/DML, dynamisk datamaskering Radnivå, tabellnivå (når du bruker T-SQL), ingen for Spark Innebygd RLS-redigeringsprogram Sikkerhet på radnivå
Få tilgang til data via snarveier Ja (indirekte gjennom lakehouse) Ja No Ja
Kan være en kilde for snarveier Ja (tabeller) Ja (filer og tabeller) Nei Ja
Spørring på tvers av elementer Ja, spør på tvers av lakehouse- og lagertabeller Ja, spør på tvers av lakehouse- og lagertabeller; spørring på tvers av lakehouses (inkludert snarveier ved hjelp av Spark) No Ja, spørring på tvers av KQL-databaser, lakehouses og lagre med snarveier
Avansert analyse Opprinnelige elementer i tidsserien, fullstendig geospatial lagring og spørringsfunksjoner
Støtte for avansert formatering Full indeksering for fri tekst og halvstrukturerte data som JSON
Ventetid for inntak Inntak i kø, strømming av inntak har et par sekunder ventetid

Merk

Eventhouse er et arbeidsområde for flere KQL-databaser. KQL-database er generelt tilgjengelig, mens Eventhouse er i forhåndsversjon. Hvis du vil ha mer informasjon, kan du se Oversikt over Eventhouse (forhåndsversjon).

Scenarioer

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 å komme i gang med rengjøring, modellering og analyse av data, men må bestemme seg for å bygge et datalager eller et lakehouse. Etter å ha gjennomgått detaljene i forrige tabell, er de primære beslutningspunktene det tilgjengelige kompetansesettet og behovet for transaksjoner med flere tabeller.

Susan har brukt mange år på å bygge datalagre 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 datalager, 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.

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 av 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 et 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

Ash, en utvikler av borgere, er en Power BI-utvikler. De er kjent med Excel, Power BI og Office. De må bygge et dataprodukt for en forretningsenhet. De vet at de ikke helt har ferdigheter til å bygge et datalager eller et innsjøhus, og de virker som for mye for deres behov og datavolumer. De ser gjennom detaljene i forrige tabell og ser at de primære beslutningspunktene er deres egne ferdigheter og deres behov for selvbetjening, ingen kodefunksjonalitet og datavolum under 100 GB.

Ash jobber med forretningsanalytikere som er kjent med Power BI og Microsoft Office, og vet at de allerede har et Premium-kapasitetsabonnement. Når de tenker på deres større team, innser de at de primære forbrukerne av disse dataene kan være analytikere, kjent med no-code og SQL analytiske verktøy. Ash bestemmer seg for å bruke et Power BI-datamart, som gjør det mulig for teamet å samhandle med å bygge funksjonaliteten raskt, ved hjelp av en no-code-opplevelse. Spørringer kan utføres via Power BI og T-SQL, samtidig som spark-brukere i organisasjonen også får tilgang til dataene.

Scenario 4

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 KQL-database på grunn av skalerbarhet, rask responstid, avanserte analysefunksjoner, inkludert tidsserieanalyse, geospatiale funksjoner og rask direkte spørringsmodus i Power BI. Spørringer kan utføres ved hjelp av Power BI og KQL for å sammenligne mellom gjeldende og tidligere perioder, raskt identifisere nye problemer eller gi geo-spatial analyse av land- og maritime ruter.

Relatert innhold