Microsoft Fabric-beslutningsvejledning: Vælg et datalager
Brug denne referencevejledning og eksempelscenarierne til at hjælpe dig med at vælge et datalager til dine Microsoft Fabric-arbejdsbelastninger.
Egenskaber for datalager
I denne tabel sammenlignes datalagre som f.eks. warehouse, lakehouse, Power BI-datamart og eventhouse baseret på datamængde, type, udviklerpersona, kompetencesæt, handlinger. og andre funktioner.
| Lageragersted | Lakehouse | Power BI-datamart | Eventhouse | |
|---|---|---|---|---|
| Datamængde | Ubegrænset | Ubegrænset | Op til 100 GB | Ubegrænset |
| Datatype | Struktureret | Ustruktureret, halvstruktureret, struktureret | Struktureret | Ustruktureret, halvstruktureret, struktureret |
| Primær udviklerperson | Udvikler af data warehouse, SQL-tekniker | Datatekniker, dataforsker | Borgerudvikler | Citizen Data scientist, Data engineer, Data scientist, SQL Engineer |
| Kompetencesæt for primær udvikler | SQL | Spark(Scala, PySpark, Spark SQL, R) | Ingen kode, SQL | Ingen kode, KQL, SQL |
| Data organiseret af | Databaser, skemaer og tabeller | Mapper og filer, databaser og tabeller | Database, tabeller, forespørgsler | Databaser, skemaer og tabeller |
| Læsehandlinger | T-SQL, Spark (understøtter læsning fra tabeller ved hjælp af genveje, understøtter endnu ikke adgang til visninger, lagrede procedurer, funktioner osv.) | Spark, T-SQL | Spark, T-SQL, Power BI | KQL, T-SQL, Spark, Power BI |
| Skrivehandlinger | T-SQL | Spark(Scala, PySpark, Spark SQL, R) | Dataflow, T-SQL | KQL, Spark, forbindelsesøkosystem |
| Transaktioner med flere tabeller | Ja | Nr. | Nej | Ja, for indtagelse med flere tabeller. Se opdateringspolitik. |
| Primær udviklingsgrænseflade | SQL-scripts | Spark-notesbøger,Spark-jobdefinitioner | Power BI | KQL-forespørgselssæt, KQL-database |
| Sikkerhed | Objektniveau (tabel, visning, funktion, lagret procedure osv.), kolonneniveau, rækkeniveau, DDL/DML, dynamisk datamaskering | Rækkeniveau, kolonneniveau (for lakehouse, der er tilgået via et SQL Analytics-slutpunkt), tabelniveau (når du bruger T-SQL), ingen for Spark | Indbygget RLS-editor | Sikkerhed på rækkeniveau |
| Få adgang til data via genveje | Ja, gennem et lakehouse ved hjælp af tre-del navne | Ja | Nr. | Ja |
| Kan være en kilde til genveje | Ja (tabeller) | Ja (filer og tabeller) | Nej | Ja |
| Forespørgsel på tværs af elementer | Ja, forespørg på tværs af lakehouse- og lagertabeller | Ja, forespørg på tværs af lakehouse- og warehouse-tabeller. forespørgsel på tværs af lakehouses (herunder genveje ved hjælp af Spark) | Nr. | Ja, forespørg på tværs af KQL-databaser, lakehouses og lagre med genveje |
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 komme i gang med at rense, modellere og analysere data, men skal beslutte at bygge et data warehouse eller et lakehouse. Efter gennemgang af detaljerne i den forrige tabel er de primære beslutningspunkter de tilgængelige færdigheder og behovet for transaktioner med flere tabeller.
Susan har brugt mange år på at bygge data warehouses på relationsdatabaseprogrammer og kender 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 sig for at bruge et data 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 lakehouse og får adgang til data warehouse-funktionerne med sql analytics-slutpunktet for lakehouse. Ved hjælp af Fabric-portalen oprettes der genveje til de eksterne datatabeller, og de placeres i mappen /Tables . Susan kan nu skrive T-SQL-forespørgsler, der refererer til genveje til at forespørge Delta Lake-data i lakehouse. Genvejene vises automatisk som tabeller i SQL Analytics-slutpunktet og kan forespørges med T-SQL ved hjælp af tredelte navne.
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 de team, 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 sig for at bruge et lakehouse, hvilket gør det muligt for datateknikerteamet at bruge deres forskellige færdigheder i forhold til dataene, samtidig med at teammedlemmer, der er højt kvalificerede i T-SQL, kan bruge dataene.
Scenarie 3
Ash, der er borgerudvikler, er Power BI-udvikler. De kender Excel, Power BI og Office. De skal oprette et dataprodukt til en forretningsenhed. De ved, at de ikke helt har færdighederne til at bygge et data warehouse eller et lakehouse, og de ser ud til at være for meget til deres behov og datamængder. De gennemser detaljerne i den forrige tabel og kan se, at de primære beslutningspunkter er deres egne færdigheder og deres behov for selvbetjening, ingen kodefunktionalitet og datavolumen under 100 GB.
Ash arbejder sammen med forretningsanalytikere, der kender Power BI og Microsoft Office, og ved, at de allerede har et Premium-kapacitetsabonnement. Når de tænker på deres større team, indser de, at de primære forbrugere af disse data kan være analytikere, der kender værktøjer uden kode og SQL-analyse. Ash beslutter sig for at bruge en Power BI-datamart, som gør det muligt for teamet at interagere med at bygge funktionaliteten hurtigt ved hjælp af en oplevelse uden kode. Forespørgsler kan udføres via Power BI og T-SQL, samtidig med at alle Spark-brugere i organisationen også kan få adgang til dataene.
Scenario 4
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 et eventhouse på grund af dets skalerbarhed, hurtige svartider, avancerede analysefunktioner, herunder tidsserieanalyse, geospatiale funktioner og hurtig direkte forespørgselstilstand i Power BI. Forespørgsler kan udføres ved hjælp af Power BI og KQL for at sammenligne mellem aktuelle og tidligere perioder, hurtigt identificere nye problemer eller levere geo-rumlige analyser af land- og søfartsruter.