Välj ett Microsoft Fabric distributionsmönster

När du distribuerar Microsoft Fabric måste du bestämma hur du ska strukturera kapaciteter, arbetsytor och objekt i organisationen. Rätt distributionsmönster beror på dina krav för styrning, säkerhet, prestandaisolering och kostnadshantering. Den här guiden hjälper arkitekter och plattformsteam att utvärdera fyra distributionsmönster och förstå överväganden och kompromisser för var och en.

Hierarki på fyra nivåer

Följande diagram visar hierarkin på fyra nivåer som definierar alla Fabric distributioner.

Ladda ned en Visio fil i den här arkitekturen.

Distributionshierarkin flödar från din Microsoft 365 klientorganisation ned till enskilda objekt. Ditt val av distributionsmönster avgör hur du använder varje nivå.

• Nivå för hyresgäst. Överst finns din Microsoft 365-tenant, som fungerar som identitets- och administrativ gräns för din organisation. Din Fabric-klientorganisation finns inom denna Microsoft 365-klientorganisation och alla Fabric-resurser finns inom denna enda klientorganisations gräns. Inställningar på klientnivå, inklusive Microsoft Entra Conditional Access, private-länkar och känslighetsetiketter, gäller för alla kapaciteter och arbetsytor.

• Kapacitetsnivå. Konfigurera minst en kapacitet för Fabric i en Microsoft 365 klient. Varje kapacitet är bunden till en specifik Azure region och har en specifik F SKU som avgör tillgängliga beräkningsresurser mätta i kapacitetsenheter (CUS). Kapaciteter styr datahemvist och anger faktureringsgränser. En enda kapacitet kan vara värd för flera arbetsytor.

• Arbetsytenivå. Varje kapacitet innehåller en eller flera arbetsytor. Arbetsytor är de primära containrarna för samarbete och styrning. De definierar åtkomstkontroll via fyra arbetsyteroller (administratör, medlem, deltagare och läsare), stöder Git-integrering för versionskontroll och fungerar som omfång för distributionspipelines. En arbetsyta tillhör en kapacitet i taget. Kapacitetsmigrering i samma region är enkel. Migrering mellan regioner är möjlig, men du måste ta bort och återskapa de flesta Fabric-objekt, inklusive lakehouses, datamagasin, notebook-filer och pipelines. Därför föredrar du migrering i samma region.

• Objektnivå. Arbetsytor innehåller Fabric-objekt som lakehouses, lager, anteckningsböcker, pipelines, semantiska modeller, rapporter och dashboards. Objekt ärver arbetsytebehörigheter som standard. Microsoft OneLake-säkerhetsroller ge detaljerad åtkomstkontroll på tabell-, mapp-, kolumn- och radnivå, men de gäller endast för användare i rollen Visningsprogram. Arbetsyteadministratörer, medlemmar och deltagare kringgår OneLake-säkerhetsroller.

Följande begränsningar av licensierings- och arbetsytetyp avgör ofta vilket distributionsmönster som är mest praktiskt:

• Nya arbetsytor startar på delad kapacitet om du inte omtilldelar dem. Varje klientorganisation har en delad kapacitet som är värd för Mina arbetsytor och kan vara värd för Power BI Pro eller PPU-arbetsytor (Premium per användare). För att implementera ett kontrollerat Fabric-distributionsmönster för produktionsarbetsbelastningar behöver du vanligtvis omallokera arbetsytor till en dedikerad Fabric-kapacitet i klientorganisationen.

• PPU ersätter inte Fabric-kapacitet. PPU tillhandahåller Power BI Premium-funktioner per användare, men inkluderar inte Fabric-kapacitet. Om du vill skapa eller köra icke-Power BI Fabric-objekt som sjöhus, lagerhus och anteckningsböcker behöver du en F-kapacitet.

• Arbetsytetyp påverkar vad mönstret kan hantera. Fabric-implementeringsmönstren i den här artikeln förutsätter Fabric-arbetsytor som stöds av F SKU. A- och EM-SKU:er stöder endast Power BI-objekt, så de kan inte stödja implementeringsmönster för hela vägen i Fabric.

• Power BI visningslicensiering kan ändra kostnaden för ett mönster. På F64 och större kapaciteter kan användare med rollen Läsare komma åt Power BI innehåll med en kostnadsfri licens. För mindre kapaciteter behöver Power BI konsumenter en Pro-, PPU- eller utvärderingslicens. Det här tröskelvärdet kan minska kostnadseffektiviteten för ett centraliserat mönster för stora läsarpopulationer.

• Power BI redigering och delning kräver minst en Pro- eller PPU-användare. Även om en arbetsyta använder Fabric-kapacitet behöver organisationer användare med Pro- eller PPU-licenser för att skapa och dela Power BI-objekt.

Komponenter

• Microsoft 365 tenant: En identitets- och administrativ gräns för din organisation. Den är värd för Microsoft Entra ID (tidigare Azure Active Directory) för autentisering och auktorisering.

• Fabrickapacitet: En beräknings- och faktureringsresurs som används i en specifik Azure-region, till exempel East US eller West Europe. För att minska kostnaderna kan du pausa kapaciteter när de inte används.

• Fabric arbetsyta: En samarbetscontainer för Fabric objekt. Den stöder rollbaserad åtkomstkontroll (RBAC), Git-integrering och distributionspipelines. För logisk gruppering kan du tilldela arbetsytor till Fabric domäner.

• Fabric objekt: Data- och analysartefakter som sjöhus, informationslager, notebook-filer, pipelines, dataflöden, semantiska modeller, rapporter och instrumentpaneler.

• Fabric domäner: Logiska grupper som organiserar arbetsytor efter affärsenhet eller ämnesområde. Domäner stöder delegerad styrning och visas i OneLake-katalogen för identifiering och tillsyn.

• OneLake: En enhetlig, hierarkisk datasjö där hyresgäster innehåller arbetsytor som innehåller objekt. Fabric lagrar data i OneLake. OneLake stöder Azure Data Lake Storage API:er, genvägar till extern lagring och integrering med Data Lake Storage verktyg, till exempel Azure Storage Explorer och AzCopy.

• OneLake-katalog: Ett centraliserat gränssnitt för att hitta, styra och skydda Fabric data i klientorganisationen. Användare kan komma åt katalogen med hjälp av verktyg som Microsoft Teams, Excel och Microsoft Copilot Studio.

Förstå Fabric implementeringsnivåer

Organisationens struktur, mål, säkerhetskrav, skala, styrningsmodell och programlivscykel påverkar beslut på varje distributionsnivå. Mer information om varje nivå finns i Hierarki på fyra nivåer.

• Kapaciteter styr datahemvist och geografisk distribution. Organisationer som arbetar på flera geografiska platser kan använda kapaciteter i olika Azure regioner för att styra var data lagras. Varje kapacitet är bunden till en specifik Azure region, som stöder distributioner med flera geografiska områden mellan regioner. För att stödja centraliserad styrning kan Fabric domäner gruppera arbetsytor och deras associerade kapaciteter mellan regioner.

• Arbetsytor fungerar som den primära styrnings- och säkerhetsgränsen. Varje arbetsyta definierar åtkomstkontroll via fyra roller, stöder versionskontroll via Git-integrering och fungerar som omfång för distributionspipelines. Om du vill centralisera samarbete och innehållsidentifiering använder du OneLake-katalogen för att implementera en enhetlig identifierings- och styrningsupplevelse över klientorganisationens OneLake-data. Användare kan hitta och interagera med innehåll från verktyg som Teams och Excel via den här katalogen.

• Varje nivå påverkar val av programlivscykel. Funktioner som distributionspipelines och livscykelhantering är inte tillgängliga i mönster för enskilda arbetsytor eftersom de kräver separata arbetsytor. Organisationer som använder domäner för att gruppera arbetsytor kan delegera administration på domännivå utan behörighet som innehavaradministratör, vilket påverkar hur team hanterar versioner och styrning mellan affärsenheter.

Vanliga mönster för alla distributioner

Alla Fabric distributionsmönster har följande grundläggande egenskaper:

• Arbetsytor som gränser för skalning, styrning och säkerhet. Distributionsmönster använder Fabric arbetsytor som primär enhet för objektorganisation, behörigheter och DevOps-funktionsomfång. Oavsett vilket mönster du väljer definierar arbetsytor gränsen för samarbete och åtkomstkontroll.

• Fabric domäner för delegering över flera arbetsytor och affärsenheter. Använd Fabric domäner för delegering. Du kan hantera flera arbetsytor som kan tillhöra samma affärsenhet eller hantera data som tillhör en affärsdomän och som omfattar mer än en arbetsyta. Om du vill hantera och styra data på domännivå kan du justera inställningar på klientnivå och använda en domänspecifik konfiguration för dessa inställningar.

• Kapaciteter för beräkningsskalning med dedikerad kapacitet per arbetsyta för prestandagarantier. Om du måste uppfylla specifika prestandanivåer använder du Fabric kapaciteter för att skala beräkningsresurser och erbjuda dedikerade kapaciteter per arbetsyta. Organisationer som behöver arbetsbelastningsisolering för prestandakänsliga jobb kan tilldela dessa arbetsytor till en separat kapacitet som har en garanterad CU-allokering.

• OneLake-katalog för tillgångsidentifiering och fliken Säker för datasäkerhetsprinciper. Om du vill främja identifiering och användning av datatillgångar i klientorganisationen använder du OneLake-katalogen. Om du vill visa, övervaka och konfigurera säkerhetsroller mellan arbetsytor och objekt använder du fliken Säker i OneLake-katalogen.

• Tillägg till Microsoft Cloud funktioner om inbyggda Fabric funktioner inte är tillgängliga. Om en intern funktion inte är tillgänglig kan distributionsmönster utökas till att använda motsvarande funktioner från Microsoft Cloud, till exempel Azure och Microsoft 365. Organisationer kan till exempel använda Azure Pipelines eller GitHub Actions för CI/CD-orkestrering (kontinuerlig integrering och kontinuerlig leverans) om Fabric-distributionspipelines inte täcker deras automatiseringskrav över arbetsytor. Organisationer kan också använda Microsoft Purview för företagsomfattande datastyrning som sträcker sig över Fabric och icke-Fabric datakällor.

Välj ett distributionsmönster

I följande scenarier beskrivs vanliga affärskrav och de distributionsmönster som hanterar dem. Använd dessa scenarier för att identifiera det mönster som passar din organisation bäst.

• Scenario 1: Snabbare tid att marknadsföra med samarbete mellan team. Om din organisation vill ha snabbare tid till marknad, samarbete mellan team och lägre begränsningar för dataanvändning kan du implementera ett monolitiskt distributionsmönster. I det här scenariot arbetar din organisation i och hanterar en enda arbetsyta.

  Använd mönster 1: Monolitisk distribution.

• Scenario 2: Isolerade teammiljöer med central infrastrukturhantering. Om din organisation vill tillhandahålla isolerade teammiljöer och en central infrastrukturhanteringsgrupp kan du implementera flera arbetsytor som använder antingen en delad kapacitet eller separata kapaciteter. Det här scenariot passar även organisationer som vill implementera en datanätarkitektur.

  Använd mönster 2: Flera arbetsytor, enskild kapacitet eller mönster 3: Flera arbetsytor, separata kapaciteter.

• Scenario 3: Fullständig affärsenhetsautonomi över dataplattformar. Om din organisation vill ha en helt decentraliserad modell som ger affärsenheter eller team friheten att styra och hantera sina egna dataplattformar kan du implementera en distributionsmodell som använder antingen separera arbetsytor med dedikerad kapacitet eller flera Fabric klienter.

  Använd Mönster 3: Flera arbetsytor, separata kapaciteter eller Mönster 4: Flera Fabric-abonnenter.

• Scenario 4: Hybridmetod som kombinerar flera mönster. Om din organisation vill ha en hybridlösning som använder flera mönster för att uppfylla kraven kan du implementera en hybridmetod. Du kan till exempel konfigurera en enda arbetsyta för specifika affärsenheter, till exempel i ett monolitiskt distributionsmönster, samt separata dedikerade arbetsytor och separata kapaciteter för andra affärsenheter.

Mönster 1: Monolitisk distribution

I det här distributionsmönstret allokerar du en arbetsyta för alla användningsfall. Alla affärsenheter arbetar på samma arbetsyta.

Följande egenskaper gäller för det här mönstret:

• Kapacitet för tygföremål är densamma för alla. Tiden som en fråga eller ett jobb tar varierar beroende på de andra arbetsbelastningar som använder samma kapacitet.

• Maximalt antal CU:er för arbetsytan är begränsade till största möjliga F SKU. För datateknik- och datavetenskapsupplevelser kan kapacitetsadministratörer konfigurera Autoscale-fakturering för Apache Spark för att flytta den beräkningskapacitet som används av Spark Engine utanför de allokerade CU:erna.

• Funktioner som är begränsade till en arbetsyta gäller för alla affärsenheter som delar arbetsytan.

• Alla arbetsyteobjekt och data finns i en region. Du kan inte använda det här mönstret för scenarier med flera geografiska områden.

• Funktioner som förlitar sig på flera arbetsytor är inte tillgängliga, till exempel distributionspipelines och livscykelhantering.

• Begränsningar för enskild arbetsyta gäller.

• Specifika kapacitetsbegränsningar för SKU gäller.

När du ska använda det här mönstret

Du kan implementera det här distributionsmönstret om:

• Din organisation har inte komplexa tekniska krav, den har en liten användarbas eller små semantiska modeller.

• Din organisation verkar i en enda region.

• Du bryr dig inte i första hand om organisationsavgränsning mellan affärsenheter.

• Din organisation kräver inte arbetsytaspecifika funktioner, till exempel att dela kodlager med Git.

• Du vill implementera en medallion-arkitektur för lakehouse. Om din organisation använder en enda arbetsyta kan du skapa separata sjöhus på arbetsytan för att hantera brons-, silver- och guldlager.

• Organisationens affärsenheter delar roller, och du kan ha samma arbetsytenivå-behörigheter för användare i arbetsytan. Om till exempel flera användare från olika affärsenheter är administratörer för en enda arbetsyta har de samma rättigheter för alla objekt på arbetsytan.

• Din organisation tolererar varierande jobbavslutstider. Om en kapacitet delas kan användarna göra förfrågningar när som helst. Antalet CUs som är tillgängliga för att köra ett jobb beror på de andra frågeprocesserna som körs på den tillgängliga kapaciteten, vilket kan leda till varierande avslutningstider för jobb.

• Din organisation kan uppfylla sina CU-affärskrav med hjälp av en enda Fabric-kapacitet.

Designområdesöverväganden

I följande tabell beskrivs överväganden som kan påverka ditt beslut att använda det här distributionsmönstret.

Mönster 2: Flera arbetsytor, en kapacitet

I det här distributionsmönstret allokerar du flera arbetsytor på en enda delad kapacitet. Arbetsytor delar den kapaciteten, så samtidiga arbetsbelastningar kan påverka prestandan för jobb och interaktiva frågor.

Följande egenskaper gäller för det här mönstret:

• Kapacitet för tygföremål är densamma för alla. Tiden som en fråga eller ett jobb tar varierar beroende på de andra arbetsbelastningar som använder samma kapacitet.

• Maximalt antal CU:er för arbetsytan är begränsade till största möjliga F SKU. För datateknik och datavetenskapsupplevelser kan kapacitetsadministratörer konfigurera autoskalningsfakturering för Spark för att flytta beräkningskapaciteten som används av Spark-motorn utanför de allokerade CU:erna.

• Funktioner som är begränsade till en arbetsyta gäller för alla affärsenheter som delar arbetsytan.

• Alla arbetsyteobjekt och data finns i en region. Du kan inte använda det här mönstret för scenarier med flera geografiska områden.

• Du kan använda DevOps-funktioner som kräver separata arbetsytor, till exempel distributionspipelines och livscykelhantering.

• Begränsningar gäller för en enda arbetsyta.

• Specifika kapacitetsbegränsningar för SKU gäller.

När du ska använda det här mönstret

Du kan implementera det här distributionsmönstret om:

• Du vill ha en hub-spoke-arkitektur som centraliserar vissa aspekter av analysmiljön och decentraliserar andra.

• Du vill ha decentralisering av variabel drift och hantering. Din organisation kan till exempel vara värd för brons- och silverskikten i en medaljongarkitektur på en arbetsyta och vara värd för guldskiktet på en separat arbetsyta. Denna separation återspeglar ofta distinkta operativa ansvarsområden, till exempel där ett team hanterar brons- och silverskikten och ett annat team hanterar guldskiktet.

• Du bryr dig inte i första hand om prestandahantering och arbetsbelastningsisolering.

• Din organisation behöver inte distribuera arbetsbelastningar i olika geografiska regioner. Alla data måste finnas i en region.

• Din organisation kan kräva separata arbetsytor eftersom:

  • Medlemmar i teamet som ansvarar för arbetsbelastningar finns på olika arbetsytor.

  • Du vill skapa separata arbetsytor för varje typ av arbetsbelastning. Du kan till exempel skapa en arbetsyta för datainmatning, till exempel datapipelines, dataflöden eller datateknik, och en separat arbetsyta för förbrukning via ett informationslager. Den här designen fungerar bra om separata team ansvarar för varje arbetsbelastning.

  • Du vill implementera en datanätsarkitektur som grupperar en eller flera arbetsytor i en Fabric domän.

• Din organisation kan distribuera separata arbetsytor baserat på dataklassificering.

Designområdesöverväganden

I följande tabell beskrivs överväganden som kan påverka ditt beslut att använda det här distributionsmönstret.

Mönster 3: Flera arbetsytor, separata kapaciteter

I det här distributionsmönstret allokerar du flera arbetsytor mellan separata Fabric kapaciteter, vilket ger styrnings- och prestandaisolering mellan affärsenheter.

Följande egenskaper gäller för det här mönstret:

• Den största möjliga F SKU:n eller P SKU:n som är kopplad till en arbetsyta avgör det maximala antalet CU:er som en arbetsyta kan använda.

• Separata arbetsytor skapar organisations- och hanteringsdecentralisering.

• Organisationer kan skala utanför en region med hjälp av kapaciteter och arbetsytor i olika geografiska regioner.

• Du kan använda de fullständiga funktionerna i Fabric eftersom affärsenheter kan ha flera arbetsytor i separata kapaciteter och grupperas tillsammans via Fabric domäner.

• Begränsningar för arbetsytor för en enskild arbetsyta gäller, men du kan skapa nya arbetsytor för att skala utanför dessa gränser.

• Specifika SKU-kapacitetsbegränsningar gäller, men du kan skala CU:er med hjälp av separata kapaciteter.

• Du kan använda katalogen OneLake för att identifiera Fabric objekt och deras certifieringsstatus.

• Domäner kan gruppera arbetsytor så att en enda affärsenhet kan använda och hantera flera arbetsytor.

• OneLake-genvägar eliminerar fysiska kopior av data för att minska dataflytten. OneLake-genvägar erbjuder också kontrollerad åtkomst mellan arbetsytor via OneLake och överför inte ägarskapet för underliggande data.

När du ska använda det här mönstret

Du kan implementera det här distributionsmönstret om:

• Din organisation vill distribuera arkitekturramverk som datanät eller datainfrastruktur.

• Du vill prioritera flexibilitet i hur du strukturerar kapaciteter och arbetsytor.

• Du arbetar i olika geografiska regioner. I det här fallet skapar du separat kapacitet och arbetsyta för att gå mot ett distributionsmönster med flera kapaciteter och arbetsytor.

• Du arbetar i stor skala och behöver skala bortom begränsningarna av en SKU med enkel kapacitet eller en enda arbetsyta.

• Du har arbetslaster som alltid måste slutföras inom en viss tid eller som behöver uppfylla prestandabaserade mål. Du kan konfigurera separata Fabric kapacitetsbaserade arbetsytor för att uppfylla SLA:er för dessa arbetsbelastningar.

Designområdesöverväganden

I följande tabell beskrivs överväganden som kan påverka ditt beslut att använda det här distributionsmönstret.

Mönster 4: Flera Fabric klientorganisationer

I det här distributionsmönstret är alla instanser av Fabric separata entiteter med avseende på styrning, hantering, administration, skalning och lagring.

Följande egenskaper gäller för det här mönstret:

• Hyresgästresurserna är strikt åtskilda.

• Hanteringsplaner för varje klient är separata.

• Hyresgäster är separata entiteter, var och en med sina egna styrnings- och hanteringsprocesser och administreras var för sig.

• Du kan använda datapipelines eller datateknik funktioner för att dela eller komma åt data mellan Fabric klienter.

När du ska använda det här mönstret

Du kan implementera det här distributionsmönstret om:

• Din organisation har flera Fabric klienter på grund av ett företagsförvärv.

• Din organisation vill konfigurera en Fabric klientorganisation specifikt för en affärsenhet eller ett mindre dotterbolag.

Utvärdera alternativa plattformar

Om organisationens krav inte överensstämmer med Fabric-baserade distributionsmodeller bör du överväga följande begränsade alternativ:

• Azure Data Factory med antingen Data Lake Storage eller OneLake, inklusive hybridarkitekturer för Data Factory och Fabric

  Organisationer som behöver explicit orkestreringskontroll eller stegvis modernisering kan använda Data Factory för inmatning och pipelineorkestrering och Data Lake Storage som lagringsgrund. I en hybridmodell kan datapipelines som hanteras av Data Factory läsa in data till OneLake medan Fabric hanterar skapandet av analytiska dataresurser. Den här metoden stöder stegvis införande av Fabric och bevarar etablerade integrationsmönster.

• Data Lake Storage, Azure Databricks och Power BI

  Organisationer som föredrar en PaaS-baserad arkitektur (plattform som en tjänst) i stället för en enhetlig SaaS-plattform (programvara som en tjänst) kan skapa en dataegendom med hjälp av Data Lake Storage för lagring, Azure Databricks för datateknik och analys och Power BI för semantisk modellering och rapportering. Den här metoden ger maximal kontroll och flexibilitet, men kräver ökad integrering och ökar driftkomplexiteten och styrningskostnaderna.

Överväganden

Dessa överväganden implementerar grundpelarna i Well-Architected Framework, som är en uppsättning vägledande grundsatser som du kan använda för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Well-Architected Framework.

Tabellerna per mönster tidigare i den här artikeln använder designområden som är specifika för Fabric distributionsbeslut, till exempel styrning, säkerhet, administration, DevOps, användbarhet, prestanda och fakturering. Följande underavsnitt ger kompletterande vägledning organiserad efter pelarna i "Well-Architected Framework". Använd tabellerna per mönster för att jämföra mönster. Använd dessa underavsnitt för övergripande arkitekturvägledning som gäller oavsett vilket mönster du väljer.

Reliability

Tillförlitlighet hjälper till att säkerställa att ditt program kan uppfylla de åtaganden som du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.

• Inbyggd regional resiliens. Fabric ger inbyggd regional återhämtning via tillgänglighetszoner, där det stöds. Fabric distribuerar resurser automatiskt över flera zoner utan kundkonfiguration. Stöd för tillgänglighetszoner varierar beroende på Azure region. Information om hur du kontrollerar om målregionen stöder tillgänglighetszoner för Fabric finns i Fabric regiontillgänglighet.

• Katastrofåterställning (DR) kräver aktiv anmälan och har förbehåll. Återställning mellan regioner är tillgänglig via en valfri DR-inställning på sidan för kapacitetsinställningar. Aktivera inställningen för DR-kapacitet för att replikera OneLake-data över Azure parkopplade regioner med hjälp av asynkron replikering.

  Viktigt!

  Vissa Azure regioner är inte kopplade till regioner som stöder Fabric, vilket kan äventyra DR-funktionerna även om data replikeras. Eftersom datareplikeringen är asynkron kan data som skrivs omedelbart före en regional katastrof gå förlorade. Mer information finns i Reliability i Fabric.

• Enkapacitetsmönster koncentrerar risken till en region. I mönster 1 och 2 finns arbetsbelastningar i en Azure-region. Om regionen drabbas av ett avbrott påverkas alla arbetsytor samtidigt. För att skydda mot regionala fel konfigurerar du kapacitetsinställningen för att replikera OneLake-data till en parad region. Planera för den återställningstid som krävs för att återställa tjänsten i den kopplade regionen.

• Multikapacitetsmönster ger naturlig regional isolering. I mönster 3 och 4 innebär kapaciteter i olika regioner att ett regionalt avbrott endast påverkar kapaciteterna i den regionen. Arbetsbelastningar i andra regioner fortsätter att fungera. Dessa mönster stöder krav på datahemvist och utgör grunden för aktiv-passiv eller aktiv-aktiv regionala strategier.

• Kapacitets pausning påverkar tillförlitligheten. Om du pausar en Fabric-kapacitet för att minska kostnaderna, blir alla arbetsbelastningar på den otillgängliga. Tänk på tillförlitlighetseffekten innan du pausar en kapacitet som stöder produktionsarbetsbelastningar.

• OneLake-genvägar introducerar externa beroenden. Genvägar till externa datakällor medför beroende av källtillgänglighet. Om den externa källan inte är tillgänglig kan objekt som är beroende av genvägar misslyckas. Övervaka hälsotillståndet för externa datakällor och planera för en ordnad nedgång.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

• Säkerhetsmodellen i lager sträcker sig över tre nivåer. Fabric implementerar en säkerhetsmodell i flera lager som sträcker sig över klient-, arbetsytans och objektnivåerna. Ditt val av distributionsmönster avgör hur du segmenterar säkerhetsgränser. Mönster för en arbetsyta, till exempel mönster 1, framtvingar enhetlig åtkomst. Multiworkspace-mönster, till exempel mönster 2, 3 och 4, stöder säkerhetsgränser per team eller per affärsenhet.

Identitet och åtkomst

• Framtvinga autentiseringsprinciper på klientnivå med hjälp av villkorsstyrd åtkomst. Använd villkorlig åtkomst för att framtvinga autentiseringsprinciper på klientorganisationsnivå, till exempel multifaktorautentisering, enhetsefterlevnad och platsbaserade begränsningar. Villkorlig åtkomst kräver en Microsoft Entra ID P1-licens.

• Använd arbetsyteroller för att styra objektåtkomst. Tilldela arbetsyteroller för att styra vem som kan skapa, redigera och använda objekt i en arbetsyta. I mönster för flera arbetsytor, till exempel mönster 2, 3 och 4, använder du separata arbetsytor för att framtvinga rollgränser mellan affärsenheter.

• Använd detaljerad åtkomst på datanivå med hjälp av OneLake-säkerhetsroller. Använd OneLake-säkerhetsroller för att tillämpa detaljerad åtkomstkontroll på tabell-, mapp-, kolumn- och radnivå för användare i rollen Visningsprogram. Arbetsyteadministratörer, medlemmar och deltagare kringgår dessa roller.

Nätverkssäkerhet

• Använd privata länkar för inkommande trafik. Använd private-länkar för att dirigera inkommande trafik över Microsoft stamnät i stället för det offentliga Internet. Privata länkar på hyresgästnivå gäller för alla arbetsytor. Privata länkar på arbetsytans nivå ger detaljerad information per arbetsyta.

• Använd hanterade privata slutpunkter för utgående Spark-anslutningar. Använd hanterade privata slutpunkter för att skydda utgående anslutningar från Spark-arbetsbelastningar till brandväggsskyddade datakällor, till exempel Data Lake Storage och Azure SQL Database.

• Använd virtuella nätverksdatagatewayer när privata länkar på klientnivå blockerar lokala gatewayer. När du aktiverar privata länkar på klientnivå kan lokala datagatewayer inte registreras. Använd en virtuell nätverksdatagateway i stället för bryggor som ansluter lokala eller virtuella nätverksskyddade datakällor.

Dataskydd

• Använd känslighetsetiketter för dataklassificering från slutpunkt till slutpunkt. För dataklassificering och skydd tillämpar du känslighetsetiketter från Microsoft Purview Information Protection på data som flödar genom Fabric. Etiketter följer data från källa till rapport.

• Använd granskningsloggar och efterlevnadsverktyg för principframtvingande. Om du vill identifiera och svara på principöverträdelser läser du granskningsloggar och använder Microsoft Purview Compliance Manager.

Kostnadsoptimering

Kostnadsoptimering fokuserar på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

• Modellera kostnader innan du implementerar. Distributionsmönster påverkar kostnadsstrukturen. Modellera kostnader för ditt scenario med hjälp av Fabric prissättning och kapacitetsberäknaren Fabric.

• Justera din kapacitets-SKU. Anpassa storleken på din F SKU efter arbetsbelastningens behov. Börja med en mindre SKU och skala upp efter behov. Övervaka förbrukningen och identifiera överetablerade eller underetablerade kapaciteter med hjälp av appen Fabric Capacity Metrics.

• Automatisera kapacitets pausning för icke-produktionsmiljöer. Minska kostnaderna genom att pausa F SKU-kapaciteter när de inte används. I utvecklings-/testmiljöer, pausa kapaciteter utanför arbetstid. Pausning gör alla arbetslaster otillgängliga, så överväg automatisering via Azure Resource Manager Fabric API eller schemalagda pipelines.

• Mönster med en kapacitet, till exempel mönster 1 och 2, centraliserar fakturering men begränsar återbetalningen. En kapacitet innebär en faktura. Kostnadshantering är centraliserad, men återbetalning till enskilda affärsenheter är inte möjligt eftersom alla arbetsbelastningar delar samma kapacitet.

• Multikapacitetsmönster, till exempel mönster 3 och 4, stöder återbetalning per team. Varje kapacitet genererar sin egen Azure-fakturamätare. Du kan debitera kostnader för den affärsenhet som ansvarar för varje kapacitet. Du kan självständigt anpassa storleken eller pausa varje kapacitet baserat på den arbetsbelastning som den stöder.

• Hantera OneLake-lagringskostnader oberoende av varandra. OneLake-lagring faktureras enligt ett betala per användning-pris per GB och förbrukar inte processorer. Ta regelbundet bort oanvända data, inklusive mjukt borttagna data, och övervaka lagring via appen Fabric Kapacitetsmått.

• Övervaka Spark-beräkning separat. För datateknikarbetsbelastningar kan du använda separata Spark-pooler för att flytta beräkning utanför CU-budgeten. Övervaka Spark CU-förbrukningen för att undvika oväntade kostnader.

Operativ skicklighet

Operational Excellence omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Checklista för designgranskning för Operational Excellence.

• Använd distributionspipelines för stegvis befordran. Använd Fabric distributionspipelines för att höja upp innehåll via utvecklings-/test- och produktionssteg. Distributionspipelines kräver separata arbetsytor, så de är inte tillgängliga i mönster 1. I mönster 2, 3 och 4 skapar du dedikerade arbetsytor för varje DTAP-fas. Kapacitetsstrategin varierar beroende på mönster.

  • I mönster 2 har alla DTAP-arbetsytor samma kapacitet, vilket är kostnadseffektivt men inte ger prestandaisolering mellan miljöer.

  • I mönster 3 kan du använda dedikerade kapaciteter per miljö för fullständig isolering, eller så kan du balansera kostnader och isolering med hjälp av en delad kapacitet för utveckling/testning med en separat produktionskapacitet.

• Planera förproduktionsmiljöer som ett designbeslut på arbetsytenivå. Mönster 1 ger ingen förproduktionsseparation eftersom dev/test sker på produktionsarbetsytan. Mönster 2 stöder separata arbetsytor för utveckling, testning och produktion på en delad kapacitet, vilket passar funktionell validering men inte produktionsliknande prestanda- eller motståndskraftstestning. Mönster 3 stöder produktionsliknande förproduktionsvalidering via miljöjusterade arbetsytor med isolering på kapacitetsnivå. Mönster 4 omfattar separata klientorganisationer snarare än beslut som fattas på arbetsytenivå. Varje hyresgäst kan självständigt välja sin egen miljötopologi och behöver inte matcha andra hyresgäster.

• Anslut arbetsytor till Git-lagringsplatser för källkontroll. I mönster 2 och 3 överensstämmer separata arbetsytor per team eller arbetsbelastning med standardförgreningsstrategier. I det första mönstret delar alla team ett enda kodförråd, vilket kan skapa sammanslagningskonflikt.

• Övervaka kapacitets- och arbetsbelastningshälsa. Använd appen Fabric Kapacitetsmått för att övervaka kapacitetsförbrukningen, till exempel CU-användning, begränsning och överförbrukning. Du kan komma åt detaljerad telemetri om enskilda arbetsbelastningar med hjälp av övervakning av arbetsytor. I mönster med flera kapaciteter, till exempel mönster 3 och 4, kan du delegera övervakning till det team som ansvarar för varje kapacitet.

• Delegera administration genom Fabric-domäner. I mönster 2 och 3 delegerar du klientinställningar och arbetsytehantering till administratörer på domännivå utan behörighet som innehavaradministratör med hjälp av Fabric domäner. Mönster 1 kan inte använda domäner eftersom alla objekt finns på en arbetsyta.

• Hantera kapaciteter med hjälp av infrastruktur som kod (IaC). Skapa och hantera Fabric kapaciteter med hjälp av Bicep eller Terraform. Lagra infrastrukturdefinitioner i källkontrollen tillsammans med programkod.

Prestandaeffektivitet

Prestandaeffektivitet syftar på arbetsbelastningens förmåga att skala för att effektivt uppfylla användarnas krav. För mer information, se Designgranskningschecklistan för prestandaeffektivitet.

• Förstå kapacitetsdimensionering och strypningsbeteende. Varje kapacitet har en fast CU-allokering som bestäms av dess SKU. Om efterfrågan överskrider tillgängliga CUs gäller Fabric throttling och köbegäranden. Övervaka strypningshändelser med Fabric Kapacitetsmått-appen och skala upp SKU:n eller distribuera arbetsbelastningar över flera kapaciteter efter behov.

• Isolera prestandakänsliga arbetsbelastningar på en dedikerad kapacitet. I mönster 1 och 2 konkurrerar alla arbetsbelastningar om samma CU:er. En dyr fråga eller datapipeline kan försämra interaktiva frågeprestanda för andra användare. I mönster 3 och 4 kan du isolera prestandakänsliga arbetsbelastningar på en reserverad kapacitet med en garanterad CU-allokering.

• Konfigurera Spark-pooler för datateknikarbetsbelastningar. För datateknikarbetsbelastningar använder du anpassade Spark-pooler för att styra minsta och högsta antal noder och stöder automatisk skalning. Hanterade virtuella nätverk inaktiverar startpooler eller förvärmade delade kluster, vilket ökar sessionens starttid från sekunder till mellan 3 och 5 minuter.

• Placera kapaciteter nära dataproducenter och konsumenter. I mönster 3 kan du använda kapaciteter i regioner nära dataproducenter eller konsumenter, vilket minskar svarstiden mellan regioner. OneLake-genvägar kan referera till data i andra regioner, men läsningar mellan regioner medför kostnader för svarstid och utgående trafik.

• Tillämpa arbetsbelastningsspecifika optimeringstekniker. Förbättra genomsökningsprestanda med Z-Ordering och V-Ordering för lakehouses. För lager kan du optimera frågemönster för att läsa mindre batchar. Minska kapacitetsbelastningen jämfört med importläget med hjälp av Direct Lake läge för Power BI rapporter.

Kapacitetsmatris

I följande tabeller sammanfattas de viktigaste skillnaderna i funktionerna i varje mönster.

Styrning och administration

¹ Arbetsytor ger viss isolering, men alla arbetsytor delar en enda kapacitet, vilket begränsar kornigheten för användningsspårning och administration.

² Mönster 4 använder separata klienter i stället för domäner. Varje klientorganisation har en egen administrationsmodell.

Säkerhet

DevOps och livscykelhantering

³ Distributionspipelines kräver separata arbetsytor som inte är tillgängliga i ett monolitiskt mönster för en enda arbetsyta.

⁴ Git-integrering är tillgänglig, men alla team delar ett enda repository, vilket kan skapa sammanslagningskonflikter.

Prestanda och skalning

⁵ Begränsningsrisken är låg om arbetsbelastningar finns på dedikerade kapaciteter, men begränsning kan fortfarande ske inom en enda kapacitet om efterfrågan överskrider tillgängliga CU:er.

Fakturering och kostnadshantering

⁶ Varje kapacitet genererar en egen faktureringsmätare, så faktureringen distribueras mellan kapaciteter i stället för centraliserad.

Bidragsgivare

Microsoft uppdaterar den här artikeln. Följande bidragsgivare skrev den här artikeln.

Huvudförfattare:

• Amanjeet Singh | Huvudprogramchef

Övriga medarbetare:

• Lorrin Ferdinand | Huvudkonsult
• Holly Kelly | Huvudprogramchef
• Gabi Münster | Senior programansvarig
• Sarah Sasidharan | Senior Program Manager

Om du vill se icke-offentliga LinkedIn profiler loggar du in på LinkedIn.

Nästa steg

• Fabric koncept och licenser
• Fabric-arbetsytor
• Fabric domäner
• Vad är OneLake?
• Fabric distributionspipelines
• Reliability i Fabric
• Fabric säkerhetsöversikt

Relaterade resurser

• Översikt över teknikval
• Analytics från början till slut med Fabric
• Företagsintelligens med Fabric
• Bygg ett greenfield lakehouse med Fabric