In dit artikel worden vier implementatiepatronen beschreven waaruit u kunt kiezen wanneer u Microsoft Fabric implementeert. Meer informatie over overwegingen, aanbevelingen en potentiële niet-omkeerbare beslissingen voor elk implementatiepatroon.
De volgende ontwerpgebieden worden beschreven voor elk infrastructuurimplementatiepatroon:
- Beheer
- Beveiliging
- Beheer
- DevOps
- Bruikbaarheid
- Prestaties en schaal
- Facturering en kostenbeheer
Niveaus in een Infrastructuurimplementatie
Een Infrastructuurimplementatie heeft vier niveaus: tenant, capaciteit, werkruimte en item. Op het hoogste niveau is de Fabric-tenant. Elke tenant kan een of meer capaciteiten hebben, elke capaciteit kan een of meer werkruimten bevatten en elke werkruimte kan nul of meer Fabric-items bevatten.
De structuur of doelstellingen van een organisatie op het gebied van beveiliging, schaal, governance en toepassingslevenscyclus kunnen van invloed zijn op de keuze van het implementatiepatroon. Verschillende implementatiepatronen bieden verschillende flexibiliteit en nadruk op de niveaus van een implementatie.
Een organisatie kan bijvoorbeeld domeinen gebruiken om werkruimten in Fabric te groeperen. En als een organisatie een gecentraliseerde optie moet hebben die het kan gebruiken om samen te werken en inhoud te vinden, biedt een OneLake-gegevenshub in Fabric een gecentraliseerd toegangspunt en is geïntegreerd met andere vertrouwde producten, zoals Microsoft Teams en Excel.
In Fabric kan een grote organisatie met bedrijfseenheden op afzonderlijke geografische locaties capaciteiten gebruiken om te bepalen waar de gegevens zich bevinden. Het kan een bedrijfseenheid beheren die werkt vanaf een andere geografische locatie als één eenheid met behulp van Fabric-domeinen, omdat domeinen werkruimten in verschillende regio's kunnen omvatten.
Zie Microsoft Fabric-concepten en -licenties voor meer informatie over Fabric-niveaus en hun rol bij het kiezen van een implementatiepatroon.
Hoe infrastructuurimplementatiepatronen worden uitgelijnd
Alle infrastructuurimplementatiepatronen:
- Gebruik Fabric-werkruimten als grenzen voor schalen, governance en beveiliging.
- Gebruik Fabric-domeinen voor delegatie om meerdere werkruimten te beheren die mogelijk deel uitmaken van dezelfde bedrijfseenheid of wanneer gegevens die deel uitmaken van een bedrijfsdomein meer dan één werkruimte omvatten. U kunt bepaalde instellingen op tenantniveau instellen voor het beheren en beheren van gegevens op domeinniveau en domeinspecifieke configuratie gebruiken voor deze instellingen.
- Gebruik Fabric-capaciteiten om rekenresources te schalen tijdens het inrichten van toegewezen capaciteiten per werkruimte wanneer aan specifieke prestatieniveaus moet worden voldaan.
- Breid het gebruik van equivalente functies uit een Microsoft-cloud (Microsoft Azure, Microsoft 365 en andere) uit wanneer een functie niet beschikbaar is in Fabric.
- Gebruik een OneLake-gegevenshub om detectie en het gebruik van gegevensassets te promoten.
- Gebruik OneSecurity om beleidsregels voor gegevensbeveiliging in te stellen voor gegevensassets.
Scenario's op basis van bedrijfsvereisten
In dit artikel worden de volgende scenario's gebruikt om te beschrijven hoe elk implementatiepatroon kan voldoen aan verschillende bedrijfsvereisten:
- Scenario 1: Voor organisaties die sneller (of trager) op de markt willen zijn door teams te organiseren die kunnen samenwerken, met lagere beperkingen voor gegevensgebruik. In dit scenario kan een organisatie profiteren van een monolithisch implementatiepatroon. De organisatie werkt in en beheert één werkruimte. Zie Patroon 1: Monolithische implementatie voor meer informatie.
- Scenario 2: Voor organisaties die geïsoleerde omgevingen willen bieden waarin teams kunnen werken, met een centraal team dat verantwoordelijk is voor het leveren en beheren van infrastructuur. Dit scenario is ook geschikt voor organisaties die data mesh willen implementeren. In dit scenario kan een organisatie meerdere werkruimten implementeren die gebruikmaken van een gedeelde capaciteit of afzonderlijke capaciteiten hebben. Zie Patroon 2: Meerdere werkruimten die worden ondersteund door één Infrastructuurcapaciteit en Patroon 3 voor meer informatie: Meerdere werkruimten die worden ondersteund door afzonderlijke capaciteiten.
- Scenario 3: Voor organisaties die een volledig gedecentraliseerd model willen dat bedrijfseenheden of teams de vrijheid biedt om hun eigen gegevensplatformen te beheren en beheren. In dit scenario kan een organisatie een implementatiemodel kiezen waarin afzonderlijke werkruimten worden gebruikt, elk met toegewezen capaciteit of mogelijk met meerdere Fabric-tenants. Zie Patroon 3: Meerdere werkruimten die worden ondersteund door afzonderlijke capaciteiten en Patroon 4: Meerdere fabric-tenants voor meer informatie.
- Scenario 4: Een organisatie kan ervoor kiezen om een hybride benadering te gebruiken waarin meerdere patronen worden gecombineerd om de vereisten te realiseren. Een organisatie kan bijvoorbeeld één werkruimte instellen voor specifieke bedrijfseenheden (een monolithisch implementatiepatroon) tijdens het gebruik van afzonderlijke, toegewezen werkruimten en afzonderlijke capaciteiten voor andere bedrijfseenheden.
Patroon 1: Monolithische implementatie
In dit implementatiepatroon richt u één werkruimte in voor al uw gebruiksvoorbeelden. Alle bedrijfseenheden werken binnen dezelfde, enkele werkruimte.
Wanneer u één Infrastructuurcapaciteit inricht en er één werkruimte aan koppelt, zijn de volgende punten waar:
- Alle Fabric-items delen dezelfde ingerichte capaciteit. De hoeveelheid tijd die een query of taak nodig heeft, varieert omdat andere workloads dezelfde capaciteit gebruiken.
- De maximale capaciteitseenheden van de werkruimte (CU's) zijn beperkt tot de grootst mogelijke F SKU of P SKU. Voor data engineering-ervaringen kunt u afzonderlijke Spark-pools inrichten om de rekencapaciteit te verplaatsen die Fabric Spark nodig heeft buiten de ingerichte CA's.
- 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 gebieden.
- Functies die afhankelijk zijn van meerdere werkruimten, zoals implementatiepijplijnen en levenscyclusbeheer, zijn niet beschikbaar.
- Beperkingen die aan één werkruimte zijn gekoppeld, zijn van toepassing.
- Capaciteitsbeperkingen die aan een specifieke SKU zijn gekoppeld, zijn van toepassing.
U kunt ervoor kiezen om dit implementatiepatroon te implementeren om een of meer van de volgende redenen:
- Uw organisatie heeft geen complexe technische vereisten, het heeft een kleine gebruikersbasis of de semantische modellen zijn klein.
- 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 medalsight-architectuur implementeren. Wanneer uw organisatie is beperkt tot één werkruimte, kunt u scheiding bereiken tussen brons-, zilver- en goudlagen door afzonderlijke lakehouses binnen de werkruimte te maken.
- De bedrijfseenheden van uw organisatie delen rollen en het is acceptabel om dezelfde machtigingen op werkruimteniveau te hebben voor gebruikers in de werkruimte. Wanneer bijvoorbeeld meerdere gebruikers die deel uitmaken van verschillende bedrijfseenheden beheerders van één werkruimte zijn, hebben ze dezelfde rechten voor alle items in de werkruimte.
- Uw organisatie kan de voltooiingstijden van variabele taken tolereren. Als een organisatie geen vereisten heeft voor prestatiegaranties (een taak moet bijvoorbeeld binnen een specifieke periode worden voltooid), is het acceptabel om één ingerichte capaciteit te delen in bedrijfseenheden. Wanneer een capaciteit wordt gedeeld, kunnen gebruikers hun query's op elk gewenst moment uitvoeren. Het aantal BESCHIKBARE CA's voor het uitvoeren van een taak is afhankelijk van de andere query's die worden uitgevoerd op de capaciteit. Dit kan leiden tot voltooiingstijden van variabele taken.
- Uw organisatie kan alle bedrijfsvereisten (vanuit cu-perspectief) bereiken met behulp van één Fabric-capaciteit.
De volgende tabel bevat overwegingen die van invloed kunnen zijn op uw beslissing om dit implementatiepatroon te implementeren:
| Aspect | Overwegingen |
|---|---|
| Governance | - Lagere governancemandaten en beperkingen op het platform zijn vereist. - Het past bij kleinere organisaties die de voorkeur geven aan snellere markttijd. - Uitdagingen kunnen zich ontwikkelen als governancevereisten steeds complexer worden. |
| Beveiliging - Gegevensvlak | - Gegevens kunnen worden gedeeld tussen teams, dus u hoeft geen beperkingen te hebben voor gegevens tussen teams. - Teams heeft eigendomsrechten op de semantische modellen. Ze kunnen gegevens lezen, bewerken en wijzigen in OneLake. |
| Beveiliging - Besturingsvlak | - Alle gebruikers kunnen samenwerken in dezelfde werkruimte. - Er gelden geen beperkingen voor items. Alle gebruikers kunnen alle items lezen en bewerken. |
| Beheer | De organisatie heeft: - Lagere administratiekosten. - Geen strikte noodzaak om de toegang en het gebruik per team bij te houden en te bewaken. - Minder strenge belastingsbewaking voor infrastructuurworkloads in teams. |
| DevOps | DevOps profiteert van: - Eén release voor het hele platform. - Minder gecompliceerde release-pijplijnen. |
| Bruikbaarheid - Beheer istrators | - Het is eenvoudiger voor beheerders om te beheren omdat ze minder items hebben om te beheren. - Het is niet nodig om andere inrichtingen uit te voeren of aanvragen van teams af te handelen voor nieuwe capaciteiten of werkruimten. - Capaciteitsbeheerders kunnen tenantbeheerders zijn, dus u hoeft geen andere groepen of teams te maken of te beheren. |
| Bruikbaarheid - Andere rollen | - Het is acceptabel om de werkruimte te delen met andere gebruikers. - Samenwerking tussen gebruikers wordt aangemoedigd. |
| Prestaties | - Isolatie van workloads is niet verplicht. - Er moet niet worden voldaan aan strikte serviceovereenkomsten (SLA's). - Beperking is waarschijnlijk niet mogelijk. |
| Facturering en kostenbeheer | - Eén team kan kosten verwerken. - Er hoeft geen kosten in rekening te worden gebracht voor verschillende teams. |
Patroon 2: Meerdere werkruimten die worden ondersteund door één infrastructuurcapaciteit
In dit implementatiepatroon gebruikt u afzonderlijke werkruimten. Omdat één capaciteit wordt gedeeld tussen werkruimten, kunnen workloads die gelijktijdig worden uitgevoerd, invloed hebben op de prestaties van taken en interactieve query's.
Wanneer u één Infrastructuurcapaciteit inricht en er meerdere werkruimten aan koppelt, zijn de volgende punten waar:
- Alle Fabric-items delen dezelfde ingerichte capaciteit. De hoeveelheid tijd die een query of taak nodig heeft, varieert omdat andere workloads dezelfde capaciteit gebruiken.
- Het maximum aantal CU's dat een werkruimte kan gebruiken, is beperkt tot de grootst mogelijke F SKU of P SKU. Voor data engineering-ervaringen kunt u afzonderlijke Spark-pools inrichten om de rekencapaciteit te verplaatsen die Fabric Spark nodig heeft buiten de ingerichte CA's.
- 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 gebieden.
- U kunt DevOps-functies gebruiken waarvoor afzonderlijke werkruimten zijn vereist, zoals voor implementatiepijplijnen en levenscyclusbeheer.
- Beperkingen die aan één werkruimte zijn gekoppeld, zijn van toepassing.
- Capaciteitsbeperkingen die aan een specifieke SKU zijn gekoppeld, zijn van toepassing.
U kunt ervoor kiezen om dit implementatiepatroon te implementeren om een of meer van de volgende redenen:
- U wilt een hub-and-spoke-architectuur waarin uw organisatie een aantal aspecten van het gebruik van de analyseomgeving centraliseert en anderen decentraliseert.
- U wilt decentralisatie vanuit een operationeel en beheeraspect, maar in verschillende mate. U kunt er bijvoorbeeld voor kiezen om brons- en zilveren lagen van een medaillestructuur te implementeren in één werkruimte en de gouden laag die is geïmplementeerd in een andere werkruimte. Uw logica kan zijn dat één team verantwoordelijk is voor de brons- en zilverlagen en een ander team is verantwoordelijk voor het werken en beheren van de gouden laag.
- U maakt zich niet voornamelijk zorgen over prestatiebeheer en het isoleren van workloads vanuit prestatieperspectief.
- Vanuit het perspectief van een lakehouse medalsight-architectuur kan uw organisatie afzonderlijke werkruimten maken om brons-, zilver- en gouden lagen te implementeren.
- Uw organisatie hoeft geen workloads te implementeren in verschillende geografische regio's (alle gegevens moeten zich in één regio bevinden).
- Uw organisatie vereist mogelijk scheiding van werkruimten om een of meer van de volgende redenen:
- 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 (gegevenspijplijnen, gegevensstroom Gen2 of data engineering) en een afzonderlijke werkruimte maken voor gebruik via een datawarehouse. Dit ontwerp werkt goed wanneer afzonderlijke teams verantwoordelijk zijn voor elk van de workloads.
- U wilt een data mesh-architectuur implementeren waarin een of meer werkruimten zijn gegroepeerd in een Fabric-domein.
- Uw organisatie kan ervoor kiezen om afzonderlijke werkruimten te implementeren op basis van gegevensclassificatie.
De volgende tabel bevat overwegingen die van invloed kunnen zijn op uw beslissing om dit implementatiepatroon te kiezen:
| Aspect | Overwegingen |
|---|---|
| Governance | - Er zijn gemiddeld governancemandaten en beperkingen op het platform vereist. - De organisatie heeft gedetailleerdere controle nodig om afdelingen, teams en rollen te beheren. |
| Beveiliging - Gegevensvlak | - Gegevensbeperkingen zijn vereist en u moet gegevensbeveiliging bieden op basis van toegangsbeheer voor afdelingen, teams en leden. |
| Beveiliging - Besturingsvlak | - Om onbedoelde beschadiging of acties door kwaadwillende gebruikers te voorkomen, moet u mogelijk gecontroleerde toegang bieden voor Fabric-items per rol. |
| Beheer | - U hoeft geen capaciteiten te beheren omdat het een model met één capaciteit is. - U kunt werkruimten gebruiken om afdelingen, teams en gebruikers te isoleren. |
| DevOps | - U kunt onafhankelijke releases uitvoeren per afdeling, team of workload. - Het is eenvoudiger om te voldoen aan de vereisten voor ontwikkeling, testen, acceptatie en productie (DTAP) voor teams wanneer meerdere werkruimten worden ingericht om te voldoen aan elke releaseomgeving. |
| Bruikbaarheid - Beheer istrators | - U hoeft niet meerdere capaciteiten in te richten. - Tenantbeheerders beheren doorgaans capaciteit, zodat u geen andere groepen of teams hoeft te beheren. |
| Bruikbaarheid - Andere rollen | - Werkruimten zijn beschikbaar voor elke medallayer-laag. - Fabric-items worden geïsoleerd per werkruimte, waardoor onbedoelde beschadiging kan worden voorkomen. |
| Prestaties | - Er hoeft niet te worden voldaan aan strikte prestatie-SLA's. - Beperking is acceptabel tijdens piekperioden. |
| Facturering en kostenbeheer | - U hebt geen specifieke vereiste om kosten per team in rekening te brengen. - Een centraal team draagt alle kosten. - Infrastructuurteams zijn eigenaren van Infrastructuurcapaciteiten in de organisatie. |
Patroon 3: Meerdere werkruimten die worden ondersteund door afzonderlijke capaciteiten
In dit implementatiepatroon bereikt u scheiding tussen bedrijfseenheden voor governance en prestaties.
Wanneer u meerdere Fabric-capaciteiten inricht met hun eigen werkruimten, zijn de volgende punten waar:
- 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.
- Organisatie- en beheerdecentralisatie wordt bereikt door afzonderlijke werkruimten in te richten.
- Organisaties kunnen buiten één regio schalen door capaciteiten en werkruimten in verschillende geografische regio's in te richten.
- U kunt de volledige mogelijkheden van Fabric gebruiken, omdat bedrijfseenheden een of meer werkruimten kunnen hebben die zich in afzonderlijke capaciteiten bevinden en zijn gegroepeerd via Fabric-domeinen.
- Beperkingen die aan één werkruimte zijn gekoppeld, zijn van toepassing, maar u kunt buiten deze limieten schalen door nieuwe werkruimten te maken.
- Capaciteitsbeperkingen die aan een specifieke SKU zijn gekoppeld, zijn van toepassing, maar u kunt CA's schalen door afzonderlijke capaciteiten in te richten.
- Alle Fabric-items in alle werkruimten in de tenant en hun certificeringsstatussen kunnen worden gedetecteerd met behulp van een OneLake-gegevenshub.
- Domeinen kunnen werkruimten groeperen, zodat één bedrijfseenheid meerdere werkruimten kan gebruiken en beheren.
- OneLake-snelkoppelingen verminderen de verplaatsing van gegevens en ze verminderen ook de bruikbaarheid van gegevens in werkruimten.
U kunt ervoor kiezen om dit implementatiepatroon te implementeren om een of meer van de volgende redenen:
- Uw organisatie wil architectuurframeworks implementeren, zoals data mesh of data fabric.
- U wilt prioriteit geven aan flexibiliteit in de structuur van capaciteiten en werkruimten.
- U werkt in verschillende geografische regio's. In dit geval is het inrichten van een afzonderlijke capaciteit en werkruimte de drijvende kracht om naar dit implementatiepatroon met meerdere capaciteit en meerdere werkruimten te gaan.
- 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 aan een specifieke SLA voor prestaties moeten voldoen. U kunt een afzonderlijke werkruimte inrichten die wordt ondersteund door een Fabric-capaciteit om te voldoen aan de prestatiegaranties voor deze workloads.
De volgende tabel bevat overwegingen die van invloed kunnen zijn op uw beslissing om dit implementatiepatroon te kiezen:
| Aspect | Overwegingen |
|---|---|
| Governance | - U hebt een hoge mate van governance en beheer en u hebt onafhankelijkheid nodig voor elke werkruimte. - U kunt het gebruik per afdeling of bedrijfseenheid beheren. - U kunt voldoen aan de vereisten voor gegevenslocatie. - U kunt gegevens isoleren op basis van wettelijke vereisten. |
| Beveiliging - Gegevensvlak | - Gegevenstoegang kan worden beheerd per afdeling, team of gebruikers. - U kunt gegevens isoleren op basis van het itemtype Fabric. |
| Beveiliging - Besturingsvlak | - U kunt gecontroleerde toegang bieden op Fabric-items per rol om onbedoelde beschadiging of acties door kwaadwillende gebruikers te voorkomen. |
| Beheer | - Gedetailleerde beheerdersmogelijkheden zijn beperkt tot afdelingen, teams of gebruikers. - U hebt toegang tot gedetailleerde bewakingsvereisten voor gebruik of patronen van workloads. |
| DevOps | - U kunt DTAP-omgevingen isoleren met behulp van verschillende capaciteiten. - Onafhankelijke releases zijn gebaseerd op een afdeling, team of workload. |
| Bruikbaarheid - Beheer istrators | - U krijgt gedetailleerde inzicht in het gebruik per afdeling of team. - U hebt capaciteitsrechten gedelegeerd aan capaciteitsbeheerders per afdeling of team, wat helpt bij het schalen en gedetailleerde configuratie. |
| Bruikbaarheid - Andere rollen | - Werkruimten zijn beschikbaar per medallayer-laag en capaciteit. - Infrastructuuritems worden geïsoleerd per werkruimte, waardoor onbedoelde beschadiging wordt voorkomen. - U hebt meer opties om beperking te voorkomen die wordt veroorzaakt door pieken in gedeelde capaciteit. |
| Prestaties | - Prestatievereisten zijn hoog en workloads moeten voldoen aan hogere SLA's. - U hebt flexibiliteit bij het omhoog schalen van afzonderlijke workloads per afdeling of team. |
| Facturering en kostenbeheer | - Aan vereisten voor kruislings opladen kan eenvoudig worden voldaan door toegewezen capaciteiten toe te wijzen aan een organisatie-entiteit (afdeling, team of project). - Kostenbeheer kan worden gedelegeerd aan de respectieve teams die moeten worden beheerd. |
Patroon 4: Meerdere Fabric-tenants
Wanneer afzonderlijke Fabric-tenants worden geïmplementeerd, zijn alle exemplaren van Fabric afzonderlijke entiteiten met betrekking tot governance, beheer, beheer, schaal en opslag.
De volgende punten zijn waar wanneer u meerdere Fabric-tenants gebruikt:
- Tenantresources worden strikt gescheiden.
- Beheervlakken tussen tenants zijn gescheiden.
- Tenants zijn afzonderlijke entiteiten en kunnen hun eigen processen voor governance en beheer hebben, maar u kunt ze afzonderlijk beheren.
- U kunt gegevenspijplijnen of data engineering-mogelijkheden gebruiken om gegevens te delen of te openen tussen Fabric-tenants.
U kunt ervoor kiezen om dit implementatiepatroon te implementeren om de volgende redenen:
- De organisatie kan uiteindelijk meerdere Fabric-tenants hebben vanwege een bedrijfsaankoop.
- De organisatie kan ervoor kiezen om een Fabric-tenant specifiek in te stellen voor een bedrijfseenheid of een kleinere dochteronderneming.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
- Holly Kelly | Principal Program Manager
- Gabi Muenster | Senior Program Manager
- Sarath Sasidharan | Senior Program Manager
- Amanjeet Singh | Principal Program Manager