Microsoft Fabric als Data Engineering Platform

Microsoft beweert dat Fabric een alles-in-één analytics oplossing is voor bedrijven die alles dekt, van data verplaatsing tot data science, Real-Time Analytics en Business Intelligence. Het kan worden gezien als een soort besturingssysteem waarop verschillende data tools verblijven. Deze blog evalueert vanuit een platformperspectief hoe Microsoft Fabric kan worden gebruikt om een end-to-end data engineering oplossing te implementeren.

Architectuur

Het grootste voordeel van Fabric is dat het een Software-as-a-Service (SaaS) oplossing is. Dit betekent dat de eindgebruiker met Fabric geen cloudinfrastructuur hoeft te implementeren of te onderhouden. Dit is een enorm voordeel, maar brengt ook enkele nadelen met zich mee, zoals je in de volgende secties zult lezen.

Afbeelding 1: Microsoft Fabric SaaS Basis

Een uniek verkoopargument van Fabric is dat alle Fabric-services zijn gebouwd op hetzelfde datameer, genaamd OneLake. Een van de voordelen van het gebruik van OneLake is dat Power BI direct gebruik kan maken van de gegevens die door ETL-pijplijnen naar een Lakehouse of Warehouse zijn gebracht. Dit elimineert de noodzaak om DirectQuery te gebruiken om realtime gegevens op te halen of Import om snapshots van de gegevens op te slaan in een Power BI-dataset. De functie die gebruikers in staat stelt om realtime gegevens uit OneLake direct te gebruiken in Power BI-rapporten wordt DirectLake genoemd.

Afbeelding 2: DirectQuery, Import & DirectLake

Netwerken

Zoals eerder vermeld, is Microsoft Fabric een SaaS-service, wat betekent dat alle infrastructuur wordt beheerd door Microsoft. Dit betekent ook dat je gegevens zich buiten het interne netwerk van het bedrijf bevinden. Een vraag die veel bedrijven hebben, is: Waar worden mijn gegevens opgeslagen? Het korte antwoord is: ergens in Azure. Fabric Workspaces kunnen worden verbonden met Fabric-capaciteiten. Deze capaciteiten zijn Azure-resources die binnen een bepaalde regio worden gehost, maar niet binnen een Azure VNET in het abonnement van de klant.

Een andere mogelijke zorg kan zijn dat de gegevens beschikbaar zijn via het openbare internet. Gelukkig heeft Microsoft zojuist Azure Private Link-ondersteuning voor Fabric uitgebracht. Met Azure Private Link kunnen klanten het netwerkverkeer naar Fabric beperken. Dit betekent dat Fabric kan worden afgesloten van het openbare internet en dat alleen verkeer van het interne netwerk is toegestaan. Let op dat Azure Private Link-ondersteuning nog in publieke preview is.

Naast Azure Private Link heeft Microsoft ook net twee methoden uitgebracht om verbinding te maken met gegevens die zijn gehost in zelfbeheerde opslagdiensten, namelijk de VNET Data Gateway en Managed private endpoints. De VNET Data Gateway brengt extra kosten met zich mee en ondersteunt momenteel alleen Dataflows Gen2, Power BI Semantic Models en Power BI Paginated Reports. De managed private endpoints zijn inbegrepen in de prijs van de capaciteit; echter, ze worden alleen ondersteund op F64 of hogere SKU's. Let op dat de capaciteit kan worden gepauzeerd en hervat om kosten te besparen, bijvoorbeeld in het geval dat de gegevens alleen tijdens kantooruren hoeven te worden verwerkt en toegankelijk zijn.

DTAP-cyclus

Ontwikkelaars willen over het algemeen veel flexibiliteit in hoe ze toegang hebben tot gegevens om afhankelijkheden te minimaliseren en niet gehinderd te worden tijdens de ontwikkeling van nieuwe functies. Het bieden van een hoog niveau van flexibiliteit in een productieomgeving kan echter riskant zijn en zou de zorgeloze workflow van ontwikkelaars wegnemen. Aan de andere kant, bij het bouwen en onderhouden van betrouwbare productiewerkstromen, is het van het grootste belang dat componenten grondig worden getest voordat ze in productie worden vrijgegeven. Het is een best practice om de ontwikkelings-, test-, acceptatie- en productieomgeving te scheiden. Dit stelt ontwikkelaars in staat om vrij nieuwe items te bewerken of te creëren zonder het risico productiegegevens te verstoren, terwijl ze nog steeds eventuele potentiële bugs kunnen ontdekken voordat de items naar productie worden vrijgegeven.

In Fabric kan men verschillende werkruimten creëren om omgevingen te scheiden. De werkruimten hosten Fabric-items zoals Lakehouses en Warehouses, die op hun beurt de gegevens hosten. Dit betekent echter niet dat items uit één werkruimte geen toegang kunnen hebben tot gegevens uit een andere werkruimte. Bijvoorbeeld, een Dataflow in de ontwikkelingswerkruimte kan gegevens naar een Lakehouse in de productie-werkruimte schrijven. Er zijn geen netwerkbeperkingen die de gegevens van verschillende werkruimten/omgevingen kunnen scheiden. De enige manier om ervoor te zorgen dat gebruikers geen gegevens naar items in een productie-werkruimte kunnen schrijven, is door het beheren van de permissies van het item/werkruimte.

Bij het werken met gescheiden omgevingen is het belangrijk om ervoor te zorgen dat de verschillen tussen omgevingen tot een minimum worden beperkt. Microsoft Fabric heeft geïntegreerde Deployment pipelines om nieuwe of bewerkte items van de ene werkruimte naar de andere te propaganderen in de DTAP-cyclus. Dit betekent dat er geen behoefte is om YAML-pipelines te schrijven, zoals voor de implementatie van Synapse-artifacts. Deployment pipeline-regels kunnen worden geconfigureerd in elke opeenvolgende fase van de Deployment pipeline, om ervoor te zorgen dat elk item is gekoppeld aan de corresponderende items in die werkruimte. Bijvoorbeeld, het verbinden van een Notebook met het corresponderende standaard Lakehouse van die werkruimte. Op het moment van schrijven worden Dataflows Gen2 niet ondersteund in Deployment pipelines. Verder zijn Lakehouses, Warehouses, Data pipelines, Notebooks en Datamarts nog in preview.

Git-integratie

Het hebben van een goede versiecontrole is een andere essentiële mogelijkheid voor het onderhouden van productie-werkstromen. Git stelt ontwikkelaars in staat samen te werken door middel van branches en controleert wat naar productie gaat door pull-requests te gebruiken. Bovendien stelt Git snelle debugging en roll-back mogelijk in het geval van een incident. Microsoft Fabric integreert met Azure DevOps repos om de definitiebestanden van verschillende items op te slaan. Op het moment van schrijven ondersteunt Git-integratie geen Warehouses, Dataflows Gen2 en Dashboards. Microsoft vermeldt dat de geschatte releasedatum voor ondersteuning van dataflows in Q2 2024 ligt. De documentatie geeft echter niet duidelijk aan of dit Dataflows Gen2 omvat. Er zijn momenteel geen aangekondigde investeringsgebieden voor Warehouse- en Dashboard Git-ondersteuning.

Conclusie

Dus, vanuit het perspectief van een data engineering platform, wanneer zou je Microsoft Fabric moeten gebruiken en wanneer zou je meer gevestigde data engineering platforms zoals Synapse Analytics of Azure Databricks moeten gebruiken?

Over het algemeen is Microsoft Fabric een geweldig platform dat de ontwikkeling versnelt en snel inzicht geeft in je data. Het is ongelooflijk krachtig wanneer verschillende persona's, zoals data engineers, data scientists en Power BI-ontwikkelaars, samenwerken op hetzelfde platform om end-to-end data-oplossingen te bouwen met gebruik van de OneLake-architectuur.

Aan de andere kant zijn veel functies van het platform nog steeds niet ondersteund, in preview of slechts gedeeltelijk algemeen beschikbaar. Bovendien is de interface duidelijk nog in ontwikkeling. De meeste dingen werken heel intuïtief, maar sommige interfaces lijken buggy en foutmeldingen geven niet altijd duidelijke aanwijzingen over waar je moet zoeken. Naar mijn mening is het grootste nadeel van Fabric echter het beperkte niveau van omgevingsscheiding. Het hebben van slechts één beveiligingsniveau tussen ontwikkeling en productie verhoogt het risico op productie-incidenten aanzienlijk.

Als je vanaf nul begint en geen strikte productiedeallijnen hebt, kun je aannemen dat de meeste Fabric-items zowel Git-integratie ondersteuning als Deployment pipeline ondersteuning zullen hebben in de nabije toekomst. Het gebrek aan een goede scheiding van omgevingen is echter een onderwerp dat waarschijnlijk niet zal worden opgelost. Dus, als het hebben van netwerk gescheiden omgevingen belangrijk voor je is in plaats van alleen te vertrouwen op het instellen van de juiste permissies om gebruikers te verbieden om productiegegevens te verstoren, dan is Microsoft Fabric niet het platform voor je data engineering praktijken.