Hos altfor mange datateam ser ingestionlaget omtrent slik ut: én notebook per datasett, én pipeline per kilde, og en vedlikeholdsbyrde som vokser proporsjonalt med antall integrasjoner. Etter hvert som teamet skalerer, er det ikke uvanlig å ha 30–50 notebooks som er 90% identiske, men med noe ulike løsninger ut ifra hvem på teamet som bygde integrasjonen. Her er også servernavn, API-endepunkter, tabeller og SQL-spørringer hardkodet inn slik at det er vanskelig å få oversikt over ulike parameterne som styrer den faktiske integrasjonen. Når noe feiler i produksjon, og du som Data Engineer må inn i koden for å debugge blir standardspørsmålet: "Okey, hvordan var det vi hadde løst det her?". Dette skaper store kognitive laster vi gjerne kunne vært foruten.

Når man jobber med data som endrer seg over tid, er det helt naturlig å ville beholde historikken. Dette er kjernen i det som kalles Slowly Changing Dimensions type 2 (SCD2), som er en måte å sørge for at vi alltid kan se hvordan en rad så ut før, samtidig som den oppdateres med ny informasjon.

dbt (data build tool) er et verktøy som virkelig har skutt fart de siste årene, og det er ikke rart. Endelig har vi fått et verktøy som gjør det enkelt å versjonere, dokumentere, teste og release data ved hjelp av SQL. Eller?