AI-projecten zijn afhankelijk van data die uit verschillende systemen komt en bruikbaar, controleerbaar en actueel is. Lees hoe ETL en ELT werken, welke keuzes daarbij horen en hoe u schemawijzigingen, ontbrekende waarden, herkomst en datakwaliteit beheerst.
ETL of ELT: waar vindt de datatransformatie plaats?
ETL staat voor extract, transform, load: data wordt uit bronnen gehaald, eerst aangepast en daarna naar een doelsysteem geladen. Bij ELT volgt de transformatie pas nadat de ruwe data is opgeslagen. Die volgorde bepaalt waar rekenwerk plaatsvindt, hoeveel broninformatie behouden blijft en hoe snel wijzigingen in de verwerking kunnen worden doorgevoerd. Beide patronen kunnen geschikt zijn voor AI; de keuze hangt af van databronnen, beveiligingseisen, volumes en de beschikbare infrastructuur.
ETL is nuttig wanneer data vóór opslag moet worden gefilterd of gepseudonimiseerd, of wanneer het doelsysteem weinig transformatievermogen heeft. Het nadeel is dat een bewerking in de laadketen informatie kan verwijderen die later toch nodig blijkt. ELT bewaart doorgaans een ruwe kopie, zodat nieuwe transformaties opnieuw kunnen worden uitgevoerd. Dat vergroot de flexibiliteit, maar vraagt om opslagbeheer, toegangscontrole en duidelijke scheiding tussen ruwe en bewerkte datasets.
Een praktische keuze is vaak niet volledig ETL óf ELT. Gevoelige velden kunnen vóór opslag worden verwijderd, terwijl verdere normalisatie en samenvoeging in het datawarehouse gebeuren. Leg per stap vast wat verandert en waarom. Zo kunnen ontwikkelaars en data-analisten beoordelen of een fout in de bron, de transformatie of de uiteindelijke AI-invoer zit.
Data uit verschillende bronnen betrouwbaar inladen
Een AI-dataset begint vaak bij bronnen met uiteenlopende eigenschappen: relationele databases, API’s, spreadsheets, logbestanden of documenten. Een database kan wijzigingen vrijwel direct leveren, terwijl een API alleen periodieke exports aanbiedt. Bij elke bron spelen andere vragen: hoe wordt authenticatie geregeld, welke records zijn nieuw of aangepast, en wat gebeurt er als een verbinding halverwege een batch wegvalt? Zonder expliciete laadstrategie ontstaan dubbele records, gemiste wijzigingen of onbedoelde overschrijvingen.
Een volledige extractie is eenvoudig te begrijpen, maar kan bij grote tabellen inefficiënt worden en de belasting op bronsystemen verhogen. Incrementeel laden beperkt dat werk, bijvoorbeeld met een wijzigingstijdstip, oplopend ID of CDC (change data capture). Die methoden hebben randgevallen. Tijdstempels kunnen dezelfde waarde hebben, klokken kunnen afwijken en verwijderde records zijn niet altijd zichtbaar. Een betrouwbare verwerking houdt daarom bij tot welk punt data aantoonbaar is verwerkt en kan een batch veilig opnieuw uitvoeren.
Maak per bron afspraken over paginering, rate limits, time-outs, retries en verwijderingen. Sla laadmetadata op, zoals bron, extractietijd, batch-ID en het bereik van de opgehaalde records. Daarmee is achteraf te zien of een model een onvolledige export heeft gebruikt. Bewaar foutieve records apart met een reden, in plaats van ze stilzwijgend over te slaan. Dat maakt herstel mogelijk zonder dat één problematisch record de hele stroom blokkeert.
Schemawijzigingen opvangen zonder datastromen te breken
Een schema beschrijft onder meer veldnamen, datatypes en relaties tussen velden. In de praktijk verandert een schema wanneer een bronsysteem een kolom toevoegt, een veld hernoemt of een datum ineens als tekst aanlevert. Zulke wijzigingen kunnen een ETL-pipeline laten stoppen, maar kunnen ook ongemerkt verkeerde waarden opleveren. Een numerieke klantcode die als getal wordt ingelezen, kan bijvoorbeeld voorloopnullen verliezen. Een downstream-model ziet dan wel data, maar niet langer dezelfde betekenis.
Behandel schemawijzigingen daarom als contractwijzigingen tussen producent en afnemer. Leg vast welke velden verplicht zijn, welke optioneel zijn en welke datatypes en betekenissen gelden. Een extra optioneel veld kan vaak veilig worden toegevoegd; een hernoeming of wijziging van eenheid vraagt doorgaans om een expliciete migratie. Validatie bij het inladen kan onverwachte velden signaleren en bekende compatibele wijzigingen accepteren. Zo wordt niet elke uitbreiding een incident, maar blijft een betekenisvolle verandering zichtbaar.
Voorzie pipelines van tests op kolomnamen, datatypes, nullwaarden en plausibele bereiken. Bij een onverwachte wijziging kan de verwerking stoppen, de afwijkende batch in quarantaine plaatsen of doorgaan met een waarschuwing. Welke reactie passend is, hangt af van het risico: een extra beschrijvend veld is iets anders dan een gewijzigd valutaveld. Houd schema-versies bij en test transformaties met representatieve oude én nieuwe voorbeelden. Daarmee voorkomt u dat een aanpassing alleen werkt voor de nieuwste export en historische data onbruikbaar maakt.
Ontbrekende waarden herkennen en verantwoord behandelen
Een lege waarde is niet automatisch hetzelfde als nul, onbekend of niet van toepassing. In een bronsysteem kan een veld ontbreken omdat iemand het niet heeft ingevuld, omdat de informatie nog niet beschikbaar was of omdat de export de waarde niet ondersteunt. Als een pipeline al die gevallen omzet naar dezelfde lege string of nul, verdwijnt betekenisvolle informatie. Een AI-model kan die verschillen niet achteraf reconstrueren en leert mogelijk patronen die vooral het registratieproces weerspiegelen.
Begin met het meten van ontbrekende waarden per veld, bron, periode en relevante groep. Een totaalpercentage kan een probleem verbergen: een veld kan gemiddeld bijna altijd gevuld zijn, maar structureel ontbreken in één regio of productcategorie. Onderzoek ook of ontbrekende waarden samenhangen met de uitkomst die een model moet voorspellen. Dat patroon kan informatiewaarde hebben, maar kan ook een vorm van vertekening zijn wanneer het registratiebeleid verandert.
De behandeling hangt af van het gebruik. Een record met ontbrekende sleutelvelden kan ongeschikt zijn voor koppeling, terwijl een beschrijvend veld soms leeg mag blijven. Mogelijke keuzes zijn records uitsluiten, waarden imputeren, een aparte categorie gebruiken of een indicator toevoegen die aangeeft dat de oorspronkelijke waarde ontbrak. Imputatie moet binnen de trainingsdata worden geleerd en vervolgens op validatie- en productiedata worden toegepast; anders lekt informatie tussen datasets. Bewaar waar mogelijk de oorspronkelijke waarde en leg de imputatieregel vast, zodat analyses controleerbaar blijven.
Dataherkomst vastleggen voor controleerbare AI-uitkomsten
Dataherkomst, of lineage, beschrijft waar gegevens vandaan komen en welke bewerkingen ze hebben ondergaan. Voor een AI-project betekent dit niet alleen weten uit welke database een dataset komt. Ook de extractiedatum, bronselectie, transformatieversie, filters en koppelingen bepalen welke voorbeelden uiteindelijk aan een model zijn aangeboden. Als een voorspelling ter discussie staat, is zonder die informatie moeilijk vast te stellen of de oorzaak in het model, de brondata of een bewerking ligt.
Leg herkomst vast op meerdere niveaus. Op datasetniveau zijn bron, eigenaar, doel, periode en toegangsclassificatie relevant. Op batchniveau helpen een unieke ID, extractietijd, aantallen records en checksums om bestanden te herkennen en herverwerking te vergelijken. Op veldniveau kan documentatie betekenis, eenheid, toegestane waarden en transformaties beschrijven. Een veld met de naam bedrag is bijvoorbeeld onvoldoende gespecificeerd zonder te weten of het om euro’s, centen, bruto- of nettobedragen gaat.
Herkomstregistratie hoeft niet te betekenen dat elke cel een uitgebreid auditlog krijgt. Dat kan opslag en beheer onnodig complex maken. Kies detail op basis van risico en gebruik: bij persoonsgegevens of gereguleerde beslissingen kan fijnmaziger inzicht nodig zijn dan bij geaggregeerde statistiek. Bewaar daarnaast de versie van de code en configuratie waarmee een dataset is gemaakt. Dan kan een nieuwe uitvoering worden vergeleken met de oorspronkelijke, ook als de bron inmiddels is bijgewerkt. Toegangsrechten horen bij dit ontwerp: herkomstinformatie mag zelf geen gevoelige waarden onnodig blootleggen.
Datakwaliteit testen vóór data een model bereikt
Datakwaliteit is meer dan controleren of een bestand kan worden ingelezen. Een pipeline kan technisch succesvol draaien terwijl sleutels dubbel zijn, datums buiten het verwachte bereik vallen of een join records onbedoeld vermenigvuldigt. Tests moeten daarom zowel de structuur als de inhoud beoordelen. Denk aan verplichte velden, unieke identificaties, geldige datatypes, toegestane categorieën en relaties tussen tabellen. Voor tijdreeksen zijn ook ontbrekende perioden en onverwachte sprongen relevant.
Gebruik verschillende soorten controles. Schema-tests signaleren gewijzigde kolommen, integriteitstests controleren relaties en statistische controles volgen bijvoorbeeld verdelingen, nullpercentages en aantallen records. Een vaste grens werkt goed voor harde bedrijfsregels, zoals een unieke primaire sleutel. Voor statistische patronen is een vergelijking met historische waarden vaak informatiever dan één universeel maximum. Een plotselinge halvering van het aantal transacties kan wijzen op een bronstoring, maar kan ook passen bij een bekende seizoensverandering.
Bepaal per test wat er gebeurt bij een afwijking. Een kritieke controle kan de publicatie van een dataset blokkeren; een minder urgente afwijking kan een waarschuwing opleveren en een onderzoeksticket aanmaken. Maak die indeling expliciet, anders worden waarschuwingen genegeerd of worden kleine afwijkingen onnodig productiestops. Registreer testresultaten samen met de datasetversie en laat controles draaien op zowel nieuwe batches als representatieve historische data. Dat voorkomt dat een regel die voor actuele records werkt, oude perioden stilzwijgend afkeurt of juist fouten uit het verleden normaliseert.
Transformaties afstemmen op analyse en AI-training
Data die geschikt is voor rapportage is niet automatisch geschikt als modelinvoer. Een dashboard kan bijvoorbeeld maandtotalen gebruiken, terwijl een voorspelmodel individuele gebeurtenissen nodig heeft met een tijdstip en entiteit-ID. Transformeer daarom vanuit een helder gebruiksdoel: welke eenheid vormt één voorbeeld, welke kenmerken zijn op dat moment beschikbaar en wat probeert het model te voorspellen? Een verkeerde definitie van een voorbeeld leidt tot dubbeltellingen of tot kenmerken die informatie uit de toekomst bevatten.
Dat laatste heet datalek of target leakage. Het ontstaat wanneer een feature direct of indirect informatie bevat die pas na de voorspelling beschikbaar komt. Een statusveld dat achteraf op afgerond wordt gezet, kan bijvoorbeeld bijna rechtstreeks de uitkomst verklappen. Ook aggregaties vragen aandacht: een gemiddelde over de volledige dataset kan informatie uit de validatieperiode meenemen. Bereken zulke bewerkingen uitsluitend op trainingsdata of binnen de juiste tijdsvensters en pas de vastgelegde parameters daarna toe op andere datasets.
Normalisatie, categorische codering, tekstopschoning en deduplicatie moeten reproduceerbaar zijn. Bewaar regels en parameters bij de modelversie; verander ze niet stilzwijgend in een gedeelde dataset die meerdere experimenten gebruiken. Controleer bovendien of transformaties signalen verwijderen die voor bepaalde groepen relevant zijn. Een datum omzetten naar alleen een maand kan seizoenspatronen behouden, maar volgorde binnen de maand uitwissen. De juiste granulariteit volgt uit de toepassing en moet met domeinkennis en modelvalidatie worden getoetst, niet alleen met een technisch geslaagde pipeline.
ETL- en ELT-pipelines monitoren en reproduceerbaar maken
Een pipeline houdt niet op bij een geslaagde eerste uitvoering. Bronnen kunnen vertragen, API-responses veranderen en geplande taken kunnen overlappen. Monitoring moet daarom niet alleen de status van een taak tonen, maar ook laten zien hoeveel data is verwerkt, hoe lang stappen duren en welke kwaliteitscontroles afwijken. Een taak die groen eindigt terwijl er nul records zijn geladen, is functioneel geen succes. Meet laadvolumes, vertraging ten opzichte van de brontijd en de verhouding tussen geaccepteerde en afgekeurde records.
Ontwerp verwerking zo dat herstarten veilig is. Idempotente stappen leveren bij herhaling hetzelfde resultaat op in plaats van duplicaten te maken. Dat kan met stabiele sleutels, gecontroleerde upserts en batchadministratie. Bewaar foutmeldingen en de context van de mislukte stap, maar voorkom dat logs gevoelige gegevens bevatten. Retries zijn nuttig bij tijdelijke netwerkfouten; bij een structureel ongeldig schema kunnen ze juist dezelfde fout herhalen en de bron extra belasten. Maak onderscheid tussen herstelbare en niet-herstelbare fouten.
Reproduceerbaarheid vraagt om versiebeheer van code, configuratie, schema’s en relevante afhankelijkheden. Koppel elk resultaat aan de gebruikte bronextractie en pipelineversie, zodat een analyse opnieuw kan worden opgebouwd zonder te vertrouwen op de huidige stand van een bronsysteem. Bij periodieke herverwerking is ook het beleid voor correcties van belang: wordt een historische fout overschreven, als nieuwe versie opgeslagen of als correctie geregistreerd? Die keuze beïnvloedt trendanalyses en modelvergelijkingen. Leg haar vast voordat incidenten leiden tot verschillende interpretaties van dezelfde dataset.
Veelgestelde vragen
Wanneer kies je voor batchverwerking en wanneer voor streaming in een AI-pipeline?
Kies voor streaming als een AI-toepassing actuele gegevens nodig heeft om snel te reageren; kies voor batchverwerking als updates periodiek voldoende zijn. Denk bijvoorbeeld aan fraudedetectie tijdens een betaling tegenover een wekelijkse voorspelling van de vraag. Beoordeel niet alleen hoe snel data binnenkomt, maar vooral hoe snel een beslissing nodig is en wat de gevolgen zijn van vertraging.
Streaming brengt doorgaans meer technische complexiteit mee, onder meer rond volgorde, dubbele berichten en herstel na onderbrekingen. Begin daarom met de vereiste actualiteit en kies de eenvoudigste verwerkingsvorm die daaraan voldoet. Een combinatie is ook mogelijk: streaming voor tijdkritische signalen en batches voor periodieke analyses of correcties.
Wat is het verschil tussen een data lake, datawarehouse en lakehouse voor AI-projecten?
Een data lake is vooral geschikt voor het bewaren van uiteenlopende gegevens in hun oorspronkelijke of weinig bewerkte vorm, terwijl een datawarehouse gegevens doorgaans gestructureerd opslaat voor betrouwbare analyse. Een lakehouse combineert kenmerken van beide: het biedt ruimte voor diverse datatypes en probeert tegelijk beheer en analyse op een gecontroleerde manier te ondersteunen.
Voor AI kan een lake ruwe bestanden en grote hoeveelheden data huisvesten, terwijl een warehouse voorbereide datasets levert voor analyse of training. De keuze hangt af van bestaande infrastructuur, soorten data, beheerbehoeften en wie de gegevens gebruikt. Belangrijker dan de naam van het platform is dat ruwe en bewerkte data herkenbaar gescheiden zijn en dat teams datasets kunnen terugvinden en hergebruiken.
Hoe lang moet je ruwe data voor een AI-project bewaren?
Bewaar ruwe data niet langer dan nodig is voor het vastgestelde doel, de wettelijke verplichtingen en de controleerbaarheid van het project. Er bestaat geen universele bewaartermijn: een korte termijn kan volstaan voor operationele verwerking, terwijl een langere termijn nodig kan zijn om een dataset te reconstrueren of een modelresultaat te onderzoeken.
Leg per gegevenscategorie vast waarom opslag nodig is, wie toegang heeft en wanneer verwijdering plaatsvindt. Neem ook back-ups, exports en afgeleide datasets mee in het beleid. Als gegevens moeten worden verwijderd, controleer dan of kopieën in trainingsbestanden of andere afgeleide producten eveneens moeten worden aangepast. Laat bewaartermijnen en verwijderprocedures toetsen aan de toepasselijke privacyregels en interne afspraken.
Hoe voorkom je verschillen tussen data bij modeltraining en data in productie?
Voorkom verschillen tussen training en productie door dezelfde featuredefinities, transformaties en versies te gebruiken in beide omgevingen. Als bijvoorbeeld een categorische waarde tijdens training anders wordt gecodeerd dan bij voorspellingen, kan het model productiegegevens verkeerd interpreteren, ook als de pipeline technisch blijft werken.
Leg vast welke invoervelden en bewerkingsstappen bij een modelversie horen en test die met voorbeelden uit zowel de trainingsomgeving als de productieomgeving. Vergelijk bovendien de verdelingen en ontbrekende waarden van kenmerken zodra het model live is. Wijkt de productie-invoer structureel af, onderzoek dan of de bron, de verwerking of het gebruikspatroon veranderd is voordat je het model opnieuw traint.
Hoe bepaal je of AI-trainingsdata voldoende goede labels heeft?
AI-trainingsdata heeft voldoende goede labels wanneer die labels de bedoelde uitkomst consistent en bruikbaar weergeven voor de toepassing. Controleer daarom eerst of labelinstructies eenduidig zijn en of verschillende beoordelaars dezelfde voorbeelden vergelijkbaar labelen. Een groot aantal voorbeelden compenseert geen structureel onduidelijke of foutieve labels.
Laat een representatieve steekproef onafhankelijk beoordelen en onderzoek waar beoordelaars van mening verschillen. Kijk ook naar de verdeling van labels: zeldzame categorieën kunnen te weinig voorbeelden bevatten om betrouwbaar te leren. Leg vast hoe labels tot stand kwamen, wanneer ze zijn toegekend en welke onzekerheden bestaan. Bespreek twijfelgevallen met domeindeskundigen en herzie de instructies als terugkerende verschillen wijzen op onduidelijke definities.
