Een notebook in Microsoft Fabric combineert uitvoerbare code, toelichting en zichtbare resultaten in een omgeving voor gegevensverwerking. Vooral voor data-engineering is dat praktisch: een ontwikkelaar kan data uit een Lakehouse lezen, met Spark transformeren en het resultaat als Delta-tabel beschikbaar stellen. Het gebruiksgemak heeft echter een keerzijde. Een notebook dat op een willekeurige dinsdag correct draait, is nog geen betrouwbare productiecomponent. Herhaalbaarheid, duidelijke broncontracten, logging, toegangsrechten en gecontroleerde publicatie zijn minstens zo belangrijk als werkende Python-code.
Deze handleiding behandelt de functie van notebooks binnen Fabric, de inrichting van een eerste PySpark-verwerking en de stappen die nodig zijn voordat een notebook in een geplande gegevensketen thuishoort. Als doorlopend voorbeeld dient een fictieve groothandel die dagelijkse orderbestanden uit een bronomgeving ontvangt. Het eindresultaat is een gecontroleerde tabel met verkoopregels voor Power BI. Waar concrete bediening per Fabric-omgeving verschilt, staat het onderliggende ontwerpprincipe centraal.
Wat is een Fabric-notebook en waarvoor dient het?
Een notebook bestaat uit cellen met code en eventueel Markdown-uitleg. Code wordt uitgevoerd binnen een geschikte computeomgeving, veelal via een Apache Spark-sessie. In Fabric zijn notebooks geïntegreerd met onder meer Lakehouses en kunnen ze deelnemen aan Data Factory-pipelines. Ze zijn daardoor geschikt voor verkenning, het opschonen van grote datasets, het schrijven van datatransformaties, het bouwen van herbruikbare functies en het onderzoeken van afwijkende records.
Een notebook is geen vervanging van elk ander Fabric-onderdeel. Een eenvoudige gegevenskopie kan overzichtelijker zijn met een kopieeractiviteit. Een SQL-georiënteerde transformatie kan beter passen in een Warehouse. Het notebook biedt vooral meerwaarde wanneer programmeerbare logica, complexere bewerkingen of Spark-verwerking daadwerkelijk nodig zijn. De technologiekeuze hoort de taak te volgen, niet de voorkeur van een individuele ontwikkelaar.
Het verschil tussen een verkennend en een operationeel notebook
Bij een eerste analyse worden vaak voorbeeldrijen getoond, kolommen tijdelijk hernoemd en handmatig cellen uitgevoerd. Voor exploratie is dat uitstekend. Voor productie ontstaat een probleem wanneer de uitkomst afhankelijk is van de uitvoervolgorde, variabelen uit een oude sessie of een bestand in de persoonlijke map van de ontwikkelaar. Een operationeel notebook moet vanaf een nieuwe sessie reproduceerbaar starten, vereiste parameters ontvangen en bij onjuiste invoer herkenbaar stoppen.
In een professioneel ontwerp worden bronlocaties, datums en omgevingsnamen daarom niet overal in de code gekopieerd. Ze worden vastgelegd als parameters of in beheerde configuratie. Ook wordt vooraf bepaald wat bij een lege daglevering gebeurt: is nul verkoop een geldige uitkomst of ontbreekt de bron? Dat verschil mag niet pas bij een misleidend dashboard worden ontdekt. Documentatie geeft voor elke invoer de betekenis, het verwachte formaat, de eigenaar en de minimale datakwaliteit aan.
Voorbeeldarchitectuur: van orders naar rapportagetabel
De groothandel ontvangt elke ochtend orderregels met OrderId, OrderDate, CustomerId, Quantity en UnitPrice. Een bronbestand wordt eerst als ruwe levering bewaard in de Bronze-laag. Een notebook controleert of verplichte velden bestaan, zet datatypen om, verwijdert exact gedefinieerde dubbele leveringen en produceert een Silver-tabel met gevalideerde orderregels. Een aanvullende Gold-transformatie berekent bruikbare aggregaties, bijvoorbeeld omzet per maand en productgroep.
Het vastleggen van Bronze, Silver en Gold is geen automatische garantie voor kwaliteit. De waarde ontstaat doordat per laag expliciet is vastgesteld welke bewerkingen toegestaan zijn. Bronze bewaart de bron zo getrouw mogelijk voor herleidbaarheid. Silver bevat controleerbare bedrijfsregels. Gold richt zich op afgesproken analytische definities. Voor iedere overgang hoort een test te bestaan die verklaart waarom records zijn toegevoegd, gewijzigd of afgewezen.
Lakehouse koppelen en gegevens lezen
Een Fabric-notebook werkt binnen de rechten en instellingen van zijn werkruimte. Voor de verwerking moet het juiste Lakehouse beschikbaar zijn en moet duidelijk zijn onder welke identiteit de code wordt uitgevoerd. Interactieve rechten van de ontwikkelaar zijn niet automatisch gelijk aan de rechten van een geplande pipeline. Een notebook dat persoonlijk probleemloos leest, kan daardoor onder een andere uitvoercontext mislukken.
Een minimale PySpark-stap kan bijvoorbeeld een bestaande tabel lezen:
orders = spark.read.table("bronze_orders")
orders.printSchema()
print("Aantal bronregels:", orders.count())
De tabelnaam is fictief en veronderstelt dat deze in de actieve catalogus beschikbaar is. In een productieontwerp wordt het volledige tabelpad afgestemd op de werkelijke Lakehouse-configuratie. printSchema() controleert de ingelezen structuur, maar bewijst nog niet dat alle waarden juist zijn. Een kolom kan immers als tekst bestaan terwijl een numeriek bedrag werd verwacht. Daarom volgt pas daarna de inhoudelijke validatie.
Schema, datatypen en ongeldige records
Fouten ontstaan regelmatig wanneer systemen een getal met een decimale komma exporteren, ontbrekende klantcodes als lege tekst aanleveren of datums door elkaar in verschillende formaten opslaan. Impliciete typeconversie kan dan onverwacht null-waarden opleveren. Een gedegen notebook bepaalt bewust welke waarden verplicht zijn en welke bronvariaties worden geaccepteerd.
Een voorbeeld van een eerste controle:
from pyspark.sql import functions as F
required = {"OrderId", "OrderDate", "Quantity", "UnitPrice"}
missing = required - set(orders.columns)
if missing:
raise ValueError(f"Verplichte kolommen ontbreken: {sorted(missing)}")
invalid = orders.filter(
F.col("OrderId").isNull() | (F.col("Quantity") <= 0)
)
if invalid.limit(1).count() > 0:
raise ValueError("Bron bevat ongeldige orderregels")
Deze regels zijn een illustratie. In echte omgevingen kunnen retouren negatieve aantallen bevatten en moet de controlevraag dus anders worden geformuleerd. De juiste validatie is altijd afhankelijk van het bedrijfsproces. Afgekeurde records kunnen in een afzonderlijke quarantainevoorziening worden opgeslagen, inclusief reden en bronbestand, in plaats van zonder verklaring uit de dataset te verdwijnen.
Herhaalbaarheid en dubbele verwerking voorkomen
Stel dat een pipeline om 07.00 uur een notebook aanroept en na twintig minuten door een netwerkstoring opnieuw start. Zonder bescherming kan dezelfde orderlevering tweemaal in de rapportagetabel terechtkomen. Een praktische maatregel is een stabiele zakelijke sleutel gebruiken en vastleggen hoe nieuwe en bestaande orders worden verwerkt. Waar de situatie daarom vraagt, kan een MERGE-bewerking tegen een Delta-tabel worden toegepast in plaats van onvoorwaardelijk regels toe te voegen.
Een goede herstarttest voert dezelfde levering bewust twee keer uit. Het aantal unieke order-ID’s en de berekende omzet moeten na de tweede run gelijk blijven, tenzij de bedrijfsregels expliciet anders voorschrijven. Ook een gedeeltelijk voltooide verwerking moet worden getest: kan het proces veilig opnieuw draaien wanneer Bronze wel is geschreven, maar Silver nog niet? Het antwoord hoort in het ontwerp te staan voordat een planning wordt ingeschakeld.
Prestaties: niet elke extra handeling is onschuldig
Spark verdeelt verwerking over taken en partities. Dat biedt schaalbaarheid, maar verkeerd gekozen operaties kunnen duur zijn. Een herhaald count() op een grote dataset veroorzaakt bijvoorbeeld telkens werk. Eveneens kan het onnodig verzamelen van miljoenen records op de driver tot geheugentekorten leiden. Het tonen van tien voorbeeldregels is iets anders dan een volledige dataset naar lokale Python-objecten kopiëren.
Optimalisatie begint bij het uitvoeringsplan en de gegevensomvang. Beperk bronkolommen, filter zo vroeg als logisch mogelijk, vermijd onnodige brede joins en kies een passende schrijfstrategie. Een technisch snelle uitvoering die correcte historische wijzigingen mist, is echter geen succes. Meet daarom zowel runtime en capaciteit als resultaatkwaliteit. De vertraging van een enkele geplande run zegt weinig zonder inzicht in hoeveelheid gegevens en betrokken bewerkingen.
Notebook en pipeline: verantwoordelijkheden scheiden
Het notebook voert de inhoudelijke transformatie uit; een pipeline kan verantwoordelijk zijn voor planning, afhankelijkheden, vervolgactiviteiten en foutafhandeling. Daarmee blijven bedrijfslogica en procesorkestratie beter van elkaar te onderscheiden. Een pipeline kan pas de semantische rapportagelaag verversen nadat het notebook aantoonbaar succesvol is afgerond en de datakwaliteitscontroles zijn geslaagd.
Ontwerp bij elke stap een betekenisvolle foutmelding. Alleen een technische uitzondering zonder datasetnaam of leveringsdatum kost beheerders onnodig veel zoektijd. Registreer ten minste de verwerkingsdatum, run-identificatie, bron, aantal verwerkte records, aantal afgekeurde records, duur en resultaatstatus. Let op dat logs geen gevoelige persoonsgegevens of toegangsgegevens bevatten. Bij een storing moet een beheerder kunnen bepalen of opnieuw uitvoeren veilig is.
Versiebeheer en wijzigingen gecontroleerd uitrollen
Een notebook dat door meerdere medewerkers wordt gebruikt, vraagt om dezelfde zorgvuldigheid als andere software. Leg codewijzigingen vast met een korte motivatie, laat belangrijke transformaties beoordelen en test niet direct met vertrouwelijke productiedata. Gebruik waar mogelijk ontwikkel- en productieafspraken, opslag van configuratie buiten vaste codewaarden en een aantoonbare rollbackprocedure. De mogelijkheden voor bronbeheer en deployment hangen af van de gebruikte Fabric-inrichting.
Belangrijk is ook om datawijzigingen te onderscheiden van codewijzigingen. Een nieuwe kolom in het bronbestand kan het schema veranderen zonder dat het notebook zelf is aangepast. Daarom worden tests niet alleen na een release uitgevoerd, maar ook bij afwijkingen in het broncontract. Een eigenaar van de bronlevering moet bereikbaar zijn wanneer nieuwe of ontbrekende velden worden gedetecteerd.
Toegangsrechten en vertrouwelijke gegevens
Notebooktoegang, toegang tot een werkruimte en toegang tot onderliggende data zijn verschillende zaken. Een medewerker die code mag aanpassen, hoeft niet vanzelfsprekend alle klantgegevens te kunnen bekijken. Zorg voor passende werkruimterollen en datamachtigingen en toets expliciet de identiteit waaronder geplande verwerking draait. Gevoelige data hoort niet in voorbeelden, schermopnamen of uitvoer van foutmeldingen te belanden.
Voor het groothandelsvoorbeeld kan een ontwikkelaar werken met synthetische orderregels, terwijl geautomatiseerde verwerking uitsluitend de benodigde productietabellen gebruikt. De administratieve eigenaar legt bewaartermijnen, incidentmeldingen en toegangsevaluaties vast. Schakel niet breed toegangsrechten uit om een enkele mislukte notebookrun te verhelpen; onderzoek eerst welke identiteit en welk recht daadwerkelijk ontbreken.
Kwaliteitscontrole: drie zakelijke acceptatietests
Een bruikbare acceptatieset bevat meer dan het antwoord ‘notebook succesvol uitgevoerd’. Test eerst een normale levering met vooraf bekende totaalaantallen en omzet. Test daarna een bestand waarin een verplichte kolom ontbreekt; verwerking moet gecontroleerd stoppen of het probleem expliciet isoleren. Test tot slot een tweede uitvoering van dezelfde levering; er mogen geen onbedoelde dubbeltellingen ontstaan.
Vergelijk na de verwerking bron- en doelaantallen met de gedocumenteerde regels voor uitval, retouren en correcties. Het verschil moet verklaarbaar zijn. Controleer vervolgens een steekproef van orderbedragen met een onafhankelijke berekening. Leg vast wie deze tests goedkeurt en welke afwijking acceptabel is. Pas na een geslaagde controle kan de verwerkte tabel als bron voor een managementdashboard worden beschouwd.
Waar kunnen AI en Copilot helpen?
AI kan helpen bij het verklaren van Spark-foutmeldingen, het beschrijven van een schema of het voorstellen van testgevallen. Gegenereerde code verdient dezelfde controle als handgeschreven code: syntaxis, gegevenssemantiek, prestaties en rechten moeten worden beoordeeld. Copilot-functies en beschikbaarheid verschillen per Fabric-omgeving, regio, licentie en beheerdersinstellingen. Een voorbeeldprompt vormt daarom geen garantie dat een specifieke functie binnen iedere tenant beschikbaar is.
Bij de praktijkgerichte trainingen van Cursus Compleet over AI en Microsoft Copilot komt het kritisch beoordelen van gegenereerde analyses en code aan bod. Voor organisaties die met Fabric werken, is de belangrijkste vaardigheid het vertalen van een technisch voorstel naar aantoonbaar correcte bedrijfsgegevens, niet het ongecontroleerd kopiëren van een codefragment.
Wanneer is een notebook de juiste keuze?
Een notebook is passend wanneer datatransformaties programmeerbare logica vereisen en de organisatie het beheer ervan aankan. Het is minder passend als een eenvoudige ingebouwde gegevensstap hetzelfde resultaat met minder onderhoud oplevert. Een goede keuze hangt samen met de omvang van de gegevens, bestaande kennis, frequentie, latency, kosten en fouttolerantie. Vergelijk deze kenmerken vóór implementatie en niet pas nadat een complexe oplossing is gebouwd.
Voor de fictieve groothandel levert een notebook vooral waarde op wanneer meerdere bronformaten, inhoudelijke controles en een herhaalbare Delta-verwerking nodig zijn. Het succes is meetbaar: iedere run is herleidbaar, dezelfde levering verandert niet onbedoeld het totaal, fouten worden zichtbaar en een nieuwe beheerder kan zonder mondelinge toelichting vaststellen hoe de keten werkt.
Conclusie
Notebooks in Fabric maken krachtige data-engineering mogelijk, maar de kwaliteit zit niet in het aantal uitgevoerde cellen. Een betrouwbaar notebook gebruikt expliciete broncontracten, gecontroleerde transformaties, herstartbare uitvoer, passende rechten en meetbare controles. Met deze basis kan een notebook veilig onderdeel worden van een grotere Fabric-gegevensketen, zonder dat de juistheid van rapportages afhankelijk blijft van toeval of een individuele ontwikkelaar.
Verder leren over Microsoft Fabric
De keuze voor een geschikte training hangt af van het gebruikte platform en de dagelijkse werkzaamheden. Als binnen het cursusaanbod een aantoonbaar passende Fabric-training beschikbaar is, kan die direct aan dit artikel worden gekoppeld. Anders is een inhoudelijk afgebakende incompany-training over data-engineering en kwaliteitscontroles passender dan een willekeurige cursus uit een ander cluster.
Training over Microsoft Fabric bespreken →