Data-ingestie (data ingestion)

Wat is data-ingestie?

Data-ingestie is het proces waarbij je data verzamelt uit de bronnen en binnenbrengt in een systeem waar je ze kan opslaan, bewerken of analyseren. De bronnen zijn overal waar de data al leeft: een applicatiedatabase, een SaaS-tool met een API, logbestanden, sensoren, een message queue, een plat bestand dat op een server wordt gedropt. De bestemming is meestal een data lake, een data warehouse of een lakehouse.

Het is de eerste stap van zowat elke datapijplijn. Niets verderop, geen transformatie, geen rapport, geen model, gebeurt voor de data is binnengehaald. Loopt de ingestie te laat of onvolledig, dan erft alles wat erbovenop staat het probleem.

Ingestie is enkel het verplaatsen en laten landen van data. Het opschonen en hervormen is een aparte klus. Dat onderscheid telt, want hoe en wanneer je opschoont, hangt af van of je in batches binnenhaalt of als een doorlopende stroom.

Batch versus streaming

Er zijn twee brede manieren om data binnen te brengen, en die keuze bepaalt het grootste deel van het ontwerp.

Batch-ingestie verzamelt data over een periode en laadt ze in één keer. Een nachtelijke taak haalt om 2 uur de bestellingen van de dag op. Elk uur landt er een bestand dat wordt opgepikt. Batch is eenvoudiger te bouwen en te draaien, en goedkoper voor hetzelfde volume, dus dekt het de meeste rapporteringsbehoeften. De keerzijde is versheid: het warehouse is maar zo actueel als de laatste run.

Streaming-ingestie brengt data binnen gebeurtenis per gebeurtenis, terwijl ze ontstaat, met een vertraging van seconden of minder. Een betaling, een klik, een sensormeting stroomt binnen op het moment zelf. Dat is wat je nodig hebt voor live dashboards, fraudecontroles of waarschuwingen. De prijs is complexiteit: je draait een systeem dat altijd aanstaat en pieken, herhaalpogingen en gebeurtenissen in de verkeerde volgorde moet aankunnen.

Een ruwe leidraad: is een rapport van enkele uren oud prima, dan is batch meestal het juiste en goedkopere antwoord. Grijp pas naar streaming als de waarde van de data snel daalt met de ouderdom.

Waar ingestie in de pijplijn zit

Ingestie is de E in ETL en ELT, het extract-en-load-deel voor er iets getransformeerd wordt. De twee patronen verschillen in wanneer het opschonen gebeurt.

Bij de klassieke ETL wordt data onderweg getransformeerd, zodat ze al in vorm binnenkomt. In de modernere ELT-aanpak wordt ruwe data eerst binnengehaald en pas later in het warehouse getransformeerd, met de rekenkracht van dat warehouse. ELT is gangbaar geworden omdat cloud-warehouses en lakehouses goedkoop zijn om in op te slaan en snel genoeg om ter plekke te transformeren. Hoe dan ook is ingestie de stap die de ruwe data laat landen.

Hoe change data capture past

Een volledige brontabel bij elke run overkopiëren is verspilling zodra die tabel groot wordt. Change data capture, of CDC, is de techniek die enkel binnenhaalt wat veranderde: de toevoegingen, aanpassingen en verwijderingen sinds de vorige lezing, meestal door het transactielogboek van de brondatabase te lezen.

CDC is wat ingestie bijna in real time maakt vanuit een operationele database. In plaats van een nachtelijke volledige kopie van een tabel met een miljoen rijen, stream je de paar duizend rijen die echt veranderden. Het is een gangbare brug tussen een live applicatiedatabase en een analytisch systeem, en tools zoals Debezium zijn er rond gebouwd.

Waar moet je op letten bij data-ingestie

Schema drift breekt dingen stilletjes. Voegt een bron een kolom toe, hernoemt of hertypeert er een, dan kan een ingestietaak vastlopen of, erger, gewoon doordraaien en foute data laden. Volg de bronschema's op en beslis vooraf hoe je met veranderingen omgaat.

Idempotentie en duplicaten. Een herhaalde of overlappende laadopdracht kan dezelfde records twee keer binnenbrengen. Ingestie heeft een manier nodig om dezelfde batch opnieuw te laden zonder duplicaten te maken, vaak via een upsert op een stabiele sleutel.

API-limieten op SaaS-bronnen. Data uit een SaaS-tool trekken betekent leven met haar rate limits en pagineringsregels. Een naïeve volledige ophaling kan afgeknepen worden of aflopen. Voorzie incrementele laadopdrachten en een backoff.

Verwachtingen rond versheid. Gebruikers gaan ervan uit dat het dashboard actueel is. Ververst het maar één keer per nacht, zeg dat dan. Verkeerde verwachtingen over hoe vers de data is, wekken meer wantrouwen dan de vertraging zelf.