Een Microsoft Fabric-implementatiepatroon kiezen

Wanneer u Microsoft Fabric implementeert, moet u bepalen hoe u capaciteiten, werkruimten en items in uw organisatie structureert. Het juiste implementatiepatroon is afhankelijk van uw vereisten voor governance, beveiliging, prestatie-isolatie en kostenbeheer. Deze handleiding helpt architecten en platformteams vier implementatiepatronen te evalueren en inzicht te hebben in de overwegingen en afwegingen voor elke implementatie.

Hiërarchie op vier niveaus

In het volgende diagram ziet u de hiërarchie met vier niveaus waarmee alle Fabric implementaties worden gedefinieerd.

Download een Visio-bestand van deze architectuur.

De implementatiehiërarchie stroomt van uw Microsoft 365 tenant naar afzonderlijke items. Uw keuze voor het implementatiepatroon bepaalt hoe u elk niveau gebruikt.

• Tenantniveau. Bovenaan staat uw Microsoft 365 tenant, die fungeert als de identiteits- en beheergrens voor uw organisatie. Uw Fabric-tenant bevindt zich binnen deze Microsoft 365 tenant en alle Fabric resources bevinden zich binnen deze ene tenantgrens. Instellingen op tenantniveau, waaronder Microsoft Entra Conditional Access, private-koppelingen en gevoeligheidslabels, zijn van toepassing op alle capaciteiten en werkruimten.

• Capaciteitsniveau. Stel ten minste één Fabric capaciteit in binnen een Microsoft 365 tenant. Elke capaciteit is gebonden aan een specifieke Azure regio en heeft een specifieke F-SKU die de beschikbare rekenresources bepaalt die worden gemeten in capaciteitseenheden (CA's). Capaciteiten bepalen de gegevenslocatie en bieden factureringsgrenzen. Eén capaciteit kan meerdere werkruimten hosten.

• Werkruimteniveau. Elke capaciteit bevat een of meer werkruimten. Werkruimten zijn de primaire containers voor samenwerking en governance. Ze definiëren toegangsbeheer via vier werkruimterollen (Beheerder, Lid, Inzender en Viewer), ondersteunen Git-integratie voor versiebeheer en fungeren als het bereik voor implementatiepijplijnen. Een werkruimte behoort tot één capaciteit tegelijk. Migratie van capaciteit in dezelfde regio is eenvoudig. Migratie tussen regio's is mogelijk, maar u moet de meeste Fabric items verwijderen en opnieuw maken, waaronder lakehouses, magazijnen, notebooks en pijplijnen. Geef daarom de voorkeur aan migratie van dezelfde regio.

• Itemniveau. Werkruimten bevatten Fabric-objecten zoals lakehouses, magazijnen, notebooks, pijplijnen, semantische modellen, rapporten en dashboards. Items nemen standaard werkruimtemachtigingen over. Microsoft OneLake-beveiligingsrollen bieden gedetailleerd toegangsbeheer op tabel-, map-, kolom- en rijniveau, maar ze zijn alleen van toepassing op gebruikers in de rol Viewer. Werkruimtebeheerders, leden en inzenders omzeilen OneLake-beveiligingsrollen.

De volgende beperkingen voor licenties en werkruimtetypen bepalen vaak welk implementatiepatroon het meest praktisch is:

• Nieuwe werkruimten beginnen op gedeelde capaciteit, tenzij u ze opnieuw toewijst. Elke tenant heeft een gedeelde capaciteit die als host fungeert voor Mijn werkruimten en kan Power BI Pro- of PPU-werkruimten (Premium Per User) hosten. Als u een beheerd Fabric-implementatiepatroon voor productieworkloads wilt implementeren, moet u werkruimten doorgaans opnieuw toewijzen aan een toegewezen Fabric capaciteit in de tenant.

• PPU is geen vervanging voor Fabric capaciteit. PPU biedt Power BI Premium-functies per gebruiker, maar bevat geen Fabric capaciteit. Als u niet-Power BI Fabric items zoals lakehouses, magazijnen en notebooks wilt maken of uitvoeren, hebt u een F-capaciteit nodig.

• Het type werkruimte is van invloed op wat het patroon kan hosten. Bij de Fabric-implementatiepatronen in dit artikel wordt ervan uitgegaan dat de Fabric-werkruimtes ondersteund worden door F SKU. A- en EM-SKU's ondersteunen alleen Power BI items, zodat ze geen end-to-end Fabric implementatiepatronen kunnen ondersteunen.

• Power BI viewerlicenties kunnen de kosten van een patroon wijzigen. Op F64 en grotere capaciteiten hebben gebruikers met de rol Kijker toegang tot Power BI inhoud met een gratis licentie. Voor kleinere capaciteiten hebben Power BI gebruikers een Pro-, PPU- of proeflicentie nodig. Deze drempelwaarde kan de kosteneffectiviteit van een gecentraliseerd patroon voor grote lezerspopulaties verminderen.

• Power BI creatie en delen vereist ten minste één Pro- of PPU-gebruiker. Zelfs als een werkruimte gebruikmaakt van Fabric capaciteit, hebben organisaties gebruikers met Pro- of PPU-licenties nodig om Power BI items te maken en te delen.

Components

• Microsoft 365 tenant: Een identiteits- en beheergrens voor uw organisatie. Het host Microsoft Entra ID (voorheen Azure Active Directory) voor verificatie en autorisatie.

• Fabric capaciteit: Een reken- en factureringsresource die wordt gebruikt in een specifieke Azure regio, bijvoorbeeld VS - oost of Europa - west. Als u de kosten wilt verlagen, kunt u capaciteiten onderbreken wanneer deze niet in gebruik zijn.

• Fabric werkruimte: Een samenwerkingscontainer voor Fabric items. Het ondersteunt op rollen gebaseerd toegangsbeheer (RBAC), Git-integratie en implementatiepijplijnen. Voor logische groepering kunt u werkruimten toewijzen aan Fabric domeinen.

• Fabric items: Gegevens- en analyseartefacten zoals lakehouses, datawarehouses, notebooks, pijplijnen, gegevensstromen, semantische modellen, rapporten en dashboards.

• Fabric domains: Logische groeperingen die werkruimten organiseren per bedrijfsunit of onderwerpgebied. Domeinen ondersteunen gedelegeerd beheer en worden weergegeven in de OneLake-catalogus voor detectie en toezicht.

• OneLake: Een uniforme, hiërarchische data lake waar tenants werkruimten bevatten, die items bevatten. Fabric slaat gegevens op in OneLake. OneLake ondersteunt Azure Data Lake Storage API's, snelkoppelingen naar externe opslag en integratie met Data Lake Storage hulpprogramma's, zoals Azure Storage Explorer en AzCopy.

• OneLake-catalogus: Een gecentraliseerde interface voor het zoeken, beheren en beveiligen van Fabric gegevens in de tenant. Gebruikers hebben toegang tot de catalogus met behulp van hulpprogramma's zoals Microsoft Teams, Excel en Microsoft Copilot Studio.

Inzicht in Fabric implementatieniveaus

De structuur, doelstellingen, beveiligingsvereisten, schaal, governancemodel en levenscyclus van toepassingen zijn van invloed op beslissingen op elk implementatieniveau. Zie Hiërarchie met vier niveaus voor meer informatie over elk niveau.

• Capaciteiten bepalen de gegevenslocatie en geografische distributie. Organisaties die op meerdere geografische locaties werken, kunnen capaciteiten in verschillende Azure regio's gebruiken om te bepalen waar gegevens worden opgeslagen. Elke capaciteit is gebonden aan een specifieke Azure regio, die ondersteuning biedt voor meerdere geografische implementaties in verschillende regio's. Om gecentraliseerd beheer te ondersteunen, kunnen Fabric domeinen werkruimten en de bijbehorende capaciteiten in verschillende regio's groeperen.

• Werkruimten fungeren als de primaire governance- en beveiligingsgrens. Elke werkruimte definieert toegangsbeheer via vier rollen, ondersteunt versiebeheer via Git-integratie en fungeert als het bereik voor implementatiepijplijnen. Als u samenwerking en inhoudsdetectie wilt centraliseren, gebruikt u de OneLake-catalogus om een uniforme detectie- en governance-ervaring te implementeren voor de OneLake-gegevens van de tenant. Gebruikers kunnen inhoud vinden en ermee werken vanuit hulpprogramma's zoals Teams en Excel via deze catalogus.

• Elk niveau heeft invloed op de levenscycluskeuzes van toepassingen. Functies zoals implementatiepijplijnen en levenscyclusbeheer zijn niet beschikbaar in patronen met één werkruimte, omdat hiervoor afzonderlijke werkruimten nodig zijn. Organisaties die domeinen gebruiken om werkruimten te groeperen, kunnen beheer op domeinniveau delegeren zonder tenantbeheerdersbevoegdheden, wat van invloed is op de wijze waarop teams releases en governance in bedrijfseenheden beheren.

Algemene patronen voor alle implementaties

Alle Fabric implementatiepatronen delen de volgende fundamentele kenmerken:

• Werkruimten als grenzen voor schaal, governance en beveiliging. Implementatiepatronen gebruiken Fabric werkruimten als primaire eenheid voor itemorganisatie, machtigingen en DevOps-functiebereik. Ongeacht welk patroon u kiest, definiëren werkruimten de grens voor samenwerking en toegangsbeheer.

• Fabric-domeinen voor delegatie over meerdere werkruimten en bedrijfseenheden. Gebruik Fabric domeinen voor delegatie. U kunt meerdere werkruimten beheren die mogelijk deel uitmaken van dezelfde bedrijfseenheid of gegevens beheren die deel uitmaken van een bedrijfsdomein en meer dan één werkruimte omvatten. Als u gegevens op domeinniveau wilt beheren en beheren, kunt u instellingen op tenantniveau aanpassen en een domeinspecifieke configuratie voor deze instellingen gebruiken.

• Capaciteiten voor het schalen van rekenkracht met toegewezen capaciteit per werkruimte voor prestatiegaranties. Als u aan specifieke prestatieniveaus moet voldoen, gebruikt u Fabric capaciteiten om rekenresources te schalen en toegewezen capaciteiten per werkruimte te bieden. Organisaties die workloadisolatie nodig hebben voor prestatiegevoelige taken, kunnen deze werkruimten toewijzen aan een afzonderlijke capaciteit met een gegarandeerde CU-toewijzing.

• OneLake-catalogus voor assetdetectie en het tabblad Beveiligen voor gegevensbeveiligingsbeleid. Gebruik de OneLake-catalogus om ontdekking en het gebruik van gegevens in uw tenant te bevorderen. Als u beveiligingsrollen in werkruimten en items wilt weergeven, bewaken en configureren, gebruikt u het tabblad Beveiligen in de OneLake-catalogus.

• Extensie voor Microsoft Cloud functies als systeemeigen Fabric functies niet beschikbaar zijn. Als een systeemeigen functie niet beschikbaar is, kunnen implementatiepatronen worden uitgebreid naar equivalente functies uit de Microsoft Cloud, zoals Azure en Microsoft 365. Organisaties kunnen bijvoorbeeld Azure Pipelines of GitHub Actions gebruiken voor CI/CD-orchestratie (continue integratie en continue levering) als Fabric implementatiepijplijnen niet voldoen aan hun behoeften aan automatisering voor meerdere werkruimten. Organisaties kunnen ook Microsoft Purview gebruiken voor gegevensbeheer in de hele onderneming die Fabric en niet-Fabric gegevensbronnen omvat.

Een implementatiepatroon selecteren

In de volgende scenario's worden algemene bedrijfsvereisten en de implementatiepatronen beschreven die hierop betrekking hebben. Gebruik deze scenario's om het patroon te identificeren dat het beste bij uw organisatie past.

• Scenario 1: Snellere markttijd met samenwerking tussen teams. Als uw organisatie sneller op de markt wil komen, samenwerking tussen teams en lagere beperkingen voor gegevensgebruik, kunt u een monolithisch implementatiepatroon implementeren. In dit scenario werkt uw organisatie in en beheert één werkruimte.

  Patroon 1 gebruiken: Monolithische implementatie.

• Scenario 2: Geïsoleerde teamomgevingen met centraal infrastructuurbeheer. Als uw organisatie geïsoleerde teamomgevingen en een centraal infrastructuurbeheerteam wil bieden, kunt u meerdere werkruimten implementeren die gebruikmaken van een gedeelde capaciteit of afzonderlijke capaciteiten. Dit scenario is ook geschikt voor organisaties die een data mesh-architectuur willen implementeren.

  Gebruik Patroon 2: Meerdere werkruimten, één capaciteit of Patroon 3: Meerdere werkruimten, afzonderlijke capaciteiten.

• Scenario 3: Volledige bedrijfseenheidautonomie over gegevensplatformen. Als uw organisatie een volledig gedecentraliseerd model wil dat bedrijfseenheden of teams de vrijheid biedt om hun eigen gegevensplatformen te beheren en beheren, kunt u een implementatiemodel implementeren dat gebruikmaakt van eparate werkruimten met toegewezen capaciteit of meerdere Fabric tenants.

  Gebruik Pattern 3: Meerdere werkruimten, afzonderlijke capaciteiten of Pattern 4: Meerdere Fabric-huurders.

• Scenario 4: Hybride benadering die meerdere patronen combineert. Als uw organisatie een hybride oplossing wil die gebruikmaakt van meerdere patronen om te voldoen aan de vereisten, kunt u een hybride benadering implementeren. U kunt bijvoorbeeld één werkruimte instellen voor specifieke bedrijfseenheden, zoals in een monolithisch implementatiepatroon, en afzonderlijke, toegewezen werkruimten en afzonderlijke capaciteiten voor andere bedrijfseenheden.

Patroon 1: Monolithische implementatie

In dit implementatiepatroon wijst u één werkruimte toe voor alle use cases. Alle bedrijfseenheden werken binnen dezelfde werkruimte.

De volgende kenmerken zijn van toepassing op dit patroon:

• Fabric items dezelfde capaciteit delen. De tijd die een query of taak kost, is afhankelijk van de andere workloads die dezelfde capaciteit gebruiken.

• Maximale werkruimte-CU's zijn beperkt tot de grootst mogelijke F-SKU. Voor data engineering- en data science-ervaring kunnen capaciteitsbeheerders Autoscale Facturering voor Apache Spark configureren om de rekencapaciteit van de Spark-engine buiten de toegewezen CU's te verplaatsen.

• Functies die zijn afgestemd op een werkruimte, zijn van toepassing op alle bedrijfseenheden die de werkruimte delen.

• Alle werkruimte-items en -gegevens bevinden zich in één regio. U kunt dit patroon niet gebruiken voor scenario's met meerdere geografische regio's.

• Functies die afhankelijk zijn van meerdere werkruimten zijn niet beschikbaar, bijvoorbeeld implementatiepijplijnen en levenscyclusbeheer.

• Beperkingen voor één werkruimte zijn van toepassing.

• Er gelden specifieke SKU-capaciteitsbeperkingen.

Wanneer gebruikt u dit patroon?

U kunt dit implementatiepatroon implementeren als:

• Uw organisatie heeft geen complexe technische vereisten, heeft een kleine gebruikersbasis of heeft kleine semantische modellen.

• Uw organisatie werkt in één regio.

• U houdt zich niet voornamelijk bezig met de scheiding van de organisatie tussen bedrijfseenheden.

• Uw organisatie vereist geen functies binnen het bereik van de werkruimte, zoals het delen van codeopslagplaatsen met Git.

• U wilt een lakehouse-medaillonarchitectuur implementeren. Als uw organisatie gebruikmaakt van één werkruimte, kunt u afzonderlijke lakehouses binnen de werkruimte maken om brons-, zilver- en goudlagen te beheren.

• De bedrijfseenheden van uw organisatie delen rollen en u kunt dezelfde machtigingen op werkruimteniveau hebben voor gebruikers in de werkruimte. Als meerdere gebruikers uit verschillende bedrijfseenheden bijvoorbeeld beheerders van één werkruimte zijn, hebben ze dezelfde rechten voor alle items in de werkruimte.

• Uw organisatie tolereert de voltooiingstijden van variabele taken. Als een capaciteit wordt gedeeld, kunnen gebruikers op elk gewenst moment query's uitvoeren. Het aantal beschikbare CU's om een taak uit te voeren hangt af van de andere query's die op de capaciteit worden uitgevoerd, wat kan leiden tot variabele tijden voor taakvoltooiing.

• Uw organisatie kan voldoen aan de bedrijfsvereisten van de CU door gebruik te maken van één Fabriccapaciteit.

Overwegingen voor ontwerpgebied

De volgende tabel bevat overwegingen die van invloed kunnen zijn op uw beslissing om dit implementatiepatroon te gebruiken.

Patroon 2: Meerdere werkruimten, één capaciteit

In dit implementatiepatroon wijst u meerdere werkruimten toe aan één gedeelde capaciteit. Werkruimten delen die capaciteit, zodat gelijktijdige workloads van invloed kunnen zijn op de prestaties van taken en interactieve query's.

De volgende kenmerken zijn van toepassing op dit patroon:

• Fabric items dezelfde capaciteit delen. De tijd die een query of taak kost, is afhankelijk van de andere workloads die dezelfde capaciteit gebruiken.

• Maximale werkruimte-CU's zijn beperkt tot de grootst mogelijke F-SKU. Voor data engineering- en data science-ervaringen kunnen capaciteitsbeheerders Facturering voor Spark automatisch schalen configureren om de rekencapaciteit te verplaatsen die door de Spark-engine buiten de toegewezen CA's wordt gebruikt.

• Functies die zijn afgestemd op een werkruimte, zijn van toepassing op alle bedrijfseenheden die die werkruimte delen.

• Alle werkruimte-items en -gegevens bevinden zich in één regio. U kunt dit patroon niet gebruiken voor scenario's met meerdere geografische regio's.

• U kunt DevOps-functies gebruiken die afzonderlijke werkruimten vereisen, zoals implementatiepijplijnen en levenscyclusbeheer.

• Beperkingen voor één werkruimte zijn van toepassing.

• Er gelden specifieke SKU-capaciteitsbeperkingen.

Wanneer gebruikt u dit patroon?

U kunt dit implementatiepatroon implementeren als:

• U wilt een hub-spoke-architectuur die enkele aspecten van de analyseomgevingsbewerking centraliseert en andere decentraliseert.

• U wilt variabele operationele en beheerdecentralisatie. Uw organisatie kan bijvoorbeeld de brons- en zilverlagen van een medaille-architectuur in één werkruimte hosten en de gouden laag in een afzonderlijke werkruimte hosten. Deze scheiding weerspiegelt vaak verschillende operationele verantwoordelijkheden, bijvoorbeeld waarbij één team de brons- en zilverlagen beheert en een ander team de gouden laag beheert.

• U maakt zich niet voornamelijk zorgen over prestatiebeheer en workloadisolatie.

• Uw organisatie hoeft geen workloads te implementeren in verschillende geografische regio's. Alle gegevens moeten zich in één regio bevinden.

• Uw organisatie vereist mogelijk afzonderlijke werkruimten omdat:

  • Leden van het team dat verantwoordelijk is voor workloads bevinden zich in verschillende werkruimten.

  • U wilt afzonderlijke werkruimten maken voor elk type workload. U kunt bijvoorbeeld een werkruimte maken voor gegevensopname, zoals gegevenspijplijnen, gegevensstromen of data engineering, en een afzonderlijke werkruimte voor verbruik via een datawarehouse. Dit ontwerp werkt goed als afzonderlijke teams verantwoordelijk zijn voor elke workload.

  • U wilt een data mesh-architectuur implementeren waarmee een of meer werkruimten worden gegroepeerd in een Fabric domein.

• Uw organisatie kan afzonderlijke werkruimten implementeren op basis van gegevensclassificatie.

Overwegingen voor ontwerpgebied

De volgende tabel bevat overwegingen die van invloed kunnen zijn op uw beslissing om dit implementatiepatroon te gebruiken.

Patroon 3: Meerdere werkruimten, afzonderlijke capaciteiten

In dit implementatiepatroon wijst u meerdere werkruimten toe aan afzonderlijke Fabric capaciteiten, wat governance- en prestatieisolatie tussen bedrijfseenheden biedt.

De volgende kenmerken zijn van toepassing op dit patroon:

• De grootst mogelijke F SKU of P SKU die is gekoppeld aan een werkruimte bepaalt het maximum aantal CU's dat een werkruimte kan gebruiken.

• Afzonderlijke werkruimten zorgen voor organisatie- en beheer-decentralisatie.

• Organisaties kunnen buiten één regio schalen met behulp van capaciteiten en werkruimten in verschillende geografische regio's.

• U kunt de volledige mogelijkheden van Fabric gebruiken, omdat bedrijfseenheden meerdere werkruimten in afzonderlijke capaciteiten kunnen hebben en kunnen worden gegroepeerd via Fabric domeinen.

• Werkruimtebeperkingen voor één werkruimte zijn van toepassing, maar u kunt nieuwe werkruimten maken om buiten deze limieten te schalen.

• Specifieke SKU-capaciteitsbeperkingen zijn van toepassing, maar u kunt CU's schalen met behulp van afzonderlijke capaciteiten.

• U kunt de OneLake-catalogus gebruiken om Fabric items en de bijbehorende certificeringsstatussen te ontdekken.

• Domeinen kunnen werkruimten groeperen, zodat één bedrijfseenheid meerdere werkruimten kan gebruiken en beheren.

• Met OneLake-snelkoppelingen worden fysieke kopieën van gegevens geëlimineerd om de verplaatsing van gegevens te verminderen. OneLake-snelkoppelingen bieden ook beheerde toegang tussen werkruimten via OneLake en dragen geen eigendom van de onderliggende gegevens over.

Wanneer gebruikt u dit patroon?

U kunt dit implementatiepatroon implementeren als:

• Uw organisatie wil frameworks voor architectuur zoals data mesh of data fabric implementeren.

• U wilt prioriteit geven aan flexibiliteit in de structuur van capaciteiten en werkruimten.

• U werkt in verschillende geografische regio's. In dit geval maakt u een afzonderlijke capaciteit en werkruimte aan om naar een implementatiepatroon met meerdere capaciteiten en werkruimten toe te werken.

• U werkt op grote schaal en hebt vereisten om te schalen buiten de limieten van een SKU met één capaciteit of één werkruimte.

• U hebt workloads die altijd binnen een bepaalde tijd moeten worden voltooid of die moeten voldoen aan op prestaties gebaseerde SLO's. U kunt een afzonderlijke, door Fabric-capaciteit ondersteunde werkruimte instellen om te voldoen aan SLO's voor die workloads.

Overwegingen voor ontwerpgebied

De volgende tabel bevat overwegingen die van invloed kunnen zijn op uw beslissing om dit implementatiepatroon te gebruiken.

Patroon 4: Meerdere Fabric-gebruikers

In dit implementatiepatroon zijn alle exemplaren van Fabric afzonderlijke entiteiten met betrekking tot governance, beheer, beheer, schaal en opslag.

De volgende kenmerken zijn van toepassing op dit patroon:

• Tenantresources worden strikt gescheiden.

• Beheervlakken tussen tenants zijn gescheiden.

• Tenants zijn afzonderlijke entiteiten, elk met eigen governance- en beheerprocessen en elk afzonderlijk beheerd.

• U kunt data pipelines of data engineering functies gebruiken om gegevens te delen of erop toegang te krijgen tussen Fabric tenants.

Wanneer gebruikt u dit patroon?

U kunt dit implementatiepatroon implementeren als:

• Uw organisatie heeft meerdere Fabric tenants vanwege een zakelijke overname.

• Uw organisatie wil een Fabric tenant specifiek instellen voor een bedrijfseenheid of een kleinere dochteronderneming.

Alternatieve platforms evalueren

Als de vereisten van uw organisatie niet overeenkomen met op Fabric gebaseerde implementatiemodellen, kunt u de volgende beperkte alternatieven overwegen:

• Azure Data Factory met Data Lake Storage of OneLake, waaronder hybride Data Factory- en Fabric-architecturen

  Organisaties die expliciet indelingsbeheer of gefaseerde modernisering nodig hebben, kunnen gebruikmaken van Data Factory voor opname en pijplijnindeling en Data Lake Storage als de opslagbasis. In een hybride model kunnen door Data Factory beheerde gegevenspijplijnen gegevens laden in OneLake terwijl Fabric het maken van analytische gegevensassets beheert. Deze aanpak ondersteunt incrementele acceptatie van Fabric en behoudt gevestigde integratiepatronen.

• Data Lake Storage, Azure Databricks en Power BI

  Organisaties die de voorkeur geven aan een PaaS-architectuur (Platform as a Service) in plaats van een SaaS-platform (Software as a Service), kunnen een gegevensdomein bouwen met behulp van Data Lake Storage voor opslag, Azure Databricks voor data engineering en analyses, en Power BI voor semantische modellering en rapportage. Deze aanpak biedt maximale controle en flexibiliteit, maar vereist meer integratie-inspanning en verhoogt de operationele complexiteit en governance-overhead.

Overwegingen

Met deze overwegingen worden de pijlers van het Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die u kunt gebruiken om de kwaliteit van een workload te verbeteren. Zie het Well-Architected Framework voor meer informatie.

In de tabellen per patroon eerder in dit artikel worden ontwerpgebieden gebruikt die specifiek zijn voor Fabric implementatiebeslissingen, zoals governance, beveiliging, beheer, DevOps, bruikbaarheid, prestaties en facturering. De volgende subsecties bieden aanvullende richtlijnen die zijn georganiseerd door Well-Architected Framework-pijler. Gebruik de tabellen per patroon om patronen te vergelijken. Gebruik deze subsecties voor kruislingse architectuurrichtlijnen die van toepassing zijn, ongeacht welk patroon u kiest.

Reliability

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie Ontwerp controlelijst voor betrouwbaarheid voor meer informatie.

• Ingebouwde regionale veerkracht. Fabric biedt ingebouwde regionale tolerantie via beschikbaarheidszones, waar ondersteund. Fabric automatisch resources distribueert over meerdere zones zonder klantconfiguratie. Ondersteuning voor beschikbaarheidszones verschilt per Azure regio. Zie Fabric regio-beschikbaarheid om te controleren of uw doelregio beschikbaarheid voor Fabric ondersteunt.

• Noodherstel (DR) vereist opt-in en heeft kanttekeningen. Herstel tussen regio's is beschikbaar via een opt-in DR-instelling op de pagina capaciteitsinstellingen. Schakel de DR-capaciteit instelling in om OneLake-gegevens te repliceren in Azure-gekoppelde regio's met behulp van asynchrone replicatie.

  Belangrijk

  Sommige Azure-regio's zijn niet gekoppeld aan regio's die Fabric ondersteunen, waardoor de disaster recovery-capaciteiten kunnen worden aangetast, zelfs als gegevens worden gerepliceerd. Omdat gegevensreplicatie asynchroon is, kunnen gegevens die direct voor een regionale ramp worden geschreven, verloren gaan. Zie Reliability in Fabric voor meer informatie.

• Patronen met enkele capaciteit concentreren risico in één regio. In patronen 1 en 2 bevinden workloads zich in één Azure regio. Als de regio een storing ondervindt, worden alle werkruimten tegelijkertijd beïnvloed. Als u wilt beschermen tegen regionale fouten, configureert u de capaciteitsinstelling om OneLake-gegevens te repliceren naar een gekoppelde regio. Plan de hersteltijd die nodig is om de service in de gekoppelde regio te herstellen.

• Multicapaciteitspatronen bieden natuurlijke regionale isolatie. In patronen 3 en 4 betekent capaciteit in verschillende regio's dat een regionale storing alleen van invloed is op de capaciteiten in die regio. Workloads in andere regio's blijven doorgaan. Deze patronen ondersteunen vereisten voor gegevensresidentie en bieden de basis voor actief-passieve of actief-actieve regionale strategieën.

• Capaciteit pauzeren is van invloed op de betrouwbaarheid. Als u een Fabric-capaciteit pauzeert om de kosten te verlagen, zijn alle workloads op deze capaciteit niet meer beschikbaar. Houd rekening met het betrouwbaarheidseffect voordat u een capaciteit onderbreekt die productieworkloads ondersteunt.

• OneLake-snelkoppelingen introduceren externe afhankelijkheden. Snelkoppelingen naar externe gegevensbronnen leiden tot afhankelijkheid van de beschikbaarheid van bronnen. Als de externe bron niet beschikbaar is, kunnen items die afhankelijk zijn van snelkoppelingen mislukken. Bewaken de gezondheid van externe gegevensbronnen en plan voor gradiële degradatie.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Ontwerpcontrolelijst voor beveiliging voor meer informatie.

• Het gelaagde beveiligingsmodel omvat drie niveaus. Fabric implementeert een gelaagd beveiligingsmodel dat de tenant-, werkruimte- en itemniveaus omvat. Uw keuze voor het implementatiepatroon bepaalt hoe u beveiligingsgrenzen segmenteren. Patronen met één werkruimte, zoals patroon 1, dwingen uniforme toegang af. Multiworkspace-patronen, zoals patronen 2, 3 en 4, ondersteunen beveiligingsgrenzen per team of per bedrijfseenheid.

Identiteit en toegang

• Dwing verificatiebeleid op tenantniveau af met behulp van voorwaardelijke toegang. Gebruik Voorwaardelijke toegang om verificatiebeleid op tenantniveau af te dwingen, zoals meervoudige verificatie, apparaatnaleving en locatiegebaseerde beperkingen. Voor voorwaardelijke toegang is een Microsoft Entra ID P1-licentie vereist.

• Werkruimterollen gebruiken om de toegang tot items te beheren. Wijs werkruimterollen toe om te bepalen wie items in een werkruimte kan maken, bewerken en gebruiken. Gebruik in multiworkspace-patronen, zoals patronen 2, 3 en 4, afzonderlijke werkruimten om rolgrenzen tussen bedrijfseenheden af te dwingen.

• Pas gedetailleerde toegang op gegevensniveau toe met behulp van OneLake-beveiligingsrollen. Gebruik OneLake-beveiligingsrollen om gedetailleerd toegangsbeheer toe te passen op tabel-, map-, kolom- en rijniveau voor gebruikers in de rol Viewer. Werkruimtebeheerders, leden en inzenders omzeilen deze rollen.

Netwerkbeveiliging

• Gebruik privékoppelingen voor binnenkomend verkeer. Gebruik private-koppelingen om inkomend verkeer via de Microsoft backbone te routeren in plaats van via het openbare internet. Privékoppelingen op tenantniveau zijn van toepassing op alle werkruimten. Privékoppelingen op werkruimteniveau bieden granulariteit per werkruimte.

• Beheerde privé-eindpunten gebruiken voor uitgaande Spark-verbindingen. Gebruik beheerde privé-eindpunten om uitgaande verbindingen van Spark-workloads naar met firewall beveiligde gegevensbronnen te beveiligen, zoals Data Lake Storage en Azure SQL Database.

• Gebruik gegevensgateways voor virtuele netwerken wanneer privékoppelingen op tenantniveau on-premises gateways blokkeren. Wanneer u privékoppelingen op tenantniveau inschakelt, kunnen on-premises gegevensgateways zich niet registreren. Gebruik een gegevensgateway voor een virtueel netwerk in plaats van bruggen die on-premises of door een virtueel netwerk beschermde gegevensbronnen verbinden.

Gegevensbescherming

• Vertrouwelijkheidslabels toepassen voor end-to-end gegevensclassificatie. Pas voor gegevensclassificatie en -beveiliging gevoeligheidslabels van Microsoft Purview Information Protection toe op gegevens die door Fabric stromen. Labels volgen de gegevens van de bron naar het rapport.

• Gebruik auditlogboeken en hulpprogramma's voor naleving voor het afdwingen van beleid. Als u beleidsschendingen wilt detecteren en erop wilt reageren, raadpleegt u auditlogboeken en gebruikt u Microsoft Purview Compliance Manager.

Kostenoptimalisatie

Kostenoptimalisatie richt zich op manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie controlelijst ontwerpbeoordeling voor kostenoptimalisatievoor meer informatie.

• Modelkosten voordat u implementeert. Implementatiepatronen zijn van invloed op uw kostenstructuur. Modelkosten voor uw scenario met behulp van Fabric prijzen en de Fabric capaciteitsschatter.

• Pas uw capaciteits-SKU aan. Berecht uw F-SKU op basis van de vraag naar werkbelasting. Begin met een kleinere SKU en schaal zo nodig omhoog. Bewaak het verbruik en identificeer overingerichte of minder ingerichte capaciteiten met behulp van de app Fabric Capacity Metrics.

• Automatiseer het onderbreken van capaciteit voor niet-productieomgevingen. Verlaag de kosten door F SKU-capaciteiten te onderbreken wanneer ze niet in gebruik zijn. Pauzeer capaciteiten buiten werkuren in ontwikkel-/testomgevingen. Onderbreken maakt alle workloads niet beschikbaar, dus overweeg automatisering via Azure Resource Manager Fabric API's of geplande pijplijnen.

• Patronen met één capaciteit, zoals patronen 1 en 2, centraliseren de facturering, maar beperk de terugstorting. Eén capaciteit betekent één factuur. Kostenbeheer is gecentraliseerd, maar terugstorting naar afzonderlijke bedrijfseenheden is niet mogelijk omdat alle workloads dezelfde capaciteit delen.

• Multicapaciteitspatronen, zoals patronen 3 en 4, bieden ondersteuning voor terugstorting per team. Elke capaciteit genereert een eigen Azure factureringsmeter. U kunt kosten in rekening brengen voor de bedrijfseenheid die verantwoordelijk is voor elke capaciteit. U kunt elke capaciteit onafhankelijk aanpassen of onderbreken op basis van de ondersteunde workload.

• Beheer de opslagkosten van OneLake onafhankelijk. OneLake-opslag wordt gefactureerd tegen een gebruikstarief per GB en verbruikt geen CUs. Verwijder regelmatig ongebruikte gegevens, inclusief voorlopig verwijderde gegevens, en bewaak de opslag via de app Fabric Capacity Metrics.

• Spark-berekening afzonderlijk bewaken. Voor data engineering-workloads kunt u afzonderlijke Spark-pools gebruiken om rekenkracht buiten het CU-budget te verplaatsen. Als u onverwachte kosten wilt voorkomen, controleert u het Spark CU-verbruik.

Operationele uitmuntendheid

Operational Excellence behandelt de operationele processen die een toepassing implementeren en deze in productie houden. Voor meer informatie, zie Controlelijst voor ontwerpevaluatie voor Operational Excellence.

• Implementatiepijplijnen gebruiken voor gefaseerde promotie. Gebruik Fabric-implementatiepijplijnen om inhoud te promoten via ontwikkelings-/test- en productiefasen. Implementatiepijplijnen vereisen afzonderlijke werkruimten, zodat ze niet beschikbaar zijn in patroon 1. Maak in patronen 2, 3 en 4 toegewezen werkruimten voor elke DTAP-fase. Capaciteitsstrategie verschilt per patroon.

  • In patroon 2 delen alle DTAP-werkruimten dezelfde capaciteit, wat rendabel is, maar geen prestatie-isolatie tussen omgevingen biedt.

  • In patroon 3 kunt u toegewezen capaciteiten per omgeving gebruiken voor volledige isolatie, of u kunt kosten en isolatie verdelen met behulp van een gedeelde capaciteit voor ontwikkelen/testen met een afzonderlijke productiecapaciteit.

• Plan preproductieomgevingen als ontwerpbeslissing op werkruimteniveau. Patroon 1 biedt geen preproductiescheiding omdat dev/test plaatsvindt in de productiewerkruimte. Patroon 2 ondersteunt afzonderlijke ontwikkel-, test- en productiewerkruimten op één gedeelde capaciteit, die geschikt is voor functionele validatie, maar niet voor productie- of tolerantietests. Patroon 3 ondersteunt productie-achtige preproductievalidatie via werkruimten die zijn afgestemd op de omgeving met isolatie op capaciteitsniveau. Patroon 4 omvat afzonderlijke tenants in plaats van beslissingen op werkruimteniveau. Elke tenant kan onafhankelijk een eigen omgevingstopologie kiezen en hoeft niet overeen te komen met andere tenants.

• Verbind werkruimten met Git-opslagplaatsen voor broncodebeheer. In patronen 2 en 3 zijn afzonderlijke werkruimten per team of workload afgestemd op standaardvertakkingsstrategieën. In patroon 1 delen alle teams één opslagplaats, wat tot samenvoegingsconflicten kan leiden.

• De capaciteit en werkbelasting monitoren. Gebruik de app Fabric Capacity Metrics om het capaciteitsverbruik te bewaken, zoals CU-gebruik, throttling, en overschrijdingen. U hebt toegang tot gedetailleerde telemetrie over afzonderlijke workloads met behulp van werkruimtebewaking. In patronen met meerdere capaciteiten, zoals patronen 3 en 4, kunt u bewaking delegeren aan het team dat verantwoordelijk is voor elke capaciteit.

• Beheer delegeren via Fabric domeinen. In patronen 2 en 3 delegeert u tenantinstellingen en werkruimtebeheer aan beheerders op domeinniveau zonder tenantbeheerdersbevoegdheden met behulp van Fabric-domeinen. Patroon 1 kan geen domeinen gebruiken omdat alle items zich in één werkruimte bevinden.

• Capaciteiten beheren met infrastructuur als code (IaC). Maak en beheer Fabric capaciteiten met behulp van Bicep of Terraform. Sla infrastructuurdefinities op in broncodebeheer naast toepassingscode.

Prestatie-efficiëntie

Prestatie-efficiëntie verwijst naar de mogelijkheid van uw workload om efficiënt te voldoen aan de behoeften van de gebruiker. Zie controlelijst ontwerpbeoordeling voor prestatie-efficiëntievoor meer informatie.

• Inzicht in capaciteitsbepaling en begrenzingsgedrag. Elke capaciteit heeft een vaste CU-toewijzing die wordt bepaald door de SKU. Als de vraag groter is dan de beschikbare CU's, past Fabric beperking toe en worden verzoeken in een wachtrij geplaatst. Bewaak throttling-evenementen met behulp van de Fabric Capacity Metrics-app en vergroot de SKU-capaciteit of verdeel workloads indien nodig over meerdere capaciteiten.

• Prestatiegevoelige workloads isoleren op een toegewezen capaciteit. In patronen 1 en 2 concurreren alle workloads voor dezelfde CU's. Een dure query of gegevenspijplijn kan de prestaties van interactieve query's voor andere gebruikers verminderen. In patronen 3 en 4 kunt u prestatiekritische workloads isoleren op een toegewezen capaciteit met een gegarandeerde CU-toewijzing.

• Spark-pools configureren voor data engineering-workloads. Voor data engineering-workloads gebruikt u aangepaste Spark-pools om het minimum- en maximumaantal knooppunten te beheren en automatische schaalaanpassing te ondersteunen. Beheerde virtuele netwerken schakelen starterspools of vooraf beheerde gedeelde clusters uit, waardoor de starttijd van de sessie tussen 3 en 5 minuten wordt verhoogd.

• Plaats capaciteiten dicht bij gegevensproducenten en consumenten. In patroon 3 kunt u capaciteiten gebruiken in regio's dicht bij gegevensproducenten of consumenten, waardoor de latentie tussen regio's wordt verminderd. OneLake-snelkoppelingen kunnen verwijzen naar gegevens in andere regio's, maar leesbewerkingen tussen regio's brengen latentie- en uitgaande kosten met zich mee.

• Werkbelastingspecifieke optimalisatietechnieken toepassen. Verbeter de scanprestaties met Z-Ordering en V-Ordering voor lakehouses. Voor magazijnen optimaliseert u querypatronen om kleinere batches te lezen. Verminder de capaciteitsbelasting in vergelijking met de importmodus met behulp van Direct Lakemodus voor Power BI-rapporten.

Mogelijkheidsmatrix

De volgende tabellen geven een overzicht van de belangrijkste verschillen in de mogelijkheden van elk patroon.

Governance en beheer

¹ Werkruimten bieden enige isolatie, maar alle werkruimten delen één capaciteit, waardoor de granulariteit van het bijhouden en beheren van gebruik wordt beperkt.

² Patroon 4 maakt gebruik van afzonderlijke tenants in plaats van domeinen. Elke tenant heeft een eigen beheermodel.

Beveiliging

DevOps en levenscyclusbeheer

³ Implementatiepijplijnen vereisen afzonderlijke werkruimten, die niet beschikbaar zijn in een monolithisch patroon voor één werkruimte.

^{4 Git-integratie} is beschikbaar, maar alle teams delen een enkele opslagplaats, wat het risico op samenvoegingsconflicten vergroot.

Prestatie en schaal

⁵ Beperkingsrisico is laag als workloads zich op toegewezen capaciteiten bevinden, maar beperking kan nog steeds plaatsvinden binnen één capaciteit als de vraag de beschikbare CU's overstijgt.

Facturering en kostenbeheer

⁶ Elke capaciteit genereert een eigen factureringsmeter, dus facturering wordt verdeeld over capaciteiten in plaats van gecentraliseerd.

Bijdragers

Microsoft dit artikel onderhoudt. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

• Amanjeet Singh | Principal Program Manager

Andere Inzenders:

• Lorrin Ferdinand | Hoofdadviseur
• Holly Kelly | Senior Programma Manager
• Gabi Münster | Senior programmamanager
• Sarah Sasidharan | Senior Program Manager

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen 

• Fabric concepten en licenties
• Fabric werkruimten
• Fabric domeinen
• Wat is OneLake?
• Fabric-implementatiepijplijnen
• Betrouwbaarheid in Fabric
• Fabric beveiligingsoverzicht

Gerelateerde bronnen

• Overzicht van technologiekeuzen
• Analytics eind-tot-eind met Fabric
• Enterprise business intelligence met Fabric
• Bouw een greenfield lakehouse met Fabric