Microsoft OneLake-mønstre og grundlæggende kapaciteter

Denne artikel introducerer almindelige OneLake-mønstre og de platformfunktioner, du kan bruge til at implementere dem. Brug informationen i denne artikel til at tænke over, hvordan du ønsker at organisere dit datamiljø, og vælg derefter de mønstre, der passer til dine forretnings-, tekniske og governance-behov.

Hvert mønster beskriver, hvordan man organiserer data og ejerskab for at opnå et specifikt arkitektonisk mål. For at implementere et mønster kombinerer du en eller flere grundlæggende OneLake-funktioner – datavirtualisering, åben datainteroperabilitet, centraliseret styring samt integreret analyse og AI. Hver funktion afhænger igen af specifikke produktfunktioner som genveje, spejling, OneLake-sikkerhed og Direct Lake-tilstand. Den samme funktion og funktion optræder ofte i mere end ét mønster.

Bemærkning

Denne artikel er baseret på mønstre, der er identificeret i OneLake arkitekturvejledningswhitepaperet.

Overvej disse fem mønstre som byggesten til dit OneLake-design. De fleste miljøer kombinerer mere end ét. Vælg de mønstre, der matcher dine mål:

Samlet dataadgang med minimal replikering

Hvis dine data er spredt over flere clouds, lokale systemer eller eksterne søer, kan det være upraktisk – eller endda muligt – at kopiere det hele ét sted. Det samlede dataadgangsmønster med minimal replikation behandler OneLake som et enkelt logisk datalag på tværs af disse kilder. I stedet for at bygge ingest-pipelines for hver kilde, bruger du genveje til at referere data på stedet og spejle, når du har brug for en synkroniseret, forespørgselsoptimeret kopi.

Brug dette mønster, når:

  • Dine data er spredt over flere skyer, on-premises systemer eller eksterne søer.
  • At replikere data til en central butik ville skabe overdreven lagerplads, latenstid eller compliance-overhead.
  • Du skal hurtigt onboarde nye kilder uden at oprette fulde extract, transform, load (ETL) pipelines.
  • Du vil bevare investeringer i eksisterende datalakes, lagre og operationelle lagre.

Anvend samlet dataadgang

For at sætte dette mønster i praksis, start med to primære tilgange til dataadgang, der ikke kræver, at du bygger eller driver dataflytningsprocesser: virtualisering gør kildedata tilgængelige via OneLake uden at kopiere dem, og zero-ETL-spejling bringer en platformstyret, synkroniseret kopi ind i OneLake som analyseklare Delta-tabeller. Brug kun Fabric-databevægelsesværktøjer, når disse tilgange ikke understøtter kilden eller opfylder dine krav. For yderligere vejledning i valg og kombination af disse tilgange, se Unify data with OneLake shortcuts and mirroring.

  1. Registrer dine datakilder for at afgøre, hvilke OneLake kan få adgang til via virtualisering eller zero-ETL-spejling: cloud-objektlagring, eksterne kataloger, driftsdatabaser og Dataverse. Marker eventuelle resterende kilder som nødvendige, når de har brug for en databevægelsesmetode.

  2. Vælg den rette dataadgangsteknik for hver understøttet kilde. Foretræk virtualisering, når kildekoden understøtter adgang uden kopi. Brug zero-ETL-spejling, når kilden kræver en synkroniseret, forespørgselsoptimeret kopi:

Kildedata Sådan får du adgang til den Datahåndtering
Cloud objektlagring (Azure Data Lake Storage Gen2, Amazon S3, Google Cloud Storage) og S3-kompatibel on-premises lagring Genveje Virtualisering: Gør kildedata tilgængelige uden at kopiere dem
Data administreret i et eksternt katalog, som du ønsker at gøre tilgængeligt uden at kopiere (for eksempel Azure Databricks Unity Catalog) Metadataspejling - synkroniserer kun katalogmetadata (skemaer, tabeller) og tilgår kildedataene via genveje Virtualisering: Gør kildedata tilgængelige uden at kopiere dem
Operationelle databaser, der kræver en forespørgselsoptimeret kopi (Azure SQL Database, Azure Cosmos DB, Snowflake, PostgreSQL, SQL Server 2025, Oracle Database, Google BigQuery) Databasespejling eller åben spejling for understøttede tilpassede og partnerløsninger Zero-ETL spejling: Opretter en synkroniseret Delta-kopi
Dataverse (Dynamics 365 og Power Platform data) Genveje eller link til Microsoft Fabric for nul-kopiadgang Virtualisering: Gør kildedata tilgængelige uden at kopiere dem

  1. Transformér kildedata, når det er nødvendigt. Genvejstransformationer kan behandle understøttede filer, der er eksponeret via en genvej, uanset om filerne er gemt eksternt eller allerede i OneLake. Brug genvejsfiltransformationer til at konvertere strukturerede filer til Delta-tabeller eller genvejs-AI-transformationer til at behandle ustruktureret tekst. Genvejstransformationer skaber transformeret Delta-output og holder det synkroniseret med de data, der refereres til i genvejen.

  2. Brug Fabric-databevægelsesværktøjer, når virtualisering og mirroring ikke understøtter en kilde, eller når du har brug for komplekse transformationer, orkestrering, en planlagt bevægelsesrytme eller streaming-indtagning. For hjælp til at vælge mellem pipelines, dataflows, copy jobs og eventstreams, se Vælg en databevægelsesstrategi.

Når du vælger databevægelse, så landkopierede data i et åbent tabelformat, såsom Delta Parquet eller Iceberg. Spejling og genvejstransformationer skaber allerede Delta-output. Brug af åbne formater holder virtualiserede data, synkroniserede kopier og transformeret Delta-output læsbare af Fabric-motorer og eksterne platforme.

  1. Registrer årsagen, hver gang du opretter en synkroniseret kopi, transformeret Delta-output eller en kopi via Fabric databevægelsesværktøjer. Denne registrering gør beslutningen reviderbar. Lav kun en kopi, når en kilde har brug for et fysisk, forespørgselsoptimeret layout eller ikke kan opfylde dine krav til aktualisering, transformationsomkostninger, overholdelse eller behandling virtuelt.

  2. Anvend OneLake-sikkerhed på de data, der gøres tilgængelige gennem OneLake, så de samme politikker dækker virtualiserede data, synkroniserede kopier og transformeret Delta-output.

  3. Godkend og beskriv de resulterende dataelementer i OneLake-kataloget , så forbrugerne kan finde og stole på dem.

Unified dataadgangsfunktioner

  • Datavirtualisering og zero-ETL-spejling - Eksponer data, der findes i andre systemer og skyer, gennem no-copy referencer eller synkroniserede, analyseklare kopier. Funktioner:
  • Centraliseret styring – Anvend konsekvent sikkerhed og opdagelse på virtualiserede kilder, ligesom du ville på native OneLake-data. Funktioner:
  • Åben datainteroperabilitet - Hold virtualiserede data og platformstyrede kopier læsbare for både Fabric-motorer og eksterne platforme. Funktioner:

Medaljonarkitektur (bronze, sølv, guld)

At gøre data tilgængelige i OneLake er kun det første skridt. Rådata fra kildesystemer er som regel ikke sikre at bruge direkte til analyse eller AI. Den indeholder ofte dubletter, fejl, inkonsistente formater eller følsomme felter. Når flere teams bygger på samme kildedata, har de brug for en fælles definition af, hvad hvert datatrin er betroet til.

Medaljonarkitekturmønsteret organiserer data i OneLake i tre kvalitetslag: bronze for rå, uforanderlige kildedata; sølv til rensede og konformede data; og guld for certificerede, forretningsklare tabeller og semantiske modeller. Hvert lag er et defineret trin, som downstream-forbrugere kan stole på. Sølv- og guldtabeller kan genbruges på tværs af BI-, analyse- og AI-arbejdsbelastninger, så teams genopbygger ikke den samme rensnings- eller modelleringslogik i separate værktøjer.

Brug dette mønster, når:

  • Flere teams bygger på samme kildedata og har brug for ensartet kvalitet.
  • Du har brug for sporbar oprindelse fra rå input til certificerede output.
  • Du har brug for en klar kontrakt mellem data engineering og analytics- eller AI-forbrugere.

For mere information om dette mønster, se Forstå medaljonarkitektur for Fabric med OneLake. Den artikel dækker lagdesign, udrulningsmodeller, lagringsformater, materialiserede sø-visninger og optimering af delta-tabel.

Sådan anvender du det

En fungerende medaljon afhænger af én idé: hvert lag er en kontrakt med nedstrøms forbrugere, og data går kun videre til det næste lag, når det opfylder lagens kvalitetsstandarder.

  1. Identificer dine rå kilder og de forbrugere, der er afhængige af certificerede data.

  2. Definer, hvad der hører til i hvert lag, og anvend disse definitioner konsekvent på tværs af domæner:

    Lag Indhold Typiske forbrugere
    Bronze Rå, uforanderlig data indsamlet direkte fra kilder uden nogen skema-håndhævelse Dataingeniører (begrænset adgang)
    Sølv Renset, deduplikeret og tilpasset fælles forretningsdefinitioner Dataingeniører og uddannede analytikere
    Guld Kuraterede, forretningsklare tabeller og semantiske modeller Alle BI-, analyse- og AI-forbrugere

  3. Producer hvert lag med den rette Fabric-arbejdsbyrde – typisk Data Engineering (Spark) eller Data Factory for bronze og sølv, og data warehouse eller Power BI semantiske modeller for guld. Bevar kildenøjagtigheden i bronze ved at bruge det oprindelige format, en genvej til kildedata, Parquet eller Delta efter behov. Brug Delta-tabeller til sølv og guld, så Fabric-arbejdsbelastninger pålideligt kan læse og skrive de raffinerede data.

  4. Anvend lagbevidste adgangspolitikker. Brug OneLake-sikkerhed til understøttede elementer samt de gældende Fabric- og SQL-tilladelser for warehouses. Begræns adgangen til bronze, gør sølv tilgængeligt for analytikere og giv adgang til guld baseret på forbrugernes behov og minimumskrav.

  5. Brug kuraterede guldresultater til downstream-analyser. Byg guldlags semantiske modeller i Direct Lake-tilstand, så Power BI kan læse OneLake-data uden at oprette en importeret kopi eller kræve planlagte opdateringer.

  6. Bekræft, at alle guldudvindinger har sporbar afstamning gennem sølv til dens bronzekilder. Derefter kan du godkende guldlagstabeller og semantiske modeller som certificeret i OneLake-kataloget. Denne validering hjælper forbrugerne med at identificere, hvilke data der er klar til produktionsbrug.

  7. Genbrug guld-semantiske modeller til at kickstarte Fabric IQ-ontologier. Dette trin giver AI-agenter styret forretningskontekst baseret på certificerede data.

Grundlæggende kapaciteter

  • Integreret analyse og AI – Bronze-, sølv- og guldlag leverer alle analyse- og AI-arbejdsbelastninger på OneLake uden motorspecifikke kopier. Funktioner:
  • Centraliseret styring - Anvend forskellige adgangspolitikker og kvalitetsporte på hvert lag, så forbrugerne kun ser data, der passer til deres rolle. Funktioner:
  • Åben data-interoperabilitet - Gem lagene i åbne formater, så eksterne motorer kan læse dem sammen med Fabric. Funktioner:

Domæneorienteret datamesh på en delt platform

Hvis du har flere forretningsteams, der producerer og forbruger data, kan det at dirigere hver anmodning gennem et enkelt centralt datateam forsinke leveringen. Forretningsteams forstår ofte deres egne data og krav bedst, men decentralisering af ejerskab uden delt styring kan føre til inkonsekvent sikkerhed, kvalitet og oprindelse.

Det domæneorienterede datamesh-mønster giver hvert forretningsdomæne ejerskab af sine egne dataprodukter, mens alle domæner følger fælles standarder på et OneLake-fundament. Hvert domæne offentliggør sine egne dataprodukter, og andre domæner får adgang til dem via genveje og forbruger dem med Fabric-analyser og AI-arbejdsbelastninger. Centraliserede identitets-, sikkerheds- og styringspolitikker gælder ensartet på tværs af alle domæner.

Brug dette mønster, når:

  • Et enkelt centralt datateam bliver en flaskehals for levering.
  • Forskellige forretningsområder har forskellige data, krav og frigivelsesrytmer.
  • Du har brug for klar ansvarlighed for datakvalitet på domæneniveau uden at opgive virksomhedsomfattende styring.

Anvend et domæneorienteret datamesh

Find den rette balance mellem decentralisering og konsistens. Skub ejerskabet til det domæne, der kender dataene bedst, og hold identitet, sikkerhed og oprindelse centraliseret, så alle domænets dataprodukter opfylder de samme standarder.

  1. Identificer dine forretningsområder. Hvert domæne bør repræsentere et sammenhængende område af virksomheden med et team, der kan eje og drive dataprodukterne fra ende til ende.

  2. Opret et domæne for hvert forretningsområde og tildel arbejdsområder til det. Opret et separat centralt domæne for delt infrastruktur og genanvendelige virksomhedsdata.

  3. Definer dataproduktstandarder, som hvert domæne skal opfylde – for eksempel krav til godkendelse eller certificering, dokumenterede skemaer, ejerskabsmetadata, versionsstyring og service-level agreements (SLA'er). Disse standarder gør hvert produkt til en genanvendelig og opfindbar kontrakt i stedet for blot en arbejdsområdemappe.

  4. Brug OneLake-sikkerhed til at anvende rollebaserede dataadgangskontroller på mappe-, tabel-, række- og kolonneniveau, så producenter kan offentliggøre dataprodukter uden at eksponere alt i deres arbejdsområde.

  5. Anvend lejerdækkende styring med OneLake-kataloget for tværdomæne-opdagelse og -afstamning, samt Microsoft Purview for følsomhedsetiketter og revision. Udvid den samme identitet og politikmodel til AI-agenter, der forbruger domænedataprodukter, så agentadgang styres som enhver anden forbrugers.

  6. Lad forbrugerdomæner bruge genveje til at referere til producentdataprodukter i stedet for at kopiere dem. Forbrugere kan derefter bruge de refererede dataprodukter i Fabric-arbejdsbyrden, der passer til deres behov. For Power BI semantiske modeller skal du bruge Direct Lake-tilstand til at læse data direkte fra OneLake. Brug Fabric Data Agents eller Fabric IQ til at skabe AI-oplevelser baseret på styrede domænedataprodukter.

  7. Hvis domæner publicerer til kataloger uden for Fabric, skal du planlægge synkronisering af adgangskontrol, så tilladelserne forbliver konsistente mellem OneLake og det eksterne katalog.

    Tip

    Microsoft open source-accelerator Policy Weaver kan automatisere denne synkronisering for Azure Databricks (Unity Catalog), Snowflake og Dataverse-kilder. Den spejler dataadgangspolitikker ind i OneLake-sikkerhedsroller, som supplement til spejling (som flytter data, men ikke tilladelser).

Datamesh-funktioner

  • Centraliseret styring - Decentraliser ejerskabet til domæner, mens identitet, sikkerhed og slægtslinje holdes centraliseret. Funktioner:
  • Datavirtualisering - Lad forbrugerdomæner bruge producentejede dataprodukter gennem referencer i stedet for kopier. Funktioner:
    • Genveje muliggør nul-kopideling mellem domæner.
  • Integreret analyse og AI - Gør alle domænets dataprodukter forbrugbare på tværs af Fabric-arbejdsbelastninger. Funktioner:

Platformkonsolidering til analyse og AI

Hvis du kører flere analyseplatforme side om side – separate værktøjer til data warehousing, business intelligence, data science, realtidsanalyse og AI – kommer hvert værktøj med sine egne datakopier, pipelines og governance-model. Denne fragmentering driver omkostningerne op og gør det svært at anvende ensartet sikkerhed eller få ét svar på et forretningsspørgsmål.

Platformkonsolideringsmønsteret bringer disse arbejdsbelastninger over på Fabric, hvor OneLake leverer et fælles, styret datafundament. Fabric-arbejdsbelastninger tilgås, transformerer, synkroniserer eller analyserer data gennem dette fundament i stedet for at stole på separate data- og styringsmodeller for hvert værktøj.

Brug dette mønster, når:

  • Du bruger flere analyseplatforme med overlappende funktioner.
  • Motorspecifikke datakopier og pipelines driver omkostninger og vedligeholdelsesomkostninger.
  • Du har brug for en enkelt styrings- og sikkerhedsmodel på tværs af alle analyse- og AI-arbejdsbelastninger.

Anvendelse platformkonsolidering

Sigt efter færre platforme, ikke flere integrationer. Konsolider arbejdsbelastninger i Fabric i stedet for at samle værktøjer, og bro kun eksterne motorer, når du ikke kan pensionere dem endnu.

  1. Gør et optæl over de analyse-, datawarehousing-, datalogi-, business intelligence- (BI) og AI-værktøjer og -pipelines, du bruger i dag. Bemærk, hvilke arbejdsbelastninger hvert værktøj betjener, og hvilke data det kopierer.

  2. Tillæg hver eksisterende arbejdsbelastning til den Fabric-arbejdsbyrde, der kan erstatte den:

    Ældre arbejdsbelastning Fabric arbejdsbyrde
    Dataorkestrering og ETL datafabrik
    Spark-notesbøger og lakehouse-behandling Dataudvikler
    SQL datavarehus Datalager
    Streaming og KQL-analyse Real-Time Intelligence-
    ML-modeltræning og eksperimentsporing datavidenskab
    Operationelle databaser Databaser (SQL-database i Fabric og Cosmos DB i Fabric)
    BI-visualisering og semantiske modeller Power BI med Direct Lake-tilstand
    Samtalebaseret AI baseret på virksomhedsdata Fabric Data Agents, Copilot for Fabric, Fabric IQ

  3. Etabler én governance- og sikkerhedsmodel på tværs af alle arbejdsbelastninger ved brug af OneLake-sikkerhed, Microsoft Purview og OneLake-kataloget. Konfigurer kundeadministrerede nøgler, når understøttede Fabric-elementer kræver et ekstra lag kryptering.

  4. Konsolider analytiske data i OneLake ved at bruge Delta- eller Iceberg-format, så arbejdsbelastninger kan dele et styret datafundament. Inkluder operationelle arbejdsbelastninger ved at konsolidere dem på Fabric Databases, som gør synkroniserede analytiske data tilgængelige i OneLake.

  5. Jord-AI på de konsoliderede data. Byg ontologier (forhåndsvisning) over dit kuraterede datalag og eksponer dem for agenter via Ontology MCP-serveren, så Fabric Data Agents, Microsoft 365 Copilot og eksterne værktøjer ræsonnerer over den samme styrede kontekst. Du kan generere ontologidefinitioner fra Power BI semantiske modeller i Import, Direct Lake eller DirectQuery-tilstand. Brug Direct Lake-tilstand , når du har brug for genererede bindings til understøttede OneLake-data, og gennemgå de nuværende ontologibegrænsninger.

  6. For eksterne motorer, du ikke kan pensionere endnu, eksponer OneLake-data til dem via Azure Databricks-integration, Iceberg-interoperabilitet med Snowflake eller OneLake-adgang og API'er.

  7. Pensionér de udskiftede værktøjer, datakopier og pipelines, efter du har valideret Fabric-ækvivalenten. På den måde fjerner konsolideringen omkostninger, licenser og overdragelser i stedet for at tilføje endnu en platform til bunken.

Platformkonsolideringsmuligheder

Ekstern datadeling på tværs af organisationer

Hvis du løbende udveksler data med partnere, leverandører, kunder eller andre afdelinger, tilføjer batch-eksport, filoverførsler og duplikerede downstream-systemer forsinkelse, omkostninger og governance-huller. Det eksterne datadelingsmønster giver forbrugere uden for din organisation eller forretningsafdeling direkte adgang til kuraterede OneLake-data uden gentagne eksporter. Forbrugere kan få adgang til dataene via Fabric cross-tenant deling eller fra eksterne analyseplatforme som Snowflake og Azure Databricks ved at bruge OneLakes interoperabilitetsfunktioner.

Forbrugerne ser opdateringer, efterhånden som du udgiver dem. Du kontrollerer adgangen til kildedataene gennem delings- eller interoperabilitetsmekanismen, der understøtter forbrugerens platform.

Brug dette mønster, når:

  • Du udveksler data løbende med eksterne organisationer.
  • Batch-eksport eller filoverførsler tilføjer latenstid, kompleksitet eller governance-huller.
  • Du skal spore og tilbagekalde ekstern adgang centralt.

Anvend ekstern datadeling

Ekstern deling fungerer bedst, når du bruger virtualisering i stedet for at eksportere data. Match adgangsmetoden til det, hver forbruger kan læse, og anvend de adgangskontroller, der understøttes af denne delings- eller interoperabilitetsmekanisme.

  1. Identificer de dataprodukter, du ønsker at dele eksternt, og de forbrugere, der har brug for dem (partnere, leverandører, kunder). Typisk deler man kuraterede tabeller og filer, der er veldefinerede og dokumenterede.

  2. Vælg den rette delingsmetode for hver forbruger:

    Forbrugertype Anbefalet fremgangsmåde
    Fabric-brugere i en anden lejer Ekstern datadeling til skrivebeskyttet, virtualiseret kryds-lejer adgang
    Snowflake on Azure users Iceberg-interoperabilitet med Snowflake for at læse Fabric-tabeller eksponeret i Iceberg-format
    Azure Databricks Users OneLake-katalogføderation i Azure Databricks til forespørgsler i OneLake-tabeller via Unity Catalog uden at kopiere data
    Applikationer eller værktøjer, der understøtter ADLS Gen2 eller Blob API'er OneLake-adgang og API'er til at få adgang til OneLake-data via understøttede API'er

    For at bringe Dataverse-data ind i OneLake før deling, brug det samlede dataadgangsmønster.

  3. Scope-ekstern adgang med de tilladelser, der understøttes af den valgte delingsmekanisme. For ekstern datadeling i Fabric giver delingen skrivebeskyttet adgang til enhver bruger i den inviterede brugers hjemmelejer. Udbydersidens sikkerheds- og styringspolitikker, herunder OneLake-sikkerhed, følsomhedsetiketter og datatabsforebyggende politikker, håndhæves ikke i forbrugerens lejemål. Forbrugeren skal styre adgangen nedstrøms i deres miljø.

  4. Aftal vilkårene for hvert delingsforhold på forhånd – hvad der deles, med hvem, og hvor længe. For ekstern deling af eksterne data i Fabric, tilbagekald adgang fra fanen Eksterne datadelinger på siden Administrer tilladelser. For andre tilgange, tilbagekald adgangen gennem den valgte delingsmekanisme. Bekræft, at forbrugeren mister sigte.

  5. Anvend følsomhedsetiketter, audit og forebyggelse af datatab med Microsoft Purview i udbyderens Fabric-miljø.

  6. Godkend og dokumenter kildedataprodukterne i OneLake-kataloget , så udbydere kan finde og styre dem, før de deles. OneLake-kataloget udgiver ikke dataprodukter til eksterne lejere eller analyseplatforme.

Eksterne datadelingsmuligheder

  • Datavirtualisering - Del data via no-copy referencer uden at administrere eksportpipelines. Funktioner:
    • Ekstern datadeling muliggør virtualiseret deling mellem Fabric-lejere.
    • Genveje lader partnere forbruge publicerede data uden at kopiere dem.
  • Interoperabilitet mellem åbne data – Del med forbrugere, der ikke bruger Fabric, ved at publicere i åbne formater. Funktioner:
  • Centraliseret styring - Styr kildedata i Fabric og kontroller ekstern adgang gennem hver delingsmekanisme. Funktioner:
  • Last updated on