Microsoft OneLake-mönster och grundläggande funktioner

Den här artikeln introducerar vanliga OneLake-mönster och de plattformsfunktioner du kan använda för att implementera dem. Använd informationen i denna artikel för att fundera igenom hur du vill organisera din datamiljö, och välj sedan de mönster som passar dina affärs-, tekniska och styrningsbehov.

Varje mönster beskriver hur man organiserar data och ägande för att uppnå ett specifikt arkitektoniskt mål. För att implementera ett mönster kombinerar du en eller flera grundläggande OneLake-funktioner – datavirtualisering, öppen datainteroperabilitet, centraliserad styrning samt integrerad analys och AI. Varje funktion förlitar sig i sin tur på specifika produktfunktioner som genvägar, spegling, OneLake-säkerhet och Direct Lake-läge. Samma förmåga och funktion förekommer ofta i mer än ett mönster.

Se dessa fem mönster som byggstenar för din OneLake-design. De flesta miljöer kombinerar mer än en. Välj de mönster som matchar dina mål:

• Enhetlig dataåtkomst med minimal replikering – Använd OneLake för att exponera data från många källsystem utan att kopiera den.
• Medallionarkitektur (brons, silver, guld) – Organisera data så att den flödar genom tre kvalitetslager, från rå insamling till certifierad affärsklar data.
• Domänorienterat datamesh på en delad plattform – Möjliggör för affärsdomäner att äga och publicera sina egna dataprodukter på en enda styrd grund.
• Plattformskonsolidering för analys och AI – Konfigurera analys-, datavetenskap- och AI-arbetsbelastningar att köras på en kopia av data.
• Extern datadelning mellan organisationer – Ge partners och kunder tillgång till OneLake-data utan export eller dubbletter av kopior.

Enhetlig dataåtkomst med minimal replikering

Om din data är utspridd över flera moln, lokala system eller externa sjöar kan det vara opraktiskt – eller ens möjligt – att kopiera allt på ett ställe. Den enhetliga dataåtkomsten med minimal replikeringsmönster behandlar OneLake som ett enda logiskt datalager över dessa källor. Istället för att bygga inmatningspipelines för varje källa använder du genvägar för att referera till data på plats och spegla när du behöver en synkroniserad, frågeoptimerad kopia.

Använd det här mönstret i sådana här scenarier:

• Din data är spridd över flera moln, lokala system eller externa sjöar.
• Att replikera data till ett centralt lager skulle innebära alltför stora krav på lagringsutrymme, latens eller overhead för regelefterlevnad.
• Du behöver snabbt ansluta nya källor utan att utforma fullständiga extraherings-, transformerings- och laddningspipelines (ETL).
• Du vill skydda investeringar i befintliga datasjöar, datalager och operativa datalager.

Tillämpa enhetlig dataåtkomst

För att omsätta detta mönster i praktiken, börja med två primära dataåtkomstmetoder som inte kräver att du bygger eller driver datarörelseprocesser: virtualisering gör källdata tillgänglig via OneLake utan att kopiera den, och zero-ETL-spegling ger en plattformshanterad, synkroniserad kopia till OneLake som analysklara Delta-tabeller. Använd endast Fabric-datarörelseverktyg när dessa metoder inte stödjer källan eller uppfyller dina krav. För ytterligare vägledning om hur du väljer och kombinerar dessa angreppssätt, se Samordna data med OneLake-genvägar och spegling.

1. Inventera dina datakällor för att avgöra vilka OneLake kan nå via virtualisering eller zero-ETL-spegling: molnobjektlagring, externa kataloger, operativa databaser och Dataverse. Markera eventuella kvarvarande källor som behöver en metod för dataflytt.

2. Välj rätt dataåtkomstteknik för varje stödd källa. Föredra virtualisering när källkoden stödjer åtkomst utan kopiering. Använd zero-ETL-spegling när källan kräver en synkroniserad, frågeoptimerad kopia:

1. Transformera källdata vid behov. Genvägstransformationer kan bearbeta stödda filer som exponeras via en genväg, oavsett om filerna lagras externt eller redan finns i OneLake. Använd genvägsfiltransformationer för att konvertera strukturerade filer till delta-tabeller eller genvägs-AI-transformationer för att bearbeta ostrukturerad text. Genvägstransformationer skapar transformerad Delta-utgång och håller den synkroniserad med den data som genvägen refererar till.

2. Använd Fabric-verktyg för datarörelse när virtualisering och spegling inte stödjer en källkod eller när du behöver komplexa transformationer, orkestrering, schemalagd rörelsetakt eller strömmande intagning. För hjälp med att välja mellan pipelines, dataflöden, kopieringsjobb och händelseströmmar, se Välj en datarörelsestrategi.

Om du väljer dataförflyttning bör du lagra de kopierade data i ett öppet tabellformat, till exempel Delta Parquet eller Iceberg. Spegeling och genvägstransformationer skapar redan Delta-utdata. Att använda öppna format håller virtualiserad data, synkroniserade kopior och transformerad Delta-utdata läsbar av Fabric-motorer och externa plattformar.

1. Registrera anledningen varje gång du skapar en synkroniserad kopia, transformerad Delta-utgång eller en kopia via Fabric-datarörelseverktyg. Denna dokumentation gör beslutet granskabart. Skapa en kopia endast när en källa behöver en fysisk, frågeoptimerad layout eller inte kan uppfylla dina krav på färskhet, transformationskostnader, efterlevnad eller bearbetning virtuellt.

2. Tillämpa OneLake-säkerhet på data som görs tillgängliga via OneLake så att samma policyer täcker virtualiserad data, synkroniserade kopior och transformerad Delta-utdata.

3. Godkänn och beskriv de resulterande datapunkterna i OneLake-katalogen så att konsumenter kan hitta och lita på dem.

Enhetliga åtkomstfunktioner för data

• Datavirtualisering och zero-ETL-spegling – Exponera data som finns i andra system och moln genom no-copy referenser eller synkroniserade, analysklara kopior. Funktioner:
  • Genvägar gör källdata tillgänglig i OneLake utan att kopiera den.
  • Metadataspegling synkroniserar extern katalogmetadata och får tillgång till källdata via genvägar.
  • Genvägsfiltransformationer och genvägs-AI-transformationer omvandlar källdata till synkroniserad Delta-utdata.
• Centraliserad styrning – Tillämpa konsekvent säkerhet och upptäckt på virtualiserade källor precis som du skulle göra på native OneLake-data. Funktioner:
  • OneLakes säkerhet och dataåtkomstkontrollmodellen tillämpar konsekventa åtkomstpolicyer på data i OneLake.
  • OneLake-katalogen stödjer upptäckt och godkännande.
• Interoperabilitet med öppna data – Håll virtualiserad data och plattformshanterade kopior läsbara av både Fabric-motorer och externa plattformar. Funktioner:
  • Isbergstabeller i OneLake gör isbergsdata tillgängliga för Fabric och externa motorer.
  • Delta Parquet är ett öppet tabellformat för lagring av analysklar data.
  • OneLake-åtkomst och API:er gör det möjligt för externa applikationer och verktyg att komma åt OneLake-data.

Medaljongarkitektur (brons, silver, guld)

Att göra data tillgänglig i OneLake är bara det första steget. Rådata från källsystemen är vanligtvis inte säkra att använda direkt för analys eller AI. Den innehåller ofta dubbletter, fel, inkonsekventa format eller känsliga fält. När flera team bygger på samma källdata behöver de en gemensam definition av vad varje datasteg är betrodd för.

Medaljongarkitekturen organiserar data i OneLake i tre kvalitetslager: brons för rå, oföränderlig källdata; silver för renad och konformerad data; och guld för certifierade, affärsklara tabeller och semantiska modeller. Varje lager är ett definierat steg som nedströms konsumenter kan förlita sig på. Silver- och guldtabeller kan återanvändas i BI-, analys- och AI-arbetsbelastningar, så team bygger inte om samma rensnings- eller modelleringslogik i separata verktyg.

Använd det här mönstret i sådana här scenarier:

• Flera team bygger på samma källdata och behöver konsekvent kvalitet.
• Du behöver spårbar härstamning från råa indata till certifierade utdata.
• Du behöver ett tydligt kontrakt mellan datateknik och analys- eller AI-konsumenter.

För mer information om detta mönster, se Förstå medaljongarkitektur för Fabric med OneLake. Den artikeln täcker lagerdesign, distributionsmodeller, lagringsformat, materialiserade sjövyer och optimering av Delta-tabeller.

Hur man applicerar det

En fungerande medaljong bygger på en idé: varje lager är ett kontrakt med nedströms konsumenter, och data går bara vidare till nästa lager efter att det uppfyller det lagrets kvalitetsstandarder.

1. Identifiera dina råkällor och de konsumenter som är beroende av certifierad data.

2. Definiera vad som hör hemma i varje lager och tillämpa dessa definitioner konsekvent över domäner:

   Skikt	Innehåll	Typiska konsumenter
   Brons	Rå, oföränderlig data som fångas direkt från källor utan schema-övervakning	Dataingenjörer (begränsad åtkomst)
   Silver	Renade, deduplicerade och anpassade till gemensamma affärsdefinitioner	Dataingenjörer och utbildade analytiker
   Guld	Kuraterade, affärsklara tabeller och semantiska modeller	Alla BI-, analys- och AI-konsumenter

3. Skapa varje lager med rätt arbetsbelastning i Fabric – vanligtvis Data Engineering (Spark) eller Data Factory för brons och silver, och Data Warehouse eller Power BI-semantiska modeller för guld. Bevara källtrogenheten i bronsskiktet genom att använda originalformatet, en genväg till källdata, Parquet eller Delta efter behov. Använd Delta-tabeller för silver och guld så att Fabric-arbetsbelastningar tillförlitligt kan läsa och skriva de förädlade data.

4. Tillämpa lagermedvetna åtkomstpolicyer. Använd OneLake-säkerhet för stödda objekt och de tillämpliga Fabric- och SQL-behörigheterna för lager. Begränsa tillgången till brons, gör silver tillgängligt för analytiker och ge tillgång till guld baserat på konsumenternas behov och minimikrav.

5. Använd kuraterade guldresultat för nedströmsanalys. Bygg semantiska modeller i guldskiktet med Direct Lake-läge så att Power BI kan läsa OneLake-data utan att skapa en importerad kopia eller kräva schemalagda uppdateringar.

6. Bekräfta att varje guldproduktion har spårbar härstamning genom silver till dess bronskällor. Därefter rekommenderar du guldlagerstabeller och semantiska modeller som certifieras i OneLake-katalogen. Denna validering hjälper konsumenter att identifiera vilka data som är redo för produktionsanvändning.

7. Återanvänd semantiska referensmodeller för att snabbt komma igång med ontologier i Fabric IQ. Detta steg ger AI-agenter en styrd affärskontext som bygger på certifierade data.

Grundläggande funktioner

• Integrerad analys och AI – Brons-, silver- och guldlager matar varje analys- och AI-arbetsbelastning på OneLake utan motorspecifika kopior. Funktioner:
  • Medallionens sjöhusarkitektur i OneLake ger designvägledning för de tre lagren.
  • Direct Lake-läget låter Power BI-semantiska modeller läsa guldskiktsdata direkt från OneLake.
  • Arbetsbelastningar i Fabric, såsom Data Engineering och Data Warehouse, producerar och förfinar lagren.
• Centraliserad styrning – Tillämpa olika åtkomstpolicyer och kvalitetsgrindar på varje lager så att konsumenterna endast ser data som är lämplig för deras roll. Funktioner:
  • OneLake-säkerhet tillämpar åtkomstprinciper på lagernivå.
  • OneLake-katalogen stödjer lagermedveten upptäckt och certifiering.
  • Microsoft Purview tillämpar känslighetsetiketter och granskning.
• Öppen datainteroperabilitet – Lagra lagren i öppna format så att externa motorer kan läsa dem tillsammans med Fabric. Funktioner:
  • Delta Parquet är ett öppet tabellformat för lagring av förfinade lagerdata.
  • Iceberg-tabeller i OneLake gör lagerdata tillgängliga för Iceberg-kompatibla motorer.
  • OneLake-åtkomst och API:er gör det möjligt för externa applikationer och verktyg att komma åt lagredata.

Domänorienterad datamesh på en delad plattform

Om du har flera affärsteam som producerar och konsumerar data kan det att routa varje förfrågan genom ett enda centralt datateam fördröja leveransen. Affärsteam förstår ofta sin egen data och sina krav bäst, men att decentralisera ägandet utan delad styrning kan leda till inkonsekvent säkerhet, kvalitet och härstamning.

Det domänorienterade datamesh-mönstret ger varje affärsdomän äganderätt till sina egna dataprodukter medan alla domäner följer gemensamma standarder på en OneLake-grund. Varje domän publicerar sina egna dataprodukter, och andra domäner får tillgång till dem via genvägar och konsumerar dem med Fabric-analys och AI-arbetsbelastningar. Centraliserade identitets-, säkerhets- och styrningspolicys gäller enhetligt över alla domäner.

Använd det här mönstret i sådana här scenarier:

• Ett enda centralt datateam blir en flaskhals för leverans.
• Olika affärsområden har olika data, krav och releasefrekvenser.
• Du behöver tydligt ansvar för datakvalitet på domännivå utan att ge upp företagsövergripande styrning.

Applicera ett domänorienterat datamesh

Hitta rätt balans mellan decentralisering och konsekvens. Flytta ägarskapet till den domän som känner till datan bäst, och håll identitet, säkerhet och härstamning centraliserade så att varje domäns dataprodukter uppfyller samma standarder.

1. Identifiera dina affärsområden. Varje domän bör representera ett sammanhängande område av verksamheten med ett team som kan äga och driva dess dataprodukter från början till slut.

2. Skapa en domän för varje affärsområde och tilldela arbetsytor till det. Skapa en separat central domän för delad infrastruktur och återanvändbar företagsdata.

3. Definiera dataproduktstandarder som varje domän måste uppfylla – till exempel krav på godkännande eller certifiering, dokumenterade scheman, ägarmetadata, versionshantering och servicenivåavtal (SLA). Dessa standarder gör varje produkt till ett återanvändbart, upptäckbart kontrakt snarare än bara en arbetsytmapp.

4. Använd OneLake-säkerhet för att tillämpa rollbaserade åtkomstkontroller på mapp-, tabell-, rad- och kolumnnivå så att producenter kan publicera dataprodukter utan att exponera allt i sin arbetsyta.

5. Tillämpa styrning i hela klientorganisationen med OneLake-katalogen för domänöverskridande identifiering och datahärkomst, samt Microsoft Purview för känslighetsetiketter och granskning. Utvidga samma identitets- och policymodell till AI-agenter som konsumerar domändataprodukter, så att agentåtkomst styrs som vilken annan konsument som helst.

6. Låt konsumentdomäner använda genvägar för att referera till producentdataprodukter istället för att kopiera dem. Användare kan sedan använda de dataprodukter som det hänvisas till i den arbetsbelastning i Fabric som passar deras behov. För Power BI-semantiska modeller, använd Direct Lake-läget för att läsa data direkt från OneLake. Använd Fabric Data Agents eller Fabric IQ för att skapa AI-upplevelser baserade på styrda domändataprodukter.

7. Om domäner publicerar till kataloger utanför Fabric, planera för åtkomstkontrollsynkronisering så att behörigheterna förblir konsekventa mellan OneLake och den externa katalogen.

   Tip

   Microsoft öppen källkodsaccelerator Policy Weaver kan automatisera denna synkronisering för Azure Databricks (Unity Catalog), Snowflake och Dataverse-källor. Den återspeglar principer för dataåtkomst i OneLake-säkerhetsroller och kompletterar spegling (som flyttar data men inte behörigheter).

Datamesh-funktioner

• Centraliserad styrning – Decentralisera ägandet till domäner samtidigt som identitet, säkerhet och härstamning hålls centraliserade. Funktioner:
  • Domäner grupperar arbetsytor efter affärsområde.
  • OneLake-säkerhet tillhandahåller rollbaserade åtkomstkontroller för mappar, tabeller, rader och kolumner.
  • OneLake-katalogen möjliggör domänöverskridande upptäckt och härstamning.
  • Microsoft Purview tillämpar känslighetsetiketter och granskning.
• Datavirtualisering – Låt konsumentdomäner använda producentägda dataprodukter genom referenser istället för kopior. Funktioner:
  • Genvägar möjliggör delning utan kopiering mellan domäner.
• Integrerad analys och AI – Gör varje domäns dataprodukter förbrukningsbara över Fabric-arbetsbelastningar. Funktioner:
  • Direct Lake-läget låter Power BI-semantiska modeller läsa domändataprodukter direkt från OneLake.
  • Fabric-arbetsbelastningar som Data Engineering, Data Warehouse, Real-Time Intelligence och Data Science bearbetar och analyserar domändataprodukter.
  • Fabric Data Agents och Fabric IQ stödjer AI-upplevelser baserade på domändataprodukter.

Plattformskonsolidering för analys och AI

Om du kör flera analysplattformar sida vid sida – separata verktyg för datawarehousing, business intelligence, data science, realtidsanalys och AI – kommer varje verktyg med egna datakopior, pipelines och styrningsmodell. Denna fragmentering driver upp kostnaderna och gör det svårt att tillämpa konsekvent säkerhet eller få ett enda svar på en affärsfråga.

Plattformskonsolideringsmönstret för dessa arbetsbelastningar till Fabric, där OneLake tillhandahåller en delad, styrd databas. Fabric-arbetsbelastningar får tillgång till, transformerar, synkroniserar eller analyserar data via denna grund istället för att förlita sig på separata data- och styrningsmodeller för varje verktyg.

Använd det här mönstret i sådana här scenarier:

• Du använder flera analysplattformar med överlappande funktioner.
• Enginespecifika datakopior och datapipelines medför ökade kostnader och ökad underhållsbelastning.
• Du behöver en enhetlig styrnings- och säkerhetsmodell över alla analys- och AI-arbetsbelastningar.

Genomför plattformskonsolidering

Sikta på färre plattformar, inte fler integrationer. Konsolidera arbetsbelastningar i Fabric i stället för att koppla samman verktyg, och anslut externa motorer bara när du ännu inte kan avveckla dem.

1. Inventera de analysverktyg, datalagringsverktyg, datavetenskapsverktyg, business intelligence-verktyg (BI) och AI-verktyg samt arbetsflöden du använder idag. Notera vilka arbetsbelastningar varje verktyg hanterar och vilken data det kopierar.

2. Koppla varje befintlig arbetsbelastning till den Fabric-arbetsbelastning som kan ersätta den:

   Äldre arbetsbelastning	Fabric-arbetsbelastning
   Dataorkestrering och ETL	Datafabriken
   Spark-notebookar och bearbetning i lakehouse	Dataingenjör
   SQL-datavaruhus	Informationslager
   Streaming och KQL-analys	Realtidsinformation
   ML-modellträning och experimentspårning	Datavetenskap
   Driftsdatabaser	Databaser (SQL-databas i Fabric och Cosmos DB i Fabric)
   BI-visualisering och semantiska modeller	Power BI med Direct Lake-läge
   Konversations-AI baserad på företagsdata	Fabric Data Agents, Copilot for Fabric, Fabric IQ

3. Etablera en styrnings- och säkerhetsmodell över alla arbetsbelastningar med hjälp av OneLake-säkerhet, Microsoft Purview och OneLake-katalogen. Konfigurera kundhanterade nycklar när stödda Fabric-objekt kräver ytterligare ett lager av kryptering.

4. Konsolidera analytisk data i OneLake genom att använda Delta- eller Iceberg-format så att arbetsbelastningar kan dela en styrd databas. Inkludera operativa arbetsbelastningar genom att konsolidera dem i Fabric Databases, som gör synkroniserad analysdata tillgänglig i OneLake.

5. Basera AI på de konsoliderade data. Bygg ontologier (förhandsgranskning) över ditt kurerade datalager och exponera dem för agenter via Ontology MCP-servern, så att Fabric Data Agents, Microsoft 365 Copilot och externa verktyg resonerar över samma styrda kontext. Du kan generera ontologidefinitioner från Power BI-semantiska modeller i Import-, Direct Lake- eller DirectQuery-läge. Använd Direct Lake-läget när du behöver genererade bindningar till stödd OneLake-data, och granska de nuvarande ontologibegränsningarna.

6. För externa motorer som du inte kan avveckla ännu kan du ge dem åtkomst till OneLake-data via Azure Databricks-integration, Iceberg-interoperabilitet med Snowflake eller OneLake-åtkomst och API:er.

7. Avveckla de utbytta verktygen, datakopiorna och datapipelines när du har validerat motsvarigheten i Fabric. På så sätt tar konsolideringen bort kostnader, licenser och överlämningar istället för att lägga till en ny plattform i högen.

Plattformskonsolideringsmöjligheter

• Integrerad analys och AI – För samman analys-, datavetenskap- och AI-arbetsbelastningar på en gemensam OneLake-grund. Funktioner:
  • Arbetsbelastningar i Fabric, såsom Data Factory, Data Engineering, Data Warehouse, Real-Time Intelligence, Data Science, Databaser och Power BI, kan få åtkomst till, transformera, synkronisera eller analysera data via den gemensamma grunden.
  • Direct Lake-läget låter Power BI-semantiska modeller läsa OneLake-data direkt.
  • Fabric Data Agents, Copilot for Fabric och Fabric IQ stödjer AI-upplevelser baserade på OneLake-data.
  • Ontologier och Ontology MCP-servern tillhandahåller styrd affärskontext till AI-agenter.
  • OneLake som kunskapskälla för Microsoft Foundry låter Foundry indexera OneLake-filer för användning av AI-agenter.
• Interoperabilitet med öppna data – Låt externa plattformar som du inte avvecklar fortsätta att läsa samma data. Funktioner:
  • Isbergstabeller i OneLake och Delta Parquet lagrar data i öppna tabellformat.
  • OneLake-åtkomst och API:er gör det möjligt för externa applikationer och verktyg att komma åt OneLake-data.
  • Azure Databricks-integration och Iceberg-interoperabilitet med Snowflake gör det möjligt för externa analysplattformar att läsa OneLake-data.
• Centraliserad styrning – Byt ut säkerhetsmodeller per verktyg mot en styrnings- och revisionsmodell som täcker alla arbetsbelastningar. Funktioner:
  • Fabric governance ger en gemensam styrningsram över Fabric-arbetsbelastningar.
  • OneLake-säkerhet ger enhetliga dataåtkomstkontroller.
  • OneLake-katalogen stödjer upptäckt och härstamning över arbetsbelastningar.
  • Microsoft Purview-integration tillämpar känslighetsetiketter och granskning.
  • Kundhanterade nycklar lägger till ytterligare ett lager av kryptering till stödda Fabric-objekt.

Extern datadelning mellan organisationer

Om du utbyter data med partners, leverantörer, kunder eller andra avdelningar löpande, lägger batchexport, filöverföringar och duplicerade nedströmssystem till latens, kostnads- och styrningsluckor. Det externa datadelningsmönstret ger konsumenter utanför din organisation eller affärsavdelning direkt tillgång till kuraterad OneLake-data utan återkommande export. Konsumenter kan komma åt data via Fabric cross-tenant sharing eller från externa analysplattformar som Snowflake och Azure Databricks genom att använda OneLakes interoperabilitetsfunktioner.

Konsumenter ser uppdateringar när du publicerar dem. Du kontrollerar åtkomsten till källdata genom delnings- eller interoperabilitetsmekanismen som stöder konsumentens plattform.

Använd det här mönstret i sådana här scenarier:

• Du utbyter data med externa organisationer på löpande basis.
• Batchexport eller filöverföringar tillför latens, komplexitet eller gap i styrning.
• Du måste spåra och återkalla extern åtkomst centralt.

Använd extern datadelning

Extern delning fungerar bäst när du använder virtualisering istället för att exportera data. Matcha åtkomstmetoden med vad varje konsument kan läsa och tillämpa de åtkomstkontroller som stöds av den delnings- eller interoperabilitetsmekanismen.

1. Identifiera vilka dataprodukter du vill dela externt och de konsumenter som behöver dem (partners, leverantörer, kunder). Vanligtvis delar du kuraterade tabeller och filer som är väl definierade och dokumenterade.

2. Välj rätt delningsmetod för varje konsument:

   Konsumenttyp	Rekommenderat tillvägagångssätt
   Fabric-användare i en annan klientorganisation	Extern datadelning för skrivskyddad, virtualiserad åtkomst mellan hyresgäster
   Snowflake-användare på Azure	Iceberg-interoperabilitet med Snowflake för att läsa Fabric-tabeller exponerade i Iceberg-format
   Azure Databricks-användare	OneLake-katalogfederation i Azure Databricks för att söka OneLake-tabeller via Unity Catalog utan att kopiera data
   Applikationer eller verktyg som stödjer ADLS Gen2 eller Blob API:er	OneLake-åtkomst och API:er för att komma åt OneLake-data via stödda API:er

   För att importera Dataverse-data till OneLake innan du delar den, använd det enhetliga dataåtkomstmönstret.

3. Avgränsa extern åtkomst med de behörigheter som stöds av den valda delningsmekanismen. För extern datadelning i Fabric ger delningen skrivskyddsbehörighet för alla användare i den inbjudna användarens hemtenant. Säkerhets- och styrningspolicyer på leverantörssidan, inklusive OneLake-säkerhet, känslighetsetiketter och policyer för att förhindra dataförlust, tillämpas inte i konsumentens hyresgäst. Konsumenten måste styra tillgången nedströms i sin miljö.

4. Kom överens om villkoren för varje delningsrelation i förväg – vad som delas, med vem och hur länge. För Fabric extern datadelning, återkalla åtkomst från fliken Externa datadelningar på sidan Hantera behörigheter. För andra metoder, återkalla åtkomst via den valda delningsmekanismen. Bekräfta att konsumenten förlorar sikt.

5. Applicera känslighetsetiketter, revision och förebyggande av dataförlust med Microsoft Purview i leverantörens Fabric-miljö.

6. Godkänn och dokumentera källdataprodukterna i OneLake-katalogen så att leverantörer kan hitta och styra dem innan de delas. OneLake-katalogen publicerar inte dataprodukter till externa hyresgäster eller analysplattformar.

Externa datadelningsmöjligheter

• Datavirtualisering – Dela data via icke-kopieringsreferenser utan att hantera exportpipelines. Funktioner:
  • Extern datadelning möjliggör virtualiserad delning mellan Fabric-hyresgäster.
  • Genvägar låter partners konsumera publicerad data utan att kopiera den.
• Interoperabilitet med öppna data – Dela med konsumenter som inte använder Fabric genom att publicera i öppna format. Funktioner:
  • Isbergstabeller i OneLake gör delade data tillgängliga i ett öppet tabellformat.
  • Iceberg-interoperabilitet med Snowflake gör att Snowflake-konsumenter kan läsa delad OneLake-data.
  • OneLake-katalogfederationen i Azure Databricks låter Azure Databricks-konsumenter fråga OneLake-tabeller via Unity Catalog utan att kopiera data.
  • OneLake-åtkomst och API:er gör det möjligt för kompatibla applikationer och verktyg att komma åt OneLake-data.
• Centraliserad styrning – Styr källdata i Fabric och kontrollera extern åtkomst via varje delningsmekanism. Funktioner:
  • OneLake-säkerhet styr åtkomsten till källdata i Fabric.
  • Microsoft Purview tillämpar känslighetsetiketter, revision och förebyggande av dataförlust i leverantörens Fabric-miljö.
  • OneLake-katalogen stödjer leverantörsbaserad upptäckt och godkännande innan delning.