Moderne medaillon-datawarehousearchitectuur in Microsoft Fabric

Deze voorbeeldworkload beschrijft een SQL-first moderne medaillonarchitectuur voor datawarehouses (MDW). Een modern datawarehouse maakt gebruik van op SQL gebaseerde gegevensarchieven om gestructureerde gegevens te organiseren voor analyse en rapportage. Deze architectuur implementeert de brons-, zilver- en gouden lagen in Fabric Data Warehouse en maakt gebruik van Fabric Data Factory om gegevensopname en transformatie te organiseren.

Fabric Data Warehouse slaat relationele gegevens op in Delta-indeling in OneLake en ondersteunt T-SQL-ontwikkeling via tabellen, weergaven, transacties en opgeslagen procedures. Power BI, SQL-clients en andere toepassingen gebruiken gecureerde gegevens uit de gouden laag.

Architecture

Download een PowerPoint-bestand van deze architectuur.

In het diagram verzorgt Mirroring de replicatie van operationele databases, en Fabric Data Factory-pijplijnen nemen niet-gespiegelde bronnen op in het bronze-pad.

Gegevensstroom

De volgende gegevensstroom komt overeen met het vorige diagram:

1. Operationele databases, SaaS-toepassingen, bestanden en andere bronsystemen produceren gegevens.

2. Gegevensopname brengt brongegevens naar Fabric via twee manieren. Voor ondersteunde operationele databases repliceert Spiegeling in Fabric continu de gegevens naar een gespiegeld database-item in OneLake. Een warehouse CTAS of INSERT ... SELECT-stap slaat die gegevens vervolgens op in het bronze warehouse. Gebruik Fabric Data Factory-pijplijnen of T-SQL voor het datawarehouse, zoals COPY INTO, om voor bestanden, SaaS-toepassingen en andere niet-gespiegelde bronnen bronze-tabellen te laden.

3. De bronslaag slaat onbewerkte, minimaal verwerkte gegevens op in magazijntabellen. Opnamemetagegevens, zoals laadtijdstempels en bron-id's, ondersteunen controle en herverwerking.

4. De eerste transformatiefase (Bronze to silver) valideert en transformeert bronsgegevens in de zilveren laag.

5. De zilveren laag bevat opgeschoonde, ontdubbelde en conforme gegevens. Wanneer historische analyse nodig is, leggen silver-tabellen bronwijzigingen vast met ingangsdatums en indicatoren voor actuele rijen.

6. Opgeslagen procedures of dbt-taken implementeren doorgaans de Bronze to silver fase met behulp van SQL-patronen zoals CREATE TABLE AS SELECT (CTAS), INSERT ... SELECTen MERGE.

7. De gouden laag biedt gebruiksklare sterschema's, datamarts en vooraf samengevoegde tabellen.

8. De tweede transformatiefase (Silver to gold) transformeert zilveren gegevens in bedrijfsentiteiten, dimensies, feiten en aggregaties in de gouden laag.

9. Power BI gebruikt gold-data via semantische modellen. Andere consumenten, zoals SQL-clients, notebooks en toepassingen, kunnen query's uitvoeren op het SQL-eindpunt van het magazijn.

Components

• Fabric Data Warehouse biedt de T-SQL-reken- en relationele tabellen voor de brons-, zilver- en goudlagen.
• OneLake slaat datawarehousegegevens op in Delta-indeling en slaat gegevens op die door Fabric-mirroring worden gerepliceerd.
• Spiegeling in Fabric repliceert continu ondersteunde operationele databases naar OneLake.
• Fabric Data Factory gegevens opneemt en opgeslagen procedures, pijplijnen en andere transformatieactiviteiten indelen.
• Power BI biedt semantische modellen, rapporten en dashboards over gecureerde gouden gegevens.

Ontwerprichtlijnen

In de volgende richtlijnen wordt beschreven hoe u de brons-, zilver- en goudlagen implementeert en de ondersteunende werkruimten ordent. Pas deze aanbevelingen aan de gegevensbronnen en governancevereisten van uw workload en de vaardigheden van uw team aan.

Bronslaag: Onbewerkte gegevensopname

De bronslaag neemt onbewerkte gegevens op en legt alle brongegevens in de oorspronkelijke vorm vast zonder bedrijfslogica toe te passen. Het fungeert als het recordsysteem, waardoor volledige tracering en herverwerking mogelijk is. Tabellen in deze laag zijn nauw afgestemd op bronschema's en voorkomen opzettelijk filteren, ontdubbelen of verrijken. Optionele metagegevenskolommen, zoals tijdstempels voor opname of namen van bronbestanden, ondersteunen vaak controle.

Voor ondersteunde operationele databases gebruikt u Spiegeling in Fabric om continu brontabellen te repliceren naar OneLake. Gebruik voor bestands-, SaaS- of niet-ondersteunde bronnen Fabric Data Factory-pijplijnen, COPY INTO voor bulksgewijze opname, of OPENROWSET met CTAS of INSERT ... SELECT om externe bestandsgegevens op te slaan in het bronze-warehouse.

In deze fase houdt de ingestie de hervorming minimaal, zodat de bronslaag het replaybare bronsysteem blijft. Indien nodig voor niet-gespiegelde bronnen, kan een opgeslagen procedure met bronsbelasting (of een gelijkwaardig dbt-model) binnenkomende records standaardiseren en metagegevens voor laden toevoegen.

Best practices voor de bronslaag benadrukken het behoud van alle ruwe gegevens, inclusief ongeldige records, het gebruik van batchgewijze gegevensinname om problemen met kleine bestanden te voorkomen, het nauw laten aansluiten van schema's op de bronsystemen en het automatiseren van gegevensinnameworkflows met behulp van Fabric-pijplijnen om consistentie en betrouwbaarheid op schaal te waarborgen.

Zilveren laag: Gegevens opschonen en conformeren

De zilveren laag richt zich op het opschonen en conformeren van gegevens door bronsgegevens te verfijnen via de toepassing van regels voor gegevenskwaliteit, standaardisatie, ontdubbeling en integratie in meerdere bronnen. Uiteindelijk produceert het één bron van waarheid voor opgeschoonde en betrouwbare gegevens.

Normaal gesproken implementeert u transformaties in deze fase met behulp van T-SQL, met behulp van patronen zoals CREATE TABLE AS SELECT (CTAS) INSERT … SELECTen MERGE instructies ter ondersteuning van zowel batch- als incrementele verwerking. Hoewel Fabric Data Warehouse geen gerealiseerde weergaven ondersteunt, kunt u gerealiseerde lakeweergaven gebruiken, geïmplementeerd met behulp van Spark, om Delta-tabellen te genereren. Het SQL Analytics-eindpunt toont deze Delta-tabellen als tabellen die het magazijn kan lezen.

Aanbevolen procedures voor de zilveren laag zijn het ontwerpen van transformaties die idempotent zijn, het consistent afdwingen van regels voor gegevenskwaliteit en het gebruik MERGE voor incrementele updates. Wanneer de workload historisering vereist, bewaart u rijversies met ingangs- en einddatums en een indicator voor de huidige rij. Gouddimensies kunnen deze geschiedenis gebruiken om het gedrag van type 1 of type 2 langzaam veranderende dimensies (SCD) te implementeren.

Gouden laag: Gecureerde gegevens voor analyse

De gouden laag levert gecureerde, zakelijke gegevens die zijn geoptimaliseerd voor analyse, rapportage en verbruik door BI-hulpprogramma's zoals Power BI. Deze laag is ontworpen rond analytische modelleringspatronen, die vaak sterschema's gebruiken met feiten- en dimensietabellen, domeinspecifieke datamarts en vooraf geaggregeerde overzichtstabellen ter ondersteuning van uitvoerende query's en intuïtieve analyses.

Doorgaans leidt u gouden tabellen uitsluitend af van zilveren gegevens en stelt u ze beschikbaar voor eindgebruikers en rapportagehulpprogramma's.

Gebruik stabiele surrogaatsleutels voor dimensies, zodat feiten niet afhankelijk zijn van veranderlijke bronsysteemsleutels. Fabric Data Warehouse ondersteunt BIGINT IDENTITY kolommen voor het genereren van surrogaatsleutels. Identiteitswaarden zijn uniek, maar zijn niet gegarandeerd opeenvolgend of geordend, en er kunnen hiaten voorkomen. Als deze beperkingen niet geschikt zijn voor de workload, genereert en bewaart u surrogaatsleutels in transformatielogica en onderhoudt u een duurzame toewijzing aan elke natuurlijke sleutel. Genereer geen surrogaatsleutels opnieuw tijdens een volledige vernieuwing.

Aanbevolen procedures voor de gouden laag omvatten het modelleren van gegevens om nauw te zijn afgestemd op analytische en zakelijke use cases, waar mogelijk gegevens samen te voegen om de prestaties te verbeteren, beveiligingscontroles zoals beveiliging op rijniveau (RLS), beveiliging op kolomniveau (CLS) en gegevensmaskering, en het grondig documenteren van gegevensherkomsten en transformaties.

Werkruimtestrategie

Een workspace-strategie definieert hoe brons-, zilver- en goudlagen logisch en fysiek worden gescheiden om governance, beveiliging en operationele eenvoud in balans te brengen. U kunt lagen implementeren met behulp van afzonderlijke werkruimten per laag, die we aanbevelen wanneer sterke beveiligingsgrenzen, duidelijk eigendom of strikte scheiding van verantwoordelijkheden vereist zijn. U moet bijvoorbeeld onbewerkte gegevensopname isoleren van gecureerde bedrijfsgegevens.

U kunt ook lagen binnen één werkruimte implementeren met behulp van afzonderlijke magazijnen voor brons-, zilver- en goudgegevens. Deze aanpak kan de beheerlast verminderen en ontwikkeling en tests over meerdere lagen heen vereenvoudigen, terwijl de scheiding op datawarehouseniveau tussen medallion-lagen behouden blijft.

De keuze tussen deze benaderingen is doorgaans afhankelijk van factoren zoals organisatorische schaal, beveiligingsvereisten, teamstructuur en volwassenheid van governance. Veel ondernemingen nemen een hybride model aan naarmate hun Fabric implementatie zich ontwikkelt. We raden u aan afzonderlijke werkruimten te gebruiken wanneer isolatie, governance en eigendomsgrenzen vereist zijn.

Implementatierichtlijnen

Fabric Data Warehouse biedt transactionele consistentie en betrouwbare gegevensverwerking in de brons-, zilver- en gouden lagen. Gebruik batchgeoriënteerde schrijfbewerkingen om problemen met kleine bestanden te minimaliseren en de efficiëntie van opslag en query's te verbeteren. Gebruik MERGE instructies om te laat binnenkomende of gewijzigde gegevens te verwerken in scenario's voor incrementele verwerking.

Houd transacties kort om concurrentieconflicten te verminderen en concurrency te optimaliseren, vooral in omgevingen met hoge gegevensinname. Bewaak de prestaties en operationele status actief met behulp van Fabric queryinzichten en dynamische beheerweergaven (DMV's). Dankzij de architectuurscheiding van lees- en schrijfworkloads in Fabric kunnen opname- en transformatietaken gelijktijdig worden uitgevoerd zonder analytische query's te blokkeren, waardoor voorspelbare prestaties voor downstreamanalyses en -rapportage mogelijk zijn.

Gebruik opgeslagen T-SQL-procedures en Fabric Data Factory-pijplijnen voor systeemeigen SQL-transformatie en -indeling. Teams die de voorkeur geven aan modulaire SQL-modellen en -tests, kunnen gebruikmaken van de Microsoft-onderhouden dbt-adapter voor Fabric Data Warehouse. Voer uniekheid, referentiële integriteit en geaccepteerde waardetests uit als implementatie- of pijplijnpoorten voordat u gegevens naar downstreamlagen publiceert.

Alternatives

Deze architectuur bevat meerdere onderdelen die u kunt vervangen door andere Azure-services of -benaderingen, afhankelijk van de functionele en niet-functionele vereisten van uw workload. Bekijk de volgende alternatieven en hun compromissen.

Voor scenario's die grootschalige data engineering, geavanceerde analyses, machine learning of ongestructureerde gegevens benadrukken, kan een lakehouse-first-architectuur op Microsoft Fabric beter passen. In deze benadering fungeert een Fabric lakehouse als het primaire gegevensarchief in OneLake en worden transformaties voornamelijk geïmplementeerd met behulp van hulpprogramma's op basis van Spark, zoals notebooks of Dataflow Gen2. Dit patroon biedt de gedistribueerde berekeningen, notebooks en machine learning-hulpprogramma's die niet de focus hebben op deze SQL-first warehouse-architectuur.

Voor organisaties met een sterke focus op data science, AI of complexe gedistribueerde verwerking is Azure Databricks een ander alternatief. Azure Databricks wordt doorgaans geselecteerd wanneer workloads een grondige integratie vereisen met opensource-machine learning-frameworks, gedetailleerde controle over spark-uitvoering of overdraagbaarheid met meerdere clouds.

Voor bijna realtime- of gebeurtenisgestuurde analyses zijn Fabric Real-Time Intelligence, Azure Event Hubs of Azure Stream Analytics mogelijk geschikter dan een batchgeoriënteerd ontwerp voor medailles in Fabric Data Warehouse.

Scenario-details

Fabric Data Warehouse is zeer geschikt voor deze medaillonarchitectuur wanneer het primaire doel is om goed beheerde, analyseklare gegevens op schaal te leveren met behulp van vertrouwde SQL-patronen.

Scenario 1: Relationele semantiek en SQL-prestaties voor gecureerde gegevenssets die gereed zijn voor analyses

Fabric Data Warehouse is geschikt omdat het relationele tabellen en weergaven, ACID-transacties en T-SQL-bewerkingen biedt boven op Delta-gegevens. Deze functieset ondersteunt workloads waarin gegevens al zijn opgeschoond en geharmoniseerd en consistent via SQL moeten worden opgevraagd.

Voorbeeld: Een luchtvaartmaatschappij bouwt gecureerde gouden gegevenssets voor vluchtbewerkingen en omzetanalyses. Analisten zijn afhankelijk van stabiele SQL-queryprestaties om on-time prestatietrends, routewinstgevendheid en bemanningsgebruik te evalueren. Het gebruik van magazijntabellen en weergaven zorgt voor transactionele consistentie en betrouwbaar querygedrag, wat moeilijker is om te garanderen met ad-hoc toegang op basis van bestanden.

Scenario 2: Gecentraliseerd beheer met een SQL-eerste ervaring

Fabric Data Warehouse maakt gecentraliseerd beheer mogelijk via machtigingen op werkruimteniveau, beveiliging op objectniveau en ingebouwde gegevensafstamming, en stelt gegevens beschikbaar via een SQL-interface die analytics-engineeringteams bekend voorkomt. Deze aanpak vermindert de operationele wrijving, vereenvoudigt het toegangsbeheer en versnelt de acceptatie in teams zonder nieuwe toegangsparadigma's te introduceren.

Voorbeeld: Een globale onderneming dwingt strikte scheiding van taken af: platformteams beheren opname- en transformaties en analyseteams gebruiken alleen gecureerde gegevens. Door alleen tabellen met gouden lagen beschikbaar te maken via een magazijn en de toegang centraal te beheren, voorkomt de organisatie onbeheerde toegang tot onbewerkte of tussenliggende gegevens terwijl een vertrouwde op SQL gebaseerde werkstroom behouden blijft.

Scenario 3: geoptimaliseerd BI-verbruik voor rapportage en dashboards

Het magazijn is geoptimaliseerd voor hoge gelijktijdigheid, leesintensieve workloads, waardoor het een sterke keuze is wanneer grote aantallen zakelijke gebruikers dashboards en rapporten gebruiken die zijn gebaseerd op consistente semantische modellen. Deze optimalisatie is vooral belangrijk wanneer prestaties, stabiliteit en voorspelbaar querygedrag vereist zijn tijdens piekgebruik.

Voorbeeld: Financiële en operationele teams hebben tijdens kantooruren toegang tot Power BI dashboards om KPI's te bewaken, zoals omzet, operationele efficiëntie en SLA-naleving. Fabric Data Warehouse isoleert SELECT en niet-SELECTworkloads in afzonderlijke rekenpools, waardoor de directe concurrentie tussen dashboardquery’s en data-inname in het warehouse afneemt.

Scenario 4: Dimensionale modelleringsondersteuning voor een herbruikbare gouden laag

Fabric Data Warehouse op natuurlijke wijze wordt uitgelijnd met dimensionale modelleringspatronen, waaronder feiten- en dimensietabellen, die u vaak in de gouden laag gebruikt om bedrijfsvriendelijke, herbruikbare gegevenssets beschikbaar te maken. Deze modellen vereenvoudigen analyses, verminderen logicaduplicatie en bevorderen consistente metrische definities in teams.

Voorbeeld: Een retailorganisatie maakt gedeelde dimensietabellen voor klanten, producten en winkels, samen met feitentabellen voor verkoop en voorraad. Deze gouden gegevenssets worden hergebruikt in meerdere Power BI rapporten en bedrijfseenheden, zodat KPI's zoals netto-omzet of voorraadomzet eenmaal worden gedefinieerd en consistent worden toegepast.

Considerations

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

Betrouwbaarheid

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

Controleer de betrouwbaarheid in Microsoft Fabric voor het gedocumenteerde tolerantiemodel, inclusief zone-downgedrag en regionale overwegingen. Toets de herstelverwachtingen aan deze richtlijnen voor uw regio en werkbelastingvereisten.

Voor scenario's voor herstel na noodgevallen tussen regio's ontwerpt en documenteert u een herstelstrategie die overeenkomt met de vereisten van de organisatie en het model voor gedeelde verantwoordelijkheid.

• Fabric Data Warehouse ondersteunt PRIMARY KEY, FOREIGN KEYen UNIQUEtabelbeperkingen alleen als NOT ENFORCED. Het magazijn valideert geen uniekheid of referentiële integriteit. Opname- en transformatielogica moet dubbele of zwevende records detecteren en voorkomen dat ze downstreamlagen bereiken.

Security

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie de controlelijst voor ontwerpbeoordeling voor Beveiliging voor meer informatie.

Microsoft Fabric biedt mogelijkheden voor het beheren, beheren en controleren van beveiligingsinstellingen op basis van organisatievereisten. Houd rekening met de volgende beveiligingsprocedures:

• Gebruik Microsoft Entra ID eenmalige aanmelding (SSO) om gebruikers te verifiëren en consistent identiteitsbeheer te bieden op verschillende apparaten en locaties.

• Pas machtigingen op basis van werkruimten toe om te bepalen wie Fabric artefacten kan maken, wijzigen of gebruiken.

• Gebruik de inkomende en uitgaande netwerkbeveiligingscontroles van Fabric bij de toegang tot gegevens of diensten binnen of buiten uw netwerk. Deze besturingselementen omvatten voorwaardelijke toegang, privékoppelingen, toegang tot vertrouwde werkruimten en beheerde privé-eindpunten.

• Gebruik Fabric auditlogboeken om gebruikersactiviteiten, configuratiewijzigingen en gegevenstoegang op het platform bij te houden.

Zie Security in Fabric voor meer informatie.

Kostenoptimalisatie

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

Microsoft Fabric biedt capaciteitsreserveringen voor een gedefinieerd aantal capaciteitseenheden (CA's). Reserveringen van één jaar kunnen helpen bij het verlagen van de kosten voor voorspelbare, stabiele werkbelastingen.

Houd rekening met de volgende procedures om het gebruik van Fabric capaciteit te maximaliseren:

• Begin met proefcapaciteiten of F-SKU's voor betalen per gebruik om inzicht te krijgen in het gedrag van de workload. Voer een afgebakende proof of concept uit met representatieve workloads voor gegevensinname, transformatie en rapportage. Bewaak het CU-verbruik en extrapoleer resultaten om de productiebehoeften te schatten. U kunt Fabric capaciteiten schalen naarmate de vraag toeneemt.

• Analyseer historisch gebruik om piek- en dalperioden te identificeren. Plan niet-kritieke werkbelastingen of achtergrondtaken in tijdens perioden met minder vraag om de constante druk op CU te verminderen.

• Verminder onnodig rekenverbruik door SQL-query's, DAX-taken (Data Analysis Expressions) en achtergrondtaken te optimaliseren.

• Fabric ondersteunt bursting en smoothing om korte pieken in de vraag naar rekenkracht op te vangen en het verbruik van achtergrondworkloads over de tijd te verdelen. Met deze functies kunt u capaciteit voor gemiddeld gebruik in plaats van piekvraag aanpassen. Zie Uw Fabric-capaciteit evalueren en optimaliseren voor meer informatie.

• Coördineer langlopende transformaties en vernieuwingsbewerkingen om overlappende workloads met hoge rekenkracht op dezelfde capaciteit te voorkomen. Zie Workloadbeheer in Fabric Data Warehouse voor meer informatie.

Houd rekening met de volgende prijsoverwegingen:

• OneLake-opslagvolume, bewaarperiode en patronen voor gegevenstoegang zijn rechtstreeks van invloed op de totale kosten. Schat de verwachte gegevensgroei per medalliance-laag en stem de retentie af op bedrijfs- en nalevingsvereisten.

• Microsoft Fabric prijzen zijn gebaseerd op een toegewezen F-capaciteit, gemeten in CU's. Power BI-licenties per gebruiker staan los van Fabric-capaciteit en richten deze niet in.

Gebruik de vooraf geconfigureerde kostenraming in de Azure-prijscalculator om een eerste kosteninschatting voor deze architectuur te krijgen. Pas de waarden aan zodat deze overeenkomen met de verwachte werkbelasting.

Operationele uitmuntendheid

Operational Excellence omvat de operationele processen die een workload in productie implementeren, bewaken en onderhouden. Zie de controlelijst voor ontwerpbeoordeling voor Operational Excellence voor meer informatie.

Microsoft Fabric biedt ingebouwde operationele zichtbaarheid voor workloads voor data engineering, opslag en analyse. Gebruik de app Fabric Capacity Metrics om het capaciteitsverbruik te bewaken, resource-intensieve artefacten te identificeren en te begrijpen hoe interactieve en achtergrondworkloads bijdragen aan het algehele gebruik. Met deze inzichten kunnen teams weloverwogen operationele beslissingen nemen over schalen, plannen en optimaliseren.

Stel proactieve waarschuwingen in, zodat capaciteitsbeheerders vroeg hoge gebruiks- of beperkingsvoorwaarden kunnen identificeren en kunnen reageren voordat de impact van de gebruiker optreedt.

Prestatie-efficiëntie

Prestatie-efficiëntie verwijst naar de mogelijkheid van een workload om efficiënt te schalen en te voldoen aan de vraag van gebruikers. Zie de controlelijst voor ontwerpbeoordeling voor Prestatie-efficiëntie voor meer informatie.

Microsoft Fabric bevat verschillende mechanismen om prestaties en capaciteitsgebruik te beheren:

• Bursting en afvlakking zorgen ervoor dat kortdurende pieken in de vraag naar rekenkracht sneller kunnen worden verwerkt, terwijl het gebruik over de tijd wordt gespreid. Interactieve bewerkingen verlopen doorgaans over minuten en achtergrondbewerkingen worden vloeiend over langere vensters.

• Beperking wordt toegepast wanneer een capaciteit een duurzaam rekengebruik ondervindt dat hoger is dan de limieten van de toegewezen SKU. Throttling vertraagt of weigert nieuwe bewerkingen om de stabiliteit van het platform te beschermen.

• De app Fabric Capacity Metrics biedt gedetailleerde inzicht in het capaciteitsverbruik en maakt onderscheid tussen interactieve bewerkingen (zoals rapportquery's) en achtergrondbewerkingen (zoals opname of modelvernieuwing). Dit onderscheid maakt gerichte prestatieoptimalisaties mogelijk voor verschillende workloadtypen.

Bijdragers

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

• Prabhjot Kaur | Senior Cloud Solution Architect

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

Volgende stappen

• Wat is het Fabric Datawarehouse?
• Warehouse-connectiviteit
• Wat is Copilot in het Data Warehouse?
• CI/CD in Fabric Data Warehouse
• Data Warehouse architectuur

Gerelateerde bronnen

• Kies een analytische gegevensopslag in Microsoft Fabric
• Wat is een data lake?
• Dataopslag en Analyse