Menu
In de eerste 20 jaar van de carrière van Marcel-Jan Krijgsman werkte hij voornamelijk als database beheerder. Testen was iets wat testers of ontwikkelaars deden. Vijf jaar geleden werd hij data engineer en daarmee, zo begon hij langzaam meer en meer te beseffen, ook ontwikkelaar. Van data pipelines.
Wat er gebeurt als je niet test, daar kwam hij al gauw achter. Gelukkig nog in de testomgeving. Tijd om zichzelf in te lezen in het onderwerp. Hoe doe je dat, een data pipeline testen? Hoe meer hij blogs en boeken erover las, hoe meer hij in de “rabbit hole” raakte. Helemaal toen hij besloot het onderwerp ook mee te nemen in de Certified Data Engineering Professional opleiding van de DIKW Academy.
Veel ontwikkelaars schrijven hun code, en kijken of die werkt. Als test is dat niet voldoende. Je moet er rekening mee houden dat een hoop fout kan gaan wanneer je data pipelines maakt. Bijvoorbeeld omdat de data die je wilt lezen er niet is, of de job waar je van afhankelijk bent niet klaar is wanneer je het verwacht of dat het systeem waarmee je verbinding maakt niet beschikbaar is. Op data niveau kan er ook heel veel fout gaan. Gebruikers kunnen verkeerde data ingevoerd hebben, data is niet juist gelabeld (verkeerde kolomnamen) of komt dubbel voor. Met andere woorden: verwacht het onverwachte!
Zelf kwam hij onlangs een typisch onverwacht probleem tegen: onze batch job deed er opeens erg lang over. Wat was er aan de hand? Ging de verwerking ineens zo traag? Was er zoveel meer data te verwerken? Geen van dat alles: de code checkte aan het einde van een data lake uitvraag het aantal gelezen rijen. Dat haalde het script uit een query rapportje dat Apache Hive, de big data warehouse software, gaf. En toen gaf Hive opeens geen query rapport meer. Marcel-Jan wist ook niet dat dat een optie was.
Dus besloot het script dat het aantal rijen NULL was. Een lege waarde. De database waarin het script die status moest bijhouden, accepteerde geen NULL als aantal. Dus het script kon nooit de status op COMPLETED zetten. En dus bleef het script doorlopen en steeds weer proberen die status bij te werken. Wat nooit lukte. En Marcel-Jan en zijn team maar wachten.
Goed nadenken over testen had dit probleem kunnen voorkomen. Precies ook waarom zijn interesse voor dit onderwerp groeide. Kennelijk moet je niet alleen checken of je script in “goede tijden” de juiste data levert, maar ook checken of de systemen waarvan je afhankelijk bent de juiste input leveren. Zoals de test “heb ik eigenlijk wel een Hive query rapport?” of “Is het aantal gelezen rijen wel een getal?”
Dat soort vragen kun je checken met zogenaamde “unit tests.” Bij unit tests check je of een klein stuk code, bijvoorbeeld een eenvoudige Python functie, op de juiste manier werkt. Het testen van de juiste dingen is een kunst op zich. Niet voor niets zijn er over dit onderwerp boeken geschreven. In Python kun je gebruik maken van het keyword assert. Met assert kun je checken dat als je bepaalde input in je code stopt, of er dan het verwachte uit komt. Bijvoorbeeld: als je in een optel-functie de input 2 en 2 invoert, komt er dan 4 uit als output? Dat is een test.
Al zoekend en lezend kwam Marcel-Jan er ook achter dat er een methodologie bestaat die Test Driven Development (TDD) heet. Bij TDD begin je niet eerst je functionaliteit te coderen. Nee, je begint eerst een test te schrijven voor wat je wilt bouwen. Die run je en de test faalt. Dat is verwacht. Je hebt de functionaliteit immers nog niet geschreven. Dat is de volgende stap. Daarna run je je test opnieuw en als het goed is, is de test nu succesvol. Dit lijkt wat omslachtig, maar TDD voorkomt op deze manier al vroeg allerlei bugs, die later wellicht pas in productie opduiken.
Als je die tests eenmaal geschreven hebt, is er geen enkele reden waarom je die slechts eenmalig met de hand moet draaien. Diverse Continuous Integration toepassingen kunnen alle tests uitvoeren bij elke wijziging aan de data pipeline of zelfs de hele code base van een organisatie. En dan wordt het interessant. Want dat betekent opnieuw dat je heel snelle feedback krijgt of je update van de code een probleem veroorzaakt. Een probleem dat anders wellicht pas veel later zou kunnen opduiken.
Die Continuous Integration software kan trouwens daar nog allerlei andere tests aan toevoegen, zoals controle op veel voorkomende bugs, security issues, afnemen van de performance en zelfs de stijl van programmeren.
Continuous Integration is overigens meer dan tooling alleen. Het is ook een verandering van werkwijze. De ontwikkelaars worden aangespoord om regelmatig hun aanpassingen aan de code, hoe klein ook, te uploaden naar de code repository. Liefst dagelijks of vaker. Ook dit zorgt weer voor kortere feedback loops.
En het zijn precies dit soort ontwikkelingen die moderne organisaties zoveel wendbaarder maakt. Waardoor ze supersnel bugs kunnen oplossen en nieuwe functionaliteit kunnen uitrollen, ook in data pipelines. Wat weer resulteert in tevreden klanten. En wie had nou gedacht dat dat veroorzaakt zou worden door een saai onderwerp als testen?
DIKW Intelligence
Wattbaan 1
3439 ML Nieuwegein
