Microsoft OneLake-mønstre og grunnleggende kapasiteter

Denne artikkelen introduserer vanlige OneLake-mønstre og plattformfunksjonene du kan bruke for å implementere dem. Bruk informasjonen i denne artikkelen til å tenke gjennom hvordan du ønsker å organisere datamiljøet ditt, og velg deretter mønstrene som passer dine forretnings-, tekniske og styringsbehov.

Hvert mønster beskriver hvordan man organiserer data og eierskap for å oppnå et spesifikt arkitektonisk mål. For å implementere et mønster kombinerer du en eller flere grunnleggende OneLake-funksjoner – datavirtualisering, åpen datainteroperabilitet, sentralisert styring og integrert analyse og AI. Hver funksjon baserer seg på spesifikke produktfunksjoner som snarveier, speiling, OneLake-sikkerhet og Direct Lake-modus. Den samme funksjonaliteten og funksjonen forekommer ofte i mer enn ett mønster.

Notat

Denne artikkelen er basert på mønstre identifisert i OneLake arkitekturveiledningswhitepaper.

Se på disse fem mønstrene som byggeklosser for ditt OneLake-design. De fleste miljøer kombinerer mer enn ett. Velg mønstrene som matcher målene dine:

Enhetlig datatilgang med minimal replikering

Hvis dataene dine er spredt over flere skyer, lokale systemer eller eksterne innsjøer, kan det hende det ikke er praktisk – eller engang mulig – å kopiere alt på ett sted. Det enhetlige datatilgangsmønsteret med minimal replikasjon behandler OneLake som et enkelt logisk datalag på tvers av disse kildene. I stedet for å bygge innleveringspipelines for hver kilde, bruker du snarveier for å referere data på stedet og speiling når du trenger en synkronisert, spørringsoptimalisert kopi.

Bruk dette mønsteret når:

  • Dataene dine er spredt over flere skyer, lokale systemer eller eksterne innsjøer.
  • Å replikere data til en sentral lagring vil skape overdreven lagrings-, latens- eller compliance-overhead.
  • Du må onboarde nye kilder raskt uten å lage fullstendige extract, transform, load (ETL) pipelines.
  • Du ønsker å bevare investeringer i eksisterende datalakes, lagre og operative lagre.

Bruk enhetlig datatilgang

For å sette dette mønsteret ut i praksis, start med to primære tilnærminger til datatilgang som ikke krever at du bygger eller opererer databevegelsesprosesser: virtualisering gjør kildedata tilgjengelig via OneLake uten å kopiere dem, og zero-ETL-speiling bringer en plattformstyrt, synkronisert kopi inn i OneLake som analyseklare Delta-tabeller. Bruk kun Fabric-databevegelsesverktøy når disse tilnærmingene ikke støtter kilden eller oppfyller kravene dine. For ytterligere veiledning om valg og kombinasjon av disse tilnærmingene, se Unify data with OneLake snarveier og speiling.

  1. Inventar datakildene dine for å finne ut hvilke OneLake kan få tilgang til via virtualisering eller zero-ETL-speiling: skybasert objektlagring, eksterne kataloger, driftsdatabaser og Dataverse. Merk eventuelle gjenværende kilder som trenger en databevegelsesmetode.

  2. Velg riktig datatilgang for hver støttet kilde. Foretrekk virtualisering når kildekoden støtter no-copy tilgang. Bruk zero-ETL-speiling når kilden krever en synkronisert, spørringsoptimalisert kopi:

Kildedata Hvordan få tilgang til den Databehandling
Skyobjektlagring (Azure Data Lake Storage Gen2, Amazon S3, Google Cloud Storage) og S3-kompatibel lokal lagring Snarveier Virtualisering: Gjør kildedata tilgjengelig uten å kopiere dem
Data som administreres i en ekstern katalog som du ønsker å gjøre tilgjengelig uten å kopiere (for eksempel Azure Databricks Unity Catalog) Metadataspeiling – synkroniserer kun katalogmetadata (skjemaer, tabeller) og får tilgang til kildedataene via snarveier Virtualisering: Gjør kildedata tilgjengelig uten å kopiere dem
Operasjonelle databaser som trenger en spørringsoptimalisert kopi (Azure SQL Database, Azure Cosmos DB, Snowflake, PostgreSQL, SQL Server 2025, Oracle Database, Google BigQuery) Databasespeiling, eller åpen speiling for støttede, tilpassede og partnerløsninger Zero-ETL speiling: Oppretter en synkronisert Delta-kopi
Dataverse (Dynamics 365 og Power Platform-data) Snarveier eller lenke til Microsoft Fabric for null-kopitilgang Virtualisering: Gjør kildedata tilgjengelig uten å kopiere dem

  1. Transformer kildedata når det trengs. Snarveitransformasjoner kan behandle støttede filer som eksponeres gjennom en snarvei, enten filene lagres eksternt eller allerede er i OneLake. Bruk snarveisfiltransformasjoner for å konvertere strukturerte filer til Delta-tabeller, eller snarveier AI-transformasjoner for å behandle ustrukturert tekst. Snarveistransformasjoner skaper transformert Delta-utgang og holder den synkronisert med dataene som snarveien refererer til.

  2. Bruk Fabric-databevegelsesverktøy når virtualisering og speiling ikke støtter en kilde, eller når du trenger komplekse transformasjoner, orkestrering, en planlagt bevegelsesrytme eller streaming-inntak. For hjelp til å velge mellom pipelines, dataflyter, kopijobber og hendelsesstrømmer, se Velg en databevegelsesstrategi.

Når du velger databevegelse, kopierer du data på land i et åpent tabellformat, som Delta Parquet eller Iceberg. Speiling og snarveistransformasjoner skaper allerede Delta-utdata. Bruk av åpne formater holder virtualiserte data, synkroniserte kopier og transformert Delta-utdata lesbare av Fabric-motorer og eksterne plattformer.

  1. Registrer årsaken hver gang du lager en synkronisert kopi, transformert Delta-utgang, eller en kopi gjennom Fabric-databevegelsesverktøy. Denne registreringen gjør avgjørelsen reviderbar. Lag en kopi kun når en kilde trenger et fysisk, spørringsoptimalisert oppsett eller ikke kan møte kravene til ferskhet, transformasjonskostnader, etterlevelse eller prosessering virtuelt.

  2. Bruk OneLake-sikkerhet på dataene som gjøres tilgjengelige gjennom OneLake slik at de samme policyene dekker virtualiserte data, synkroniserte kopier og transformert Delta-utgang.

  3. Godkjenn og beskriv de resulterende dataelementene i OneLake-katalogen slik at forbrukerne kan finne og stole på dem.

Enhetlige dataaksessmuligheter

  • Datavirtualisering og zero-ETL-speiling – Eksponer data som ligger i andre systemer og skyer gjennom no-copy referanser eller synkroniserte, analyseklare kopier. Funksjoner:
  • Sentralisert styring – Bruk konsekvent sikkerhet og oppdagelse på virtualiserte kilder akkurat som du ville gjort på native OneLake-data. Funksjoner:
  • Åpen datainteroperabilitet – Hold virtualiserte data og plattformstyrte kopier lesbare både av Fabric-motorer og eksterne plattformer. Funksjoner:

Medaljongarkitektur (bronse, sølv, gull)

Å gjøre data tilgjengelig i OneLake er bare det første steget. Rådata fra kildesystemer er vanligvis ikke trygt å bruke direkte til analyse eller AI. Den inneholder ofte duplikater, feil, inkonsistente formater eller sensitive felt. Når flere team bygger på samme kildedata, trenger de en felles definisjon av hva hvert datatrinn er betrodd for.

Medaljongarkitekturmønsteret organiserer data i OneLake i tre kvalitetslag: bronse for rå, uforanderlig kildedata; sølv for rensede og konforme data; og gull for sertifiserte, forretningsklare tabeller og semantiske modeller. Hvert lag er et definert trinn som nedstrøms forbrukere kan stole på. Sølv- og gulltabeller kan gjenbrukes på tvers av BI-, analyse- og AI-arbeidsbelastninger, så team bygger ikke opp samme rensings- eller modelleringslogikk i separate verktøy.

Bruk dette mønsteret når:

  • Flere team bygger på samme kildedata og trenger jevn kvalitet.
  • Du trenger sporbar opprinnelse fra rå input til sertifiserte output.
  • Du trenger en tydelig kontrakt mellom data engineering og analyse- eller AI-forbrukere.

For mer informasjon om dette mønsteret, se Forstå medaljongarkitektur for Fabric med OneLake. Den artikkelen dekker lagdesign, distribusjonsmodeller, lagringsformater, materialiserte innsjøvisninger og optimalisering av Delta-tabeller.

Hvordan bruke det

En fungerende medaljong hviler på én idé: hvert lag er en kontrakt med nedstrøms forbrukere, og data går bare videre til neste lag etter at det oppfyller det lagets kvalitetsstandarder.

  1. Identifiser dine rå kilder og forbrukerne som er avhengige av sertifiserte data.

  2. Definer hva som hører hjemme i hvert lag, og bruk disse definisjonene konsekvent på tvers av domener:

    Lag Innhold Typiske forbrukere
    Bronse Rå, uforanderlig data hentet direkte fra kilder uten skjemahåndhevelse Dataingeniører (begrenset tilgang)
    Sølv Renset, deduplisert og tilpasset felles forretningsdefinisjoner Dataingeniører og utdannede analytikere
    Gull Kuraterte, forretningsklare tabeller og semantiske modeller Alle BI-, analyse- og AI-forbrukere

  3. Produser hvert lag med riktig Fabric-arbeidsbelastning – vanligvis Data Engineering (Spark) eller Data Factory for bronse og sølv, og datalager eller Power BI semantiske modeller for gull. Bevar kildenøyaktigheten i bronse ved å bruke originalformatet, en snarvei til kildedata, Parquet eller Delta etter behov. Bruk Delta-tabeller for sølv og gull slik at Fabric-arbeidsbelastninger pålitelig kan lese og skrive de raffinerte dataene.

  4. Bruk lagbevisste tilgangspolicyer. Bruk OneLake-sikkerhet for støttede elementer og de gjeldende Fabric- og SQL-tillatelsene for lagre. Begrens tilgangen til bronse, gjør sølv tilgjengelig for analytikere, og gi tilgang til gull basert på forbrukernes behov og minimumskrav.

  5. Bruk kuraterte gullresultater for nedstrøms analyse. Bygg gulllags semantiske modeller i Direct Lake-modus slik at Power BI kan lese OneLake-data uten å lage en importert kopi eller kreve planlagte oppdateringer.

  6. Bekreft at hver gullproduksjon har sporbar avstamning gjennom sølv til bronsekildene. Deretter anbefaler du gulllagstabeller og semantiske modeller som sertifisert i OneLake-katalogen. Denne valideringen hjelper forbrukerne med å identifisere hvilke data som er klare for produksjonsbruk.

  7. Gjenbruk gull-semantiske modeller for å kickstarte Fabric IQ-ontologier. Dette steget gir AI-agenter styrt forretningskontekst basert på sertifiserte data.

Grunnleggende kapabiliteter

  • Integrert analyse og AI – bronse-, sølv- og gulllag mater alle analyse- og AI-arbeidsbelastninger på OneLake uten motorspesifikke kopier. Funksjoner:
  • Sentralisert styring – Bruk ulike tilgangspolicyer og kvalitetsporter på hvert lag slik at forbrukerne kun ser data som passer til deres rolle. Funksjoner:
  • Åpen datainteroperabilitet – Lagre lagene i åpne formater slik at eksterne motorer kan lese dem sammen med Fabric. Funksjoner:

Domeneorientert datamesh på en delt plattform

Hvis du har flere forretningsteam som produserer og konsumerer data, kan det å rute hver forespørsel gjennom et enkelt sentralt datateam forsinke leveringen. Forretningsteam forstår ofte sine egne data og krav best, men desentralisering av eierskap uten delt styring kan føre til inkonsekvent sikkerhet, kvalitet og bakgrunn.

Det domeneorienterte datamesh-mønsteret gir hvert forretningsdomene eierskap til sine egne dataprodukter, mens alle domener følger felles standarder basert på OneLake. Hvert domene publiserer sine egne dataprodukter, og andre domener får tilgang til dem via snarveier og bruker dem med Fabric-analyser og AI-arbeidsbelastninger. Sentraliserte identitets-, sikkerhets- og styringspolicyer gjelder ensartet på tvers av alle domener.

Bruk dette mønsteret når:

  • Et enkelt sentralt datateam blir en flaskehals for levering.
  • Ulike forretningsområder har distinkte data, krav og utgivelsesrytmer.
  • Du trenger tydelig ansvarlighet for datakvalitet på domenenivå uten å gi opp selskapsomfattende styring.

Bruk et domeneorientert datamesh

Finn den rette balansen mellom desentralisering og konsistens. Flytt eierskapet til det domenet som kjenner dataene best, og hold identitet, sikkerhet og avstamning sentralisert slik at alle domenets dataprodukter oppfyller de samme standardene.

  1. Identifiser forretningsdomenene dine. Hvert domene bør representere et sammenhengende område av virksomheten med et team som kan eie og drive dataproduktene fra ende til ende.

  2. Opprett et domene for hvert forretningsområde og tildel arbeidsområder til det. Sett opp et eget sentralt domene for delt infrastruktur og gjenbrukbare bedriftsdata.

  3. Definer dataproduktstandarder som hvert domene må oppfylle – for eksempel krav til godkjenning eller sertifisering, dokumenterte skjemaer, eierskapsmetadata, versjonering og servicenivåavtaler (SLA). Disse standardene gjør hvert produkt til en gjenbrukbar, oppdagbar kontrakt i stedet for bare en arbeidsplassmappe.

  4. Bruk OneLake-sikkerhet for å anvende rollebaserte dataadgangskontroller på mappe-, tabell-, rad- og kolonnenivå, slik at produsenter kan publisere dataprodukter uten å eksponere alt i arbeidsområdet sitt.

  5. Bruk leietakeromfattende styring med OneLake-katalogen for tverrdomene-oppdagelse og opprinnelse, og Microsoft Purview for sensitivitetsetiketter og revisjon. Utvid samme identitet og policymodell til AI-agenter som konsumerer domenedataprodukter, slik at agenttilgangen styres som enhver annen forbruker.

  6. La forbrukerdomener bruke snarveier for å referere til produsentdataprodukter i stedet for å kopiere dem. Forbrukere kan deretter bruke de refererte dataproduktene i Fabric-arbeidsmengden som passer deres behov. For Power BI semantiske modeller, bruk Direct Lake-modus for å lese data direkte fra OneLake. Bruk Fabric Data Agents eller Fabric IQ for å skape AI-opplevelser basert på styrte domenedataprodukter.

  7. Hvis domener publiserer til kataloger utenfor Fabric, planlegg for synkronisering av tilgangskontroll slik at tillatelsene forblir konsistente mellom OneLake og den eksterne katalogen.

    Tips

    Microsoft sin åpne kildekode-akselerator Policy Weaver kan automatisere denne synkroniseringen for Azure Databricks (Unity Catalog), Snowflake og Dataverse-kilder. Den speiler datatilgangspolicyer inn i OneLake-sikkerhetsroller, som et supplement til speiling (som flytter data, men ikke tillatelser).

Datamesh-egenskaper

  • Sentralisert styring – Desentraliser eierskapet til domener samtidig som identitet, sikkerhet og avstamning holdes sentralisert. Funksjoner:
  • Datavirtualisering – La forbrukerdomener bruke produsenteide dataprodukter gjennom referanser i stedet for kopier. Funksjoner:
    • Snarveier muliggjør null-kopideling mellom domener.
  • Integrert analyse og AI – Gjør alle domenes dataprodukter forbrukbare på tvers av Fabric-arbeidsbelastninger. Funksjoner:

Plattformkonsolidering for analyse og AI

Hvis du kjører flere analyseplattformer side om side – separate verktøy for datavarehus, forretningsintelligens, data science, sanntidsanalyse og AI – kommer hvert verktøy med sine egne datakopier, pipelines og styringsmodell. Denne fragmenteringen øker kostnadene og gjør det vanskelig å anvende konsekvent sikkerhet eller få ett svar på et forretningsspørsmål.

Plattformkonsolideringsmønsteret bringer disse arbeidsbelastningene over på Fabric, hvor OneLake tilbyr et delt, styrt datafundament. Fabric-arbeidsbelastninger får tilgang til, transformerer, synkroniserer eller analyserer data gjennom dette fundamentet i stedet for å stole på separate data- og styringsmodeller for hvert verktøy.

Bruk dette mønsteret når:

  • Du bruker flere analyseplattformer med overlappende muligheter.
  • Motorspesifikke datakopier og pipelines driver kostnader og vedlikeholdskostnader.
  • Du trenger en felles styrings- og sikkerhetsmodell på tvers av alle analyse- og AI-arbeidsbelastninger.

Anvendelse plattformkonsolidering

Sikt på færre plattformer, ikke flere integrasjoner. Konsolider arbeidsmengder i Fabric i stedet for å bygge bro mellom verktøy, og bro eksterne motorer bare når du ikke kan pensjonere dem ennå.

  1. Ta oversikt over analyseverktøyene, datavarehuset, data science, business intelligence (BI) og AI-verktøyene og pipelinene du bruker i dag. Noter hvilke arbeidsbelastninger hvert verktøy betjener og hvilke data det kopierer.

  2. Koble hver eksisterende arbeidsbelastning til Fabric-arbeidsmengden som kan erstatte den:

    Eldre arbeidsmengde Fabric workload
    Dataorkestrering og ETL Data fabrikk
    Spark-notatbøker og lakehouse-prosessering Dataingeniør ing
    SQL datavarehus Datavarehus
    Strømming og KQL-analyse Real-Time
    ML-modelltrening og eksperimentsporing Datavitenskap
    Operative databaser Databaser (SQL-database i Fabric og Cosmos DB i Fabric)
    BI-visualisering og semantiske modeller Power BI med Direct Lake-modus
    Konversasjonsbasert AI basert på bedriftsdata Fabric Data Agents, Copilot for Fabric, Fabric IQ

  3. Etabler én styrings- og sikkerhetsmodell på tvers av alle arbeidsbelastninger ved bruk av OneLake-sikkerhet, Microsoft Purview og OneLake-katalogen. Konfigurer kundestyrte nøkler når støttede Fabric-elementer krever et ekstra lag med kryptering.

  4. Konsolider analytiske data i OneLake ved å bruke Delta- eller Iceberg-formatet slik at arbeidsmengder kan dele et styrt datafundament. Inkluder operasjonelle arbeidsbelastninger ved å konsolidere dem på Fabric Databases, som gjør synkroniserte analytiske data tilgjengelige i OneLake.

  5. Bakke-AI på de konsoliderte dataene. Bygg ontologier (forhåndsvisning) over ditt kuraterte datalag og eksponer dem for agenter via Ontology MCP-serveren, slik at Fabric Data Agents, Microsoft 365 Copilot og eksterne verktøy resonnerer over samme styrte kontekst. Du kan generere ontologidefinisjoner fra Power BI semantiske modeller i Import-, Direct Lake- eller DirectQuery-modus. Bruk Direct Lake-modus når du trenger genererte bindings til støttede OneLake-data, og gjennomgå de nåværende ontologibegrensningene.

  6. For eksterne motorer du ikke kan pensjonere ennå, eksponer OneLake-data for dem gjennom Azure Databricks-integrasjon, Iceberg-interoperabilitet med Snowflake, eller OneLake-tilgang og API-er.

  7. Pensjoner de erstattede verktøyene, datakopier og pipelines etter at du har validert Fabric-ekvivalenten. På den måten fjerner konsolideringen kostnader, lisenser og overleveringer i stedet for å legge til en ny plattform i bunken.

Plattformkonsolideringsmuligheter

Ekstern datadeling på tvers av organisasjoner

Hvis du utveksler data med partnere, leverandører, kunder eller andre avdelinger på løpende basis, legger batch-eksport, filoverføringer og dupliserte nedstrømssystemer til forsinkelse, kostnader og styringsgap. Det eksterne datadelingsmønsteret gir forbrukere utenfor din organisasjon eller forretningsavdeling direkte tilgang til kuraterte OneLake-data uten gjentakende eksport. Forbrukere kan få tilgang til dataene via Fabric cross-tenant sharing eller fra eksterne analyseplattformer som Snowflake og Azure Databricks ved å bruke OneLakes interoperabilitetsmuligheter.

Forbrukere ser oppdateringer etter hvert som du publiserer dem. Du kontrollerer tilgangen til kildedataene gjennom delings- eller interoperabilitetsmekanismen som støtter forbrukerens plattform.

Bruk dette mønsteret når:

  • Du utveksler data med eksterne organisasjoner på løpende basis.
  • Batch-eksport eller filoverføringer gir forsinkelse, kompleksitet eller styringsgap.
  • Du må spore og tilbakekalle ekstern tilgang sentralt.

Bruk ekstern datadeling

Ekstern deling fungerer best når du bruker virtualisering i stedet for å eksportere data. Match tilgangsmetoden til det hver forbruker kan lese, og bruk tilgangskontrollene som støttes av den delings- eller interoperabilitetsmekanismen.

  1. Identifiser dataproduktene du ønsker å dele eksternt og hvilke forbrukere som trenger dem (partnere, leverandører, kunder). Vanligvis deler du kuraterte tabeller og filer som er godt definerte og dokumenterte.

  2. Velg riktig delingsmetode for hver forbruker:

    Forbrukertype Anbefalt tilnærming
    Fabric-brukere i en annen tenant Ekstern datadeling for skrivebeskyttet, virtualisert kryss-leietaker-tilgang
    Snowflake on Azure users Interoperabilitet mellom isfjell og Snowflake for å lese Fabric-tabeller eksponert i isfjellformat
    Azure Databricks users OneLake-katalogføderasjon i Azure Databricks for å spørre OneLake-tabeller gjennom Unity Catalog uten å kopiere data
    Applikasjoner eller verktøy som støtter ADLS Gen2 eller Blob API-er OneLake-tilgang og API-er for å få tilgang til OneLake-data via støttede API-er

    For å hente Dataverse-data inn i OneLake før deling, bruk det enhetlige datatilgangsmønsteret.

  3. Scope ekstern tilgang med tillatelsene støttet av den valgte delingsmekanismen. For ekstern datadeling i Fabric gir delingen skrivebeskyttet tilgang til enhver bruker i den inviterte brukerens hjemmeleietaker. Sikkerhets- og styringspolicyer på leverandørsiden, inkludert OneLake-sikkerhet, sensitivitetsetiketter og retningslinjer for forebygging av datatap, håndheves ikke i forbrukerens leietaker. Forbrukeren må styre nedstrøms tilgang i sitt miljø.

  4. Bli enige om vilkårene for hvert delingsforhold på forhånd – hva som deles, med hvem, og hvor lenge. For Fabric ekstern datadeling, tilbakekall tilgang fra fanen Eksterne datadelinger på siden Administrer tillatelser. For andre tilnærminger, tilbakekall tilgangen gjennom den valgte delingsmekanismen. Bekreft at forbrukeren mister sikten.

  5. Bruk sensitivitetsetiketter, revisjon og forebygging av datatap med Microsoft Purview i leverandørens Fabric-miljø.

  6. Godkjenn og dokumenter kildedataene i OneLake-katalogen slik at leverandører kan finne og styre dem før de deles. OneLake-katalogen publiserer ikke dataprodukter til eksterne leietakere eller analyseplattformer.

Eksterne datadelingsmuligheter

  • Datavirtualisering – Del data gjennom no-copy referanser uten å administrere eksportpipelines. Funksjoner:
    • Ekstern datadeling gir virtualisert deling mellom Fabric-leietakere.
    • Snarveier lar partnere konsumere publiserte data uten å kopiere dem.
  • Åpen datainteroperabilitet – Del med forbrukere som ikke bruker Fabric ved å publisere i åpne formater. Funksjoner:
  • Sentralisert styring – Styr kildedata i Fabric og kontroller ekstern tilgang gjennom hver delingsmekanisme. Funksjoner:
    • OneLake-sikkerheten begrenser tilgangen til kildedata i Fabric.
    • Microsoft Purview anvender sensitivitetsetiketter, revisjon og forebygging av datatap i leverandørens Fabric-miljø.
    • OneLake-katalogen støtter leverandørbasert oppdagelse og godkjenning før deling.
  • Last updated on