Een ETL-pipeline op GitHub, zonder platformfactuur

In een ander artikel schreef ik dat ik Fabric afraadde bij een kmo en dat we het opgelost hebben met een gehoste database en Python. Dat bleef te vaag. Hier staat hoe die keten er concreet uitziet.

De vier stukken

Een script dat data ophaalt bij de bron. Bij ons is dat Python dat via de API van het ERP de facturen, boekingen en analytische lijnen binnenhaalt.

Een database om het in te zetten. Wij gebruiken Neon, een gehoste PostgreSQL. Je maakt er in minuten een project aan en voor het volume van een kmo blijf je in het goedkope segment.

Een plek waar de verwerking gebeurt. Dat is SQL in diezelfde database: de ruwe tabellen omzetten naar feiten en dimensies waar een rapport mee overweg kan.

En iets dat het op tijd doet draaien. Daarvoor gebruiken wij GitHub Actions.

Power BI kijkt uiteindelijk naar de klaargezette tabellen in de database, in import-modus.

Waarom GitHub Actions het inplant

Dit is het stuk waar mensen verrast van opkijken, want GitHub kennen ze als een plek voor code, niet als een planner.

Maar een Action is gewoon een computer die op een afgesproken moment jouw script uitvoert. Je legt in een bestand vast wanneer hij moet draaien en wat hij moet doen. Je code staat er al, want je bewaart je scripts toch ergens. En de geheimen, je API-sleutels en je databankwachtwoord, zet je in de secrets van je repository. Die staan versleuteld, ze komen niet in je code terecht, en het script leest ze als omgevingsvariabele.

Dat laatste is belangrijker dan het klinkt. De meest voorkomende manier waarop een sleutel uitlekt, is dat iemand hem in een bestand zet dat later gedeeld wordt.

Voor een publieke repository is dit gratis. Voor een private zitten er minuten in je abonnement, en een ophaalscript dat een paar minuten per keer draait, blijft daar ruim binnen.

Wat je ervoor terugkrijgt

Een logboek van elke uitvoering. Je ziet wanneer hij draaide, hoe lang hij deed en wat er misging. Dat is meer inzicht dan de meeste mensen hebben in hun huidige exportproces.

Een verwittiging als het faalt. Dat is de belangrijkste functie van allemaal, want een koppeling die stil stopt is gevaarlijker dan geen koppeling. Je kijkt dan naar cijfers van vorige week in de veronderstelling dat ze van vandaag zijn.

En een geschiedenis van wijzigingen. Als je ophaalscript aangepast is en er klopt iets niet meer, kan je exact zien wat er wanneer veranderd is.

Waar het minder geschikt voor is

Eerlijk blijven, want dit is geen wondermiddel.

Het is geen realtime. Je draait op een schema, en als je op de minuut actueel moet zijn, heb je iets anders nodig.

Het is niet gemaakt voor heel zware verwerking. Een Action heeft beperkte capaciteit en een tijdslimiet per uitvoering. Voor een kmo met facturen en boekingen is dat ruim voldoende, voor miljoenen rijen per uur niet.

En er moet iemand zijn die er begrijpt wat er staat. Dat is de echte kost. Je ruilt een maandelijkse licentie voor een stuk eigen opzet dat onderhouden moet worden. Als er in je organisatie niemand is die dat kan en je wil er ook niemand voor inhuren, dan is een platform met een factuur misschien eerlijker.

Een detail dat je zal tegenkomen

Plan je uitvoering niet op het uur. Iedereen doet dat, waardoor de wachtrij op dat moment het langst is en je taak later start dan je denkt. Zet hem op een willekeurige minuut.

En vergeet je planning niet uit te zetten als de bron verdwijnt. Ik heb een keten laten draaien tegen een testomgeving die op een afgesproken datum zou verdwijnen, en die uitschakeling staat sindsdien als taak in mijn eigen lijst. Een pipeline die tegen niets draait, stuurt elke dag keurig een foutmelding tot iemand er genoeg van heeft.

De stelling

De vraag is niet of je een dataplatform kan betalen. De vraag is of je een dataplatform nodig hebt voordat je weet hoeveel data je werkelijk verwerkt. Bij de meeste kmo's is het antwoord nee, en dan is de goedkope weg ook de snelste.