Best Practices voor Data Engineering
Vijf dingen waar ik steeds op terugkom. Geen ervan is slim bedacht, en dat is min of meer het punt.
1. Bouw voor volgend jaar, niet voor het volgende decennium
Kies het eenvoudigste dat de komende twaalf maanden overleeft. Over jaar drie zit je er toch naast, en de architectuur die je daarvoor bouwde staat er dan nog steeds, heeft nog steeds upgrades nodig en is eigendom van iemand die er niet bij was toen je koos. Het meeste dat ik heb moeten ontwarren was toegevoegd voor een schaal die nooit kwam.
2. Meet de grenzen, niet alles
Je hebt geen metric per functie nodig. Je wilt weten, bij elke overgang waar data een systeemgrens passeert, hoeveel rijen erin gingen, hoeveel eruit kwamen en wanneer. Dat zijn drie getallen en een timestamp per stap, en daarmee beantwoord je de meeste is-het-stuk-of-gewoon-traag vragen voordat iemand een notebook opent.
3. Kwaliteitschecks horen in de pipeline
Een testsuite op zijn eigen schema vertelt je het probleem van gisteren. Zet de asserties in dezelfde run als de transformatie en laat ze die laten falen. Dat voelt een week lang agressief, en daarna stuur je geen slechte data meer stroomafwaarts, wat precies de ruil was die je wilde.
4. Schrijf op waarom, niet wat
De code zegt wat. Nooit waarom de valutaconversie vóór de dedup gebeurt, of waarom die ene bron 48 uur krijgt voor late data en de rest niet. Dat wordt één keer besloten, in een chatdraad, en leeft daarna in iemands hoofd tot die persoon vertrekt. Drie regels commentaar op het rare stuk zijn meer waard dan een wiki die niemand opent.
5. Maak de loop kort genoeg om te gebruiken
Als een wijziging controleren betekent wachten op de nachtelijke run, stoppen mensen met controleren. Gesamplede data, een lokale runner, wat het ook onder de tien minuten krijgt. De teams die ik het snelst zag verbeteren hadden niet de beste documentatie. Zij konden iets uitproberen vóór de lunch.