Een datapipeline lijkt vaak eenvoudig zolang hij net gedraaid heeft. Een bronbestand komt binnen, een notebook loopt, een tabel wordt bijgewerkt en een dashboard ververst. Voor de gebruiker is het resultaat zichtbaar en voor het engineeringteam voelt de run afgerond.
Pas later blijkt wat er ontbreekt. Welke levering lag precies onder een publicatie? Welke stap heeft de data aangeraakt? Welke controles zijn uitgevoerd, onder welk beleid, en wat was de uitkomst? Op dat moment blijken veel pipelines wel data te produceren, maar geen blijvend geheugen over hoe die data tot stand is gekomen.
Precies daar begint het nut van Latero Runtime.
Een pipeline levert twee producten op
Een datapipeline levert niet alleen data op. Hij levert ook kennis op over die data:
- welk bronbestand is gebruikt
- hoe de verwerking is verlopen
- welke controles zijn uitgevoerd
- hoe bron en doel met elkaar verbonden zijn
Die tweede opbrengst wordt in veel omgevingen niet structureel opgeslagen. Daardoor is reproduceerbaarheid fragiel, audittrail handmatig en bestuurlijke uitleg afhankelijk van logs, screenshots en herinneringen.
Waarom de architectuur ertoe doet
Dat probleem los je niet op met losse logging. Het vraagt om een architectuur waarin metadata net zo vanzelfsprekend wordt geproduceerd als de data zelf.
In een Databricks-omgeving is de medallion-opzet daarvoor een logisch anker. De keten van landing naar raw, bronze, silver en gold is namelijk niet alleen een verwerkingspad, maar ook een reeks risicomomenten.
Elke overgang stelt een andere vraag:
- landing naar raw: is het aangeleverde bestand volledig en ongewijzigd overgenomen?
- raw naar bronze: klopt de structuur met het contract?
- bronze naar silver: zijn mappings, typen en kwaliteitsregels consistent toegepast?
- silver naar gold: is de publicatielaag herleidbaar tot de onderliggende bron en transformaties?
Zonder vastlegging per overgang blijft de architectuur een plaatje. Met vastlegging per overgang wordt het een controleerbaar systeem.
Drie soorten bewijs
Latero Runtime behandelt metadata daarom als een eerste-klas product en legt drie soorten bewijs vast.
Uitvoeringsmetadata legt per stap vast wat er draaide, wanneer, met welke duur, in welke jobcontext en met welk resultaat.
Kwaliteitsmetadata legt vast welke controles zijn uitgevoerd, onder welk beleid, met welke severity en met welke uitkomst.
Lineage-metadata legt de herkomstketen vast van bestand naar tabel en van attribuut naar attribuut.
Samen vormen die drie registraties het geheugen van de pipeline.
Hoe Latero Runtime dit in de keten plaatst
Latero Runtime schrijft die registraties niet als los nagesprek, maar tijdens de uitvoering van de stap zelf. In de Databricks-referentie-implementatie gebeurt dat via Pipeline.step(...), met writes naar:
workspace.meta.runsworkspace.meta.dq_resultsworkspace.meta.lineage_datasetworkspace.meta.lineage_attribute
Latero Control leest die registraties vervolgens als consumptielaag uit. Daarmee blijft de scheiding helder: Latero Runtime produceert het bewijs, Latero Control maakt het leesbaar voor observability, governance en uitleg.
Wat dit in de praktijk oplost
Drie maanden later hoeft niemand meer te reconstrueren op basis van toeval. Dan is zichtbaar welke levering onder een publicatie lag, welke checks zijn geslaagd of gefaald, welke stap de data heeft aangepast en hoe een kolom in de eindlaag is opgebouwd.
Dat is geen extra luxe. Voor serieuze datapijplijnen hoort dit bij het product.