Transcriptie: Lake, warehouse of lakehouse? Mathijs Visscher en Nicky Boon over data engineering bij Stedin

Hey, hallo allemaal. Welkom bij een nieuwe aflevering van de CodeKlets podcast. Gemaakt voor coders, voor coders en iedereen die interesse heeft in development.

Ja.

Hey, vandaag gaan we het hebben over data engineering. Ja, het is misschien het niet meest zichtbare vakgebied, maar wel volgens mij echt een belangrijke fundering onder de moderne data platformen en AI oplossingen. Ik zeg altijd maar zonder goede data geen slimme AI. En volgens mij is het de tijd om er snel in te gaan duiken. Maar dat gaan we gelukkig niet alleen doen, samen met z'n tweetjes.

Ja, klopt.

We hebben twee hele goede data engineers weten te strikken.

We zijn eigenlijk geen data engineers, hè, Kishen. Dat is een bommetje droppen.

Oeh, dat wordt echt zo. Ja, oké, dit wordt al meteen interessant. Want we zien al meteen de interessante ontwikkelingen rondom data engineering en de titels die er nu ontstaan.

Volgens mij.

Maar ja, misschien is het wel beter als jullie jezelf even aankondigen dan. Want ja, ik kan natuurlijk wel iets ervan maken. Maar misschien zou Mathijs als eerst even kunnen beginnen met zichzelf voor te stellen.

Zeker, ik ben Mathijs. Ik ben data platform engineer. En ik denk dat we er zo wel op terug gaan komen wat dan precies het verschil is. Vroeger bij vorige werkgevers en klanten wel data engineer geweest. Dus ik kan er wel wat over vertellen. En nu dus data platform engineer bij Stedin.

Ja, oké, mooi. Nou, dan heel erg benieuwd wat het verschil is, maar... En we hebben ook nog een andere gast, Nicky Boon.

Ja, dankjewel. Nicky is ook data platform engineer bij Stedin. En ook in een verleden wel ook als data engineer werkzaam geweest. Dus we weten wel het een en ander van. En ja, het is leuk om misschien dadelijk ook het verschil even een beetje toe te leggen.

Ja, lijkt me wel zeker leuk.

Zeker interessant.

Ik heb er gewoon helemaal geen verstand van.

Oeh, nou wie...

Dan gaan we wat aan doen vandaag.

Ja, precies.

Ja, absoluut. Nee, oké. Misschien, ja, zullen we gelijk induiken dan wat het verschil is?

Nou, ik wil eigenlijk eerst nog even kijken hoe jullie, want wij zijn ook software ontwikkelaars, en ergens, want ik geloof niet dat als je geboren bent dat je denkt, nou, nu word ik data engineer. Dus je bent er op een of andere manier ingerold. Ik weet niet wie daar iets over wil vertellen. Hoe ben je hiertoe gekomen?

Ja, nee, ik zou wel eerlijk bekennen, het stond niet vroeger in mijn vriendenboekjes van, wat je wil je later worden, dat ik dacht van, nou, data platform engineer, dat wordt hem.

Dat je als klein mannetje bij iemand op kantoor ging kijken die data-engineerde was.

Met een tekening.

Met een tekening.

Mijn verhaal is eigenlijk, ik ben ooit, toen ik begon met studeren, ben ik psychologie gaan studeren. ...vanuit dat ik niet zo goed wist wat ik met mezelf aan moest...

...en.

Dat wel interessant vond. Ik dacht van, nou, dat zie ik wel, want als ik het toch niet weet... ...dan kan ik net zo goed alles gaan doen... ...in ieder geval iets wat ik leuk vind. Daar kwam ik er vrij snel achter dat ik... ...vooral de statistiek en de wiskundekant heel leuk vond. Dus een beetje die afslag genomen binnen psychologie... ...en daarna richting data science doorgeschot. En daar ga je natuurlijk vrij snel van statistische modellen... ...waar je nog wat dingen kan klikken... ...waar dan al wat code onderhangt... ...naar zelf modellen schrijven. En eigenlijk op die manier is het met coderen in aanraking gekomen. In eerste instantie vooral coderen in R. Dat wordt wat meer in de wetenschappelijke wereld gebruikt. En later Python. En vanaf daar is het eigenlijk een soort van glijdende schaal natuurlijk. Dan zak je steeds dieper weg. Eerst schrijf je een simpel programmaatje om een kerstboompje in Python te maken. En vervolgens zit je hiermee met van alles bezig. Dus ja, zo doen we dat eigenlijk gewoon vanuit studie.

Ja, cool.

En jij Mathijs?

Ja, eigenlijk best wel vergelijkbaar. Dus dat is een beetje saai.

Maar ook niet weten wat je met jezelf aan moest en psychologie gaan studeren?

Nou, ongeveer wel eigenlijk. Ik heb zelf psychology en technology op de TU Eindhoven gestudeerd. Dus het lijkt er eigenlijk best wel veel op. Ook een soort van de studiekeuze gemaakt doordat ik op de website van de Technische Universiteit Eindhoven ging kijken. En het doorlas en dacht, psychologie met een beetje techniek en programmeren. ...en toen ook geprogrammeerd. Ik had gelijk in het eerste kwartiel object-oriented Java programmeren. Het was het eerste jaar dat de studie in het Engels was... ...en die leraar die dat gaf, die kon helemaal geen Engels. Dat is wat ik er nog van weet. En ik vond het vak helemaal vreselijk. Ik dacht echt, ik wil helemaal niet programmeren. Maar ja, op een gegeven moment meer en meer gaan doen. Ik vond de statistische vakken ook heel interessant... ...toen ook daarom omgeschoold naar richting data science... Toen geprobeerd solliciteren als data scientist. Maar toen kwam je er toch achter dat er veel meer te doen was in data engineering. En toen, nou ja, vind je ook in de data engineering terechtgekomen.

Oh, wauw, ja.

Vergelijkbaar pad, ja. Ja, wat interessant.

Dat is ook een van ons tweeën kunnen uitnouden.

Inderdaad. Nu denk ik wel van, jeetje, there goes the diversity. Nee, maar je noemt echt wel een paar dingen al, weet je. Je noemt data science, data engineering hebben we het net ook genoemd. En ik mis er eentje. Wat heb je nog meer? Wat je met data allemaal niet kan doen. Je hebt data-analysten natuurlijk. Daarna data-analysten. Voor degene die echt nu helemaal nieuw in de wereld van data rollen, zouden we misschien die rollen kunnen uitleggen? Even heel kort.

Ja, dus een data-engineer die maakte dataproducten. Dus die zorgde ervoor dat de rauwe brondata opgewerkt wordt tot data waar je ook daadwerkelijk iets mee kan. Dus als je een AI-model wil gaan laten draaien op data die niet geëngineerd is, om het maar even zo te zeggen. Ja, dan zeggen ze altijd shit in, shit out. Dat gaat niet werken. Er zitten misschien duplicaten in, er zitten velden in die niet kloppen. Nee, er zijn heel veel manieren, heel veel dingen die niet goed kunnen zijn aan de data. Dus wat een data engineer doet, die verrijkt, combineert, engineert dus de data. En vervolgens kan dus of een analist of een data scientist, kan er mee aan de slag. En de grap is een beetje van het pad van wat Nicky en ik allebei soort van bewandeld hebben. Als je data science als studie doet, dan heb je dus altijd al een perfecte dataset. En als je dan vervolgens in het werkveld terechtkomt, dan kom je erachter dat de wereld niet zo in elkaar zit.

Daar waarschuw je je wel altijd voor op je studie. Van hé, zo is het niet in het echt.

Nee, perfect Excel-etje, dat krijg je niet.

Bedankt, nu ben ik goed voorbereid.

Ja, precies.

Ja, dus nu ben je echt aan het leren.

Ja, alleen nu doe ik geen data science meer.

Nou, ja, ja, ja. Nee, snap ik. Is het ook een vak wat echt belangrijk is in de AI? Data science? Waar je in zou moeten duiken om misschien met AI het ene en ander goed te kunnen begrijpen... En uit te kunnen voeren.

Ja, ik denk dat het nu een beetje een ingewikkelde discussie wordt. Wat nou het verschil is tussen AI, data science en machine learning. Ik denk dat we daar een beetje voor op moeten passen.

Ja, dat denk ik.

Maar je bedoelt met de vraag, is data engineering belangrijk voor?

Nou, kijk, weet je. Data science is natuurlijk ook een manier om, je informatie te analyseren. Het is misschien ook wel te structureren, denk ik. Want wat leer je daar over het algemeen?

Bij de data science. Dat gaat echt voornamelijk over machine learning. Wel voor een heel groot gedeelte. Ook wel wat andere. Maar dat is echt aan het einde van de keten. Dus we hadden ook wel wat data visualization. Dat hadden wij op zich ook wel. We hadden wat process mining. Waarin je door event data bepaalde inzichten gaat verkrijgen. Maar het grootste gedeelte is toch wel de klassieke machine learning. Waarin je dus decision trees en de key nearest neighbors. Al die klassieke machine learning modellen. Uiteindelijk ook iets van neurale netwerken. Nou, ik kan me voorstellen dat ze nu ook veel over LLMs... ook, nou ja, wat de wiskunde daarachter is en dat soort dingen. Dus echt de wetenschap achter al die, ja, datamodellen, data, et cetera, et cetera.

Ja, misschien om het nog iets platter te slaan voor mensen die denken... god, ik heb geen idee wat al die modellen ook betekenen. Want dat, ja, dat je natuurlijk gestudeert. Maar Datasite is vaak, zeg maar, zeker met die modellen bezig... om de toekomst te voorspellen. Althans modellen maken om te voorspellen wat er gaat gebeuren. Of dat nou is wanneer mensen iets gaan kopen of whatever. Terwijl om nog ook op je eerder vraag terug te komen. Een analist kijkt eigenlijk altijd naar het verleden. Die kijkt wat heeft daar plaatsgevonden. Die probeert dat te structureren.

Ja, inderdaad. En je zei het net ook al, dus de data-engineer is over het algemeen dan bezig om de data dan verder te verrijken. Is dat zijn enige doel? Maar wat zijn dan nog meer dingen die een data-engineer doet en waarom het zo belangrijk is?

Het is een beetje als een soort van de infrastructuur of zo. Je hebt natuurlijk ook echt de platformengineering, echt de infrastructuur van een dataplatform, maar je maakt eigenlijk gewoon de gebaande paden voor die data scientist en die data analyst. Dus je probeert gewoon hele bronnen van data te ontsluiten en kwaliteit te checken, normaliseren, om nog maar weer een term erin te gooien. om het schoon te maken, te verrijken misschien. Dus het is wel breder dan wat, maar ook verschillend per use case.

Ja, vaak moeten ze het ook in een bepaald model toebrengen. Dus je hebt natuurlijk allerlei bronnen en data, maar dat betekent niet dat dat ook... Aan de eindketen moet die data er misschien heel anders qua model ook uitzien. Dus een data scientist die modellen maakt, die wil vaak een platte tabel hebben. Maar een analist die rapportages maakt, die wil vaak een ster model hebben, die dus meerdere bronnen weer combineert. Dus dat is dan ook de taak van de data engineer om het fit for purpose te krijgen. Dat je de data zo aanlevert, zodat ze verderop in de keten er ook echt iets mee kunnen.

Ja, leuk.

Maar is er in jullie geval wel een overlap, zeg maar, of is dat niet? Of is het gewoon echt wel een best wel een harde scheiding? Dus dat tussen data engineering en de science die erna komt? Of valt dat mee?

Ja, wij zijn dus weer data platform.

Ja, absoluut.

Om het weer eens van nog verwarrender te maken. Misschien handig dat we daar iets over willen. Ja, precies.

Begin daar maar mee. Ja, dat is wel handig.

Ja, dus wat je... Misschien leuk om met een voorbeeld dat aan te geven. Maar wat je veel bij bedrijven ziet, waar ze niet echt data platform engineering doen, is dat eigenlijk alle teams wat data engineers hebben, die maken eigenlijk allemaal hun eigen platformpje. En dan krijg je dus binnen een grote bedrijven dat je wel tien, twintig verschillende data platformpjes hebt. En wat we bij Stedin in ieder geval proberen, omdat we dus ook een data platform afdeling hebben, proberen we één data platform te bouwen om dus ervoor te zorgen dat die data engineers allemaal een beetje op dezelfde manier werken. Dus wij maken eigenlijk de patronen, de herbruikbare patronen die de data engineers kunnen gebruiken om hun data engineering te doen. Dus ja, dan voorkom je dat, nou Pietje wil misschien graag met tool A werken, maar Henk die wil weer met tool B werken. En bij de ene team gebruiken ze de ene strategie om hun deployments, dus om hun releases en dat soort dingen te kunnen doen. Als je dat allemaal gelijk trekt, dan kan het ook efficiënter zijn. Dan hoeft een data engineer alleen nog maar te data engineeren en eigenlijk niet meer over dat onderliggende na te denken.

Ja, ik snap hem. Ja. Ja, dat is eigenlijk hetzelfde. software development platform engineering is hetzelfde. Die zorgen dat ze een platform aanbieden, uitrollen, securities bij ons. Ja, het zal bij jullie ook zo zijn. Dat soort regels die worden daarmee gewaarborgd. Ja, oké, die bedrijf ik.

En hoe word je eigenlijk dan zo'n platform engineer?

Psychologie studeren.

Ja, blijkbaar wel. Hij heeft er echt veel mee te maken.

Ja, hij wordt volgens mij helemaal gek, denk ik. Ja, hoe word je dat?

Hoe kom je er niet vanaf? Kun je beter afdragen?

Dat is misschien beter afdragen, ja.

Is dat zo?

Nee, nee, nee.

Nee, ik denk wel dat er zit wel een bepaalde overlap in een soort van... Natuurlijk dat je iets van een technische achtergrond en daar wat voor interesse in ieder geval aan hebt. En ik denk toch wel, wat ik een beetje afgelopen jaren zie, het trekt wel altijd een soort van zelfde type mensen die toch wel bepaalde interesse in ieder geval hebben in... Bepaalde mate dus van hoe technisch iets moet zijn. Dus dat ze bijvoorbeeld, analistenwerk te makkelijk of te saai vinden. En toch wel een soort van een uitdaging zoeken in wat ingewikkeldere, complexere puzzels. Want dat is toch een beetje puzzelen met vrij directe feedback. Best praktisch werk voor achter een computer zitten. Dus ja, ik denk dat dat misschien voorspellende factoren zou kunnen zijn. Hoe je het verder wordt. Want ja, er is zover ik weet geen data engineering opleiding. Dus misschien op tolge school inmiddels, maar dat weet ik niet.

Maar ik trouw dat dat ook echt niet.

Misschien een bepaalde specialisatie of zo, dat bij informatica. Maar nee, dat zou ik ook niet weten. Maar wat je wel bij ons in team ziet, is dat er eigenlijk twee routes zijn. Of je bent eerst data engineer en vindt eigenlijk dat platformgedeelte het leukste. Misschien veel hebben ook bij een klant als data engineer gezeten en hielden zich eigenlijk ook bezig met, nou dan vaak een wat kleiner platformpje. En vinden vooral echt de inhoudelijke data niet zo heel erg interessant, maar voornamelijk de deploymentstraat die ze dan hebben opgezet en, de tools die eronder liggen. Dus de databricks of de fabrics komen misschien zo nog op. Dus uit die hoek is denk ik ongeveer de helft van ons team, dus meer is data engineer dan de data platform engineer geworden. En we hebben ook wat mensen die meer eigenlijk... meer gewoon eigenlijk DevOps engineer zijn... of software gemaakt hebben... of veel met Kubernetes bijvoorbeeld hebben gewerkt... veel met deployment pipelines. Dat soort dingen dat ze meer vanuit die hoek komen. Dus iets minder vanuit de data hoek. En dat is eigenlijk een beetje de... en die mix proberen we ook altijd wel een beetje te houden. Je wil toch wel als data platform engineer... in ieder geval een paar mensen wel hebben... die ook data engineer zijn geweest. Ik vergelijk het altijd met... als je een auto produceert... maar je kan niet auto rijden. Ja, dat is toch gewoon handig. Je wil wel in ieder geval gereden hebben om te weten hoe je een auto moet bouwen. Dat is met dit ook een beetje.

Ja, ja. Oké, en, wat is nou de toolbox voor een data engineer? Voor de mensen die misschien denken, oh misschien wel een leuk vak om in te duiken. Wat zou een goede toolbox zijn?

Ja, er wordt veel in Python geschreven als we beginnen bij de programmeertaler. Eigenlijk de meeste tools maken wel van iets van Spark gebruikt. Dus dat is de engine die de dataverwerking eigenlijk gaat doen. Dus ja, de meeste data engineers die werken dan met Python en Spark, wat dan PySpark genoemd wordt. Vaak in notebooks. Eigenlijk ook vanaf de studie deden wij ook al heel veel met notebooks. En dat is voor data engineering eigenlijk niet anders. Wordt veel met notebooks gewerkt. Ja, en Databricks, Fabric, Snowflake, dat zijn wel de veel voorkomende data engineering, moderne data engineering tools.

Ja, wat is Databricks? nog wat zijn Databricks of whatever.

Misschien nog wel ik denk dat je nog wel een cruciale vergeet wat wij ook nog wel veel zien ik denk dat je toch wel een sequel ook wel vaardig moet zijn oh ja dat.

Is zo normaal.

Tegenwoordig het is zo normaal, misschien wel de makkelijkste programmeren te leren volgens mij heeft er een paar 20 of 30 statements die je kan doen dus op een gegeven moment ben je wel uitgeleerd, Maar het is wel zeker nog steeds integraal onderdeel van ons werk ook.

Ja.

En om op jouw vraag terug te komen, wat is Databricks? Wat zijn Databricks? Databricks is, nou inmiddels is het wel, is het echt uitgenomen. Het is echt gewoon een, hoe moet ik het omschrijven, een data en analytics platform weer. Dus het is, een software oplossing die je kan afnemen via een cloud provider. Als Azure, als AWS. Waar je je data engineering kan doen. waar je tegenwoordig ook wat dingen kan visualiseren, waar je machine learning modellen kan draaien, waar dus die gekoppeld, die Spark Engine, die Mathijs zei, aanhangt.

Oh, oké, ja.

Dus het is eigenlijk een soort van web-based app om je coderen in te doen, je notebooks in te doen.

Ja, ja, ja.

Ik denk dat het makkelijkst is om te ontschouden. Ja, en het schedulen ervan.

En het schedulen, ja. Ja, het is wel een, ja, de naam zegt al iets dat het de bouwstede is, maar goed. Het is iets wat je gebruikt als bouwsteen of is het het uiteindelijke product, draait er iets op?

Het is eigenlijk een schilletje. Onder de motorkap zijn het gewoon virtuele machines waar dus die Spark-clusters die dus de dataverwerking doen. Ja, precies. Op je ADLS of op je S3-bucket, daar heb je gewoon je faal staan, wat dan in Databricks weer gevisualiseerd wordt als een soort van database, zeg maar. Dus het is een schilletje waar je dus inderdaad je notebooks maakt en als je die dan aftrapt of scheduled, dan gaan die Spark-clusters die dus eigenlijk op die virtuele machines draaien gaan, dus die data verwerken en dan weer schrijven naar zo'n faal weer in je S3 of in je ADLS. En in Databricks zie je dat dan maar in je database.

Oké.

En ik hoor ook wel eens in de data engineering werelden, een wereld hoor ik, datalake, warehouse, lakehouse. Ik had echt soms zoiets van, wow, wat zit er überhaupt een verschil in? Of we hebben het over hetzelfde. Zou je dat eens kunnen toelichten?

Zeker, ja. Ik denk dat warehouse een beetje natuurlijk het klassieke model, gewoon jaar 90 gestructureerde data, wat je in een tabelvorm ziet. Daarna is volgens mij de datalake een beetje opgekomen, Dat zit een beetje in de naam. Het wordt ook wel vaak Data Swamp genoemd in moderne presentaties. Want dat vinden ze leuk om het zo te noemen. Omdat ze dan kunnen laten zien hoe krachtig de lake house is. Maar het is eigenlijk gewoon een verzamelplek waar je gewoon alle type files kwijt kan. En dat heeft het voordeel. Je kan alle type files kwijt. Dat heeft het nadeel. Het is gewoon heel ongestructureerd. En alles raakt er een beetje in verzeld. En daardoor is het ook wat lastig om mee te werken. En een lake house is eigenlijk een soort van hoe is dat het promoten. Dus dat ga ik hier ook maar gewoon netjes doen. Het beste van beide werelden is eigenlijk een gestructureerde versie van zo'n data lake, waar je dus wel heel veel verschillende typen files kwijt kan, maar wel een wat gestructureerdere basis heeft.

En degene die het structureert, zijn dat data engineers of wie doet dat? Want die krijgen waarschijnlijk bronnen van alle kanten, die gaan een data lake in of... En dan wordt er iets gestructureerd door wie?

Ja, dus het idee van een lake house is dat je dus... Je slaat het wel op als files, maar de structuur zit in de files zelf, zeg maar. Dus net zoals dat je in je database je schema's hebt. Heb je dat in je files die je in een lake house hebt, heb je die ook weer. Dus het kruipt eigenlijk steeds verder naar elkaar toe. Een warehouse en een lake house eigenlijk. En het voornaamste verschil is dat een Lakehouse eigenlijk als files bestaat. En ook als er geen SQL-servertje draait, kan je die files gewoon bij z'n speaker openen en bekijken. En dat voor een warehouse heb je natuurlijk nog een server nodig om dan die database te kunnen bevragen. Maar ze doen steeds meer aan die... Wat je bijvoorbeeld ook hebt met Lakehouse, omdat het dus verschillende files zijn, wat je dus zou kunnen doen, wat dit ook heel krachtig maakt met heel veel data, Is dat je kan zeggen van oké, de data is nu te veel voor één machine. Dus wat we doen, we zogenaamd partitioneren de data. Bijvoorbeeld op datum of op een column waarvan jij handig denkt, dat is een logische manier om dit zo te structureren. En dan wat je dan kan zeggen is van oké, ik laat één jaar aan data door de ene machine doen. En ander jaar aan data door een andere machine doen. En dan ga ik later de uitkomsten weer samenbrengen. En dat is wat Spark dus ook heel krachtig maakt voor heel veel data. is dat hij heel veel parallel eigenlijk over verschillende machines kan doen.

Ja, en ik hoor ook in de data engineering wereld dat je dataoplossingen op batch manier of op een realtime manier zou kunnen verwerken. Wanneer zou je voor batch kiezen en wanneer realtime?

Ik zal bijna altijd voor bed kiezen.

Echt? Altijd? Ja? Oké.

Nou ja, de vraag is hoe snel wil jij tot actie overgaan? Dus als je logging en monitoring bijvoorbeeld doet van wat dan ook. Ja, dat wil je realtime. Want als er ergens een alarm afgaat waarop iets in de fik staat. Dan wil je niet na een half uur een bericht krijgen. Dan wil je gelijk een bericht krijgen. Maar wat je toch wel vaak ziet is. Wat je ook vaak binnen Stedin hoort. dan vragen mensen van... ja, we willen dit graag realtime doen. En dan vraag je, oké, hoe vaak wordt er naar het rapport gekeken? Ja, één keer per dag. Waarom wil je het dan realtime doen? Het is veel goedkoper om het dan één keer per uur te doen... als je toch maar één keer per dag gaat kijken. Dus dat is meer de vraag van... hoe snel wil je tot actie overgaan? Of hoe vaak ga je naar een dashboard kijken? Wat is precies de waarde die jij... ...uit je data wil halen. Ja, dat is dat.

Het voelt vaak ook wel een beetje real-time verwerking... ...als zo'n buzzword... ...wat dan managers op een gegeven moment hebben gehoord... ...van we kunnen nu real-time de data verwerken... ...dat ze denken, dat moet ik hebben. Maakt niet uit of ik er naar kijk... ...maar ze willen het dan. Dat is niet meer een soort van middel... ...maar het is gewoon een doel geworden.

Ja, vandaar dat ik die vraag even stel. Want we horen het wel meer.

Ja, ik denk dat het wel goed is om... ...er zijn wel twee verschillende dingen. Wat is de waarheid.

Zeg maar?

Ja, maar je hebt dus inderdaad... Dus real-time is eigenlijk meer continu. Dus je stroma data continu daar een soort van waarde uit proberen te halen. Maar wat je ook hebt is dat je dus event-based je batchverwerking gaat doen. Wat je dus ook kan hebben is als er elk uur een file ergens landt. Dat je die file dan gelijk gaat oppakken en gaat verwerken. Dat is batchverwerking, want je doet het maar één keer per uur. Maar dan zeg je gewoon, oké, ik doe het event-based. Dus de file landen gaat gelijk verwerken. Dat is in zekere zin ook real-time, want je doet het gelijk. Alleen je bent het niet continu aan het draaien, zeg maar.

Ja, oké.

En dat is denk ik wel altijd goed om te doen. Om zoveel mogelijk dus niet te zeggen van ik zet iets elk kwartier aan.

Nee.

Dat is eigenlijk altijd een zaktebot. Je moet altijd kijken van oké, ja je moet gaan draaien als het nodig is. Dat is natuurlijk altijd goedkoper dan elk kwartier. En dan misschien de helft van de tijd van niks draaien.

Ja, ik denk ook dat je altijd moet beginnen vanuit de noodzaak. Die vraag die je net stelde om te vragen van, ja, maar hoe vaak kijk je naar zo'n rapport? Dat zegt natuurlijk ook al heel veel. Ja, en als je het dan hebt over, dus die datastromen, weet je wel, van de bron en verwerken en uiteindelijk er wat mee doen. Kunnen jullie de luisteraars een beetje meenemen in hoe je dan, ja, zo'n data pipeline noemen wij dat natuurlijk heel vaak. Hoe je dat maakt, dus vanaf begin tot einde. Hebben jullie daar misschien...

Ja, er zijn natuurlijk om mee te beginnen... heel veel verschillende tools al voor. Maar over die tools genomen... zit er wel een vergelijkbaar patroon in. Vaak wil je proberen om in eerste instantie... de data die je ergens vandaan haalt. Je hebt je brondata om die binnen te trekken. Stel dat het een faal is... dat je die faal eerst eens kopieert naar je eigen systeem. Dus dat je het altijd ook weer opnieuw zou kunnen opbouwen. Vervolgens wil je daar misschien wel... Nou, is het bijvoorbeeld allemaal nested data, dus het is een JSON, is het allemaal dingen nog verpakt, wil je dat eerst eens gaan uitpakken voordat je er wat mee gaat doen. Je wil misschien bepaalde data quality checks doen, zijn essentiële velden, bijvoorbeeld de klant ID is die wel gevuld, zitten er niet bepaalde waarden die niet mogen, dus dat wil je gaan doen. Je wil misschien ook nog wel historie daarvan gaan opslaan. Dus als het gaat om klantdata die bijvoorbeeld verhuisd is, wil je weten dat die wel daarvoor ook op het oude adres heeft gewoond. Nou, dat mag je weer niet lang opslaan. Maar misschien niet het allerbeste voorbeeld, maar jullie snappen mijn punt.

Ja, zeker.

En vervolgens gaan we een beetje dat traject in wat we eerder hebben besproken. Ook van, oké, nou, we hebben een soort van opgeschonde, gecheckte versie van die data die we hebben binnengehaald. en gaan we toewerken naar het model waar dus die analist of scientist in kwestie wat mee wil gaan doen. Dus zitten er wat transformaties in, misschien wat verrekening, misschien dus het samenvoegen van wat bronnen. En zo doorloop je eigenlijk een beetje zo'n pipeline. En dat zijn natuurlijk vaak wel meerdere pipelines die naar verschillende lagen van, nou ja, dan gaan we misschien wel wat dieper op architectuur in, maar verschillende lagen waar je dingen wil opslaan. Maar ik denk dat dat een beetje de basis is van zo'n datapipeline. Zonder het te ingewikkeld te maken.

Ja, en je noemde net ook al datamodel. Hoe past dat dan samen? Dus je hebt de data die dan inderdaad uit de bron komt. Hoe past het model dan daarbij?

Het model is eigenlijk het makkelijkste manier om data zo te structureren dat het en vaak sneller benaderbaar is, omdat logische componenten bij elkaar zitten en dus ook gewoon, los van sneller benadenbaar voor een systeem, ook voor mensen wat logischer is dat bepaalde componenten bij elkaar zitten. Dus het is gewoon, En een manier om bepaalde bronnen te kunnen combineren tot dus een logisch model met logische data bij elkaar. Maar ook om het gewoon een beetje menselijke maat en dus ook voor computers makkelijker benaderbaar te maken.

Ja, dus het is een soort van domeinkennis of het is een bepaald domein waar zo'n model in...

Er zit vaak een logische verdeling op basis van wat voor type data het is en wat voor type mensen ermee werken. Ja, er zijn vast hele leuke manieren om dit te kunnen uitleggen. Maar ik weet niet of je een leuk voorbeeld hebt van een datamodel.

Oh, nu moet ik een poging gaan over de datamodeleren.

Ja, kom, kom.

Iedereen wakt op je hoofd. Je kan je niet melden.

Nee, dit is moeilijk, hè?

Ja, je moet het zo zien. Als je met een klapblokje over het terras heen loopt, dan ga je allemaal opschrijven wat iedereen besteld heeft. Maar uiteindelijk wil je aan het einde van de dag ook weer gaan bestellen om je voorraden weer aan te vullen. Nou ja, als je dan gewoon één op één al die klapblokjes Dus gewoon onder elkaar een excelletje zet. Ja, dan is het best wel heel lastig om in één oogopslag. Of met één simpele query te kunnen zien. Van oké, wat moet ik nou bestellen? En daar doe je eigenlijk data modellen voor. Dus je gaat proberen op een logische manier de verschillende objecten bij elkaar te brengen. Dus je hebt misschien, een tabel met je voorraad. Een tabel met je bestellingen. Een tabel met je transacties. Dus je probeert op objectniveau dingen goed samen te brengen. En dat wat Nicky zegt klopt. Dus er zijn eigenlijk vaak twee doelen met de data modelleren. Vroeger, dat wordt nu iets minder belangrijk omdat storage niet zo heel duur is... ...maar vroeger was het ook heel belangrijk om het zo efficiënt mogelijk op te slaan. En dan efficiënt in de zin van dat het zo min mogelijk schijfruimte kost. Dus je wil geen dubbele data en dat soort dingen hebben. Dan krijg je dus vaak meerdere tabellen... Dan wordt het dus qua opslag efficiënt. Maar op een gegeven moment wil je de data ook gaan lezen. En dan moet je dus al die tabellen weer gaan zitten combineren. En dan ga je dus een datumodel maken wat efficiënt te lezen is. Dus dan ga je vaak bijvoorbeeld naar een stermodel toe. Waarbij je dus je transacties hebt. Die komen er steeds bij. En eromheen heb je je zogenaamde dimensietabellen. En dat zijn dan de waardes die niet zo heel vaak wijzigen. Dus dat bijvoorbeeld je klantinformatie of je productinformatie, dat verandert niet zo snel. Maar je transacties, bijvoorbeeld als je op het terras zit, alles wat gekocht wordt of betalingen, dat verandert wel heel snel. En nou ja, als je dat dus goed opbouwt, dan kan je dus heel makkelijk in je rapportje zien wat je moet gaan bestellen, omdat het brood en salami op is.

Ja, dus het is eigenlijk objecten detecteren, vastleggen, misschien ook wel processen of niet?

Dat kan allemaal meespelen. Ja, zeker.

Het lijkt wel gewoon op normaal database modellering.

Zeker?

Ja, dat is het.

Dat is het eigenlijk zo precies. Ik heb dit ooit eerder gedaan.

Ik heb dit ooit in het verleden.

Ja.

En ik hoorde ook iemand, dat zei jij volgens mij, normaliseren. Toen kreeg ik al trauma's over vijfde normaal vormen.

Wie wil die uitleggen?

Ah ja. Nee, nee, nee. Ik ga het vanuit de sequel met die uitleggen. Ja, maar dat is wat wij ook doen. Ja, dat is een internationale database. Ja. Ja, je kunt data gewoon heel efficiënt op slaan. Dus stel dat je relaties hebt tussen twee entiteiten, een een-op-n-relatie. Kun je het heel dom opslaan in één tabel. En heel veel herhalende data krijg je dan. Dat is niet handig. Dus dan ga je naar de tweede of de derde normaal vorm. Dus dan één paastabel, een-op-n. Nou goed, dat verhaal dus. En zo kun je gaan tot de vijfde normaal vorm. Heel leuk voor opslag. Drama om hem weer uit te lezen. Dus dat is dus waarom ik de vijf normaal gewoon een beetje bogus vind. Maar sommige mensen vinden dat heel tof. En daar houdt het voor mij meestal op, dus bij de derde normaalvorm.

En wie doet dat dan? Is dat die data engineer dan?

Data engineers doen dat ook, maar bij applicatie ontwikkeling zien we dit op zich ook. Je ziet wel, en nu ga ik de wat meer klassieke data engineer misschien wel tegen de schenen schoppen. Je ziet dat echt het data modelleren, in ieder geval die normaalvormen, dus proberen je data efficiënter op te slaan, wordt eigenlijk minder belangrijk. Ook omdat de moderne lakehouse technieken, daarvoor is het al wat minder belangrijk om die dubbele data heel erg te vermijden. Om dus die data maar door te normaliseren. Dat wordt eigenlijk steeds minder belangrijk. Dus we gaan steeds verder naartoe. Dus dat je eigenlijk vanaf de bronnen gaat kijken, wat is de purpose die het uiteindelijk moet hebben. En die soort van die tussenstap, dus van die data maar eindeloos normaliseren. Om vervolgens alles weer om te bouwen naar bijvoorbeeld stermodellen of voor data science een platte tabel. Dat zie je eigenlijk dat dat minder nodig is, omdat dus de engines in Spark, maar ook hoe de data, nou dat zijn dan parquet files, dat is vaak de onderliggende file structuur, daar is het minder belangrijk en soms zelfs minder handig om dus die data maar eindeloos te blijven normaliseren.

Ja, oké, dat is interessant.

Ja.

Oké, maar dan is eigenlijk de technologie, de tooling noemen we het even, die heeft dat voor je opgeloste zaanheidsstekens. Ja, oké. Wat op zich wel logisch is.

Oké, dus dan is normaliseren niet meer nodig dan. Oh shit, zeg ik nou iets geks?

Hij kijkt me echt zo aan. Kijkt wie het zegt waarschijnlijk.

Geen commentaar.

Dan zijn we platformen en je neer geworden.

Dan krijgen wij straks mailtjes. Oh, wij hebben ons mailadres niet gedeeld. Nee, nee, nee. Krijgen we al een brief, aangetekende brieven thuis.

Niemand weet waar we wonen.

Geen probleem, joh. Alleen voornaam gezegd gelukkig.

Maar valt datanormalisering dan onder datacquality, vind jij dan? of omdat het niet meer nodig is hoef je dat niet meer te doen.

Nee, dus volgens mij maakt het datamodel voor datakwaliteit niet zoveel uit. Dus je hebt natuurlijk verschillende soorten van datakwaliteit. Je kan het helemaal aan het einde doen. Dan is het meer een soort van profiling van de data. Dus hoe ziet de data er uiteindelijk aan het einde van het feestje uit? Of je kijkt al vanaf de bron. Je krijgt gewoon een rij aan data binnen en je gaat daar al kijken van... Oké, is de leeftijd onder de... Hoe oud is het de oudste persoon op aarde? Is de leeftijd onder de 113?

Ja, precies.

Zijn we unieke keys, zijn we primary keys, dat soort dingen. Daar is eigenlijk het modelleren minder belangrijk voor.

Nee, precies. Want Nicky, wat is datakwaliteit volgens jou?

Dat is wel lastig om natuurlijk zo van samen te vallen, omdat het best veel omvattend is. Maar ja, wat ik eerder ook al zei en wat Mathijs net benoemd, is het natuurlijk sowieso goed om in een vroeg stadium te gaan checken of de DAVA die in je bestanden of hoe je het ook binnenkrijgt bevat wat je verwacht. Dus dat er gewoon geen onlogische dingen in zitten. Maar hoe wij bijvoorbeeld ook, want wij hebben vorige week en de week daarvoor nog met het team een data quality workshop ook gegeven voor de teams die ons platform gebruiken. En daar hebben we bijvoorbeeld ook een tool, of eigenlijk een framework van Great Expectations om te checken, nou ja, bevat dus mijn data die in transit is. Dus tijdens het opwerken nog steeds de waarde die ik verwacht. je kan dus daarvoor al dingen checken, je kan checken of wij gebruiken bijvoorbeeld ook Sonar Cloud, om vulnerabilities snel te scannen, om te checken of je testcoverage, dus hoeveelheid code die je daadwerkelijk test, of die gecoverd is dus dat zijn allemaal dingen die een soort van die wij in ieder geval onder de paraplu van data quality, proberen te vangen ja.

In zekere zin zit natuurlijk gewoon in het woord je noemt het vulnerabilities, kan je dat toelichten? Want bedoel je dan in de code-vunabilities of in de packages?

In de code is het in het geval, ja. Dus, nou ja, bijvoorbeeld dat ik heb zo slecht geslapen dat ik mijn secrets per ongeluk in hardcoded naar mijn git heb gepushed, dat je daar achterkomt. Dat zou je dan niet zo snel doen, maar dit gebeurt nog meer dan je zou willen.

Ja, mooi.

Ik snap het nu.

Ja, dat is wel belangrijk om daar even bij stil te staan.

Beetje verslaapt.

Ja, klopt.

En dan kan ik anders secrets in de code zetten.

Nee, inderdaad. En als je het hebt over de technologie, we hebben best wel wat technologie al genoemd binnen de wereld van data. Welke technologie denken jullie dat gaat verdwijnen binnen vijf jaar? Dat je echt denkt van nou, we werken hier wel mee, maar dit gaat toch wel een keer stoppen.

Vijf jaar is lang hè?

Ja, tegenwoordig wel, ja.

Oké, tegenwoordig wel, hè.

Ja, ze zeggen met alle agents dat eigenlijk alles wat niet open source is gaat verdwijnen, want je kan toch alles zelf bouwen?

Ja.

Oh ja, echt?

Ja.

Oh.

Ja.

Je kunt ook alles nabouwen tegenwoordig.

Ja.

Uitwinst, sorry, als het software is, met al die reverse engineering, bouw je nu ook echt alles letterlijk na.

Ja.

Dus dat is wel spannend, zeg maar.

Zeker, al denk ik wel, vijf jaar is wel lang, maar toch denk ik wel dat voor organisaties zoals Stedin, En dat het ook wel echt een voordeel heeft om dingen bijvoorbeeld van Microsoft af te nemen. Meer managed services. Dus dat zij zorgen dat de software waar alles op draait, up-to-date blijft en dat soort dingen. Dat je wat minder... Stel je zou alles zelf bouwen en weer een grote server hierboven neerzetten en alles open source gaan bouwen. Dan heb je veel meer... Veel meer plekken, waar aanvallen op kunnen gebeuren natuurlijk. Dan ben je opeens voor heel de stack verantwoordelijk.

Ja, je bent verantwoordelijk. Want in principe is die attack service... die zou in principe ongeveer hetzelfde kunnen blijven.

Zeker, zeker.

Alleen Microsoft heeft er wel een heel groot leger... en meer ervaring. En die kunnen dat waarschijnlijk beter dan dat je dat zelf doet. Ja, dat is altijd het spanningveld hoor. Dit is wel een soort van... Het is niet heen en weergaand. Want nu, iedereen zit in de cloud inmiddels. Maar je krijgt natuurlijk nu andere vraagstukken van, kunnen we Amerikaanse bedrijven vertrouwen? Want de data staat daar, wat gaan die ermee doen? Moeten we alternatieven hebben? Moeten we het zelf doen? Dus dat is wel een actueel ding.

100%. Al denk ik wel dat de moderne, de big data oplossingen die in de cloud zijn. Ja, dat is nog steeds, kan eigenlijk alleen maar over de Amerikaanse as. Want ook bijvoorbeeld de SAP Cloud is gewoon gehost bij Azure. Natuurlijk is het in Europa gehost, maar dan ben je toch altijd gelieerd aan Amerikaanse beleefd.

Nee, dat begrijp ik ook. Dus waar het heen gaat, weet ik niet. De vraag was natuurlijk welke technologie is er over vijf jaar. Die voorspelling zou ik echt niet durven of kunnen invullen. Want alles verandert zo snel. Maar niet alleen op technologisch vlak, maar dus ook op politiek en weet ik wat allemaal. Wat voor vlakken nog meer. Je zei trouwens, dat is wel grappig. Je zei eerder van storage is niet per se een probleem. Maar juist nu is storage knijterduur. Dus het is echt wel iets wat iemand twee jaar geleden absoluut niet had kunnen voorspellen. Anders had ik heel veel aardig schijven gekocht.

Ja, voor ISSD's en Mannerry is het extreem duur. Ja, dat is waar. Ja, dat is waar.

Dus dat, ja.

Dat zijn dingen veranderen wel.

Dus er gebeuren heel veel dingen, zeg maar, die je gewoon echt niet kon voorspellen. En dat was misschien vijf jaar geleden iets makkelijker. En tien jaar geleden nog. Dus dat was wat rustiger. Maar nu is het echt zo enorm dynamisch dat je echt niet meer.

Ja, als ik dan toch een inschatting moet doen. Dat wordt dan een beetje een flauw antwoord. Maar wat je nu bijvoorbeeld bij Fabric, maar ook bij Databricks ziet. Het gebruik van agents wordt gewoon veel belangrijker.

Oh ja.

Dus ja, dat je niet meer. Nou ja, Nicky, hoeveel code schrijf jij nu nog zelf? in procenten.

Ik wil dat eigenlijk niet in de podcast vertellen natuurlijk, maar 100 procent.

Je moet per regel betaal natuurlijk.

Nee, ik krijg elke vrijdag van mijn manager mailtjes, zoals bij Elon Musk, hoeveel code heb je deze week? Nee, maar het is afgelopen jaar natuurlijk, als ik alleen al afgelopen jaar zie, is het zoveel minder geworden, want ik weet nog dat wij vorig jaar rond de kerstdagen nog met, wat vorige versies van Copilot flink hebben zitten vloeken, omdat hij dan voor de simpelste dingen niet deed wat je vroeg en dat je dacht nou, ik doe het zelf wel, zeg maar. Ja, precies. Ik doe het alles zelf. Het kost nu alleen maar tijd en heel veel energie. Maar dat zal echt veranderen natuurlijk. Die kwaliteit is zo snel omhoog gegaan dat, ja, voor echt simpele dingen schrijf je eigenlijk niks meer zelf. En je ziet dat je al veel meer naar een rol toe gaat waar je, ...nadenkt over wat de oplossing moet zijn... ...en dat goed gaat uittekenen...

...en.

Goed gaat bespreken met elkaar... ...en dan zorgt dat je met een volledig informatiepakket... ...gaat kijken van... ...hoe zou zo'n model dit bijvoorbeeld oplossen... ...en dan gaat kijken van... ...ik zie dat hij dit wel goed doet en dat niet... ...en dan ga je een beetje tweaken daar... ...maar dat je eigenlijk al meer code aan tweaken bent... ...dan echt volledig zelf nog dingen schrijven.

We hadden het gisteren nog... ...een refactor van een bepaald patroon... ...waren we aan het uittekenen... En dan hebben we denk ik wel een uur, anderhalf uur getekend. En toen zei ik tegen een collega toen het klaar was van... Nou, we hebben het nu uitgetekend, maar je moet het nu nog maken. En toen zei hij, ja, volgens mij hebben we het moeilijkst al gehad. We hebben al bedacht hoe je moet werken. En als je overal aan gedachten hebt, dan is eigenlijk de uitvoering... Wat vroeger, echt vroeger, een jaar geleden nog, gewoon heel veel werk was.

Bizar hè, hoe zo dat gaat.

Ja, en dus om nog even op die vraag terug te komen van... Wat is er over vijf jaar verdwenen? Ja, dus tools die niet goed meegaan nu. Je ziet bijvoorbeeld bij Fabric dat ze de agents steeds meer context geven. Dus als een agent heel veel van jouw werk kan zien, hoe jouw datamodellen er bijvoorbeeld uitzien. Als hij al ziet hoe het uiteindelijk een datamodel moet worden, dan kan hij veel sneller voor jou die ETL schrijven. Dus kan hij veel sneller die Python script schrijven om de data ook zo te krijgen. Dus wat je bij Fabric ziet is dat ze zorgen dat die agents steeds meer van wat je aan het doen bent qua code, qua data, qua modellen. ...steeds meer context gaat verkrijgen... ...waardoor die ook steeds beter kan helpen. Ik denk de tools die daar niet goed mee omgaan... ...die dat niet ook zo snel mogelijk in een... ...ja, dat duurt het gewoon veel langer om je werk te doen... ...en dan wordt het steeds interessanter... ...om te switchen van software... En dat is denk ik breder dan alleen data engineering. Ik kan me ook voor financiële systemen, kan ik me dit ook voorstellen. Als jij in je CRM systeem je NLM al ernaast hebt en je zegt van ik heb deze en deze gesproken. Hier is een transcriptie van het gesprek. Vul me aan en je bent nou vijf minuten klaar. Dan heb je geen zin om in je oude CRM systeem dat allemaal met het handje over te typen, de klant op te zoeken, et cetera, et cetera. Dus ik denk, ja, in algemene zin, bedrijven die niet meegaan om dit goed in hun software te krijgen, ja, die gaan het verliezen van de bedrijven die wel daar heel innovatief mee bezig zijn.

Ja, klopt. Ik wil er nog even een leuke stelling in gooien. Dat is een beetje een raakvlak ook. Nou, iedereen die wil AI, toch? Dat is wel heel erg duidelijk. Zelfs wij, jij wil het ook volgens mij. Ik zie het aan je.

Heel veel mensen, ja.

Ja, jij wil het gewoon. maar niemand die wil eerst zijn data op orde brengen. Zin wel ervan.

Volgens mij heeft Mathijs eerder al de gevleugelde uitspraak shit in, shit out.

Ja, we zien beginnen.

Of garbage in, garbage out en iets netterder woorden. Ja, ik denk dat dat een beetje het antwoord is op als je niet wil zorgen dat je datakwaliteit hoog genoeg is om die modellen op te doen.

Zien we dat ook veel in de praktijk?

Nou, ik denk dat we dat wel bijvoorbeeld... Ook buiten Stedin trouwens ook. Ja, bij die eerdere modellen bijvoorbeeld ook van, ik refereer nog maar graag terug aan een jaar geleden toen wij met Microsoft Copilot wat eerdere versies aan het klooien waren. Of soms als je AI-modellen bepaalde vragen, die is van, nou ja, misschien weet ik veel wat obscuurder zijn of waar ze gewoon oude informatie nog voor gebruiken voor een wat goedkoper model, dat die informatie gewoon niet op orde is. Dus je ziet dat eigenlijk direct terugkomen en dus ook om het wel een beetje binnen ons werkveld te houden met die, code zoals nu, dus die modellen die meer context hebben, zoals bijvoorbeeld wij gebruiken dan veel GitHub Copilot ook en dat zit in onze Visual Studio Code en die heeft toegang tot een repository en soms heb ik informatie nodig over meerdere repositories, kan ik die allemaal erin gooien en heeft die al die context. Dan kost het wel een hoop van betokens vaak om dat goed uit te lezen, maar dat is even wat anders. Maar dan merk je gewoon dat hij is ervan, omdat hij tot veel meer van de relevante informatie beschikking heeft, dat hij tot een veel beter antwoord kan komen dan wanneer je gewoon zegt, hé, dit is mijn add-or, dit is mijn probleem, hier is mijn code. En dan gaat hij misschien uit luiheid, pakt hij gewoon, want die dingen zijn natuurlijk ook zo lui mogelijk, omdat ze zo snel mogelijk willen antwoorden, pakt hij het eerste antwoord wat hij heeft gevonden op een oud Reddit-forum. Wat helemaal niet relevant is voor jou. En dat brengt hij dan natuurlijk met, hey, goede vraag. Ik heb hier een supergoed antwoord. Dit werkt met een raketje erbij. En dan werkt het niet, omdat hij gewoon niet tot die datakwaliteit eronder eigenlijk veel lager is van dat model.

Ja, dus eigenlijk kunnen we ook wel zeggen dat AI-problemen zijn over het algemeen dataproblemen.

In deze context wel. Er zijn denk ik ook nog wel wat andere contexten te schetsen. Maar in deze context, ja.

Ja, het houdt ook een beetje van wat je met AI bedoelt. Soms wordt er ook mee bedoeld dat bedrijven voorspelmodellen gebaseerd op hun data willen bouwen. Bijvoorbeeld bij Stedin gaan voorspellen waar het licht gaat uitvallen. Omdat er te veel stoom op het net. En dat ze dan misschien hier en daar een, zonnepanelenpark kunnen uitzetten op afstand of zo. Weet je, dat soort dingen. Ja, je kan je voorstellen als je je data engineering niet goed doet. En er zit heel veel foutieve data in. Ja, dan kan je AI model nog zo goed zijn. maar die gaat dan echt niet kunnen voorspellen waar het licht gaat uitvallen. En ja, het klinkt minder sexy. Het is toch data engineering. Ja, je wil AI, je wil gewoon spannende dingen doen. Dus databranden combineren en opschonen. Ja, niemand houdt van poetsen, toch? Nee, klopt.

Ja, daarom. Daarom dat we ook dachten om dit onderwerp gewoon even in onze podcast een keer de revue te laten passeren om even de aandacht ervoor weer te geven.

Nou ja, je hoort ook, dat is volgens mij zelfs een van onze afdeling objectives om meer AI te gebruiken of zo.

Ja, dat bedoel je ze graag managers natuurlijk.

Ja, precies. Wij willen AI.

Wij willen AI, ja. Wat dan?

Ik vind het sowieso niet irritant, want AI is natuurlijk een enorm grote vakgebied. Nu wordt AI synoniem aan LLM gebruik. Dat is eigenlijk wat er nu vooral is. Als je dan in willekeurig iemand buiten, dan is het oh, chat, GPT of misschien klaar. Maar het is natuurlijk veel breder. Dus machine learning, ik bedoel, tien jaar geleden was machine learning helemaal hot. En nu is het nog steeds AI, maar LLMs. Maar vinden jullie dat niet irritant of zo? Of hebben jullie zoiets van, nee, jullie weten niet waar jullie het over hebben. Want dit is zeg maar ML, dit is AI en dit is, of ze is AI, LLM modelgebruik. Hebben jullie dat nooit? Of hebben jullie zoiets van, oh nee, we go with the flow.

Ja, LLM is een onderdeel van AI.

Ja, ja.

En ja, dus wat de meeste mensen thuis zien is inderdaad hun appje GCPT op de telefoon. Dus ja, tuurlijk dat is oké, maar het is natuurlijk artificial intelligence betekent niks anders dan een computer die dingen beslist of dingen voorspelt of dingen kan zonder dat jij hoeft te helpen, zeg maar. Dingen kan leren, dat soort dingen. Dat is natuurlijk heel breed. Wat ik voornamelijk irritant vind is dat je als team een objective krijgt van gebruik meer AI, maar dat is natuurlijk geen doel op zich. Wat is het doel wat je wil bereiken? Efficiënte werken, innoveren of iets van. Ja, klopt. Dus AI is geen doel. Het is gewoon een verzameling van tools, van computers die dingen kunnen. Dat vind ik wel, dat is irritant. Ja, dat mensen denken dat AI is LLM. En dan denk ik, ja, nee, oké.

Dat maakt niet uit.

Er zijn grotere problemen in de wereld.

Ja, dat is zeker zo.

Ja. Ja, oké. Ik had hier ook nog een vraag over... Ja, wat maakt data engineering nou zo belangrijk voor AI? Maar volgens mij hebben we dit eigenlijk al een beetje beantwoord. Ik bedoel, de data quality, toch? Dus je moet ervoor zorgen dat je datasturing ook goed op orde hebt.

Ja.

Wat ik merk, maar dat is voor software development in het algemeen, wat wij, bijvoorbeeld stel iemand bouwt, stel Kishen maakt iets. En dat is echt supergoed. Nee, die heeft de poolrequest gemaakt, ik wil gaan reviewen. En ik moet die, ik ben met mijn eigen werk ook bezig. En dan wil ik zijn werk reviewen. Maar vroeger, dan ging ik niet helemaal zijn brain's uitchecken, te zorgen dat mijn data in de juiste state komt en dat ik de juiste dingen heb. Terwijl nu kun je dat wel. Nu kun je gewoon tegen colloot van oké, zorgen dat je dit kunt testen en ik wil het gewoon draaien vanuit een bepaalde folder. En al die stappen die deed je niet, misschien uit luiheid, want het kost veel tijd. Merken jullie dat ook bij data engineering? Dus dat je met bepaalde LLM-modellen dat je data genereert, zodat je even heel snel kunt zien van oké, deze hypothese komt wel over een moment wat ik had verwacht. Of deden jullie dat al?

Nou, ik denk wel, ik heb misschien nog wel van vanmorgen een graal voorbeeld waar we dus op een van onze patronen ook een refactor hadden gedaan. Ik zal niet teveel op de details neergaan, want dat is helemaal niet interessant natuurlijk. Zowel voor jullie als voor de luisteraar. Maar waar ik dus ook aan, in dit geval GitHub-koop uit, heb ik gevraagd van, hey, ik heb helemaal geen zin om dit te testen, maar goed dat jij er bent. Kan jij voor mij een script genereren en even die data klaarzet, moet aan deze eisen voldoen, check wat allemaal nu veranderd is en schrijf het uit met elke keer een stukje tekst wat je nu test. Maak testcases en print weer uit wat er wel of niet goed is te gaan. en zo heb ik gewoon in een minuut dat hele script dat ik stap voor stap kunnen doorlopen of alle functionaliteiten nog steeds hetzelfde waren als dat ik verwacht dat ik hem die eisen meegegeven.

Precies.

En anders, als ik dat helemaal zelf had moeten testen dan was ik nooit natuurlijk in een half uurtje of een uurtje klaar geweest. Dus ik gebruik het daar wel graag voor. Tegelijkertijd moet ik wel ook zeggen dat wat we ook af en toe al zien binnen het team is dat, Die modellen hebben er soms ook wel een handje van om veel code te refactoren. Omdat ze dan weer een nieuwe skill ergens is aangezet. Of misschien het laatste van het laatste. Waar wij dan helemaal geen verstand meer per se van hebben. Dat het soms ook wel moeilijker wordt juist om te reviewen. Omdat de PR's ook wel groter zijn geworden. Omdat je best veel tegelijk kan doen. Dus dat het ook wel belangrijk is om of ergens in een integratietest goed die change nog op te pakken. Of dus wel goed dat ook daadwerkelijk zelf gaan testen. Waar je vroeger misschien makkelijker, ja, had iemand dertig regels code aangepast, kon je het nog wel lezen.

Ja, ja, ja.

Dat is wel, ja, ik merk dat dat wel echt...

Ik denk dat dat er al van meenig is.

Ja.

Ja, en om daar nog op aan te vullen, we zijn nu wel, dus de data-engineers die het platform gebruiken, gebruiken eigenlijk nog relatief weinig NLM's. natuurlijk ze gebruiken ze wel... maar echt de kracht... dus eigenlijk wat Nicky zegt... dus in een soort van hybride vorm... dat dus de NLM een soort van... de context snappen... en voor jou een soort van test script gaan genereren. Want ik geloof wel... Gewoon volledig die agents alles laten testen. Uiteindelijk is dat ook aan het einde van de rit een stuk duurder. Je kan beter dat een agent er maar één keer over na hoeft te denken. Eén keer een testscript maakt. Dat je dat testscript gewoon steeds kan hergebruiken.

Dat is altijd nog goedkoper.

Dan dat je de hele tijd de agent alles laat testen.

Klopt, ja.

Maar daar zijn we nu druk mee om daar beter over na te denken. Hoe kan een data engineer de huidige technieken met agent beter in zijn werk gaan toepassen? Dat wordt ook steeds meer van ons als data platform engineer. Wordt dat ook steeds meer onder deur van ons werk. van hoe kunnen wij ook agents ontwikkelen die de detentie neerweer kunnen gebruiken om bijvoorbeeld een soort test te maken, snelle ETL te kunnen bouwen, et cetera, et cetera.

Ja. Oh, ja, ja, ja.

Ja.

Ja, nou ja, dat wordt bij ons ook weleens gezegd van ja, soms is het gewoon automatiseren en geen AI. Want dan, dus precies wat jij zegt, je maakt de script om het te automatiseren en dan gebruik je iedere keer dat script en niet iedere keer opnieuw AI. Want dan, dat kost je gewoon tokens. En dat is ook niet zo slim, omdat het ook niet deterministisch is. Je krijgt niet altijd hetzelfde resultaat.

Exact, precies.

Dus dat, ja.

Ja, want iets wat je net beschreven was, volgens mij, Nicky, je had het net over, dus dat je die testen zeg maar laat genereren. Maar dat klinkt een beetje als regressietesten, toch? Dus je bouwt iets volgens specs en je kijkt of dat nog steeds hetzelfde wordt.

Ik zie het wel, ja.

Iets wat, zou je ook, weet je wel, ik hou ook heel erg van nadenken over niet alleen maar de regressie, maar ook dingen die er eventueel daarnaast nog fout zouden kunnen gaan. Dus ook naar de failure scenario's, gaten, edge cases en dat soort dingen. Passen jullie ook dat soort dingen toe tijdens jullie, noem het maar even, definiëren van wat er getest zou moeten worden?

Ja, ik denk dat een van de dingen waar ik zelf het meest blij mee ben, wat we afgelopen maanden vrij goed hebben ingericht, is, goede integratietest, waar we gewoon altijd dat onze eigen code, ook omdat, nou ja, die context al geschetst, maar wij maken in principe code die weer door andere engineers gebruikt wordt. Dus op het moment dat we die code... uit het development gaan trekken... en richting een hogere omgeving gaan pushen... dat we eerst... ...allemaal scenario's gaan checken van... ...hé, onze core functionaliteiten... ...doen die nog wat verwachten? Kunnen we nog deployen? Werken alle ingestion patronen nog? Kunnen we nog tabellen wegschrijven? Etcetera. Al die functionaliteiten die wij beschikbaar maken... ...dat die nog steeds werken... ...voordat er honderd engineers... ...aan ons, nou ja, digitale bureautje staan. Ja, precies. Wat hebben jullie nu weer ongetest? Op de productie gezet. Dus we zijn er zeker mee bezig. Ook omdat, ja, we dragen natuurlijk... ...zonder het groter te maken dan het is... Maar we dragen natuurlijk bepaalde verantwoordelijkheid dat andere mensen hun werk kunnen uitvoeren. En dat moet je ook wel serieus nemen. En als we dat niet doen, worden we ook altijd wel redelijk hard gestraft. Wat betreft TurkTorin engineers. Die zijn dan terecht ook pissig.

Ja, dat snap ik.

Maar dat is best wel lastig, zo'n framework. Want als je gewoon een app bouwt, bijvoorbeeld een app waarop je, weet ik veel, auto's kan kopen, zeg maar wat. Dan is het best wel duidelijk wat de scope is. Gewoon, je moet er advertenties op kunnen zetten. Er moet geüpdatet kunnen worden. Dus dat kan ook een agent of misschien gewoon allemaal integratieversie je schrijft, kun je best wel makkelijk daar allemaal doorheen gaan. Het lastige aan een data platform is, is dat het software is waar weer andere data engineers eigenlijk software in gaan schrijven. En dat is die mogelijkheden die een data engineer heeft, ondanks dat we standaarden hebben en dat we al best wel veel hebben afgeschremd van wat ze kunnen, kunnen ze nog steeds oneindig veel, want je hebt geen idee wat ze voor code gaan bouwen. En dat maakt zo'n integratie framework best wel ingewikkeld, Want je moet echt heel erg, en daarom zei ik ook in het begin van het gesprek van, je moet eigenlijk data engineer of liever moet je data engineer zijn geweest voordat je de platform engineer wordt. Je moet een beetje in zijn huid kruipen om te mimieken wat hij straks gaat doen.

Vies, ja. Oké, nou, we zijn alweer bijna een uurtje voorbij inmiddels samen.

Ja, klopt, helemaal.

Ik heb nog twee vragen, die zou ik nog wel willen stellen.

Mag ik dat? Nee, joh.

Ja, wil het doen?

Ja, nee, nee. Oké, dankjewel samen, dankjewel samen.

Eigenlijk voor jullie beiden. Stel dat jullie vandaag mochten kiezen om vanaf scratch te beginnen, gewoon vanaf nul.

In mijn leven?

Ja, ja, ja.

Oh, ja, ja, nou, je leven is een beetje overdreven misschien.

Als je nu opnieuw geboren wordt.

Zou je dan weer psychologie? Nee. Nee, gewoon natuurlijk in de data-engineering wereld. Wat zouden jullie kiezen? Als je helemaal vanaf scratch zou mogen beginnen. Ja, gewoon als platform. Je wil een data-platform gaan maken. Wat zou je kiezen?

Wat een gewetensvraag.

Nou zit onze productmanager te luisteren. Ja, zit mij te luisteren. Of zullen we deze vragen even skippen?

Nee, ja. Het is ook lastig. Omdat het zo afhankelijk van de tijd is natuurlijk. De hele tijd nu. Wij zijn nu dan toevallig, of het is niet zo toevallig, want dat heeft iemand voor ons besloten. Maar we zijn nu dat hele dataplatform op Microsoft Fabric aan het maken. Het eerlijke antwoord op dit moment in de tijd is dat ik daar nu niet zelf voor zou kiezen. Maar dat kan zo zijn dat als je dat over een half jaar of over een jaar aan me vraagt, dat ik een heel andere antwoord daarop geef. Daarom vind ik het ook moeilijk om daar nu echt goed antwoord op te geven, vind ik.

Het is in potentie de beste keuze, alleen nu waarschijnlijk nog niet.

Ja, daarom vind ik het ook moeilijk om echt antwoord te geven op deze vraag. Behalve dat gewoon... Ik ben wel vooral blij dat ik vanaf het begin veel met Python heb gewerkt. Want dat is gewoon blijven terugkomen. Dat zal ook nog jaren er zijn. En dat het gewoon goed is om goede sequelskills te hebben. Ik zou dat in ieder geval weer doen. Omdat ik merk dat dat me gewoon heel erg helpt.

Ik zou denk ik als ik nu zou moeten kiezen voor Databricks gaan. En mogelijk over een tijdje dat Fairbreak een logischere keuze is.

Oké. En dan mijn laatste vraag. Wat is nou, dat is heel leuk om te delen aan onze luisteraars. Wat is jullie ergste dataramp die jullie ooit hebben meegemaakt in je carrière? Dat je echt dacht, wow, dit was echt shit.

Ik heb wel een leuke hier in mijn echte eerste week bij Stedin. Ik denk dat jij al weet wat ik bedoel. Ja, ik werkte hier denk ik een week of twee weken op een van onze frameworks. Die draait allemaal Docker containers. En daar moest de image of zo worden aangepast, als ik me niet vergis. Het is even geleden.

Ja, de versioning van de containers of zo.

Ja, nou goed, iets op die containers. En het is vrijdagmiddag, eind van de dag. Het is een heel erg dom werk, wat je gewoon even in al die containers moet aanpassen. Dat zou je goed moeten testen. Maar je denkt ook van ja, sorry. Ik ben geen debiel. Ik kan dit wel. Ik kan wel een paar cijfertjes aanpassen. En gewoon dat ze committen. En dat gaat wel goed. En ik ging ook op vakantie. Vrijdagmiddag. Niet getest. Alles gewoon naar productie gooit. Er was over het weekend alles eruit geklapt. Toen begon ik zeg maar mijn vakantie maandag met een appje van Mathijs. Wist je nog dat we dachten dat dit wel even snel kon? Alles eruit geklapt. Al die verladingen die plaatsgevonden over het weekend. Ik zou zeggen dat wat me nu te binnen schiet... wel een vrij domme actie is.

Dus wat was je learning point? Het was wel leerzaam.

Ja.

Altijd even testen.

Altijd even testen.

Ja, en niet... Dat is iets... Dat heb ik ook wel... Nou, dat komt deels natuurlijk... omdat nu ook echt... Wat ik eerder zei... verantwoordelijk zijn ook voor andermans werk. Dat je... En ik probeer het ook wel vaak... ons in het team erin te hamen. Ik heb het afgelopen week ook nog gezegd. Het moet niet altijd het doel zijn... om zo snel mogelijk je feature af te hebben. Of zo snel mogelijk naar productie te gaan... Dat, behalve als het nodig is, nog iets eruit ligt. En je bent een hotfix bezig. Maar zorg dat het goed is. Want ja, je kan wel een halve dag eerder zijn. Maar als het eruit klapt, heb je er alleen maar meer werk van. En gezeikt. Dus zeg maar ja, gewoon goed testen. Goed erover nadenken. Zorg dat je compleet bent. Niet gaas willen zijn.

Eigenlijk zijn die kleine changes, zijn het gevaarlijkst. Dat is wel een soort van, dat heb ik op meerdere momenten al gemerkt. Dat je denkt, oh, doe het even snel. Want dan denk je ook van, ik hoef geen syntaxchecking te doen of zo. En dan kom je erachter. Oh, crap.

Ja, ergens. die foto's men vergeten.

Cool.

En jij, Mathijs? Ja, jij maakt nooit data op mijn... Oh, jawel?

Ik sluit me niet volledig aan. Dat was veruit de grootste slipper, hè.

En nog met z'n tweeën hebben we er ook naar gekeken.

Ja, hij kon een maandag oplossen, want hij was op vakantie.

Of never deploy on Friday, toch?

Dat heb ik bij vorige opdrachten ook wel gehad.

Ik heb daar wel... Ik snap die regel, ik snap waar het van na komt. Ik ben van, je moet op ieder moment kunnen deployen, maar daar moet je heel veel voor inrichten. En in sommige momenten, als er allerlei processen bij zijn en een systeem is beschikbaar en zo, dan snap ik dat dat niet altijd kan. Maar in principe zou je zo goed moeten kunnen testen, zeg maar, dat je het altijd kunt deployen. Maar dat kan niet altijd, dat weet ik ook wel. Maar ik probeer dat wel vast te houden.

Het is een mooie streven.

Ja, als streven, ja. Dus het is niet altijd realistisch.

Nee, maar het is toch, ja, als je dan op vrijdag om vier uur er iets uitklapt.

Dan ga je overhazen proberen te fixen.

Zowel je eigenlijk ook gewoon weekend wil. En dan, nou ja, jullie weten dat ook. Als je dan overhazen iets gaat doen, wordt het vaak erger.

Even nog jouw user story afronden, net voordat je op vakantie ging.

Dat moet je ook eigenlijk gewoon niet doen.

Nee, dat is ook een vrij slecht argument om iets heel snel af te maken.

Ja, je kan beter zeggen van, hé, ik draag even over.

Ja, op die manier. Ja, precies.

Als het geen hazen heeft, ik laat een weekje liggen als je een weekje weg bent.

Ja, ja, ja.

Nou, goed, joh. Nou, dat waren mijn twee laatste vragen.

We gaan naar het laatste deel. Naar de tips. Tipjes. Ik heb geen tips.

Wat? Jij niet?

Ik heb er niet over nagedacht. Jij hebt wel over nagedacht. Nou, ik heb er misschien wel een.

Ja, kom.

Dat is niet een goede tip, want ik heb het nog niet uitgelezen. Ik heb een omnibus gekocht van X-Men. Van Marvel. Dat is wel een heel zwaar boek. Letterlijk zwaar. Het is niet te onderdreen te komen. X-Men Gold & Blue. Dat is een era, zeg maar, dat is in de jaren negentig, dat echt een reeks X-Men was uitgekomen strips, die heel erg goed waren. Die zijn gebundeld in Omnibus. En die heb ik gekocht. En daar ben je pas op pagina 20 van de, weet ik veel, 900 of zo. Dus dat is mijn tip.

Oké. Nicky, heb jij misschien een boek of een film?

Je mag alles tippen trouwens. Want aan het einde doen we altijd gewoon tips. Het mag een serie zijn, een boek, technologie, hardware, whatever. Of een uitje, een festival. Alles is goed, zeg maar. Dat hoeft niet met software ontwikkeling te maken te hebben. Maar ja.

Nee, dat scheelt ook wel. Ik ben ook niet zo iemand die in mijn vrije tijd nog heel veel... Probeer zo min mogelijk dan met mijn werkwezig. Ik probeer tijdens werktijd het goed te doen. Ik vind het ook leuk om er met collega's over te hebben. Maar buiten werk is het wel goed. God, een tip voor de luisteraars. Ik ben, ik lees sowieso graag, maar misschien omdat jij al een leestip had, toch dan een ander medium. Ik ben met mijn vriendin weer Breaking Bad aan het herkijken. Voor de mensen die het lang niet hebben gezien, of als je het nog nooit hebt gezien, ga het absoluut kijken. Maar als je het ook lang niet hebt gezien, het is nog steeds de moeite om te kijken. Het is tijdloos, het is geniaal. Zit er weer helemaal in.

Goed zo, dat was zeker tof.

Ja, ik ga toch wel een nerd. Nicky zei, ik probeer zo min mogelijk werkachtige dingen in mijn vrije tijd te doen. Ik doe het wel heel veel. Dan zit ik thuis aan mijn homelab, zit ik te knut. Dan denk ik, ja, heb ik net heel de dag op het scherm gezeten. Wat doe ik? Ik zit gewoon in plaats van wat achter een kit op kopen. Dan zit ik nu achter klaald. Maar voor de rest allemaal hartstikke leuk. Nee, als je oude hardware hebt, een oude laptop of een oude computer. En dat staat te verstoffen. Ga gewoon eens op onderzoek uit wat je ermee kan. Ik heb laatst een oude Raspberry Pi omgebouwd tot audio-servertje. Dus daar zit mijn Spotify Connect op en mijn Airplay. Dus ik heb nu aan de oude stereo, waar ook de platenspeler aan zit...

Nice.

Kan ik ook radio naar streamen en ook Spotify naar streamen. En is ook veiliger dan dat je een oude Chromecast eraan hangt... die deprecated is en geen software-updates meer krijgt. En dit blijft gewoon lekker up-to-date omdat het open-source is. Ga lekker daar. Maar laat het niet verstoffen. Bouw er iets moois van.

Ja, cool.

Goeie te.

Heel tof.

Nou ja, ik heb hem al gegeven.

Ik was de eerste.

Je had even de tijd.

Ik zit nog steeds te denken, joh. Meer slapen. Nou, ik heb thuis een Sonos systeem. Ik heb volgens mij zeven of acht van die krengen in mijn hele huis. En wat mij opviel is dat, ja, dit gaat echt over netwerken, maar goed. Dat mijn KPN super wifi netwerk gewoon echt niet lekker ging met Sonos. Dus op een gegeven moment als je dan de ene zodoende apparaat aan wil zetten en je wil hem dan groeperen, dat liep gewoon elke keer stuk. Dan deed hij de ene kamer wel, de andere kamer niet en dan kon Spotify daar ook niet goed mee omgaan. Ellende. Nou, ik heb best wel een week zitten uitzoeken. Ja, het werkt gewoon niet. Dus de mensen van KPN, als ze luisteren... Ik hoop dat jullie het een keertje gaan oplossen... maar ik geloof er niet echt zoveel mee in... want het zit er al best wel een tijdje. Ja, ik ben overgestapt naar UniFi. UniFi-netwerk. Dus dat zou ik echt wel... mensen die daar in die hoek gewoon problemen hebben... met groeperingen en dat soort dingen van apparaten.

Ik had hetzelfde met Ziggo... dat die Liffy Verstek zegt... Ik heb toen van... Aruba heet dat eerst. Dat is nu volgens mij HP Enterprise geworden. Maar gewoon, ja, wel voor een vermogen. Want het is natuurlijk niet goedkoop.

Nee.

Maar goede access points gekocht. En dat maakt echt een wereld van verschil. Ja, zoveel stabieler.

Ik was volgens mij voor twee, misschien driehonderd euro was ik klaar. Maar goed, ja, weet je. Het is nu al waard. Ik heb het nu geïnstalleerd. En ik merk inderdaad, het heeft iets met die multipackaging te maken of zo. Wat niet standaard aanstaat of zo bij die systemen. Andere systemen van KPN of Ziggo waarschijnlijk ook. Maar dat schook me ineens de binnenman. Ja, dus iedereen overnijntje.

Daar kan je lang mee doen.

Even een investering, maar dan is het goed.

Cool. Ik heb verder nog geen andere tips. Dat was het, denk ik, toch?

Ja, hè?

Mooi. Dit was deze aflevering. Dank je wel voor het te gast zijn en dat we hier mochten zijn.

Ja, dat sowieso.

We mochten mooi besteden deze opname doen. Je kunt op codeklets.nl alles vinden. Jullie krijgen eigen pagina's, Dan kunnen we je daar ook mee vinden. De aflevering komt natuurlijk online. Als show notes met tips en alles. Zoals het altijd werkt. Dus dat, ja, die zijn vindbaar.

Komen jullie ook naar Slack?

Die is heel rustig. Slack is wel heel rustig.

Rustig. We kunnen wel wat liefde gebruiken.

Ja, dat is waar. Maar goed.

Een paar leuke memes kunnen we wel even verplaatsen.

Ja, dat zou ik wel.

Dat doen jullie altijd heel goed, dus dank je wel. Dus kom voor de memes.

Ja, kom naar de Slack voor de memes.

Die je dan zelf moet posten.

Ja, dat is wel een goeie. Hé, dank je wel.

Dank je wel. Doei, doei, doei.