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
Brug disse oplysninger til at sammenligne Fabric-datalagre, f.eks. lager, lakehouse, Eventhouse, SQL-database og Power BI-datamart, baseret på datamængde, type, udviklerpersona, kompetencesæt, handlinger og andre funktioner. Disse sammenligninger er organiseret i følgende to tabeller:
| Tabel 1 af 2 | Lakehouse | Lageragersted | Eventhouse |
|---|---|---|---|
| Datamængde | Ubegrænset | Ubegrænset | Ubegrænset |
| Datatype | Ustruktureret semi-struktureret, Struktureret |
Struktureret semi-struktureret (JSON) |
Ustruktureret semi-struktureret, Struktureret |
| Primær udviklerperson | Datatekniker, dataforsker | Udvikler af data warehouse, dataarkitekt, datatekniker, databaseudvikler | Appudvikler, dataforsker, datatekniker |
| Primær udviklingsevne | Spark (Scala, PySpark, Spark SQL, R) | SQL | Ingen kode, KQL, SQL |
| Data organiseret af | Mapper og filer, databaser og tabeller | Databaser, skemaer og tabeller | Databaser, skemaer og tabeller |
| Læsehandlinger | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Skrivehandlinger | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, forbindelsesøkosystem |
| Transaktioner med flere tabeller | Nej | Ja | Ja, for indtagelse med flere tabeller |
| Primær udviklingsgrænseflade | Spark-notesbøger, Spark-jobdefinitioner | SQL-scripts | KQL-forespørgselssæt, KQL-database |
| Sikkerhed | RLS, CLS**, tabelniveau (T-SQL), ingen for Spark | Objektniveau, RLS, CLS, DDL/DML, dynamisk datamaskering | Sikkerhed på rækkeniveau |
| Få adgang til data via genveje | Ja | Ja, via SQL Analytics-slutpunktet | Ja |
| Kan være en kilde til genveje | Ja (filer og tabeller) | Ja (tabeller) | Ja |
| Forespørgsel på tværs af elementer | Ja | Ja | Ja |
| Avanceret analyse | Grænseflade til databehandling i stor skala, indbygget data parallelitet og fejltolerance | Grænseflade til databehandling i stor skala, indbygget data parallelitet og fejltolerance | Oprindelige elementer i tidsserien, fuld geo-afstand og forespørgselsfunktioner |
| Understøttelse af avanceret formatering | Tabeller, der er defineret ved hjælp af PARQUET, CSV, AVRO, JSON og et hvilket som helst Apache Hive-kompatibelt filformat | Tabeller, der er defineret ved hjælp af PARQUET, CSV, AVRO, JSON og et hvilket som helst Apache Hive-kompatibelt filformat | Fuld indeksering til fri tekst og semi-strukturerede data, f.eks. JSON |
| Ventetid for indtagelse | Tilgængelig med det samme til forespørgsler | Tilgængelig med det samme til forespørgsler | Køindtagelse, streamingindtagelse har et par sekunders ventetid |
* Spark understøtter læsning fra tabeller ved hjælp af genveje, understøtter endnu ikke adgang til visninger, lagrede procedurer, funktioner osv.
| Tabel 2 af 2 | Fabric SQL-database | Power BI-datamart |
|---|---|---|
| Datamængde | 4 TB | Op til 100 GB |
| Datatype | Struktureret semi-struktureret, Ustruktureret |
Struktureret |
| Primær udviklerperson | AI-udvikler, appudvikler, databaseudvikler, DB-administrator | Dataspecialist, dataanalytiker |
| Primær udviklingsevne | SQL | Ingen kode, SQL |
| Data organiseret af | Databaser, skemaer, tabeller | Database, tabeller, forespørgsler |
| Læsehandlinger | T-SQL | Spark, T-SQL |
| Skrivehandlinger | T-SQL | Dataflow, T-SQL |
| Transaktioner med flere tabeller | Ja, fuld ACID-overholdelse | Nej |
| Primær udviklingsgrænseflade | SQL-scripts | Power BI |
| Sikkerhed | Objektniveau, RLS, CLS, DDL/DML, dynamisk datamaskering | Indbygget RLS-editor |
| Få adgang til data via genveje | Ja | Nej |
| Kan være en kilde til genveje | Ja (tabeller) | Nej |
| Forespørgsel på tværs af elementer | Ja | Nej |
| Avanceret analyse | T-SQL-analysefunktioner, data replikeret til delta-parquet i OneLake til analyse | Grænseflade til databehandling med automatiseret justering af ydeevne |
| Understøttelse af avanceret formatering | Tabelunderstøtter OLTP, JSON, vektor, graf, XML, afstand, nøgleværdi | Tabeller, der er defineret ved hjælp af PARQUET, CSV, AVRO, JSON og et hvilket som helst Apache Hive-kompatibelt filformat |
| Ventetid for indtagelse | Tilgængelig med det samme til forespørgsler | Tilgængelig med det samme til forespørgsler |
** Sikkerhed på kolonneniveau, der er tilgængelig i Lakehouse via et SQL-analyseslutpunkt ved hjælp af T-SQL.
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 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 har skrevet for at bygge sit lager på SQL Server, fungerer på Fabric-data warehouseet, 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 hjælp af SQL-editoren på Fabric-portalen skriver Susan og andre teammedlemmer analyseforespørgsler, der refererer til andre data warehouses og Delta-tabeller i lakehouses ved ganske enkelt at bruge navne med tre dele til at udføre forespørgsler på tværs af databaser.
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 er 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.
Scenarie 5
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 Fabric med det samme SQL Database Engine 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. Kirby designer datapipelines med Fabric Data Factory for at importere data til Fabric SQL-databasen for at importere eksisterende driftsdata uden konvertering af datatyper.