Data Ingestion methodes in Microsoft Fabric

Wanneer je voor het eerst aan de slag gaat met Microsoft Fabric zal een van je eerste vraagstukken waarschijnlijk zijn: “Wat is de beste manier om de data uit mijn bronsystemen in Fabric te krijgen?” 

Dankzij OneLake, de centrale opslag voor alle services binnen de Fabric-architectuur, zijn er veel manieren om data in te laden. Sommige ken je misschien al van andere Microsoft-producten, andere zijn volledig nieuw.

In deze blog zetten we de verschillende methodes op een rij. Ook bespreken we de voor- en nadelen, en in welke scenario’s elke methode het beste werkt.

De volgende methodes komen aan bod:

1. Data pipeline 
2. Dataflow 
3. Notebook 
4. Eventstream 
5. Shortcut 
6. Mirroring 

De methodes op een rijtje

1. Data pipeline

Gebruikers van de Microsoft-stack kennen data pipelines waarschijnlijk al van Azure Data Factory of Azure Synapse Analytics. In de basis zijn het orkestratie-tools. Met de vele beschikbare “activities” kun je er ook data mee inladen en transformeren in Fabric.

Voor- en nadelen van pipelines

Een voordeel van pipelines is dat het in principe een no-code oplossing is, waardoor deze makkelijk te begrijpen is. Door middel van “drag and drop” kunnen er allerlei activiteiten op een canvas geplaatst worden die parallel of sequentieel worden uitgevoerd. Een veelgebruikte activiteit is de “Copy data activity”. Deze heeft een goede performance voor het kopiëren van grote datavolumes door gebruik te maken van “intelligent throughput optimization” en (aanpasbare) parallelliteit. Daarnaast zijn er ook allerlei activiteiten voor het toepassen van control flow logica, zoals if-then-else statements en for-each loops. Hierdoor is het ook mogelijk om een metadata-gedreven aanpak te gebruiken om geautomatiseerd een grote hoeveelheid items te laden. Ten slotte zijn er ook activitieten die een externe actie kunnen triggeren (zowel binnen als buiten Fabric), zoals het uitvoeren van een notebook, stored procedure of dataflow.

Een ander voordeel is dat er een grote hoeveelheid standaard connectoren beschikbaar is om gemakkelijk data in te laden vanuit allerlei bronnen. Een mogelijk nadeel hierbij is dat in sommige gevallen de opties van de standaard activities te beperkt zijn,  bijvoorbeeld wanneer je data ophaalt met een API en een complexe JSON-response (met meerdere geneste levels) terugkrijgt. Deze is lastig uit te lezen met de “Copy data activity” in een pipeline. Met een notebook zijn hier een stuk meer mogelijkheden voor. Verder hebben pipelines geen (native) mogelijkheden voor het transformeren van data. Dit kan wel gemakkelijk worden opgelost door bijvoorbeeld een Notebook-activity of een Stored Procedure-activity toe te voegen die de gewenste transformatie uitvoert.

Verder is het goed om te weten dat pipelines in Fabric veel overeenkomsten hebben met die in Data Factory. Toch zijn er ook verschillen. Zo zijn er een aantal handige nieuwe activiteiten beschikbaar, zoals een Outlook- en Teams- activiteit waarmee notificaties kunnen worden gestuurd met output vanuit andere pipeline-activiteiten. Ook is er een nieuwe “semantic model refresh” activity. Er zijn echter ook een aantal zaken die ontbreken of verschillen: zo kan je in Fabric geen gebruik maken van een Self-Hosted Integration Runtime voor het laden van on-premise data. Wel kan je hiervoor de on-premise Data Gateway of de Virtual Network Data Gateway gebruiken. Verder zijn er in Fabric pipelines geen aparte Linked Services en datasets voor de verbinding met brondata. In plaats daarvan maak je rechtstreeks op een activiteit een connectie aan. Deze kan je vervolgens terugvinden en bewerken in het menu “manage connections and gateways”. Ook triggers worden niet meer apart aangemaakt maar zijn geïntegreerd in de pipeline. Hierbij wordt onderscheid gemaakt tussen “schedules” (de oude schedule triggers) en “triggers” (event triggers, maken gebruik van de nieuwe Fabric-service Data Activator).

2. Dataflow (Gen2)

Ook dataflows zijn een oude bekende uit de wereld van Azure en Power BI. De dataflow in Fabric heeft een aantal upgrades gehad ten opzichte van eerdere versies, vandaar het label “Gen2”. Het is een low/no code interface voor het laden en transformeren van data die gebruik maakt van de Power Query Engine.

Voor- en nadelen van dataflows

Een voordeel van de dataflow is dat deze een grafische interface heeft, waarbij elke stap in het ETL-proces direct inzichtelijk is (vergelijkbaar met de Power Query editor in Power BI). Voor het inladen van de data kan gebruik gemaakt worden van een groot aantal standaard connectoren voor zowel on-prem data (via de gateway) als cloud-bronnen. Data-transformaties kunnen via de interface worden gedaan, maar indien gewenst kan de gebruiker ook zelf de Power Query formuletaal (M) invoeren of aanpassen via de “advanced editor”. Dit alles maakt deze methode erg geschikt voor gebruikers met een wat minder technische achtergrond en gebruikers die vanuit Power BI naar Fabric overstappen.

Een nadeel van dataflows is dat deze niet gemakkelijk parametriseerbaar zijn. Hierdoor zijn ze minder geschikt om geautomatiseerd een grote hoeveelheid tabellen in te laden. Ook hebben ze geen out-of-the-box mogelijkheid voor “loopen” over brondata, wat bijvoorbeeld vereist is voor het ophalen van data uit een paginated API. Verder is er geen ingebouwde functionaliteit aanwezig voor data-validatie. Wel kan een dataflow worden opgenomen als activiteit in een pipeline. Op die manier kan je functionaliteiten van beide methodes combineren.

Qua performance zijn dataflows het meest geschikt voor kleinere datavolumes. Bij grote volumes is de Power Query Engine niet de meest geschikte tool en zal deze veel Capacity Units gebruiken ten opzichte van de Spark Engine (notebooks) en de “Copy Data activity” in pipelines. Wel kan je de optie “Fast Copy” aanzetten bij het ophalen van je brondata. Hiermee wordt gebruik gemaakt van de backend van de “copy data activity” in plaats van de Power Query Engine. Echter werkt deze optie dan weer niet in combinatie met alle mogelijke transformatiestappen in een dataflow.

Tenslotte nog belangrijk om te vermelden is dat de term “data flow” of “dataflow” door Microsoft in het verleden is gebruikt voor verschillende services. Dataflow Gen2 in Fabric komt het meest overeen met de eerdere PowerBI dataflows (Gen1). Deze zijn in het verleden ook wel aangeduid als “Wrangling data flows” en zijn gebouwd op Power Query. Data flows in Azure Data Factory / Synapse Analytics zijn gebouwd op de Synapse Spark infrastructuur en maken gebruik van een eigen taal genaamd “data flow script”. In het verleden werden deze ook wel aangeduid als “mapping data flows”. Door deze verschillen zijn de soorten dan ook niet compatible en kunnen ze dus niet 1-op-1 gemigreerd worden naar Fabric.

3. Notebook

Met Notebooks kan de gebruiker door middel van code (Python, Scala, SQL of R) data laden en transformeren. Hierbij wordt gebruik gemaakt van de Spark engine. Er kan connectie worden gemaakt met een grote verscheidenheid aan bronnen door het gebruiken van allerlei standaard libraries.

Voor- en nadelen van notebooks

Client libraries zijn meteen een belangrijk voordeel van het gebruik van notebooks. Deze bieden over het algemeen meer flexibiliteit dan de standaard connectoren in pipelines en dataflows. Een ander voordeel is dat je gebruik kan maken van parameters en functies, waardoor je bestaande logica gemakkelijk kan hergebruiken. Als je de inkomende data wil valideren of data-quality checks uit wil voeren is dit gemakkelijk in te bouwen, bijvoorbeeld door gebruik te maken van Python-package “Great Expectations”. Verder hebben notebooks uitgebreide mogelijkheden voor het ophalen van data vanuit APIs. Dit kan ook met pipelines en dataflows, echter zijn deze vaak beperkt in bijvoorbeeld de authenticatie-opties. Ook zijn notebook beter geschikt voor het uitlezen van complexe json-structuren.

Een handige eigenschap van notebooks is dat je met meerdere developers tegelijk hetzelfde notebook kan bewerken. Wijzigingen worden automatisch opgeslagen en je kan zien waar de andere persoon op dat moment mee bezig is.

Qua performance zijn notebooks erg geschikt voor het verwerken van grote datavolumes doordat ze gebruik maken van de Spark engine (distributed computing). Een aandachtspunt hierbij is dat het opstarten van een Spark-sessie enige tijd kost en dus overhead kan creëren wanneer dit meerdere keren moet gebeuren in een ETL-proces. Dit kan echter worden opgelost door gebruik te maken van “high concurrency mode”, waarbij meerdere notebooks gebruik kunnen maken van dezelfde Spark-sessie. Wanneer je juist aan het werk bent met kleine datavolumes is er ook de optie (momenteel in preview) om een Python-notebook te maken (in plaats van een “standaard” Fabric notebook gebaseerd op de Spark Engine). Deze draaien op een single-node cluster en zijn daarmee efficiënter en kostenbesparend.

Een potentieel nadeel van het gebruik van notebooks is dat het een code-first oplossing is. Voor gebruikers die gewend zijn aan “drag and drop” ETL-tools kan het lastig zijn om de overstap te maken richting notebooks. Een ander nadeel is dat het lastiger is om in één oogopslag te zien wat er allemaal gebeurt in een notebook ten opzichte van een pipeline of een dataflow, omdat het minder visueel en meer tekstueel is. Door goed gebruik te maken van coding best practices (zoals het gebruik van markdown cells voor documentatie, parameters en functies voor repeterende patronen) zorg je ervoor dat je notebook begrijpelijk blijft.

4. Eventstream

Evenstreams zijn Fabric’s oplossing voor het inlezen van real-time event data van bijvoorbeeld IoT-apparaten of applicatielogs. Het is een no-code (drag and drop) oplossing waarmee event-data kan worden geladen vanuit verschillende bronnen (bijvoorbeeld Azure Event Hubs en Azure IoT Hub), getransformeerd en weggeschreven. Het wegschrijven van de data kan onder andere naar een Lakehouse, KQL database of Fabric Activator.

Aangezien dit binnen Fabric de enige methode is voor het inlezen van event-data zullen we niet uitgebreid ingaan op de voor- en nadelen ervan ten opzichte van andere methodes. Wel is het goed om te vermelden dat real-time streaming over het algemeen veel compute en storage capaciteit kost. Er wordt dan ook aangeraden om minimaal een F4 capacity te gebruiken voor deze feature.

5. Shortcut

Shortcuts zijn objecten in OneLake die verwijzen naar een andere opslaglocatie (filesystem). Deze locatie kan zowel intern (binnen je eigen Fabric OneLake) als extern zijn. Externe locaties kunnen bijvoorbeeld een ADLS Gen2 account of een Amazon S3 bucket zijn. Het is ook mogelijk om shortcuts te maken naar een on-premises locatie door gebruik te maken van de on-premises data gateway. Het creëren van een shortcut kan zowel via de Fabric UI als de Fabric REST API. Je kan een shortcut maken naar een folder met daarin verschillende bestanden of naar een individueel bestand. Wanneer je een shortcut hebt aangemaakt verschijnt deze als een folder in OneLake die je kan benaderen vanuit een Lakehouse of een KQL database. Het is mogelijk om shortcuts te maken naar verschillende bestandstypes. Echter zullen alleen bestanden van het Delta Parquet format automatisch herkend worden als tabel in een Lakehouse. Andere bestandstypen zijn alleen beschikbaar in de “files” folder van het Lakehouse. Shortcuts in een KQL-database worden behandeld als external tables.

Voor- en nadelen van shortcuts

Een belangrijk voordeel van een shortcut is dat de brondata niet fysiek hoeft te worden gekopieerd. Dit bespaart tijd, kosten en het milieu. Ook zorgt dit voor een (near) real-time connectie naar de brondata. Shortcuts maken gebruik van caching. Wanneer de data eenmalig is opgeslagen in de Fabric-cache zullen opeenvolgende reads gebruik maken van deze cache, tenzij het externe bestand in de tussentijd is geüpdatet. In dat geval zal het bestand opnieuw worden uitgelezen en opgeslagen in de cache. De retentieperiode voor deze cache kan door de gebruiker worden ingesteld in de instellingen van de Fabric Workspace. Een bijkomend voordeel hiervan is dat je zelf geen logica hoeft te bouwen voor het incrementeel updaten van je data.

Een belangrijk verschil van shortcuts ten opzichte van de eerder besproken methodes is dat deze puur een verwijzing maken naar een andere data-locatie. Het is niet mogelijk om iets aan de data te veranderen binnen een shortcut. Je moet deze data dus zien als je “raw” of “bronze”-laag, die vervolgens verder getransformeerd kan worden met bijvoorbeeld een notebook.

Een nadeel van shortcuts is dat je afhankelijk bent van de externe locatie. Als er issues zijn met deze locatie zal de shortcut ook niet beschikbaar zijn. Een ander aandachtspunt is dat er mogelijk egress fees moeten worden betaald wanneer de Fabric-capacity zich in een andere regio bevind dan de externe locatie.

Shortcuts kunnen alleen gebruikt worden voor open file formats / open-source systemen. Voor relationele storage (zoals Azure SQL database) kan je gebruik maken van Mirroring.

6. Mirroring

Net als shortcuts kan Mirroring worden gebruikt om data vanuit een externe locatie real-time te synchroniseren naar OneLake. Mirroring is bedoeld voor het repliceren van data uit relationele systemen. Je kan hierbij zelf instellen of je de gehele database wil repliceren of slechts een subset van tabellen. Een verschil met shortcuts is dat de data hierbij wel fysiek wordt opgeslagen in OneLake (behalve bij gebruik van metadata mirroring, hier komen we zo meteen op terug). Hierbij wordt eenmalig een replica van de data gemaakt in het Delta Parquet format. Vervolgens worden wijzigingen op de bron gesynchroniseerd naar Fabric door middel van het “Change Data Capture” principe. De gerepliceerde data kan vervolgens worden benaderd vanuit een SQL endpoint.

Er zijn 3 soorten van mirroring te onderscheiden, waarvan de laatste 2 momenteel nog in preview zijn:

• Database mirroring repliceert een gehele database (of een subset van tabellen) in Fabric. Dit kan bijvoorbeeld worden gebruikt voor Azure SQL databases en Snowflake databases.
• Metadata mirroring synchroniseert alleen metadata in Fabric, in plaats van dat de data fysiek wordt gekopieerd. Dit kan bijvoorbeeld worden gebruikt voor het uitlezen van de structuur van Azure Databricks Unity Catalog. Voor het benaderen van de data zelf worden vervolgens shortcuts gebruikt.
• Open mirroring kan worden gebruikt om data in het open Delta Lake table format naar Fabric te schrijven vanuit een Public API of de Fabric Portal. Dit maakt het in principe voor elke applicatieontwikkelaar mogelijk om data te repliceren in Fabric.

Aangezien de gerepliceerde data wordt opgeslagen in Fabric moet je (in tegenstelling tot shortcuts) wel betalen voor opslag. Wel is het zo dat je een aantal TB “mirroring storage” gratis krijgt bij je Fabric capacity. Dit aantal is gelijk aan de SKU van je Fabric capacity (F2 = 2TB, F4 = 4TB etc.). Verder kan je ook hier te maken krijgen met cross-region egress fees, net als bij shortcuts.

Voor- en nadelen van mirroring

Voordelen van deze methode komen overeen met die van shortcuts: de brondata wordt (near) real-time geüpdate en je hoeft hier zelf geen logica voor te bouwen. Een nadeel van deze methode is dat er (nog) een aantal limitaties zijn waardoor niet alle databases, tabeltypes en datatypes worden ondersteund. Verder kan je alleen een gehele tabel mirroren, je kan dus geen kolommen uitsluiten. Ook zal je, net als bij shortcuts, aanvullende methodes (zoals een notebook) moeten gebruiken wanneer je de data wil transformeren.

Final notes

In de tabel hieronder zijn de belangrijkste voor- en nadelen en aandachtspunten per methode nog een keer samengevat.

Hopelijk heeft deze vergelijking geholpen bij het kiezen van de juiste data ingestion methode voor jouw Fabric-project. Hieronder nog een aantal punten om mee te nemen in je afweging:

• Welke skills zijn er momenteel aanwezig in mijn team? Voelt men zich prettig bij een code-based oplossing (notebooks) of is er behoefte aan een meer grafische interface? (pipelines, dataflows)
• Moet er een migratie plaatsvinden vanuit een bestaande data-oplossing naar Fabric? Onderzoek in dat geval of er elementen hergebruikt kunnen worden (bijvoorbeeld pipelines vanuit Azure Data Factory)
• Hoe belangrijk is het voor mijn organisatie om real-time data ter beschikking te hebben? Volstaat een periodiek ELT-proces of is er behoefte aan constante updates via shortcuts/mirroring?
• Houd rekening met de kosten (Capacity Units) van verschillende methodes. Dit kan sterk verschillen afhankelijk van het volume van de data, update-frequentie etc. Probeer eens een testje te doen waarbij je dezelfde bron op verschillende manier ontsluit en gebruik de Capacity Metrics App om het verbruik te monitoren!
• Houd ook rekening met de schaalbaarheid van je oplossing en het (toekomstige) data-volume. Een dataflow voelt misschien als een eenvoudige voor je eerste Fabric-experiment, maar kan deze ook gemakkelijk worden hergebruikt of geparametriseerd? En hoe is de performance bij grote data-volumes?
• Zijn er databronnen die achter een Private Network zitten en/of on-premise bronnen? In een pipeline of dataflow kan je gebruik maken van de on-premise Data Gateway of de Virtual Network Data Gateway. In Spark workloads (notebooks en eventstreams) kan je gebruik maken van een Managed Private Endpoint.
• Probeer zoveel mogelijk consistentie aan te brengen in het laden van verschillende bronnen. Wanneer je te maken hebt met veel verschillende typen brondata kan het handig of zelfs noodzakelijk zijn om verschillende methodes naast elkaar te gebruiken. Je kan in dat geval echter wel een “Parent pipeline” of “Parent notebook” maken die het laden van verschillende “child items” orkestreert.
• Houd de Microsoft Fabric blog in de gaten want er worden elke maand nieuwe features toegevoegd. Zaken die nu nog niet mogelijk zijn, zijn dat over een aantal maanden wellicht wel!

Twijfel je na het lezen van deze blog nog over welke methode het beste geschikt is voor jouw organisatie? Of kan je wel wat hulp gebruiken bij de implementatie? Neem dan contact op met ilionx, onze Fabric-experts staan voor je klaar!