Beslutningsveiledning for Microsoft Fabric: Velg et datalager
Bruk denne referanseveiledningen og eksempelscenarioene for å hjelpe deg med å velge et datalager for Microsoft Fabric-arbeidsbelastningene dine.
Egenskaper for datalager
Bruk denne informasjonen til å sammenligne Fabric-datalagre som lager, lakehouse, Eventhouse, SQL-database og Power BI-datamart, basert på datavolum, type, utviklerpersonlighet, kompetansesett, operasjoner og andre funksjoner. Disse sammenligningene er organisert i følgende to tabeller:
| Tabell 1 av 2 | Lakehouse | Lager | Eventhouse |
|---|---|---|---|
| Datavolum | Ubegrenset | Ubegrenset | Ubegrenset |
| Type data | Ustrukturert halvstrukturert, Strukturert |
Strukturert halvstrukturert (JSON) |
Ustrukturert halvstrukturert, Strukturert |
| Primær utviklerperson | Dataingeniør, dataforsker | Datalagerutvikler, dataarkitekt, dataingeniør, databaseutvikler | Apputvikler, dataforsker, dataingeniør |
| Primær utviklingsferdighet | Spark (Scala, PySpark, Spark SQL, R) | SQL | Ingen kode, KQL, SQL |
| Data organisert etter | Mapper og filer, databaser og tabeller | Databaser, skjemaer og tabeller | Databaser, skjemaer og tabeller |
| Les operasjoner | Spark, T-SQL | T-SQL, Spark* | KQL, T-SQL, Spark |
| Skriveoperasjoner | Spark (Scala, PySpark, Spark SQL, R) | T-SQL | KQL, Spark, koblingsøkosystem |
| Transaksjoner med flere tabeller | Nei | Ja | Ja, for flertabellinntak |
| Primært utviklingsgrensesnitt | Spark-notatblokker, Spark-jobbdefinisjoner | SQL-skript | KQL Queryset, KQL Database |
| Sikkerhet | RLS, CLS**, tabellnivå (T-SQL), ingen for Spark | Objektnivå, RLS, CLS, DDL/DML, dynamisk datamaskering | RLS |
| Få tilgang til data via snarveier | Ja | Ja, via endepunktet for SQL-analyse | Ja |
| Kan være en kilde for snarveier | Ja (filer og tabeller) | Ja (tabeller) | Ja |
| Spørring på tvers av elementer | Ja | Ja | Ja |
| Avansert analyse | Grensesnitt for databehandling i stor skala, innebygd data parallelisme og feiltoleranse | Grensesnitt for databehandling i stor skala, innebygd data parallelisme og feiltoleranse | Opprinnelige elementer i tidsserien, fullstendige geografiske funksjoner og spørringsfunksjoner |
| Støtte for avansert formatering | Tabeller definert ved hjelp av PARQUET, CSV, AVRO, JSON og alle Apache Hive-kompatible filformater | Tabeller definert ved hjelp av PARQUET, CSV, AVRO, JSON og alle Apache Hive-kompatible filformater | Full indeksering for fri tekst og halvstrukturerte data som JSON |
| Ventetid for inntak | Tilgjengelig umiddelbart for spørring | Tilgjengelig umiddelbart for spørring | Inntak i kø, strømming av inntak har et par sekunder ventetid |
* Spark støtter lesing fra tabeller ved hjelp av snarveier, støtter ennå ikke tilgang til visninger, lagrede prosedyrer, funksjoner osv.
| Tabell 2 av 2 | Fabric SQL-database | Power BI Datamart |
|---|---|---|
| Datavolum | 4 TB | Opptil 100 GB |
| Type data | Strukturert halvstrukturert, Ustrukturert |
Strukturert |
| Primær utviklerperson | AI-utvikler, apputvikler, databaseutvikler, DB-administrator | Dataforsker, dataanalytiker |
| Primær utviklingsferdighet | SQL | Ingen kode, SQL |
| Data organisert etter | Databaser, skjemaer, tabeller | Database, tabeller, spørringer |
| Les operasjoner | T-SQL | Spark, T-SQL |
| Skriveoperasjoner | T-SQL | Dataflyter, T-SQL |
| Transaksjoner med flere tabeller | Ja, fullstendig ACID-samsvar | Nei |
| Primært utviklingsgrensesnitt | SQL-skript | Power BI |
| Sikkerhet | Objektnivå, RLS, CLS, DDL/DML, dynamisk datamaskering | Innebygd RLS-redigeringsprogram |
| Få tilgang til data via snarveier | Ja | Nei |
| Kan være en kilde for snarveier | Ja (tabeller) | Nei |
| Spørring på tvers av elementer | Ja | Nei |
| Avansert analyse | Analysefunksjoner for T-SQL, data replikert til deltaparquet i OneLake for analyse | Grensesnitt for databehandling med automatisert ytelsesjustering |
| Støtte for avansert formatering | Tabellstøtte for OLTP, JSON, vektor, graf, XML, spatial, nøkkelverdi | Tabeller definert ved hjelp av PARQUET, CSV, AVRO, JSON og alle Apache Hive-kompatible filformater |
| Ventetid for inntak | Tilgjengelig umiddelbart for spørring | Tilgjengelig umiddelbart for spørring |
** Sikkerhet på kolonnenivå som er tilgjengelig på Lakehouse gjennom et SQL-analyseendepunkt ved hjelp av T-SQL.
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 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. Mesteparten av den eksisterende T-SQL-koden hun har skrevet for å bygge lageret sitt på SQL Server, fungerer på Fabric-datalageret, 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 hjelp av SQL-redigeringsprogrammet i Fabric-portalen skriver Susan og andre teammedlemmer analytiske spørringer som refererer til andre datalagre og Delta-tabeller i lakehouses ganske enkelt ved å bruke tredelte navn til å utføre spørringer på tvers av databaser.
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 er analytikere, kjent med ingen 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 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 et Eventhouse 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.
Scenario 5
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 Database Engine 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 utformer Kirby datasamlebånd med Fabric Data Factory for å importere data til Fabric SQL-databasen.