Lagre data i Microsoft Fabric

Microsoft Fabric tilbyr flere lagringsalternativer designet for å støtte analyse, sanntidsprosessering og operasjonell rapportering innenfor en samlet plattform. Å velge riktig lagringsopplevelse hjelper deg å optimalisere ytelsen, håndtere kostnader og tilpasse dataarkitekturen din til arbeidsbelastningens krav. Uavhengig av kilde eller forberedelsesmetode, lander all data i en samlet lagringsstiftelse kalt OneLake.

Denne artikkelen forklarer hvordan data lagres i Fabric og beskriver kjernelagringsopplevelsene som er tilgjengelige. Følgende avsnitt dekker:

  • OneLake – Den samlete, logiske datalakeen som ligger til grunn for alle Fabric-arbeidsbelastninger.
  • Lakehouse – Lagre og analysere strukturerte og ustrukturerte data ved bruk av Delta-tabeller.
  • Lager – Lagre relasjonsdata optimalisert for høyytelses SQL-analyse.
  • Eventhouse – Lagre og spørre i høyvolum, sanntids hendelsesdata.
  • Databaser og andre lagringsopplevelser – Forstå de ekstra lagringsmulighetene som finnes i Fabric.

Bruk denne oversikten for å forstå hvordan hvert lagringsalternativ fungerer og velge det som passer best for dine analytiske og operative scenarier.

Lakehouse for fleksibel datalagring

Et Lakehouse er et kjernelagringselement i Fabric som bruker OneLake til å lagre data både i fil- og tabellformat. En Lakehouse representerer en kuratert mappestruktur i OneLake og inkluderer et SQL-grensesnitt. Et Lakehouse lagrer data som Delta Parquet-filer. Du kan organisere råfiler som CSV-filer eller bilder i mapper, og du kan lage administrerte Delta-tabeller for strukturerte data. Denne modellen støtter både strukturerte og ustrukturerte data i samme miljø.

Fabric tilordner automatisk et SQL-analyseendepunkt for hvert Lakehouse. Du og verktøy som Power BI kan spørre Delta-tabeller ved å bruke Transact-SQL, som om du spør i en relasjonsdatabase. Lakehouse kombinerer skalerbarheten og fleksibiliteten til en datalake med kjernefunksjoner for lageret, inkludert direkte tabellspørring og skjemahåndtering.

Lager for strukturert analyse

Et lager i Fabric gir en tradisjonell SQL-datavarehusopplevelse (med tabeller, SQL-visninger, lagrede prosedyrer og mer) på Fabrics enhetlige lagring. Når du oppretter et lager, lagrer det data i OneLake i Delta-format som et organisert sett med Delta-tabeller med et ANSI SQL-grensesnitt på toppen. Warehouse tilbyr dedikert beregning og finjustert ytelse for komplekse SQL-spørringer og BI-lignende arbeidsbelastninger. Den støtter funksjoner som indeksering, lagrede prosedyrer og robuste ACID-transaksjoner på tabeller.

Lageret og Lakehouse deler samme underliggende OneLake-lagring. Du kan integrere dem ved å bruke snarveier eller andre interoperabilitetsfunksjoner når det trengs. Men du holder dem vanligvis adskilt for ulike bruksområder. The Warehouse er ideelt for strukturerte, relasjonelle stjerneskjema-data som du må dele opp med SQL. Du kan bruke Fabric-pipelines for å laste data inn i Warehouse. Power BI kan koble til ved å bruke Direct Lake eller DirectQuery for å hente data uten import.

Beslutningsguide: Lakehouse vs. Warehouse

Lagerbygninger og innsjøhus har distinkte, men komplementære roller.

  • Lagerbygninger er optimalisert for strukturert, bedriftsskala datalagring med full T-SQL-støtte, ACID-transaksjoner og sterk skjemahåndheving—ideelt for BI og rapportering. Velg et Warehouse for styrte, høyytelses SQL-arbeidsbelastninger og et Lakehouse for big data-behandling, utforskende analyser og scenarier som involverer ulike dataformater eller ekstern lake-integrasjon.

  • Lakehouses tilbyr fleksibel, skalerbar lagring for både strukturerte og ustrukturerte data, og støtter Spark-basert datautvikling og skrivebeskyttet SQL-analyse gjennom automatiske endepunkter.

Mange organisasjoner drar nytte av å bruke begge sammen: Lakehouses for inntak og transformasjon, og Warehouses for raffinert analyse og rapportering. For å lære mer, se beslutningsguiden.

Speilede databaser for nesten sanntids replikasjon

En speilet database i Fabric er en kontinuerlig replikert kopi av en ekstern operasjonell database, som Azure SQL Database, SQL Server, Azure Cosmos DB eller Snowflake. Fabric lagrer speilede data i OneLake i Delta Lake-format.

Speiling synkroniserer kildeendringer inn i Fabric nesten i sanntid uten å kreve tradisjonelle extract, transform og load-pipelines. Etter replikering blir dataene umiddelbart spørrbare via SQL-endepunkter og er tilgjengelige på tvers av Fabric-arbeidsbelastninger, inkludert Power BI, Spark-notatbøker og pipelines.

Denne arkitekturen støtter hybride transaksjons- og analytiske prosesseringsscenarier (HTAP), hvor du analyserer driftsdata samtidig som du opprettholder integriteten til kildesystemet. Hvis kildedataene allerede er lagret på et sted tilgjengelig via OneLake-snarveier (som Azure Data Lake Storage eller et annet Fabric-arbeidsområde), bør du vurdere å bruke snarveier for null-kopitilgang i stedet for speiling. Speiling egner seg best for operative databaser som krever kontinuerlig endringsdatainnsamling, mens snarveier er ideelle når du trenger direkte, skrivebeskyttet tilgang uten replikering.

OneLake-snarveier for null-kopieringsdatatilgang

OneLake-snarveier er logiske lenker som refererer til data i eksterne lagringssystemer eller i andre Fabric-arbeidsområder uten å kopiere dem. Snarveier gjør at refererte data vises som en del av det lokale OneLake-navnerommet, slik at alle Fabric-beregningsmotorer (Spark, SQL, Power BI) kan spørre snarveimål sammen med native data. Denne tilnærmingen opprettholder en enkelt versjon av sannheten og unngår duplisering av lagring.

Du kan også bruke OneLake datadeling for å utvide snarveistilgang over Microsoft Entra-leietakergrensene. Dataeiere gir OneLake-tillatelser til eksterne identiteter, og mottakerne lager snarveier til de delte dataene i sine egne arbeidsområder. Styringspolitikk håndheves fortsatt ved kilden. For mer informasjon, se OneLake-snarveier og ekstern datadeling.

Eventhouse for sanntids hendelsesanalyse

Et Eventhouse tilbyr et skalerbart sanntidsanalysemiljø designet for å ta imot, lagre og analysere store mengder hendelsesdata. Det er den grunnleggende motoren for Real-Time Intelligence-arbeidsbelastninger.

Et Eventhouse hoster en eller flere Kusto Query Language-databaser basert på Kusto-motoren. Disse databasene indekserer og partisjonerer automatisk data etter inntakstid. Du spør data ved å bruke Kusto Query Language.

Eventhouse egner seg godt for telemetri, sikkerhetslogger, samsvarsregistre og finansielle transaksjoner hvor lav-latens analyse og storskala inntak kreves.

SQL-database for transaksjonelle arbeidsbelastninger

SQL-databaser i Fabric støtter transaksjons- og operasjonelle analysearbeidsbelastninger. De tilbyr en fullstendig administrert relasjonsdatabaseopplevelse med støtte for T-SQL, inkludert datadefinisjon (DDL), manipulering (DML) og spørring (DQL). Du kan bruke lagrede prosedyrer, visninger og funksjoner for å bygge transaksjonelle og analytiske løsninger.

SQL-databaser bruker en automatisk speilingstjeneste for å replikere transaksjonstabeller inn i OneLake for analyse. Når du oppretter en SQL-database, starter Fabric en replikasjonsmotor som fanger inn innsettings-, oppdaterings- og sletteoperasjoner gjennom SQL-motorens endringsfeed og skriver disse endringene inn i OneLake som Delta Parquet-filer. Replikasjon skjer nær i sanntid og starter automatisk. Alle støttede tabeller er speilet som standard. Denne oppførselen sikrer at OneLake-kopien forblir synkronisert med den operative databasen.

SQL-databaser integreres med andre Fabric-opplevelser som Power BI, notatbøker, brukerdatafunksjoner, pipelines og eksterne verktøy gjennom TDS-protokollen. Denne integrasjonen gjør det mulig å bygge helhetlige løsninger, fra datainntak og transformasjon til visualisering og rapportering, uten å forlate Fabric-miljøet. Plattformen håndterer automatisk indeksering og ytelsesoptimalisering, så du trenger ikke manuelt å justere eller administrere infrastrukturen.

Cosmos DB for distribuerte NoSQL-arbeidsbelastninger

Cosmos DB i Microsoft Fabric er en fullt administrert, distribuert NoSQL-database designet for høyhastighets- og globalt distribuerte applikasjoner. Den støtter fleksible skjemamodeller og semistrukturerte JSON-data.

Cosmos DB speiles automatisk inn i OneLake i Delta-format for å støtte analyse uten å påvirke driftsytelsen. Replikasjon er kontinuerlig og nær sanntid og krever ingen manuell konfigurasjon.

Etter replikasjon blir data tilgjengelig via et SQL-analyseendepunkt. Du kan spørre data ved å bruke Transact-SQL, lage visninger og integrere med Power BI, notatbøker og pipelines.

SQL-analyseendepunktet gir et skrivebeskyttet grensesnitt til de speilede dataene, og sikrer at analytiske spørringer ikke forstyrrer transaksjonsoperasjoner. Denne arkitekturen støtter hybrid transaksjons- og analytisk prosessering (HTAP), slik at du kan samle operative og analytiske arbeidsbelastninger innenfor én plattform.

Semantisk modell for forretningslogikk og rapportering

Semantiske modeller gir det strukturerte, kuraterte laget som definerer forretningslogikk, målinger, hierarkier, relasjoner og metadata oppå rådata i Microsoft Fabric. De gjør data tolkbare og gjenbrukbare på tvers av plattformen for analyseopplevelser.

Semantiske modeller i Fabric er tett integrert med plattformens kapasitetsmodell og arbeidsområdestruktur. Semantiske modeller støtter tre spørringsmoduser: Import, DirectQuery og Direct Lake. Hver modus tilbyr ulike kompromisser mellom ytelse, friskhet og skalerbarhet:

  • Importmodus kopierer data fra kilden inn i den semantiske modellen under planlagte eller manuelle oppdateringer. Denne modusen gir den raskeste spørringsytelsen fordi Power BI opererer på data i minnet, men den introduserer forsinkelse mellom kildeoppdateringer og rapportvisning. Importmodus er ideell for høyytelsesdashbord hvor sanntidsdata ikke er kritisk.

  • DirectQuery-modus sender spørringer direkte til kildesystemet under kjøring uten å lagre data i den semantiske modellen. Denne tilnærmingen sikrer up-to-dato resultater, men kan føre til lavere ytelse avhengig av kildesystemets respons. DirectQuery er egnet for situasjoner der dataferskhet er viktigere enn hastighet, som for eksempel operasjonell rapportering.

  • Direct Lake-modus lar Power BI spørre Delta-tabeller lagret direkte i OneLake. Den kombinerer ytelsesegenskapene til Import med friskheten til DirectQuery. Den unngår dataduplisering og bruker lake-native arkitektur for skalerbar, nesten sanntidsanalyse. Direct Lake anbefales for storskala analyser på Fabric-administrerte data.

Semantiske modeller muliggjør også samtalebasert AI, semantisk søk, bedriftsrapportering og tverrdomene-resonnement ved å samle avanserte funksjoner som Fabric Data Agents, Power BI Copilot, ontologier og Power BI-rapporter. Forretningsbrukere kan også få tilgang til semantiske modeller via Excel, hvor de kan utforske data og innsikt i et PivotTable-grensesnitt som bruker levende data fra den semantiske modellen.

Beslutningsguide: Velg riktig datalager

Microsoft Fabric tilbyr flere alternativer for datalagring, hver optimalisert for spesifikke arbeidsbelastninger:

  • Lakehouse for storskala dataingeniørarbeid og åpen lagring som Delta og Iceberg, med støtte for Spark og SQL-motorer.
  • Lager for strukturert, relasjonsanalyse med høyytelses SQL-funksjoner og bedriftsrapportering.
  • Eventhouse for sanntids telemetri og logganalyse ved bruk av Kusto Query Language.
  • SQL-database for transaksjonsarbeidsbelastninger og operasjonell analyse.
  • Cosmos DB for globalt distribuerte NoSQL-applikasjoner, multi-modellapplikasjoner med lav-latens tilgang.
  • OneLake snarveier for null-kopitilgang til data i ekstern lagring eller andre Fabric-arbeidsområder og leietakere, når du ikke trenger en separat kopi og ønsker å opprettholde én enkelt versjon av Truth.

Valg av riktig lager avhenger av datastruktur, forsinkelseskrav, spørringskompleksitet og integrasjonsbehov. Når dataene du trenger allerede finnes på et tilgjengelig sted, kan snarveier eliminere behovet for replikering helt. For mer veiledning, se Valg av riktig butikk.

Relatert innhold

  • Last updated on