Beslutningsveiledning for Microsoft Fabric: datalager eller lakehouse
Bruk denne referanseveiledningen og eksempelscenarioene for å hjelpe deg med å velge mellom datalageret eller et lakehouse for arbeidsbelastningene dine ved hjelp av Microsoft Fabric.
Viktig
Microsoft Fabric er for øyeblikket i FORHÅNDSVERSJON. Denne informasjonen er knyttet til et forhåndsutgitt produkt som kan endres vesentlig før det utgis. Microsoft gir ingen garantier, uttrykt eller underforstått, med hensyn til informasjonen som er oppgitt her.
Egenskaper for datalager og lakehouse
| Datalager | Lakehouse | Power BI-datamart | |
|---|---|---|---|
| Datavolum | Ubegrenset | Ubegrenset | Opptil 100 GB |
| Datatype | Strukturert | Ustrukturert halvstrukturert, Strukturert |
Strukturert |
| Primær utviklerpersonlighet | Datalagerutvikler, SQL-tekniker |
Datatekniker, dataforsker |
Borger utvikler |
| Hovedkompetansesett for utviklere | SQL | Spark (Scala, PySpark, Spark SQL, R) |
Ingen kode, SQL |
| Data organisert etter | Databaser, skjemaer og tabeller | Mapper og filer, databaser og tabeller |
Database, tabeller, spørringer |
| Leseoperasjoner | Gnist T-SQL |
Gnist T-SQL |
Gnist T-SQL, Power BI |
| Skriveoperasjoner | T-SQL | Spark (Scala, PySpark, Spark SQL, R) |
Dataflyter, T-SQL |
| Transaksjoner med flere tabeller | Ja | Nei | Nei |
| Primært utviklingsgrensesnitt | SQL-skript | Spark-notatblokker, Spark-jobbdefinisjoner |
Power BI |
| Sikkerhet | Objektnivå (tabell, visning, funksjon, lagret prosedyre osv.), kolonnenivå, radnivå, DDL/DML |
Radnivå, tabellnivå (ved bruk av T-SQL) ingen for Spark |
Innebygd redigeringsprogram for RLS |
| Få tilgang til data via snarveier | Ja (indirekte gjennom lakehouse) | Ja | Nei |
| Kan være en kilde for snarveier | Ja (tabeller) | Ja (filer og tabeller) | Nei |
| Spørring på tvers av elementer | Ja, spørring 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) |
Nei |
Scenarioer
Se gjennom disse scenariene for å få hjelp med å velge mellom å bruke et lakehouse eller et datalager i Fabric.
Scenario 1
Susan, en profesjonell utvikler, er ny i Microsoft Fabric. De er klare til å komme i gang med å rengjøre, modellere og analysere data, men må bestemme seg for å bygge et datalager eller et lakehouse. Når du har 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 vi 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 hovedsakelig med T-SQL, samtidig som spark-brukere i organisasjonen får tilgang til dataene.
Scenario 2
Rob, en datatekniker, 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 borgerutvikler, 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 en selvbetjening, ingen kodefunksjonalitet og datavolum under 100 GB.
Ash fungerer 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 ikke-kode 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 opplevelse uten kode. Spørringer kan utføres via Power BI og T-SQL, samtidig som spark-brukere i organisasjonen også får tilgang til dataene.